메뉴
Analyze debug-analyzer.log and run tests to identify pipeline issues after a change. Standard post-change check per Captain's protocol.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Keep repository documentation lean, clear, and readable. Use automatically before adding a new document, substantially expanding or rewriting Markdown/xWiki content, adding explanatory/background sections, adding FAQs/glossaries/templates, introducing repeated framing, or reviewing a documentation diff for clutter, filler, duplication, over-broad prose, stale links, or readability problems.
MUST be used automatically for any FactHarbor bugfix, regression fix, failing test/build fix, failed-validation recovery, or defect repair — BEFORE editing code. Decides whether the best fix is reverting or amending a previous change, quarantining/deleting obsolete code, or adding new code. Also use when about to add a fallback, flag, retry, helper, guard, diagnostic, or parallel mechanism — in response to a failure or proactively (even with no failing test) — or when reviewing a diff for workaround stacking / additive repair drift.
Analyze local job reports from the most recent build/commit (HEAD by default), detect quality issues, and propose AGENTS.md-compliant fixes. Scopes to HEAD by default, or to specific job URLs / job IDs / commit / input slug passed as argument. Uses RAG (static register + handoffs + machine-readable benchmark expectations, plus dynamic follow-up scans) and runs an adaptive multi-agent debate before emitting recommendations. Complements `/prompt-diagnosis` (which is narrower — prompt provenance only) by covering evidence, boundaries, verdict reasoning, and warning severity end to end.
Structured adversarial debate on any proposition. Runs an intake/structural audit first, then spawns pipeline-mirroring roles (Advocate, Challenger, Reconciler) with optional Consistency Probes and Validator. Use when a decision needs adversarial pressure before committing — root-cause attribution, architecture choices, fix selection, design tradeoffs. Other skills invoke /debate for their adversarial synthesis steps. Adapts role count and model tiers to proposition complexity.
Consolidate all documentation in Docs/WIP/. Investigates implementation status of WIP topics using helper agents when the tool supports delegation, ensures all open items are well-described and present in the backlog, updates and cleans up backlog and status files, and moves historical/completed content to the Archive. Use this skill whenever the user says "consolidate WIP", "clean up WIP", "tidy WIP docs", "audit WIP", or asks to update the backlog from WIP — even if phrased differently. Note: this skill covers Docs/WIP/ only. To clean up the entire Docs/ tree use docs-update.
Deep analysis of the FactHarbor CB pipeline. Use for debugging, architecture decisions, evidence quality issues, or reviewing changes that span multiple pipeline stages.
| name | debug |
| description | Analyze debug-analyzer.log and run tests to identify pipeline issues after a change. Standard post-change check per Captain's protocol. |
| allowed-tools | Bash Read Glob |
ultrathink
Analyze recent pipeline runs for issues. Focus: $ARGUMENTS (leave blank for general post-change check)
For analysis-pipeline issue investigations, identify root cause before recommending fixes, prioritize quality over speed over cost, and escalate to /pipeline, /prompt-diagnosis, /report-review, or /debate only when this quick check is too narrow.
Step 1 — Read the debug log:
Read apps/web/debug-analyzer.log. If large, read the last 300 lines.
Identify: errors, warnings, stage failures, contract violations, unexpected LLM outputs, timing anomalies.
Step 2 — Run tests:
Run npm test 2>&1 | tail -40 and check pass/fail summary.
(Note: npm test is safe — it excludes expensive LLM tests.)
Step 3 — Pattern analysis: Look for:
Step 4 — Correlate with recent changes:
Run git log --oneline -5 to see what changed.
Identify whether issues correlate with specific commits.
Step 5 — Failed-attempt recovery discipline:
If the first focused validation for the slice failed (for example npm test, npm -w apps/web run build, or the manual verification explicitly described for the change), do not jump straight to a broader fix package.
First classify the earlier attempt as keep, quarantine, or revert.
Keep only the parts still justified by the evidence from Steps 1-4.
Broaden scope only if the failure evidence shows why a wider change is required.
Step 6 — Report findings: Summarize in priority order. For each issue: stage where it occurs, likely cause, recommended fix.
Flag any regressions in the Captain's priority benchmark families:
If regressions are found, recommend running /validate for a full measurement.
