菜单
Review work items, ExecPlan delivery, or arbitrary code changes with evidence-backed findings. Reviews are read-only by default and create tracker follow-ups only when explicitly requested with --create-followups.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Sequentially drain ready br issues or tk tickets through the existing ship chains with retry limits and progress state.
Update a work item with a concise execution note and close it only when validation and review evidence prove the acceptance criteria. Use for prompts that finalize work-item status after manual execution chains.
Implement or fix a work item using minimal diffs while preserving scope, local conventions, and testability. Use for prompts that change code or apply validation/review fixes.
Validate work-item changes using concrete evidence, exact commands, and explicit gap reporting. Use for validation prompts and review passes that audit proof.
Create a self-contained ExecPlan from a brainstorm artifact and/or a user brief. Follows the project's .execflow/PLANS.md spec. Applies the Ousterhout design lens. Use when creating execution plans, turning ideas into implementable steps, or wants a PRD/RFC/brainstorm turned into a step-by-step plan.
Convert an ExecPlan's milestones into tracked work items, automatically selecting tk tickets or br issues from repo context unless the user forces a tracker with --tk or --br. Use when the user wants one entrypoint that works across both tracker backends.
| name | review-suite |
| description | Review work items, ExecPlan delivery, or arbitrary code changes with evidence-backed findings. Reviews are read-only by default and create tracker follow-ups only when explicitly requested with --create-followups. |
Use this skill for /ef-review across work-item, ExecPlan delivery, branch, diff, and path-scope reviews.
Reviews are read-only by default. Do not add tracker comments, close/reopen items, create issues/tickets, edit code, or mutate repo-root workflow artifacts unless the prompt input includes --create-followups.
When --create-followups is absent, list candidate follow-ups only. When it is present, create follow-ups only for concrete, actionable findings after checking for obvious duplicates. For work-item reviews, add a concise note/comment to the original work item summarizing the review findings and the created or duplicate follow-up IDs. Do not close the original work item from the review step; the downstream finalization step closes it when validation evidence is PASS and every material review finding is represented by a follow-up. For tk, use tk add-note <item> "...". For br, prefer ACTOR="${BR_ACTOR:-assistant}" and RUST_LOG=error br ... --json, then run RUST_LOG=error br sync --flush-only after mutation.
When creating a follow-up for a work-item review, make that follow-up depend on the reviewed original item before reporting it as created. This prevents autoship ready-queue selection from implementing review follow-ups while the original item's uncommitted implementation is still dirty in the checkout. For tk, after tk create ... returns the new ID, run tk dep <new-id> <original-id>. For br, after br create ... --json returns the new ID, run RUST_LOG=error br dep add --type blocks <new-id> <original-id> --json; then run RUST_LOG=error br sync --flush-only after all mutations. If dependency creation fails, list that follow-up under incomplete follow-up coverage and set Original item may close: no.
Every review must end with a machine-readable # Finalization Handoff section. Set Original item may close: yes only when the verdict is merge-ready/pass and either there are no material findings or every material finding has a created follow-up or an explicitly identified duplicate plus an original-item note/comment. Set it to no for needs-fixes, failed, blocked, missing validation evidence, disabled/incomplete follow-up creation, or failed original-item commenting.
Review exactly one implemented work item. Resolve the work item and optional ExecPlan first. Check work-item compliance, ExecPlan compliance, acceptance criteria, validation evidence, accidental scope expansion, missing required behavior, regression risk, and merge readiness. Produce separate judgments for spec compliance, code quality, and validation evidence before giving the overall verdict.
Known execflow workflow-state files such as .pi/execflow-autoship-loop-marker.json, .pi/execflow-validation-gate.json, legacy .execflow/validation-gate.json, .execflow/autoship-progress.json, and .execflow/lessons-learned.md are not delivery artifacts by themselves. Do not create review findings just because they are dirty or untracked; treat them as unrelated workflow state unless their contents are the only available validation evidence and that evidence is stale, missing, or contradictory.
Review whether a whole ExecPlan was delivered coherently across derived issues/tickets. Resolve the plan, find derived work items, inspect status/descriptions/dependencies/comments/validation notes, and sample high-risk changed code only as needed. Focus on milestone coverage, dependency sequencing, plan drift, required docs/architecture updates, and material evidence gaps. Produce separate judgments for spec compliance, code quality, and validation evidence before giving the overall verdict.
Review an arbitrary branch, diff, or path scope. Determine the target from --base <ref>, explicit paths/context, or current uncommitted/current-branch changes. Focus on correctness, regressions, security/data-loss risks, compatibility, validation evidence, maintainability issues that create concrete bugs, and merge readiness. Produce separate judgments for spec compliance, code quality, and validation evidence before giving the overall verdict.
Every review must separate three judgments before the overall verdict:
Spec compliance: whether the implementation satisfies the work item, ExecPlan, acceptance criteria, and stated non-goals without scope creep. This is where missing required behavior, plan drift, wrong dependencies, or extra unrequested behavior belong.Code quality: whether the change is simple, maintainable, safe, compatible with local patterns, and free of concrete correctness, regression, security, data-loss, or maintainability bugs. Do not use this section for style preferences that do not create real risk.Validation evidence: whether fresh evidence proves the claimed behavior. Check exact commands, outputs, manual proof, RED/GREEN evidence or exemption, regression validation, and gaps. A final passing broad test run is not enough for testable work when RED proof or exemption is missing.The overall verdict is the minimum safe conclusion across the three judgments. For example, code can be high quality but still needs-fixes when spec compliance is incomplete or validation evidence is weak. Conversely, strong validation evidence does not excuse scope creep or concrete code risk.
Prefer fewer strong findings over many weak ones. A finding must be concrete, evidence-backed, actionable, and tied to a real risk or acceptance gap. Do not create findings for style nits, vague maintainability preferences, speculative edge cases, or redesign ideas unless they are required for correctness.
Severity:
critical — unsafe to merge/rely on, acceptance criteria are falsely complete, or there is a data-loss/security/compatibility blocker.major — real bug, missing required behavior, material plan drift, dependency error, or validation gap that should be fixed before relying on the work.minor — concrete correctness, evidence, or required-doc gap worth tracking, but not a blocker by itself.Use one concise body format for created tracker work items:
Review Follow-up
Review target: <work-item id, ExecPlan path, branch/diff/path>
Severity: <critical|major|minor>
Category: <correctness|regression|tests|maintainability|architecture|security|delivery|other>
Source finding: <short quote or paraphrase>
Required remediation: <specific action>
Acceptance criteria:
- The finding is addressed with the smallest safe change.
- Relevant validation or evidence is documented.
Use exactly these sections for all review prompts:
- nonepath/to/file:line or none