القائمة
Use when asked to "review recent changes", "chunk review", "review my diff", "review this PR", "review PR
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when the user says "validate on the sidecar", "run tests on the sidecar", "sync to sidecar", "sidecar dev loop", "check this on the sidecar", "validate remotely", "scaffold test-suites.yml", "set up smarter testing", "write .circleci/test-suites.yml", "run smarter testing doctor", or "diagnose smarter testing", or when you have made edits and want to verify them on a remote `chunk` sidecar instead of running locally. Also covers creating sidecars, snapshotting a configured environment, customizing the sidecar image via `chunk sidecar`, and scaffolding `.circleci/test-suites.yml` for CircleCI Smarter Testing.
Debug CircleCI build failures, analyze test results, and identify flaky tests. Use when the user says "debug CI", "why is CI failing", "fix CI failures", "find flaky tests", "what broke in CI", "check CircleCI", or asks about failing pipelines or build errors.
Use when asked to "find testing gaps", "chunk testing-gaps", "mutation test", "mutate this code", "test mutation coverage", or "find surviving mutants". Runs a 4-stage mutation testing process: discovery, validation via git worktrees and CI, production cross-reference, and risk assessment.
| name | chunk-review |
| description | Use when asked to "review recent changes", "chunk review", "review my diff", "review this PR", "review PR |
| version | 3.0.0 |
Use the team's generated review prompt to review recent code changes. Runs the actual review in an isolated subagent so prior conversation context does not influence the findings.
Determine the diff scope: Use the following priority order to decide what to review:
gh pr view <number-or-url> --json number,title,body,baseRefName,headRefName,headRepositoryOwner,headRepository to get PR metadatagh pr diff <number-or-url> to get the full diffgh pr view --json number,title,body,baseRefName,headRefName,headRepositoryOwner,headRepository to auto-detect it, then fetch the diff the same waygit diff --cached) — review thosegit diff main...HEAD or git diff origin/main...HEAD)Get the diff: Obtain the changes using the method selected above. If the diff is empty, tell the user there is nothing to review. Store the full diff text — you will pass it inline to the subagent. For PR reviews also store the PR title and body.
Load the review prompt: The source depends on the review type:
.chunk/context/review-prompt.md from the PR's head branch using:
gh api repos/{headRepositoryOwner}/{headRepository}/contents/.chunk/context/review-prompt.md?ref={headRefName} --jq '.content' | base64 --decode
{headRepositoryOwner} with headRepositoryOwner.login, {headRepository} with headRepository.name, and {headRefName} directly. If the file does not exist on that branch, fall back to the local .chunk/context/review-prompt.md..chunk/context/review-prompt.md from the root of the current project.chunk build-prompt to generate one. Do not proceed without it.Delegate to a subagent: Launch a general-purpose subagent with a self-contained prompt built from the template below. Substitute {{REVIEW_PROMPT}}, {{PR_CONTEXT}}, and {{DIFF}} with the actual content collected in steps 1–3. The subagent has no access to your conversation history — everything it needs must be in the prompt.
For local reviews, omit the PR context section entirely.
Subagent prompt template:
You are performing a code review. Apply the review standards below to the diff using a two-pass approach. Ignore anything outside this prompt — do not use any prior context.
## Review Standards
{{REVIEW_PROMPT}}
## PR Context (if applicable)
{{PR_CONTEXT}}
## Diff
{{DIFF}}
## Instructions
**Pass 1 — Comprehensive Review** (internal, do NOT include in output):
Apply the standards above to the diff. Do not invent criteria beyond what is in the review standards. For each potential issue, internally record:
- File path and line number
- Category (from the review standards)
- Description of the concern
- Relevant code snippet
**Pass 2 — Validate and Prioritize**:
Re-examine every finding from Pass 1. For each finding:
- Attempt to construct a **concrete failure scenario** (bug triggered, error thrown, security hole exploited, maintenance burden realized). If you cannot construct one, discard the finding.
- Rate impact: **Critical** (breaks correctness, security vulnerability, data loss) / **High** (likely bug, significant performance issue, clear maintainability problem) / **Medium** (style or convention issue with real consequences) / **Low** (nitpick, subjective preference)
- Estimate confidence (how certain you are this is a real issue). Discard anything below ~80% confidence.
- **Keep**: all Critical and High findings. At most **1 Medium per changed file**. Discard all Low findings.
- **Cap at 10 comments total**. If more than 10 survive filtering, keep the 10 highest-impact ones.
**Output the final filtered findings using this format:**
## Review Summary
**Files reviewed**: <count>
**Issues identified**: <count after filtering>
## Findings
### 1. <short title>
**`<file>:<line>`** | **<Impact>**
<Explanation — framed as a question unless 100% certain the issue is critical. Reference the specific code and explain the concrete failure scenario.>
<Optional: suggested fix or alternative approach>
---
(repeat for each finding)
If no findings survive filtering, output:
## Review Summary
**Files reviewed**: <count>
**Issues identified**: 0
No significant issues identified. The changes look good against the team's review standards.
Return the result: Output the subagent's response directly to the user without modification.
.chunk/context/review-prompt.md file is generated by chunk build-prompt and encodes the team's actual review patterns mined from real PR comments. Treat it as the authoritative source of review standards..chunk/context/review-prompt.md is missing, do not fall back to generic review criteria — prompt the user to generate it first.