菜单
Run a pre-PR quality gate (tests, typecheck, lint, code review) and then create a pull request with a structured summary. Use when the user says "create a PR", "open a PR", "submit for review", or "I'm done with this feature".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Validate test suite quality by running a real mutation testing tool and triaging surviving mutants. Use after writing tests to verify assertions catch behavioral changes, when evaluating test coverage quality, or as a CI quality gate on critical modules. The AI value here is triage — classifying survivors, writing fix tests — not generating or estimating mutations.
General-purpose analyze-then-improve test workflow for any JS/TS, Go, Java, or C# codebase. A 4-phase orchestrator: analyze with /test-health, optionally derive Gherkin with /gherkin-derive, triage into work items, implement each Story with /build + /coverage-delta + the mutation-kill agent, and validate with /quality-targets-converge. Local-first, BDD optional, Go-aware. Use when the user says "upgrade our tests", "improve test quality", or runs /test-upgrade. Lighter and general-purpose where /test-modernize is a brownfield legacy rescue.
Frontend component architecture review — dispatch the component-architecture-review agent over the frontend component files to catch reusable components that should be extracted, duplicated UI patterns, prop drilling, component-granularity problems, and inconsistent component APIs as a frontend evolves. Use when the user says "review the frontend architecture", "are my components reusable", "is this UI duplicated", "should this be a shared component", "check for prop drilling", or before extracting a component library. Advisory — it recommends, it does not edit.
Run eval fixtures against review agents and grade results. Use this after adding or modifying a review agent, to validate detection accuracy, or when the user says "run the evals", "test the agents", "check for regressions", or "how accurate is the agent".
Run all enabled review agents against target files. Use this whenever the user asks for a code review, wants feedback on their code, says "review my code", "check this before I PR", "what's wrong with this", "run the agents", or has just finished implementing a feature. Use proactively before commits and pull requests.
Charter-driven exploratory testing of a running feature or endpoint. Dispatches the QA Engineer in "Chaos Specialist" mode to probe with structured heuristics (Goldilocks, Happy-Path Divergence, Telemetry Deepening, Invariant Probing, CRUD Sweep), run adversarial expansion, and auto-triage critical defects into an incremental report. Use when the user says "explore this endpoint", "poke at this feature", or wants hands-off exploratory testing of a live target.
| name | pr |
| description | Run a pre-PR quality gate (tests, typecheck, lint, code review) and then create a pull request with a structured summary. Use when the user says "create a PR", "open a PR", "submit for review", or "I'm done with this feature". |
| argument-hint | [--skip-review] [--draft] [--base <branch>] |
| user-invocable | true |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash(git *), Bash(gh *), Bash(npm *), Bash(npx *), Bash(pnpm *), Bash(yarn *), Bash(make *), Bash(pytest *), Bash(go *), Bash(cargo *), Bash(dotnet *), Skill(code-review *) |
Role: orchestrator. This command enforces quality gates before creating a PR.
You have been invoked with the /pr command.
Arguments: $ARGUMENTS
--skip-review: Skip the /code-review step (not recommended)--draft: Create a draft PR--base <branch>: Target branch (default: main)--no-auto-merge: Do not enable auto-merge (the default is to enable it; see Step 5)Verify:
main or masterIf a plan file is present (check plans/ for the most recently modified approved or implemented plan), run the plan completion gate:
python3 scripts/progress_guardian.py --pre-pr --plan <plan-file>
A non-zero exit means incomplete steps remain; stop and surface the findings — do not open the PR until all steps are [x].
Run each check sequentially. Stop on first failure:
Tests: Detect and run the project's test suite
package.json scripts: npm test or pnpm test or yarn testpytest.ini / pyproject.toml: pytestgo.mod: go test ./...Cargo.toml: cargo test*.csproj: dotnet testMakefile with test target: make testType check (if applicable):
tsconfig.json: npx tsc --noEmitmypy.ini / pyproject.toml with mypy: mypy .Lint (if applicable):
eslint in deps: npx eslint .ruff available: ruff check .golangci-lint available: golangci-lint runCode review (unless --skip-review):
/code-review --json. /pr owns the human gate, so code-review runs non-interactively: it skips its own "fix or report?" prompt and applies its fix loop automatically (up to 5 iterations), then returns an aggregated status.{"overall": "pass|warn|fail", ...}; a documentation-only changeset short-circuits with {"status": "skipped", ...}:
overall of pass / warn, or status of skipped → continue to step 3.overall of fail → show the remaining findings and ask the user whether to proceed anyway or stop and fix.Report results as a checklist:
## Quality Gate
- [x] Tests pass (42 passed, 0 failed)
- [x] Type check clean
- [x] Lint clean
- [ ] Code review: 2 warnings (see below)
Analyze the diff against the base branch (git diff <base>...HEAD) and commit history to generate:
gh pr create --title "<title>" --body "<body>" [--draft] --base <base>
Use the structured template:
## Summary
- <bullet 1>
- <bullet 2>
## Quality Gate
- [x] Tests: <N> passed
- [x] Type check: clean
- [x] Lint: clean
- [x] Code review: <status>
## Test Plan
- [ ] <verification step 1>
- [ ] <verification step 2>
Unless --no-auto-merge or --draft was given, enable auto-merge so the PR lands automatically once checks pass and any required reviews are in — rather than merging directly to trunk. This is the default integration stance in knowledge/decision-defaults.md (auto-merge vs. direct-to-trunk).
gh pr merge --auto --squash
If the repository does not have auto-merge enabled (the command errors), report that and leave the PR open for manual merge — do not merge directly to trunk to work around it.
Display the PR URL and a summary of the quality gate results.
If any gate failed and the user chose to proceed anyway, note this in the PR body as a caveat.