メニュー
Structured debugging loop for exercise tests or build failures. Reproduce → isolate → hypothesize → fix → verify.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when a developer wants to apply a low-level, systems, or concurrency design pattern in their own code, drawing on the Battle-Tested Patterns catalog of 46 production-proven patterns. Triggers three ways: they name a pattern (ring buffer, circuit breaker, actor model, LRU cache, rate limiter, trie, bloom filter, WAL, semaphore, ...); they describe a problem one solves without naming it (fixed-size buffer that overwrites the oldest entry, cascading failures across services, throttling requests, deduplicating identical strings, ordering events without wall-clock time, snapshot isolation, prefix search, set membership without storing every key, ...); or they ask which pattern fits a problem or how two related patterns differ.
Use when reviewing or auditing an existing codebase against production-proven implementation patterns — checking whether the patterns it already implements (actor model, rate limiter, circuit breaker, LRU cache, write-ahead log, semaphore, ...) actually honor the canonical invariants, whether any are mislabeled (a "semaphore" that is really a mutex; an "MVCC" that keeps one version), whether any diverge from the reference, and which catalog patterns are absent. Triggers on "audit our architecture against best practices", "do we implement X correctly", "are our patterns right", "pattern conformance", "is this really a <pattern>?". This grades patterns already present; its companion adopt-pattern adds new ones.
Guided workflow to create a new pattern following the project template and quality standards. Walks through topic validation, source verification, implementation, exercises, challenge questions, and bilingual docs.
Verify all production proof source links in pattern documents. Run automated checks for HTTP status, format, SHA permanence, and line-range content accuracy.
| name | diagnose |
| description | Structured debugging loop for exercise tests or build failures. Reproduce → isolate → hypothesize → fix → verify. |
You are debugging a test failure or build error in this project. Follow the structured loop — do NOT jump to a fix without reproducing first.
Run the failing command and capture the exact error:
pnpm test # All tests (docs + exercises in TS/Rust/Go/Python)
pnpm test:rust # Rust only
pnpm test:go # Go only
pnpm test:python # Python only (auto-finds Python ≥ 3.10)
pnpm build # VitePress
Narrow down to the smallest failing unit:
State your hypothesis in one sentence before changing any code.
Add minimal logging or assertions to confirm/deny your hypothesis. Do NOT change production code yet.
Apply the minimal fix. Change as little as possible.
Run the full test suite, not just the failing test:
pnpm test && pnpm build
If it still fails, return to step 1 with what you learned.
If the bug was non-trivial, add a test that would have caught it.