메뉴
Build CONTEXT.md (domain glossary) + docs/adr/ via interview; keeps agent vocab aligned. Triggers "domain language", "glossary", "ADR", inconsistent terminology.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Lock file edits to one directory for the session — Edit/Write outside it are blocked, not just warned. Use when debugging to stop accidental edits to unrelated code, or to fence a parallel agent to one module. Triggers "freeze edits", "lock editing scope", "restrict edits to", "only edit this folder", "unfreeze", "lift the freeze".
Lighthouse audit + improvement loop until targets met. Triggers "lighthouse", "performance audit", "page speed", "improve scores", "LCP", "CLS", "INP", "core web vitals".
Extremely strict whole-codebase maintainability audit — checks structural quality, 1k-line file sprawl, thin wrappers, leaked logic, spaghetti growth, and dependency freshness + usage quality via context7. Pushes "code-judo" moves that delete whole branches instead of rearranging them. When fixes land, the same pass updates CHANGELOG, MANUAL, and derived schemas so the docs don't drift. Triggers "nuclear review", "thermonuclear review", "thermo-nuclear code quality review", "code judo", "deep code quality audit", "harsh maintainability review", "whole codebase review". Sibling to `/review` (per-diff Darkroom checklist) and `/zero-tech-debt` (rework patch to end-state).
Adversarial whole-repo audits in three goal-spec modes — hunt defects, drift, and dead ends rather than validate. Triggers "adversarial audit", "fable audit", "audit the codebase", "expectation gaps" (codebase mode - correctness, incoherences, affordance mismatches); "audit the docs", "docs audit", "documentation audit", "doc drift" (docs mode - accuracy vs code, inverted pyramid, doc sizing, diagram backlog); "process audit", "audit the workflows", "walk the journeys", "end-to-end audit" (process mode - empirical journey walking, state-machine map, dead ends, re-run semantics). Sibling to /nuclear-review (maintainability + code-judo deletion) - this skill audits whether the system does what it promises, not whether it should exist.
CEO/founder-mode plan review. Stress-tests plans through a product lens. Use when: - User says "ceo review", "founder review", "product review" - User wants to challenge whether they're solving the right problem - User asks "is this the right approach?", "should we even build this?" - Before committing to a large feature or architectural change - User wants to evaluate a plan from a product/business perspective
Local pre-commit review of unstaged/staged diff against the Darkroom quality checklist (TypeScript, React, a11y, perf, security). Also summarizes inbound PR review comments on the active PR. Distinct from native /review which inspects open PRs. Triggers "review my changes", "check this diff", "feedback on this code", "PR comments", "what did reviewers say", "summarize PR feedback", post-implementation self-review before commit.
| name | context-doc |
| description | Build CONTEXT.md (domain glossary) + docs/adr/ via interview; keeps agent vocab aligned. Triggers "domain language", "glossary", "ADR", inconsistent terminology. |
Two persistent artifacts that stop agent drift across sessions:
CONTEXT.md — the project's glossary. The terms domain experts and engineers both use. Updated inline as decisions crystallize.docs/adr/ — architecture decision records. One paragraph per hard-to-reverse trade-off.This skill produces both. Other skills read them via DOMAIN-AWARENESS.md (consumer rules in the same directory).
Interview the user relentlessly about every aspect of the plan, terminology, or area in question until you reach shared understanding. Walk down each branch of the design tree, resolving dependencies one at a time. For each question, propose a recommended answer.
One question at a time. Wait for feedback before continuing.
If a question can be answered by reading code, read the code instead. Don't ask the user what git blame will tell you.
Challenge against the glossary. When the user uses a term that conflicts with the existing language in CONTEXT.md, call it out: "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
Sharpen fuzzy language. When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
Discuss concrete scenarios. When domain relationships are being discussed, stress-test them with specific scenarios. Invent edge cases that force the user to be precise about boundaries between concepts.
Cross-reference with code. When the user states how something works, check whether the code agrees. Surface contradictions: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is it?"
Update CONTEXT.md inline. When a term is resolved, update the file right there. Don't batch. Format: see CONTEXT-FORMAT.md.
Don't couple CONTEXT.md to implementation. Only include terms meaningful to domain experts. "Timeout" is generic; "ShipmentDispatched" is domain.
For the directory layout (single-context vs multi-context with CONTEXT-MAP.md), see DOMAIN-AWARENESS.md. Create files lazily — no CONTEXT.md? Create one when the first term is resolved. No docs/adr/? Create it when the first ADR is needed.
See ADR-FORMAT.md for the three-criterion threshold (hard to reverse, surprising without context, real trade-off) and the format. If a decision misses any criterion, skip the ADR. Most decisions don't qualify.