القائمة
Use when fixing a bug, investigating a failure, or diagnosing unexpected behavior. Evidence first: read the failure, reproduce it, isolate root cause, make the smallest fix, and verify.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when a V3 or V4 task needs design before implementation. Produce only enough structure to reduce thrash: decisions, boundaries, sequence, and verification.
Use when the user wants the agent to keep working without waiting for input. Autopilot runs continuously: finish the given plan first, then keep making one meaningful verified improvement per iteration until interrupted.
Use after implementation, before shipping, or when the user asks for review. Focus on correctness, regressions, verification gaps, failure handling, security, and performance. Skip style-only noise.
Use after meaningful work to capture confirmed repo-specific knowledge in `.hypersonic/learned.md` and `.hypersonic/history.jsonl`: conventions, gotchas, test patterns, architecture notes, and user preferences.
Classify coding work into Hypersonic V1-V4 tiers, choose the lightest safe workflow, set verification depth, and hand off to focused skills. Use at the start of software tasks or when scope changes.
Use when the user wants to explore, prototype, vibecode, or move fast without heavy process. Build the first useful version quickly, show something real, and iterate from feedback.
| name | surgical-debug |
| description | Use when fixing a bug, investigating a failure, or diagnosing unexpected behavior. Evidence first: read the failure, reproduce it, isolate root cause, make the smallest fix, and verify. |
| parameters | {"velocity":"high","rigor":"medium","max_questions":1,"test_mode":"auto","auto_commit":false} |
Most debugging time is wasted on confident guesses. The fastest fix is evidence -> reproduction -> root cause -> targeted change -> verification.
velocity: timebox investigation and avoid side quests.rigor: trace more boundaries and verify wider blast radius.max_questions: ask only when the evidence is unavailable or ambiguous.test_mode: sets the verification floor after the fix.auto_commit: commit only when allowed by the workflow.Before changing code:
If you cannot state the failure clearly, keep reading.
Use the strongest available reproduction:
If it cannot be reproduced, gather more data before fixing.
Form at most three hypotheses. For each, define the one check that confirms or kills it.
For multi-layer bugs, inspect each boundary:
The bug often lives where data, config, or state changes shape.
Find similar working code in the same repo. Compare what differs before inventing a new pattern.
Use diagnostic logging or instrumentation only to answer a specific hypothesis, then remove it before shipping.
Change the minimum code that addresses the root cause. Do not mix debugging with cleanup, redesign, or speculative refactors.
Before editing, know:
Use test_mode as the floor:
Add a regression test when the bug is likely to return or the area is high risk.
Route back through hypersonic-core when:
The standard: prove the failure, fix the cause, and prove the fix.