메뉴
Cavekit bug-to-spec protocol. Use on test failures, user bug reports, post-mortems, or /ck:check violations to trace root cause and decide what §B and §V updates should be made through cavekit-spec.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Reviews implementation architecture with firm, evidence-based judgment: separation of concerns, maintainability, ownership, dependency direction, stability/change boundaries, validation, persistence/state ownership, runtime coordination, Conway fit, evolution strategy, and refactoring discipline. Use when asked for architecture review of module/package boundaries, cross-capability dependencies, shared code, abstraction drift, validation placement, service boundaries, strangler work, branch-by-abstraction changes, or refactoring claims.
Reviews data movement and structural resource costs: filtering, pagination, streaming, materialization, copying/cloning, allocation, serialization/parsing, batching, N+1 I/O, backpressure, lock contention, and APIs that force callers to pay unnecessary costs. Use when asked for data-flow or performance review of data-heavy paths, persistence/search/streaming APIs, parsers, async workflows, hot paths, batch jobs, CLI pipelines, or hidden memory/throughput risks.
Review delivered code, CI, config, and generated assets. Use when explicit implementation review is requested; OpenSpec artifacts are optional context.
Reviews implementation security by tracing assets, actors, attacker-controlled input, trust boundaries, enforcement points, and sinks across auth, authorization, injection, command/path/URL handling, deserialization, secrets, logs, resource exhaustion, races, supply-chain, and crypto surfaces. Use when asked for security review of external inputs, auth flows, APIs, CLI commands, file/network/subprocess access, stored payloads, dependency scripts, tenant isolation, privilege boundaries, or security-sensitive assumptions.
Reviews implementation test quality by judging whether tests prove required behavior, invariants, failure modes, and realistic regressions across the relevant codebase. Use when asked for test review of meaningful coverage, public APIs, CLIs, generated outputs, validators, parsers, persistence, mocks, snapshots, property tests, fuzzing, or regression gaps.
Explain Caveman token-stats support in Pi. Upstream Caveman stats are powered by Claude Code hooks and session logs; this Pi package does not fake token savings. Triggers on /skill:caveman-stats or "caveman stats".
| name | cavekit-backprop |
| description | Cavekit bug-to-spec protocol. Use on test failures, user bug reports, post-mortems, or /ck:check violations to trace root cause and decide what §B and §V updates should be made through cavekit-spec. |
Plan-then-execute fixes code and forgets. Cavekit backprop fixes code and updates SPEC.md so recurrence is harder.
Backprop analysis is usually paired with cavekit-spec, which performs approved SPEC.md mutations.
Read bundled ../../FORMAT.md before drafting §B or §V entries.
/ck:build verification fails./ck:check flags VIOLATE or DRIFT and root cause is found.Read failure output or bug report. Find exact file:line or behavior boundary. Name root cause in one concise sentence.
Ask:
Draft changes. Do not silently apply unless the user explicitly requested direct mutation.
Template:
§B row: B<next>|<date>|<root cause>|V<N>
§V line: V<next>: <testable rule that would have caught it>
If no invariant is useful, use - in the §B fix cell and explain why.
Example:
§B row: B3|2026-04-20|refund job ran twice on retry|V7
§V line: V7: ∀ refund → idempotency key check before charge reversal
New invariant without verification is weak. Propose a test or check that cites the invariant, for example TestV7_RefundIdempotent.
If implementation work is in scope, fix code and run the targeted test plus appropriate suite. If this skill is being used for analysis only, hand the test/code work back to /ck:build.
Use cavekit-spec to append §B and §V/§T changes after user approval. Do not commit automatically; commit only when explicitly requested by the user in this session.
Bad:
V8: code should be correct.
Good:
V8: ∀ pg_query ! params via driver, ⊥ string concat.
Still record a §B entry so future similar failures have precedent.
Every backprop analysis should produce:
/ck:spec bug: ..., /ck:build ..., or fix code.