菜单
Leverage-point analysis for failed prompts. Determines whether the fix belongs at the plan, prompt, or code level before generating any fix. Use when a prompt fails verification, a checkpoint catches an issue, fix attempts aren't working, or the user says "debug", "why did this fail", "investigate".
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Sheshiyer/skill-clusters --skill conducty-debug命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | conducty-debug |
| description | Leverage-point analysis for failed prompts. Determines whether the fix belongs at the plan, prompt, or code level before generating any fix. Use when a prompt fails verification, a checkpoint catches an issue, fix attempts aren't working, or the user says "debug", "why did this fail", "investigate". |
| aliases | ["conducty-debug","debug"] |
| tags | ["conducty/skill","conducty/debug"] |
| cluster | conductor |
| version | 1.0.0 |
| origin | robertbarclayy/conducty (MIT) |
When something fails, the first question is not "what's wrong with the code?" It's "where is the highest leverage point to fix this?" A failure might be a code bug, a prompt quality problem, a plan assumption error, or a systemic issue affecting multiple prompts. Fixing at the wrong level wastes retries.
Fix at the highest level that applies:
Plan assumptions → fixes the most, prevents future failures
↓
Prompt quality → fixes this prompt and similar future prompts
↓
Code bug → fixes this specific failure only
Plan-level fix: The design was wrong, the acceptance criteria were incorrect, or the context was insufficient. A code fix won't help because the code was implementing the wrong thing correctly. Signal: the tracer failed, or multiple prompts in the same group fail for related reasons.
Prompt-level fix: The prompt was vague, missing context, had no no-go zones, or specified the wrong approach. The code did what the prompt said, but the prompt said the wrong thing. Signal: spec review passes but verification fails, or the implementer was BLOCKED/NEEDS_CONTEXT.
Code-level fix: The prompt was clear and correct, but the implementation had a bug. This is the only case where a traditional "fix the code" approach is appropriate. Signal: the failure is in specific logic, not in misunderstanding.
Before doing anything else, determine the leverage point:
Read the failure output carefully. What exactly failed? Not "tests fail" but which test, which assertion, what value.
Compare failure against the prompt. Did the implementer build what the prompt asked for? If yes, the problem is the prompt or the plan, not the code. If no, it might be a code bug.
Check if this is systemic. Are other prompts in the same group failing? Do they share assumptions, context, or dependencies? If 2+ prompts fail in the same group, suspect a plan-level issue before investigating individual code bugs.
Classify:
Investigation depends on the leverage level. Use Read, Grep, Glob, and Bash (git diff, git log) to gather evidence — never guess.
For plan-level issues:
For prompt-level issues:
For code-level issues:
git diff via Bash)The fix depends on the leverage level:
Plan-level fix:
Prompt-level fix:
Code-level fix: Generate a root-cause-informed fix prompt:
Fix P{N}: {original description}
**Root cause**: {what was actually wrong, with evidence}
**Leverage point**: Code — the prompt was correct, the implementation had a bug
**What went wrong**: {the specific failure}
**Fix required**:
- {path/to/file} — {exact change needed and why}
**Do NOT**:
- {wrong fix that addresses the symptom}
- {scope creep that goes beyond the fix}
**Verification**: `{original verification}` AND confirm {specific fix evidence}
If a prompt has Retries >= 2 and this would be attempt #3:
STOP. Do not generate another fix.
This pattern indicates the fix is at the wrong leverage level. Three code-level fixes that don't work means the problem is at the prompt or plan level:
Instead:
blockedAfter resolving a failure, prepend an entry to [[Failure Patterns]] (the accumulating note in the vault — see [[conducty-obsidian]]):
### {YYYY-MM-DD HHmm} — {brief description}
- **Plan**: [[Plan YYYY-MM-DD HHmm Topic]]
- **Prompt**: see [[Prompt Log]] entry P{N}
- **Leverage point**: plan / prompt / code
- **Symptom**: {what the failure looked like}
- **Root cause**: {what was actually wrong}
- **Fix**: {what resolved it}
- **Prevention**: {what would prevent this in future prompts}
The pattern library is read by [[conducty-plan]] (Step 1) and [[conducty-improve]] to prevent repeat failures. A pattern that appears twice is a process gap, not bad luck. Prepend new entries (newest at top); never delete old ones.
When investigating a single failure, also check for systemic issues:
Systemic issues get plan-level or template-level fixes, not individual prompt fixes. Flag them for [[conducty-checkpoint]] and [[conducty-improve]].