メニュー
Use when a diff or codebase must receive a CodeRabbit-style audit — 7 finder angles, a dual-blind AND-gate, and fix-apply — returning P0–P3 findings and an APPROVED/REVISE verdict.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when a plan folder created by sf-pair-plan must be executed milestone-by-milestone in a worktree, with a per-milestone TDD→review→commit→tracker loop, then finalized so the branch is preserved for a PR.
Use when a user asks to create a structured implementation plan with milestones, stories, and reviewer approval using pi-subagents.
Execute a single task end-to-end with plan review, implementation review, verification, and one persistent task-plan artifact.
Use when a defined flow (.pi/workflows/<name>.yaml) must be run end-to-end with no human gates. Input may be a prompt, a markdown file, a PRD, or a Jira story.
Use when a user asks to create or validate a reusable flow from a declarative agents/phases/loops definition. Interviews the user, writes .pi/workflows/<name>.yaml, and registers /<name>.
Use when a plan folder created by sf-flow-plan must be executed in a single worktree (flow/<slug>) with TDD per story and a non-optional audit gate before commit, then finalized so the branch is preserved for a PR.
| name | sf-flow-audit |
| description | Use when a diff or codebase must receive a CodeRabbit-style audit — 7 finder angles, a dual-blind AND-gate, and fix-apply — returning P0–P3 findings and an APPROVED/REVISE verdict. |
The auditor agent is at ~/.pi/agent/agents/auditor.md (write-once). Reviewer model resolved via the 4-step chain (prompt -> config -> SF_FLOW_REVIEWER_MODEL -> ask). Threshold default 0.94, max_rounds 5 (config: audit.threshold / audit.max_rounds).
Resolve the target to a diff string. If target is a ref range → git diff <range>. If a file → read it. If absent → git diff HEAD (staged+unstaged). Cap at MAX_DIFF_CHARS (200000) — truncate with a marker via buildCodeReviewPrompt.
Dispatch the code-review builtin with buildCodeReviewPrompt(diff, repoRoot). It fans out 7 finder agents (A/B/C correctness medium-tier, D/E/F cleanup small-tier, G altitude big-tier), verifies each finding (3-way CONFIRMED/PLAUSIBLE/REFUTED, drop REFUTED), dedups by file:line:summary, ranks correctness>cleanup>altitude, and synthesizes. Collect findings into the P0-P3 contract.
Run the 10-section checklist (CHECKLIST_SECTIONS) against the changed files (churn-ranked first). In --gate mode: gateExitCode returns 1 on ANY failure, 0 only if all pass. Write the full report to specs/verifications/AUDIT-<slug>.md.
Dispatch TWO independent reviewer agents (A, B) with NO shared context (neither sees the other's report). Compute each score via qualityScore; both must pass (andGatePasses: mustFix==0 && score>=threshold). If either fails → REVISE → respond-review → re-dispatch both. Max MAX_REVIEW_ITERATIONS (5); iteration 6 forbidden (isApproved).
If apply_fixes: categorize findings (P0/P1 must-fix, P2 should-fix, P3 consider), applyOrder (severity), apply in order, run test/typecheck/lint, report. In auto mode: skip consider confirmations, note them. HARD GATE: every finding is addressed (fix, disagree+document, or clarify).
Render the merged findings via renderReport (pair's ### P0...P3 + ## Verdict format). Return VERDICT: APPROVED only if no P0/P1/P2 remain (isBlocking).
On completion, send a summary via the notify-telegram helper (TELEGRAM_BOT_TOKEN + TELEGRAM_CHAT_ID).
