メニュー
Enforces root-cause investigation before any fix is proposed or implemented. Use when encountering a bug, test failure, or unexpected behavior, before proposing or implementing a fix.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Cut a Superpipelines version release (vX.Y.Z) — verify the 5 version targets agree, draft CHANGELOG + RELEASE-NOTES entries, land them via PR (main is branch-protected), then create the GitHub release + tag and verify. Use when the user asks to cut/ship/publish a release, tag a version, do release work, or write release notes for Superpipelines.
Resolves agent `model_tier:` declarations into concrete platform-specific model strings and effort values via a 5-layer precedence chain, returning a serializable `resolved` object for dispatch. Use when `running-a-pipeline` Phase 0.45 needs to determine the concrete model + effort for each pipeline step on the active platform before dispatch.
Resolves the active runtime tier and provides the canonical DISPATCH contract for all pipeline step execution. Use when an orchestrator skill needs to dispatch pipeline steps — performs tier detection, loads the platform profile, and executes the Tier 2 inline loop when no subagent primitive is available.
Cut a Superpipelines version release (vX.Y.Z) — verify the 5 version targets agree, draft CHANGELOG + RELEASE-NOTES entries, land them via PR (main is branch-protected), then create the GitHub release + tag and verify. Use when the user asks to cut/ship/publish a release, tag a version, do release work, or write release notes for Superpipelines.
Run, resume, or list installed Superpipelines workflows from the registry.
Provides canonical engineering standards for authoring agents, skills, hooks, and pipeline orchestration in Claude Code. Use when authoring or modifying agents, skills, hooks, or pipeline-orchestration artifacts — covers model-tier selection, prompt-cache discipline, frontmatter schemas, and progressive-disclosure rules.
| name | systematic-debugging |
| description | Enforces root-cause investigation before any fix is proposed or implemented. Use when encountering a bug, test failure, or unexpected behavior, before proposing or implementing a fix. |
Systematic Debugging is based on the Iron Law: **NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST**. It replaces guess-and-check thrashing with a scientific method—Read, Reproduce, Hypothesize, and Test—ensuring that fixes address the underlying problem rather than masking symptoms. The original source of a failure; fixing it prevents the symptom from recurring. A patch that hides a failure without addressing the cause; leads to technical debt and regression. The non-negotiable rule prohibiting any fix proposal until Phase 1 is complete.Establishes a rigorous methodology for identifying, isolating, and resolving technical issues before any fix is proposed.
test-driven-development skill).<rationalization_table>
| Excuse | Reality |
|---|---|
| "The issue is too simple for process." | Simple issues have root causes. Process is faster than guessing even for minor bugs. |
| "Emergency, no time for investigation." | Systematic debugging is 5x faster than guess-and-check thrashing during crises. |
| "I see the problem, let me fix it." | Seeing a symptom is not the same as understanding the trigger. |
| "Multiple fixes at once save time." | Bundled fixes make it impossible to isolate the true resolution. |
| </rationalization_table> |
test-driven-development/SKILL.md — Creating failing tests.verification-before-completion/SKILL.md — Final verification protocol.sk-pipeline-state/SKILL.md — Debugging state corruption.root-cause-tracing.md — Backward tracing techniques.