القائمة
Diagnosis loop for hard bugs and performance regressions. Use when the user says diagnose/debug, or reports broken/failing/slow behavior.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Delivery overlay — orchestrates lean ladder, tdd, prune, review with sub-phase gates; commits only on user approval.
Flow Conductor for the aiops bundle. One entry — infers task type, shows plain-language steps, tracks journey in flow.state.yaml, dispatches skill + agent per phase.
Structured design process for the architect agent. Guides from grill conclusions to complete NOTES.md + tech-spec.md plus needed domain documentation updates through constraint gathering, module identification, interface design, alternative exploration, and risk analysis. Use when the architect needs to produce design decisions and technical specifications.
Build and query a persistent code graph for the target project. Uses graphify (Tree-sitter + Louvain clustering) for deterministic structural extraction, then the model adds semantic annotations. Use when the user says build graph, code graph, dependency graph, impact analysis, or when other skills need structured code understanding before proceeding.
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick. Use when the user says architecture review, codebase health, deepening, refactor suggestions, or complains about architectural friction.
Review in three modes — code (diff vs standards/spec), design (NOTES + tech-spec before planning), drift (implementation vs tech-spec before ship). Pick mode from Flow Conductor phase or user intent; do not mix artifact types.
| name | diagnosing-bugs |
| description | Diagnosis loop for hard bugs and performance regressions. Use when the user says diagnose/debug, or reports broken/failing/slow behavior. |
Skip phases only when explicitly justified. Read CONTEXT.md and local ADRs for module context.
If graphify-out/graph.json exists, briefly tell the user "查询代码图谱了解影响范围" then query the code graph before starting diagnosis:
/code-graph query impact <suspected-file> — find all modules affected by the suspected code area/code-graph query deps <suspected-module> — understand what the suspected module depends on/code-graph query hotspot — check if the bug area is also a known hotspot (high coupling + frequent changes)Use these results to narrow the hypothesis space in Phase 3. If no graph exists, skip silently.
This is the skill. A tight pass/fail signal that goes red on this bug beats staring at code.
Try in order: failing test → curl/script → CLI fixture → headless browser → replay trace → throwaway harness → fuzz → bisect harness → differential old/new → HITL script.
Then tighten: faster, sharper assertion, more deterministic.
Non-deterministic bugs: raise reproduction rate until debuggable. If no loop is possible, stop — list what you tried, ask for env access or captured artifacts. No red-capable command, no Phase 2.
Done when one agent-runnable command is red-capable, deterministic, fast, and already run once (paste invocation + output).
Loop goes red on the user's symptom. Shrink repro one cut at a time — every remaining piece must be load-bearing.
3–5 ranked, falsifiable hypotheses before testing. Show the list to the user when possible.
One variable at a time. Debugger > targeted logs. Tag logs [DEBUG-xxxx] for cleanup. Perf: measure baseline, then bisect.
Regression test before fix only at a correct seam (real bug pattern at call site). No seam → document as architectural finding.
Remove debug tags, delete throwaway harnesses, re-run Phase 1 loop, state winning hypothesis in commit message.
Post-fix: if prevention needs architectural change (no test seam, tangled coupling), recommend /aiops with Architecture health — after the fix, with specifics.