mirror of
https://github.com/trailofbits/claude-code-config
synced 2026-06-21 14:11:43 +00:00
Merge pull request #27 from trailofbits/update-commands
Update commands and add merge-dependabot
This commit is contained in:
Dan Guido
@@ -508,17 +508,22 @@ Custom slash commands are markdown files that define parameterized procedures. T
|
||||
mkdir -p ~/.claude/commands
|
||||
cp commands/review-pr.md ~/.claude/commands/
|
||||
cp commands/fix-issue.md ~/.claude/commands/
|
||||
cp commands/merge-dependabot.md ~/.claude/commands/
|
||||
```
|
||||
|
||||
### Review PR
|
||||
|
||||
[`commands/review-pr.md`](commands/review-pr.md) -- Reviews a GitHub PR with parallel agents, fixes findings, and pushes. Invoke with `/review-pr 456` where `456` is the PR number.
|
||||
[`commands/review-pr.md`](commands/review-pr.md) -- Reviews a GitHub PR with parallel agents (pr-review-toolkit, Codex, Gemini), fixes findings, and pushes. Invoke with `/review-pr 456` where `456` is the PR number.
|
||||
|
||||
### Fix Issue
|
||||
|
||||
[`commands/fix-issue.md`](commands/fix-issue.md) -- Takes a GitHub issue and fully autonomously completes it -- plans, implements, tests, creates a PR, self-reviews with parallel agents, fixes its own findings, and comments on the issue when done. Invoke with `/fix-issue 123` where `123` is the issue number.
|
||||
[`commands/fix-issue.md`](commands/fix-issue.md) -- Takes a GitHub issue and fully autonomously completes it -- researches, plans, implements, tests, creates a PR, self-reviews with parallel agents, fixes its own findings, and comments on the issue when done. Invoke with `/fix-issue 123` where `123` is the issue number.
|
||||
|
||||
Once a workflow is a command, it's not just faster for you -- it's something an agent can run too. You can point `/fix-issue` at 50 issues in parallel across worktrees, run `/review-pr` on every open PR in a repo, or schedule either as part of CI. Commands turn manual workflows into scalable operations.
|
||||
### Merge Dependabot
|
||||
|
||||
[`commands/merge-dependabot.md`](commands/merge-dependabot.md) -- Evaluates and merges open dependabot PRs for a repo. Audits dependabot config, builds a transitive dependency map, batches overlapping PRs, evaluates each in parallel (build, test, matrix gap analysis), and merges passing PRs sequentially with post-merge re-testing. Invoke with `/merge-dependabot trailofbits/algo`.
|
||||
|
||||
Once a workflow is a command, it's not just faster for you -- it's something an agent can run too. You can point `/fix-issue` at 50 issues in parallel across worktrees, run `/review-pr` on every open PR in a repo, run `/merge-dependabot` across all your repos, or schedule any of them as part of CI. Commands turn manual workflows into scalable operations.
|
||||
|
||||
## Writing Skills and Agents
|
||||
|
||||
|
||||
+185
-57
@@ -1,18 +1,43 @@
|
||||
# Fix GitHub Issue
|
||||
|
||||
@description End-to-end: plan, implement, test, PR, review, fix findings, and comment on a GitHub issue.
|
||||
@description End-to-end: plan, implement, test, review, fix, push, and PR for a GitHub issue.
|
||||
@arguments $ISSUE_NUMBER: GitHub issue number to fix
|
||||
|
||||
Read GitHub Issue #$ISSUE_NUMBER thoroughly. Understand the full
|
||||
context: problem description, acceptance criteria, linked PRs,
|
||||
and any discussion. Follow linked issues, referenced PRs, and
|
||||
external documentation to build complete understanding before
|
||||
planning.
|
||||
Read GitHub Issue #$ISSUE_NUMBER from the canonical repo
|
||||
(`gh issue view $ISSUE_NUMBER --repo <owner/name>`) thoroughly.
|
||||
Understand the full context: problem description, acceptance
|
||||
criteria, linked PRs, and any discussion. Follow linked issues,
|
||||
referenced PRs, and external documentation to build complete
|
||||
understanding before planning.
|
||||
|
||||
Detect the upstream repository: if a git remote named `upstream`
|
||||
exists, use it as the canonical repo (fetch from it, base branches
|
||||
on it, and submit PRs to it). Otherwise, fall back to `origin`.
|
||||
Resolve the canonical repo's `owner/name` (e.g. from `git remote
|
||||
get-url upstream`) and store it — use `--repo <owner/name>` on
|
||||
every `gh` command (issue views, PR creation, issue comments) to
|
||||
ensure they target the correct repository. Run
|
||||
`git fetch <upstream-remote>` to ensure you are working with
|
||||
up-to-date code.
|
||||
|
||||
Execute every step below sequentially. Do not stop or ask for
|
||||
confirmation at any step.
|
||||
|
||||
## 1. Plan
|
||||
## 1. Research (if needed)
|
||||
|
||||
Before planning, determine if the issue requires external context
|
||||
you don't already have — unfamiliar APIs, protocols, libraries,
|
||||
error messages, or domain-specific concepts. If so, use Exa
|
||||
(`mcp__exa__web_search_exa`) to search for:
|
||||
|
||||
- Official documentation for referenced libraries or APIs
|
||||
- Known solutions for the error messages or symptoms described
|
||||
- Implementation patterns used by similar projects
|
||||
|
||||
Skip this step for straightforward bugs where the fix is clear
|
||||
from the codebase alone.
|
||||
|
||||
## 2. Plan
|
||||
|
||||
Write a detailed implementation plan to `plan-issue-$ISSUE_NUMBER.md`
|
||||
in the repo root. The plan must:
|
||||
@@ -23,37 +48,162 @@ in the repo root. The plan must:
|
||||
- Call out risks or open questions
|
||||
- Reference relevant code paths by file:line
|
||||
|
||||
## 2. Implement
|
||||
## 3. Create branch
|
||||
|
||||
Implement the plan across all necessary files. Follow the
|
||||
project's CLAUDE.md standards. Keep changes minimal and focused
|
||||
on the issue requirements -- no speculative features.
|
||||
|
||||
## 3. Build, test, lint
|
||||
|
||||
Run the project's full quality pipeline in this order:
|
||||
|
||||
1. Build (compile/bundle if the project has a build step)
|
||||
2. Run the full test suite -- iterate on failures until green
|
||||
3. Add new tests for the changed behavior
|
||||
4. Run linting, formatting, and type-checking -- fix any issues
|
||||
|
||||
Refer to the project's CLAUDE.md or package.json/Makefile/etc.
|
||||
for the correct commands.
|
||||
|
||||
## 4. Branch, commit, and push
|
||||
Create the working branch before writing any code so changes are
|
||||
never left uncommitted on main.
|
||||
|
||||
- Determine the branch prefix from the issue type: `fix/` for
|
||||
bugs, `feat/` for features, `refactor/` for refactors, `docs/`
|
||||
for documentation. When ambiguous, use `fix/`.
|
||||
- Create a branch named `{prefix}issue-$ISSUE_NUMBER`
|
||||
- Delete the plan file (`plan-issue-$ISSUE_NUMBER.md`) -- it was a
|
||||
- Create a branch named `{prefix}issue-$ISSUE_NUMBER` based on
|
||||
the upstream remote's main branch (e.g. `upstream/main` if the
|
||||
`upstream` remote exists, otherwise `origin/main`)
|
||||
|
||||
## 4. Implement
|
||||
|
||||
Implement the plan across all necessary files. Follow the
|
||||
project's CLAUDE.md standards. Keep changes minimal and focused
|
||||
on the issue requirements — no speculative features.
|
||||
|
||||
Add tests for the changed behavior as part of implementation —
|
||||
tests are code, not a quality gate.
|
||||
|
||||
When stuck during implementation — a confusing error, an
|
||||
unfamiliar API, or an approach that isn't working — use Exa
|
||||
to search for solutions rather than spinning.
|
||||
|
||||
## 5. Build, test, lint
|
||||
|
||||
### 5a. Discover project checks (CI is the source of truth)
|
||||
|
||||
Before running anything, read the project's CI configuration to
|
||||
learn what the project *actually* runs. This takes priority over
|
||||
the fallback tables below.
|
||||
|
||||
1. **Read CI workflows.** Scan `.github/workflows/` for the main
|
||||
CI workflow (typically `ci.yml`, `test.yml`, or `build.yml`).
|
||||
Extract:
|
||||
- Test commands with feature flags (e.g.
|
||||
`cargo test --features foo,bar`)
|
||||
- Lint/format commands with non-default flags
|
||||
- Any step that runs a command then checks `git diff --exit-code`
|
||||
— these are **codegen sync checks** (schema generation,
|
||||
snapshot updates, help text, etc.). Record the command.
|
||||
- Docs/site build commands (e.g. `make site`, `mkdocs build`)
|
||||
2. **Read the Makefile** (if present). Cross-reference targets
|
||||
used in CI — these are the ones that matter.
|
||||
3. **Read CLAUDE.md** (if present at repo root or `.claude/`).
|
||||
It may define project-specific quality gates.
|
||||
|
||||
Store the discovered commands. They override the fallback table
|
||||
for any overlapping step.
|
||||
|
||||
### 5b. Run the quality pipeline
|
||||
|
||||
Detect the project language from manifest files (`Cargo.toml` →
|
||||
Rust, `pyproject.toml`/`setup.py` → Python, `package.json` →
|
||||
Node/TypeScript, `go.mod` → Go). A project may use multiple
|
||||
languages; run checks for each.
|
||||
|
||||
Run checks in this order. For each step, use the CI-discovered
|
||||
command if one was found; otherwise fall back to the default.
|
||||
|
||||
1. **Build** — compile or bundle
|
||||
2. **Test** — run the full test suite with the same feature flags
|
||||
CI uses. Iterate on failures until green.
|
||||
3. **Lint and format** — fix any issues
|
||||
4. **Extended checks** — per-language extras (see fallback table)
|
||||
5. **Codegen sync** — for every codegen check discovered in 5a,
|
||||
run the command and verify `git diff --exit-code`. If the diff
|
||||
is non-empty, the generated files are stale — regenerate and
|
||||
stage them.
|
||||
6. **Docs build** — if the changes touch documentation files and a
|
||||
docs build command exists, run it to verify the docs compile.
|
||||
|
||||
### Fallback defaults (when CI config is absent or unclear)
|
||||
|
||||
**Rust** (detected by `Cargo.toml`):
|
||||
|
||||
| step | command |
|
||||
|--------------|------------------------------------------------|
|
||||
| build | `cargo build` |
|
||||
| test | `cargo test` |
|
||||
| lint | `cargo clippy -- --deny warnings` |
|
||||
| format | `cargo fmt --check` |
|
||||
| supply chain | `cargo deny check` (if `deny.toml` exists) |
|
||||
| careful | `cargo careful test` (if `cargo-careful` installed) |
|
||||
|
||||
**Python** (detected by `pyproject.toml` or `setup.py`):
|
||||
|
||||
| step | command |
|
||||
|--------------|------------------------------------------------|
|
||||
| test | `pytest -q` |
|
||||
| lint | `ruff check` |
|
||||
| format | `ruff format --check` |
|
||||
| types | `ty check` (or `mypy` if configured) |
|
||||
| supply chain | `pip-audit` |
|
||||
|
||||
**Node/TypeScript** (detected by `package.json`):
|
||||
|
||||
| step | command |
|
||||
|--------------|------------------------------------------------|
|
||||
| build | per project (`npm run build`, `tsc`, etc.) |
|
||||
| test | `vitest` (or project test script) |
|
||||
| lint | `oxlint` (or project lint script) |
|
||||
| format | `oxfmt --check` (or project format script) |
|
||||
| types | `tsc --noEmit` |
|
||||
| supply chain | `pnpm audit --audit-level=moderate` |
|
||||
|
||||
**Go** (detected by `go.mod`):
|
||||
|
||||
| step | command |
|
||||
|--------------|------------------------------------------------|
|
||||
| build | `go build ./...` |
|
||||
| test | `go test ./...` |
|
||||
| lint | `golangci-lint run` |
|
||||
| format | `gofmt -l .` |
|
||||
| vet | `go vet ./...` |
|
||||
|
||||
If a tool is not installed, skip it with a note rather than
|
||||
failing the pipeline.
|
||||
|
||||
## 6. Self-review
|
||||
|
||||
For docs-only changes, do a focused manual review (verify links,
|
||||
check prose accuracy, confirm rendering). For code changes, use
|
||||
`/pr-review-toolkit:review-pr` to run a deep review against the
|
||||
diff (compare working tree to the upstream main branch). Produce a
|
||||
list of findings ranked by severity (P1 = blocks merge,
|
||||
P2 = important, P3 = nice to have).
|
||||
|
||||
## 7. Fix findings
|
||||
|
||||
Address all P1–P3 findings. For each finding, either:
|
||||
|
||||
- **Fix it** — apply the change, or
|
||||
- **Dismiss it** — explain why it's a false positive or not worth
|
||||
the churn (e.g. a stylistic disagreement or an impossible edge
|
||||
case). Document the reasoning inline.
|
||||
|
||||
After addressing all findings, review your own fixes: read the
|
||||
diff of changes made in this step and verify each fix is correct,
|
||||
doesn't introduce new issues, and doesn't regress other parts of
|
||||
the implementation. If you spot a problem, fix it before
|
||||
proceeding.
|
||||
|
||||
Then re-run the full quality pipeline (build, test, lint). Iterate
|
||||
until clean.
|
||||
|
||||
## 8. Commit and push
|
||||
|
||||
- Delete the plan file (`plan-issue-$ISSUE_NUMBER.md`) — it was a
|
||||
working artifact and should not be committed
|
||||
- Commit all changes with a conventional commit message referencing
|
||||
the issue
|
||||
- Push the branch
|
||||
|
||||
## 5. Create PR
|
||||
## 9. Create PR
|
||||
|
||||
Create a PR with:
|
||||
|
||||
@@ -61,37 +211,15 @@ Create a PR with:
|
||||
- A description that maps changes back to the issue requirements
|
||||
- Link to the issue with "Closes #$ISSUE_NUMBER" (or "Refs" if it
|
||||
doesn't fully close it)
|
||||
- If an `upstream` remote exists, submit the PR to the upstream
|
||||
repo using `gh pr create --repo <upstream-owner/repo>`
|
||||
|
||||
## 6. Self-review
|
||||
## 10. Comment on issue
|
||||
|
||||
Use `/compound-engineering:workflows:review` to perform a full
|
||||
multi-agent code review of the PR. Produce a list of findings
|
||||
ranked by severity (P1 = blocks merge, P2 = important, P3 = nice
|
||||
to have).
|
||||
Post a summary comment on Issue #$ISSUE_NUMBER in the canonical
|
||||
repo (`gh issue comment $ISSUE_NUMBER --repo <owner/name>`)
|
||||
linking to the PR. Include:
|
||||
|
||||
## 7. Fix findings
|
||||
|
||||
Address all P1-P3 findings. For each finding, either:
|
||||
|
||||
- **Fix it** -- apply the change, or
|
||||
- **Dismiss it** -- explain why it's a false positive or not worth
|
||||
the churn (e.g. a stylistic disagreement or an impossible edge
|
||||
case). Document the reasoning inline.
|
||||
|
||||
After addressing all findings:
|
||||
|
||||
1. Re-run the full quality pipeline (build, test, lint)
|
||||
2. Commit the fixes as a separate commit (do not squash into the
|
||||
original -- preserve review history)
|
||||
3. Push the branch (regular push, not force-push)
|
||||
4. Delete any todo files in `todos/` that were created by the
|
||||
review and are now resolved
|
||||
|
||||
## 8. Comment on issue
|
||||
|
||||
Post a summary comment on Issue #$ISSUE_NUMBER linking to the PR.
|
||||
Include:
|
||||
|
||||
- What was implemented (1-3 bullet points)
|
||||
- What was implemented (1–3 bullet points)
|
||||
- Key design decisions
|
||||
- Link to the PR
|
||||
|
||||
@@ -0,0 +1,582 @@
|
||||
# Merge Dependabot PRs
|
||||
|
||||
@description Evaluate and merge dependabot PRs with parallel builds, dependency-aware batching, and transitive dep analysis.
|
||||
@arguments $REPO: GitHub org/repo (e.g., trailofbits/algo). $OPTIONS: Optional flags — "--skip-config-audit" skips Phase 0 (use in batch runs where config audit is a separate pass).
|
||||
|
||||
Clone $REPO if not already available locally:
|
||||
|
||||
```bash
|
||||
gh repo clone $REPO /tmp/depbot-eval-$(echo "$REPO" | tr '/' '-') -- --depth=50 2>/dev/null || \
|
||||
(cd /tmp/depbot-eval-$(echo "$REPO" | tr '/' '-') && git fetch origin)
|
||||
```
|
||||
|
||||
Work from `/tmp/depbot-eval-{repo-slug}` for all subsequent phases.
|
||||
|
||||
Execute every phase below sequentially. Do not stop or ask for
|
||||
confirmation at any phase.
|
||||
|
||||
## Turn Budget Management
|
||||
|
||||
If you are running as a background agent with a `max_turns` cap:
|
||||
|
||||
- **At 75% of turns used:** Stop launching new evaluations. Merge
|
||||
any PRs already evaluated as PASS. Skip Phase 5's detailed
|
||||
reports — print only the summary table.
|
||||
- **At 90% of turns used:** Immediately print whatever summary you
|
||||
have and stop. Do not start new evaluations or re-tests.
|
||||
- **Prioritize merging over analysis.** If you must choose between
|
||||
thorough analysis of the last PR and merging already-evaluated
|
||||
PASS PRs, merge first.
|
||||
|
||||
## Phase 0: Dependabot Config Audit
|
||||
|
||||
If `$OPTIONS` includes `--skip-config-audit`, skip this entire
|
||||
phase and proceed to Phase 1.
|
||||
|
||||
Detect all package ecosystems present in the repo by checking for
|
||||
these indicator files:
|
||||
|
||||
| Indicator file(s) | Ecosystem |
|
||||
|---|---|
|
||||
| `pyproject.toml` + `uv.lock` | `uv` |
|
||||
| `pyproject.toml` (no `uv.lock`), `requirements*.txt`, `setup.py`, `setup.cfg` | `pip` |
|
||||
| `Cargo.toml` | `cargo` |
|
||||
| `package.json` | `npm` |
|
||||
| `go.mod` | `gomod` |
|
||||
| `Gemfile` | `bundler` |
|
||||
| `Dockerfile`, `docker-compose.yml` | `docker` |
|
||||
| `.github/workflows/*.yml` | `github-actions` |
|
||||
| `composer.json` | `composer` |
|
||||
| `*.csproj`, `*.fsproj` | `nuget` |
|
||||
|
||||
Read `.github/dependabot.yml`. Verify all five conditions:
|
||||
|
||||
1. **Coverage** — every detected ecosystem has a corresponding
|
||||
`updates` entry with the correct `package-ecosystem` value and
|
||||
appropriate `directory` (usually `"/"`)
|
||||
2. **uv vs pip** — if a directory has both `pyproject.toml` and
|
||||
`uv.lock`, the ecosystem MUST be `uv`, not `pip`. The `pip`
|
||||
ecosystem does not update `uv.lock`, which causes PRs that
|
||||
modify `pyproject.toml` but leave `uv.lock` out of sync.
|
||||
If any entry uses `pip` where `uv` is correct, flag it for
|
||||
correction.
|
||||
3. **Schedule** — every entry has `schedule.interval: "weekly"`
|
||||
4. **Cooldown** — every entry has a `cooldown` block with
|
||||
`default-days: 7`. This prevents dependabot from flooding the
|
||||
PR queue with rapid re-attempts after a PR is closed or merged.
|
||||
5. **Grouped updates** — every entry has a `groups` key with at
|
||||
least one group using `patterns: ["*"]` or more specific
|
||||
grouping patterns
|
||||
|
||||
If the file is missing or any condition fails, create a corrective
|
||||
PR:
|
||||
|
||||
1. `git checkout -b fix/dependabot-config`
|
||||
2. Write or update `.github/dependabot.yml`. Every `updates` entry
|
||||
MUST include all four required blocks. Use this template for each
|
||||
ecosystem entry:
|
||||
|
||||
```yaml
|
||||
- package-ecosystem: "{ecosystem}"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
cooldown:
|
||||
default-days: 7
|
||||
groups:
|
||||
{ecosystem}-dependencies:
|
||||
patterns:
|
||||
- "*"
|
||||
```
|
||||
|
||||
When updating an existing file, preserve any extra fields already
|
||||
present (labels, reviewers, open-pull-requests-limit, etc.) and
|
||||
only add missing blocks.
|
||||
|
||||
3. `git commit -m "chore: update dependabot config for full coverage, weekly schedule, 7-day cooldown, and grouped updates"`
|
||||
4. `git push origin fix/dependabot-config`
|
||||
5. `gh pr create --repo $REPO --title "Update dependabot configuration" --body "Adds missing ecosystem coverage, enforces weekly schedule, 7-day cooldown, and grouped updates."`
|
||||
6. `git checkout main`
|
||||
|
||||
Continue to Phase 1 regardless — this PR is non-blocking.
|
||||
|
||||
## Phase 1: Discovery & Baseline
|
||||
|
||||
### 1a. Fetch dependabot PRs
|
||||
|
||||
```bash
|
||||
gh pr list --repo $REPO --author "app/dependabot" --state open \
|
||||
--json number,title,headRefName,labels,files,mergeable
|
||||
```
|
||||
|
||||
If zero PRs are returned, print "No open dependabot PRs for $REPO"
|
||||
and stop.
|
||||
|
||||
### 1b. Categorize PRs
|
||||
|
||||
For each PR, examine its changed files:
|
||||
|
||||
- **Actions dep** — all changed files are under `.github/workflows/`
|
||||
or `.github/actions/`
|
||||
- **Library dep** — everything else (lockfiles, manifests, version
|
||||
pins, dependency specification files)
|
||||
|
||||
Store the categorized list for later phases.
|
||||
|
||||
### 1c. Baseline build and test
|
||||
|
||||
Verify the main branch is healthy before evaluating any PR.
|
||||
|
||||
1. Check out the default branch: use whatever
|
||||
`gh repo view --repo $REPO --json defaultBranchRef` reports
|
||||
2. Discover the build system — follow the same discovery process
|
||||
described in Phase 3's subagent instructions (read CI workflows
|
||||
first, then Makefile, then language-specific defaults)
|
||||
3. Run the build command. If it fails, **stop the entire command**
|
||||
and report: "Main branch build is broken. Fix main before
|
||||
processing dependabot PRs." Include the error output.
|
||||
4. Run the test command. If tests fail, **stop the entire command**
|
||||
and report: "Main branch tests are failing. Fix main before
|
||||
processing dependabot PRs." Include which tests fail.
|
||||
5. Record the baseline:
|
||||
- Full dependency tree from lockfile(s) (`pip freeze`,
|
||||
`cargo tree`, `npm ls --all`, `go list -m all`, etc.)
|
||||
- List of passing tests
|
||||
- Build output summary
|
||||
|
||||
Store the baseline data — subagents need it for comparison.
|
||||
|
||||
## Phase 2: Dependency Graph Analysis
|
||||
|
||||
### 2a. Build the transitive dependency map
|
||||
|
||||
Parse the repo's lockfile(s) to understand the full dependency
|
||||
tree:
|
||||
|
||||
| Ecosystem | Lockfile | Tree command |
|
||||
|---|---|---|
|
||||
| uv | `uv.lock` | `uv pip freeze` (after `uv sync`) |
|
||||
| pip | `poetry.lock`, `requirements*.txt` | `pip freeze` |
|
||||
| cargo | `Cargo.lock` | `cargo tree` |
|
||||
| npm | `package-lock.json`, `pnpm-lock.yaml` | `npm ls --all` or `pnpm ls --depth=Infinity` |
|
||||
| gomod | `go.sum` | `go list -m all` |
|
||||
| bundler | `Gemfile.lock` | `bundle list` |
|
||||
|
||||
For each library dep PR, identify which direct dependency it bumps
|
||||
(from the PR title and changed files). Look up that package in the
|
||||
dependency tree to find all its transitive dependents and
|
||||
dependencies.
|
||||
|
||||
### 2b. Group overlapping PRs into batches
|
||||
|
||||
Two PRs overlap if:
|
||||
- PR A bumps package X, PR B bumps package Y, and X depends on Y
|
||||
(or Y depends on X) in the transitive tree
|
||||
- Both PRs modify the same lockfile section for shared transitive
|
||||
dependencies
|
||||
|
||||
Group overlapping PRs into **batches**. PRs with no overlaps
|
||||
remain **independent** work units.
|
||||
|
||||
Actions dep PRs are always independent work units — they don't
|
||||
interact with library dependency trees.
|
||||
|
||||
### 2c. Sort and queue
|
||||
|
||||
Sort work units in topological order — leaf dependencies first,
|
||||
core/shared dependencies last. This ensures earlier merges are
|
||||
less likely to affect later ones.
|
||||
|
||||
If there are more than 5 work units total, process in **waves
|
||||
of 5**. The first wave starts immediately; subsequent waves start
|
||||
after the previous wave completes.
|
||||
|
||||
Print the grouping plan before proceeding:
|
||||
- List each work unit (batch or independent)
|
||||
- Show which PRs are in each batch and why they were grouped
|
||||
- Show the evaluation order
|
||||
|
||||
## Phase 3: Parallel Evaluation
|
||||
|
||||
### 3a. Fetch PR branches
|
||||
|
||||
For each work unit, fetch the PR branch into the local repo:
|
||||
|
||||
```bash
|
||||
git fetch origin pull/{number}/head:pr-{number}
|
||||
```
|
||||
|
||||
Do NOT use `wt switch` — shallow clones do not support worktrees
|
||||
reliably. Use `git checkout` directly when evaluating each PR.
|
||||
|
||||
### 3b. Launch subagents
|
||||
|
||||
Launch up to 5 subagents in parallel using the Task tool. Each
|
||||
call must use:
|
||||
- `subagent_type: "general-purpose"`
|
||||
- The appropriate prompt below (library or actions)
|
||||
|
||||
Send all Task calls in a **single message** for parallel execution.
|
||||
If more than 5 work units, wait for the current wave to complete
|
||||
before launching the next.
|
||||
|
||||
Pass each subagent:
|
||||
- The repo directory path
|
||||
- The PR number(s) and title(s)
|
||||
- The baseline dependency tree from Phase 1
|
||||
- The repo's build and test commands discovered in Phase 1
|
||||
|
||||
### Subagent prompt: Library Dep Evaluation
|
||||
|
||||
Use this prompt for each library dep work unit.
|
||||
|
||||
---
|
||||
|
||||
You are evaluating dependabot PR(s) for merge safety. Work
|
||||
in the repo directory: {repo_path}
|
||||
|
||||
**Repo:** $REPO
|
||||
**PR(s) to evaluate:** {pr_numbers_and_titles}
|
||||
**Baseline dependency tree from main:**
|
||||
|
||||
```
|
||||
{baseline_dep_tree}
|
||||
```
|
||||
|
||||
**Build command:** {build_command}
|
||||
**Test command:** {test_command}
|
||||
|
||||
Execute every step. Do not skip steps. Do not ask for confirmation.
|
||||
|
||||
**STEP 1 — Checkout**
|
||||
|
||||
```bash
|
||||
cd {repo_path}
|
||||
git fetch origin pull/{number}/head:pr-{number}
|
||||
git checkout pr-{number}
|
||||
```
|
||||
|
||||
For batches (multiple PRs), create a temporary merge branch:
|
||||
|
||||
```bash
|
||||
cd {repo_path}
|
||||
git checkout -b test-batch-{batch_id} main
|
||||
git fetch origin pull/{pr1}/head:pr-{pr1}
|
||||
git fetch origin pull/{pr2}/head:pr-{pr2}
|
||||
git merge pr-{pr1} pr-{pr2} --no-edit
|
||||
```
|
||||
|
||||
If the merge has conflicts, report FAIL with the conflicting files
|
||||
and stop.
|
||||
|
||||
**STEP 2 — Transitive dependency analysis**
|
||||
|
||||
Generate the full dependency tree using the same command that
|
||||
produced the baseline. Compare against the baseline and report:
|
||||
|
||||
```
|
||||
DIRECT CHANGES:
|
||||
- {package}: {old_version} → {new_version}
|
||||
|
||||
TRANSITIVE CHANGES:
|
||||
- {package}: {old_version} → {new_version} (depended on by: {parent})
|
||||
|
||||
NEW TRANSITIVE DEPS:
|
||||
- {package} {version} (pulled in by: {parent})
|
||||
|
||||
REMOVED TRANSITIVE DEPS:
|
||||
- {package} {version}
|
||||
|
||||
FLAGS:
|
||||
- DOWNGRADE: {package} went from {higher} to {lower}
|
||||
- MAJOR BUMP: {package} crossed a major version boundary
|
||||
```
|
||||
|
||||
If there are zero flags and zero new/removed transitive deps,
|
||||
note "Clean transitive dependency change."
|
||||
|
||||
**STEP 3 — Build**
|
||||
|
||||
Run the build command: {build_command}
|
||||
|
||||
If the build command was not provided (blank), discover it:
|
||||
|
||||
1. Read `.github/workflows/` for build steps
|
||||
2. Check `Makefile` or `justfile` for a `build` target
|
||||
3. Language-specific defaults:
|
||||
|
||||
| Manifest | Default |
|
||||
|---|---|
|
||||
| `Cargo.toml` | `cargo build` |
|
||||
| `pyproject.toml` | `uv pip install -e ".[dev]"` |
|
||||
| `package.json` | `pnpm install && pnpm build` |
|
||||
| `go.mod` | `go build ./...` |
|
||||
| `Gemfile` | `bundle install` |
|
||||
|
||||
If the build fails, report FAIL with exact error output and stop.
|
||||
|
||||
**STEP 4 — Test**
|
||||
|
||||
Run the test command: {test_command}
|
||||
|
||||
If the test command was not provided (blank), discover it using the
|
||||
same approach as Step 3:
|
||||
|
||||
| Manifest | Default |
|
||||
|---|---|
|
||||
| `Cargo.toml` | `cargo test` |
|
||||
| `pyproject.toml` | `pytest -q` |
|
||||
| `package.json` | `pnpm test` |
|
||||
| `go.mod` | `go test ./...` |
|
||||
| `Gemfile` | `bundle exec rspec` or `bundle exec rake test` |
|
||||
|
||||
If tests fail, check whether the same tests also fail on the main
|
||||
branch baseline. Pre-existing failures do not count against this PR.
|
||||
|
||||
If there are new test failures (pass on main, fail on this PR),
|
||||
report FAIL with the failing test names and error output.
|
||||
|
||||
**STEP 5 — Build matrix gap analysis**
|
||||
|
||||
Read `.github/workflows/` for `strategy.matrix` blocks. For each
|
||||
matrix dimension, report what was tested locally vs. what only
|
||||
runs in CI:
|
||||
|
||||
| Dimension | Example values | Testable locally? |
|
||||
|---|---|---|
|
||||
| OS | ubuntu, macos, windows | Current OS only |
|
||||
| Language version | python 3.9-3.12 | Installed version only |
|
||||
| Dependency version | numpy 1.x, 2.x | PR's version only |
|
||||
|
||||
Report the matrix gaps and assess risk:
|
||||
- **HIGH risk:** The dependency is known to have version-specific
|
||||
behavior (e.g., numpy/scipy ABI, pytorch CUDA builds, native
|
||||
extensions) and CI tests versions we couldn't test locally
|
||||
- **LOW risk:** The matrix covers OS variants or formatting
|
||||
differences unlikely to be affected by a dependency bump
|
||||
|
||||
If there is no matrix strategy in CI, report "No CI matrix — single
|
||||
configuration build."
|
||||
|
||||
**STEP 6 — Verdict**
|
||||
|
||||
**PASS** — all conditions met:
|
||||
- Build succeeds
|
||||
- All tests pass (or only pre-existing failures)
|
||||
- No transitive dependency flags (downgrades, major bumps)
|
||||
- No high-risk matrix gaps
|
||||
|
||||
**WARN** — build and tests pass, but concerns exist:
|
||||
- New transitive dependencies introduced
|
||||
- Transitive dep crossed a major version boundary
|
||||
- High-risk matrix gaps
|
||||
- List each specific concern
|
||||
|
||||
**FAIL** — any of:
|
||||
- Build fails
|
||||
- New test failures
|
||||
- Merge conflicts
|
||||
|
||||
Format the final report:
|
||||
|
||||
```
|
||||
## Evaluation Report: PR #{number} — {title}
|
||||
|
||||
**Verdict: {PASS|WARN|FAIL}**
|
||||
|
||||
### Transitive Dependency Analysis
|
||||
{step 2 output}
|
||||
|
||||
### Build Result
|
||||
{pass/fail with output if failed}
|
||||
|
||||
### Test Result
|
||||
{pass/fail with details}
|
||||
|
||||
### Matrix Gap Analysis
|
||||
{step 5 output}
|
||||
|
||||
### Concerns
|
||||
{list of concerns, or "None"}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Subagent prompt: Actions Dep Evaluation
|
||||
|
||||
Use this prompt for each GitHub Actions version bump PR.
|
||||
|
||||
---
|
||||
|
||||
You are evaluating a GitHub Actions version bump for merge safety.
|
||||
Work in the repo directory: {repo_path}
|
||||
|
||||
**Repo:** $REPO
|
||||
**PR to evaluate:** #{number} — {title}
|
||||
|
||||
Execute every step.
|
||||
|
||||
**STEP 1 — Checkout**
|
||||
|
||||
```bash
|
||||
cd {repo_path}
|
||||
git fetch origin pull/{number}/head:pr-{number}
|
||||
git checkout pr-{number}
|
||||
```
|
||||
|
||||
**STEP 2 — Diff analysis**
|
||||
|
||||
Run `git diff main -- .github/` to see what changed. Identify:
|
||||
- Which action(s) were bumped
|
||||
- Old and new versions (or SHA pins)
|
||||
- Whether this is a patch, minor, or major version bump
|
||||
|
||||
For major version bumps, use Exa (`mcp__exa__web_search_exa`) to
|
||||
search for breaking changes:
|
||||
`{action_name} v{old_major} to v{new_major} migration breaking changes`
|
||||
|
||||
**STEP 3 — Workflow validation**
|
||||
|
||||
Run: `actionlint .github/workflows/`
|
||||
|
||||
If `actionlint` is not installed, note this and skip to Step 4.
|
||||
|
||||
Distinguish pre-existing errors (also present on main) from new
|
||||
errors introduced by the version bump. Only new errors count
|
||||
against this PR.
|
||||
|
||||
**STEP 4 — Pin verification**
|
||||
|
||||
Check every `uses:` line in changed workflow files. Verify the
|
||||
SHA-pin format:
|
||||
|
||||
```yaml
|
||||
# GOOD:
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
|
||||
|
||||
# BAD (tag only):
|
||||
uses: actions/checkout@v4
|
||||
|
||||
# BAD (SHA without version comment):
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
```
|
||||
|
||||
Flag tag-only references as a WARN concern (not FAIL).
|
||||
|
||||
**STEP 5 — Verdict**
|
||||
|
||||
**PASS** — all conditions met:
|
||||
- actionlint clean (or only pre-existing warnings)
|
||||
- No breaking changes for major version bumps
|
||||
- Actions are SHA-pinned with version comments
|
||||
|
||||
**WARN** — concerns exist:
|
||||
- Tag pin instead of SHA pin
|
||||
- Major version bump with breaking changes that appear handled
|
||||
|
||||
**FAIL** — any of:
|
||||
- New actionlint errors
|
||||
- Major version bump with unhandled breaking changes
|
||||
|
||||
Format the report the same way as library dep evaluations.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Sequential Merge
|
||||
|
||||
Collect all subagent evaluation reports. Process work units in the
|
||||
dependency order established in Phase 2.
|
||||
|
||||
### 4a. Merge passing PRs
|
||||
|
||||
For each work unit with a **PASS** verdict, in order:
|
||||
|
||||
1. Approve the PR:
|
||||
```bash
|
||||
gh pr review --repo $REPO --approve {number} \
|
||||
--body "Automated evaluation: build, tests, and transitive dependency analysis passed."
|
||||
```
|
||||
|
||||
2. Force merge as admin:
|
||||
```bash
|
||||
gh pr merge --repo $REPO --squash --admin {number}
|
||||
```
|
||||
|
||||
3. Verify the merge succeeded (gh pr merge produces no output on
|
||||
success):
|
||||
```bash
|
||||
gh pr view --repo $REPO {number} --json state
|
||||
```
|
||||
Confirm `state` is `"MERGED"`. If not, report the error and
|
||||
skip to the next work unit.
|
||||
|
||||
4. Update main locally:
|
||||
```bash
|
||||
git checkout main && git pull origin main
|
||||
```
|
||||
|
||||
5. **Re-test the next work unit** before merging it. Checkout its
|
||||
branch and rebase onto updated main:
|
||||
```bash
|
||||
git checkout pr-{next_number}
|
||||
git merge main --no-edit
|
||||
```
|
||||
Re-run the build and test commands. If the re-test fails, mark
|
||||
this work unit as **SKIPPED** with reason: "Passed independent
|
||||
evaluation but failed after merging prior PRs. Likely conflicts
|
||||
with: {previously merged PR numbers}." Continue to the next
|
||||
work unit.
|
||||
|
||||
For **batched** work units, merge each PR in the batch
|
||||
sequentially using the same approve-then-merge flow.
|
||||
|
||||
### 4b. Handle WARN and FAIL verdicts
|
||||
|
||||
- **WARN** — do not merge. Include in final report with specific
|
||||
concerns. These need human review.
|
||||
- **FAIL** — do not merge. Include full error context for diagnosis.
|
||||
|
||||
## Phase 5: Cleanup & Report
|
||||
|
||||
### 5a. Cleanup
|
||||
|
||||
Return to main and delete local PR branches:
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git branch -D pr-{number} test-batch-{batch_id} # for each evaluated PR/batch
|
||||
```
|
||||
|
||||
### 5b. Summary report
|
||||
|
||||
Print a summary table:
|
||||
|
||||
```
|
||||
## Dependabot PR Summary for $REPO
|
||||
|
||||
| PR | Title | Type | Verdict | Action | Notes |
|
||||
|----|-------|------|---------|--------|-------|
|
||||
```
|
||||
|
||||
Include every evaluated PR with its verdict and outcome.
|
||||
|
||||
Below the table, print totals:
|
||||
|
||||
```
|
||||
**Merged:** {count}
|
||||
**Skipped (WARN — needs human review):** {count}
|
||||
**Failed:** {count}
|
||||
**Skipped (post-merge conflict):** {count}
|
||||
```
|
||||
|
||||
If a dependabot config PR was created in Phase 0:
|
||||
|
||||
```
|
||||
**Dependabot config PR:** #{number}
|
||||
```
|
||||
|
||||
### 5c. Detailed reports for non-merged PRs
|
||||
|
||||
For each WARN, FAIL, or SKIPPED PR, print the full evaluation
|
||||
report from the subagent so the user has all context needed to
|
||||
decide or fix the issue.
|
||||
+229
-24
@@ -5,56 +5,261 @@
|
||||
|
||||
Read PR #$PR_NUMBER thoroughly using `gh pr view`. Understand the
|
||||
full context: description, linked issues, commit history, and the
|
||||
diff against the base branch. Check out the PR branch locally.
|
||||
diff against the base branch.
|
||||
|
||||
Detect the upstream repository: if a git remote named `upstream`
|
||||
exists, use it as the canonical repo. Otherwise, fall back to
|
||||
`origin`. Resolve the canonical repo's `owner/name` (e.g. from
|
||||
`git remote get-url upstream`) and store it — use
|
||||
`--repo <owner/name>` on every `gh` command to ensure they target
|
||||
the correct repository. Run `git fetch <upstream-remote>` to
|
||||
ensure you are working with up-to-date code.
|
||||
|
||||
Check out the PR branch locally.
|
||||
|
||||
Execute every step below sequentially. Do not stop or ask for
|
||||
confirmation at any step.
|
||||
|
||||
## 1. Review
|
||||
|
||||
Use `/compound-engineering:workflows:review` to perform a full
|
||||
multi-agent code review of PR #$PR_NUMBER. Produce a list of
|
||||
findings ranked by severity (P1 = blocks merge, P2 = important,
|
||||
P3 = nice to have, P4 = informational).
|
||||
Run two review passes in parallel, then merge findings.
|
||||
|
||||
### Pass A — pr-review-toolkit agents
|
||||
|
||||
Launch these Task tool agents **in parallel** (single message,
|
||||
multiple tool calls), each with `subagent_type` from the
|
||||
pr-review-toolkit plugin. Tell each agent which files changed
|
||||
(from `git diff --name-only <base>...HEAD`):
|
||||
|
||||
| agent | focus |
|
||||
|-------|-------|
|
||||
| `pr-review-toolkit:code-reviewer` | Code quality, style, project guidelines |
|
||||
| `pr-review-toolkit:silent-failure-hunter` | Silent failures, swallowed errors, bad fallbacks |
|
||||
| `pr-review-toolkit:pr-test-analyzer` | Test coverage gaps and missing edge cases |
|
||||
|
||||
### Pass B — external second opinion
|
||||
|
||||
Launch these Task tool agents **in parallel with Pass A** — all
|
||||
5 agents in a single message, multiple tool calls. Each uses
|
||||
`subagent_type: general-purpose`.
|
||||
|
||||
**Codex reviewer** — tell the agent to run:
|
||||
|
||||
```bash
|
||||
codex review --base <upstream-remote>/<base-branch> \
|
||||
-c model='"gpt-5.3-codex"' \
|
||||
-c model_reasoning_effort='"xhigh"'
|
||||
```
|
||||
|
||||
- `--base` does not accept custom prompts (codex reads
|
||||
`AGENTS.md` at the repo root if one exists)
|
||||
- If `gpt-5.3-codex` fails with an auth error, retry with
|
||||
`gpt-5.2-codex`
|
||||
- Set `timeout: 600000` on the Bash call
|
||||
- Tell the agent to summarize findings only — skip
|
||||
`[thinking]`/`[exec]` blocks and sandbox warnings
|
||||
- If `codex` is not installed, report and skip
|
||||
|
||||
**Gemini reviewer** — tell the agent to run:
|
||||
|
||||
```bash
|
||||
git diff <upstream-remote>/<base-branch>...HEAD > /tmp/pr-review-diff.txt
|
||||
|
||||
# Build prompt file (avoids heredoc shell expansion issues)
|
||||
{
|
||||
echo "Review this diff for code quality, bugs, and improvements."
|
||||
if [ -f CLAUDE.md ] || [ -f .claude/CLAUDE.md ]; then
|
||||
echo ""
|
||||
echo "Project conventions:"
|
||||
echo "---"
|
||||
cat CLAUDE.md .claude/CLAUDE.md 2>/dev/null
|
||||
echo "---"
|
||||
fi
|
||||
echo ""
|
||||
echo "Diff:"
|
||||
cat /tmp/pr-review-diff.txt
|
||||
} > /tmp/pr-review-prompt.txt
|
||||
|
||||
# Pipe prompt via stdin to avoid shell metacharacter issues
|
||||
cat /tmp/pr-review-prompt.txt | gemini -p - \
|
||||
-m gemini-3-pro-preview \
|
||||
--yolo
|
||||
```
|
||||
|
||||
- Uses stdin (`-p -`) instead of heredoc to avoid shell
|
||||
expansion issues with `$`, backticks, etc. in diffs
|
||||
- Set `timeout: 600000` on the Bash call
|
||||
- If `gemini` is not installed, report and skip
|
||||
|
||||
### Merge findings
|
||||
|
||||
Collect results from all 5 sources (3 toolkit agents + Codex +
|
||||
Gemini). Deduplicate overlapping findings — if multiple sources
|
||||
flag the same issue, keep the most specific description and note
|
||||
the consensus. Rank every finding by severity:
|
||||
|
||||
- **P1** — blocks merge (correctness bugs, security issues)
|
||||
- **P2** — important (missing error handling, test gaps, logic flaws)
|
||||
- **P3** — nice to have (style, naming, minor simplifications)
|
||||
- **P4** — informational (observations, suggestions for future work)
|
||||
|
||||
## 2. Fix findings
|
||||
|
||||
Address all P1-P3 findings. For each finding, either:
|
||||
Address all P1–P3 findings. For each finding, either:
|
||||
|
||||
- **Fix it** -- apply the change, or
|
||||
- **Dismiss it** -- explain why it's a false positive or not worth
|
||||
- **Fix it** — apply the change, or
|
||||
- **Dismiss it** — explain why it's a false positive or not worth
|
||||
the churn (e.g. a stylistic disagreement or an impossible edge
|
||||
case). Document the reasoning inline.
|
||||
|
||||
P4 findings are informational -- note them but do not fix unless
|
||||
When a fix requires external context — unfamiliar library behavior,
|
||||
unclear API semantics, or an error you don't recognize — use Exa
|
||||
(`mcp__exa__web_search_exa`) to search for solutions rather than
|
||||
guessing.
|
||||
|
||||
P4 findings are informational — note them but do not fix unless
|
||||
trivial.
|
||||
|
||||
After addressing all findings, review your own fixes: read the
|
||||
diff of changes made in this step and verify each fix is correct,
|
||||
doesn't introduce new issues, and doesn't regress other parts of
|
||||
the PR. If you spot a problem, fix it before proceeding.
|
||||
|
||||
## 3. Verify
|
||||
|
||||
Run the project's full quality pipeline:
|
||||
### 3a. Discover project checks (CI is the source of truth)
|
||||
|
||||
1. Build (compile/bundle if the project has a build step)
|
||||
2. Run the full test suite -- iterate on failures until green
|
||||
3. Run linting, formatting, and type-checking -- fix any issues
|
||||
Before running anything, read the project's CI configuration to
|
||||
learn what the project *actually* runs. This takes priority over
|
||||
the fallback tables below.
|
||||
|
||||
Refer to the project's CLAUDE.md or package.json/Makefile/etc.
|
||||
for the correct commands.
|
||||
1. **Read CI workflows.** Scan `.github/workflows/` for the main
|
||||
CI workflow (typically `ci.yml`, `test.yml`, or `build.yml`).
|
||||
Extract:
|
||||
- Test commands with feature flags (e.g.
|
||||
`cargo test --features foo,bar`)
|
||||
- Lint/format commands with non-default flags
|
||||
- Any step that runs a command then checks `git diff --exit-code`
|
||||
— these are **codegen sync checks** (schema generation,
|
||||
snapshot updates, help text, etc.). Record the command.
|
||||
- Docs/site build commands (e.g. `make site`, `mkdocs build`)
|
||||
2. **Read the Makefile** (if present). Cross-reference targets
|
||||
used in CI — these are the ones that matter.
|
||||
3. **Read CLAUDE.md** (if present at repo root or `.claude/`).
|
||||
It may define project-specific quality gates.
|
||||
|
||||
Store the discovered commands. They override the fallback table
|
||||
for any overlapping step.
|
||||
|
||||
### 3b. Run the quality pipeline
|
||||
|
||||
Detect the project language from manifest files (`Cargo.toml` →
|
||||
Rust, `pyproject.toml`/`setup.py` → Python, `package.json` →
|
||||
Node/TypeScript, `go.mod` → Go). A project may use multiple
|
||||
languages; run checks for each.
|
||||
|
||||
Run checks in this order. For each step, use the CI-discovered
|
||||
command if one was found; otherwise fall back to the default.
|
||||
|
||||
1. **Build** — compile or bundle
|
||||
2. **Test** — run the full test suite with the same feature flags
|
||||
CI uses. Iterate on failures until green.
|
||||
3. **Lint and format** — fix any issues
|
||||
4. **Extended checks** — per-language extras (see fallback table)
|
||||
5. **Codegen sync** — for every codegen check discovered in 3a,
|
||||
run the command and verify `git diff --exit-code`. If the diff
|
||||
is non-empty, the generated files are stale — regenerate and
|
||||
stage them.
|
||||
6. **Docs build** — if the PR changes documentation files and a
|
||||
docs build command exists, run it to verify the docs compile.
|
||||
|
||||
### Fallback defaults (when CI config is absent or unclear)
|
||||
|
||||
**Rust** (detected by `Cargo.toml`):
|
||||
|
||||
| step | command |
|
||||
|--------------|------------------------------------------------|
|
||||
| build | `cargo build` |
|
||||
| test | `cargo test` |
|
||||
| lint | `cargo clippy -- --deny warnings` |
|
||||
| format | `cargo fmt --check` |
|
||||
| supply chain | `cargo deny check` (if `deny.toml` exists) |
|
||||
| careful | `cargo careful test` (if `cargo-careful` installed) |
|
||||
|
||||
**Python** (detected by `pyproject.toml` or `setup.py`):
|
||||
|
||||
| step | command |
|
||||
|--------------|------------------------------------------------|
|
||||
| test | `pytest -q` |
|
||||
| lint | `ruff check` |
|
||||
| format | `ruff format --check` |
|
||||
| types | `ty check` (or `mypy` if configured) |
|
||||
| supply chain | `pip-audit` |
|
||||
|
||||
**Node/TypeScript** (detected by `package.json`):
|
||||
|
||||
| step | command |
|
||||
|--------------|------------------------------------------------|
|
||||
| build | per project (`npm run build`, `tsc`, etc.) |
|
||||
| test | `vitest` (or project test script) |
|
||||
| lint | `oxlint` (or project lint script) |
|
||||
| format | `oxfmt --check` (or project format script) |
|
||||
| types | `tsc --noEmit` |
|
||||
| supply chain | `pnpm audit --audit-level=moderate` |
|
||||
|
||||
**Go** (detected by `go.mod`):
|
||||
|
||||
| step | command |
|
||||
|--------------|------------------------------------------------|
|
||||
| build | `go build ./...` |
|
||||
| test | `go test ./...` |
|
||||
| lint | `golangci-lint run` |
|
||||
| format | `gofmt -l .` |
|
||||
| vet | `go vet ./...` |
|
||||
|
||||
If a tool is not installed, skip it with a note rather than
|
||||
failing the pipeline.
|
||||
|
||||
## 4. Commit and push
|
||||
|
||||
- Commit the fixes as a separate commit (do not squash into the
|
||||
original -- preserve review history)
|
||||
- Use commit message: `fix: resolve code review findings for
|
||||
PR #$PR_NUMBER`
|
||||
original — preserve review history)
|
||||
- Write a detailed commit message that covers:
|
||||
- Subject: `fix: resolve code review findings for PR #$PR_NUMBER`
|
||||
- Body: list findings by severity, what was fixed vs dismissed
|
||||
(with brief reasoning), and confirmation that the quality
|
||||
pipeline passes
|
||||
- Push the branch (regular push, not force-push)
|
||||
- Delete any todo files in `todos/` that were created by the
|
||||
review and are now resolved
|
||||
|
||||
## 5. Post summary
|
||||
## 5. PR comment
|
||||
|
||||
Add a comment on PR #$PR_NUMBER summarizing what was done:
|
||||
Post a review summary as a PR comment using
|
||||
`gh pr comment $PR_NUMBER --repo <owner/name>`.
|
||||
|
||||
- Total findings by severity (e.g. "3 P2, 5 P3")
|
||||
- How many were fixed vs dismissed (with brief reasoning for
|
||||
any dismissals)
|
||||
- Confirmation that the quality pipeline passes
|
||||
Format the comment body as:
|
||||
|
||||
```
|
||||
## Review Summary
|
||||
|
||||
### Findings
|
||||
|
||||
[For each severity level that has findings, list them as a table:]
|
||||
|
||||
| # | Severity | Finding | Resolution |
|
||||
|---|----------|---------|------------|
|
||||
| 1 | P1 | [description] | Fixed: [what was done] |
|
||||
| 2 | P2 | [description] | Dismissed: [reasoning] |
|
||||
| ... | ... | ... | ... |
|
||||
|
||||
### Verification
|
||||
|
||||
- **Tests**: [pass/fail count]
|
||||
- **Lint**: [clean/issues]
|
||||
- **Format**: [clean/issues]
|
||||
|
||||
### Commit
|
||||
|
||||
[commit SHA and subject line]
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user