codestrike

codestrike is an open-source, AI-driven pull request review tool written in Go. Given a pull request, it runs an LLM-powered review over the diff, and posts the results back as a single comment.

Important

Public Preview: This project is currently in public preview and under active development. Features and functionality may change before the stable 1.0 release. While we encourage exploration and testing, please avoid production deployments. We welcome your feedback through GitHub Issues to help shape the final release.

Prerequisites

• Go 1.25+
• A GitHub personal access token with repo scope

Getting Started

1. Clone the repository

git clone https://github.com/CrowdStrike/codestrike.git
cd codestrike

2. Configure environment

Copy the example .env file and fill in your secrets:

cp .env.example .env

Required variables:

Variable	Description
GITHUB_TOKEN	GitHub personal access token with repo scope
OPEN_AI_BASE_URL	OpenAI-compatible API base URL (default: https://api.openai.com/v1)
OPEN_AI_KEY	OpenAI API key (or compatible provider)
LOG_LEVEL	Log level: debug, info, warn, error (default: info)
HTTP_LISTENING_PORT	Port for codestrike serve (default: 8080)

3. Review application config

Application settings (system prompt, tone, guardrails) are loaded from a YAML file. By default, codestrike looks for this file at the OS-specific user config directory under a codestrike/ subdirectory:

OS	Default path
Linux	$XDG_CONFIG_HOME/codestrike/default.yaml (falls back to ~/.config/codestrike/default.yaml)
macOS	~/Library/Application Support/codestrike/default.yaml
Windows	%AppData%\codestrike\default.yaml

Install the default configuration, prompts, and tones from the files embedded in the binary:

codestrike init

Existing files are preserved. To overwrite the bundled files with the versions from the current binary:

codestrike init --force

If no file exists at the default path, codestrike exits with an error explaining the path it looked for. Use --config <path> to point at a config file anywhere else instead.

You can customize the system prompt, tone, guardrails, context files, and token budget:

github:
  base_url: https://api.github.com

review:
  # Use inline text, or a file name from prompts/ or tones/ next to this file.
  system_prompt: default
  tone: diplomatic
  context_files:
    - CLAUDE.md
  guardrails:
    max_patch_size_bytes: 1048576
    ignored_paths:
      - vendor/
      - node_modules/
      - .git/
      - "*.lock"
      - "*.sum"
      - "*.min.js"
      - "*.min.css"
  context:
    max_input_ratio: 0.75
    reserved_output_tokens: 4096
    tokenizer_model: o200k_base
    model_limits:
      gpt-4o:
        context_window: 128000
        max_output_tokens: 16384
      claude-sonnet-4-20250514:
        context_window: 200000
        max_output_tokens: 8192

Section	Description
context_files	Project files (e.g., CLAUDE.md) loaded as additional context for the reviewer
ignored_paths	Directory prefixes and glob patterns. Globs are matched against both complete repository paths and file names at any depth
context.max_input_ratio	Maximum fraction of the model's context window used for input (default: 0.75)
context.reserved_output_tokens	Tokens reserved for the model's response (default: 4096)
context.tokenizer_model	Tiktoken encoding used for token counting (default: o200k_base)
context.model_limits	Per-model context window and max output token settings
context.enable_cursor_rules	When true, also read AGENTS.md and .cursor/rules/*.mdc (rules with alwaysApply: true, or no globs/alwaysApply frontmatter at all) from the reviewed repo as additional project context. Default: false

4. Build

make build

5. Run a review

./codestrike review https://github.com/{owner}/{repo}/pull/{number}

Or point at a specific config file with --config:

./codestrike review --config /path/to/default.yaml https://github.com/{owner}/{repo}/pull/{number}

Flags

Flag	Description
--config <path>	Path to a YAML config file
--full-context	Fetch full file content for richer reviews (slower, uses more tokens)
--persona <name>	Select a review persona — maps to a prompt file in prompts/ (e.g., security, performance)

Example with persona and full context:

./codestrike review --persona security --full-context https://github.com/{owner}/{repo}/pull/{number}

6. Run as a service

codestrike can also run as a persistent HTTP service, allowing external systems (CI pipelines, webhooks, chatbots) to trigger reviews via API:

./codestrike serve

By default the server listens on :8080. Override with --addr or the HTTP_LISTENING_PORT environment variable:

./codestrike serve --addr :9090

Endpoints

Method	Path	Description
GET	/api/v1/healthz	Health check — returns {"status":"ok"}
POST	/api/v1/review	Run an AI review on a pull request

Graceful shutdown

The server shuts down cleanly on SIGINT or SIGTERM, draining in-flight requests for up to 10 seconds.

Chain-of-thought reasoning

codestrike uses chain-of-thought prompting: the LLM is asked to reason step-by-step about each file's changes before producing review comments. The reasoning block is stripped from the final output automatically.

Cursor Integration

codestrike ships as a Cursor Plugin (plugin.json + skills/pr-review/SKILL.md) so you can ask Cursor's Agent to review a pull request directly from chat. The skill shells out to the codestrike review CLI — there is no MCP server yet, so codestrike must be built and on PATH.

To try it locally:

go install ./cmd/codestrike
ln -s "$(pwd)" ~/.cursor/plugins/local/codestrike

Reload Cursor (Developer: Reload Window) and confirm pr-review appears under Customize → Skills. codestrike's own review pipeline can also read Cursor-native project instructions (AGENTS.md, .cursor/rules/*.mdc) from the reviewed repo — see context.enable_cursor_rules above. See docs/cursor-integration.md for details and planned follow-up work (an MCP server).

Development

Common tasks are wrapped in the Makefile; run make help to list all targets.

Target	Description
make build	Build the codestrike binary for the host platform
make run	Run codestrike from source
make test	Run unit tests with the race detector and coverage
make fmt	Run go fmt against the code
make vet	Run go vet against the code
make lint	Run golangci-lint (downloaded locally if needed)
make lint-fix	Run golangci-lint and apply automatic fixes
make snapshot	Build unpublished per-platform binaries into dist/ via GoReleaser
make clean	Remove build, packaging, and tool artifacts

Continuous Integration

Pull requests and pushes to main run the ci workflow (.github/workflows/ci.yml), which verifies modules are tidy, checks formatting, and runs make vet, make test, and make build, plus a lint step via golangci-lint-action.

Tagged pushes (v*) run the release workflow (.github/workflows/release.yml), which re-runs ci, then builds and publishes release artifacts with GoReleaser and generates a changelog.

Changes to .goreleaser.yaml are validated by the goreleaser-check workflow (.github/workflows/goreleaser-check.yml), which checks the GoReleaser config and builds a snapshot release.