القائمة
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 ويثبّتها لك.
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.
استنادا إلى تصنيف SOC المهني
| 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.
