메뉴
Stress-test a plan against the project's domain model. Challenges terminology, cross-references code, updates CONTEXT.md and ADRs inline. Use when user wants to validate a plan against domain language, sharpen terminology, or mentions "domain model".
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Exercise software as real consumer would — docs-first walkthrough, full public surface coverage, adversarial misuse — producing a ranked friction report. Works for any software type (library, CLI, server/API, web UI, TUI). Use when user says "dogfood", "exercise as a consumer/user", "friction report", "consumer trial", "try it like a real user", or as harden skill Phase 1 (Exercise → friction). Re-eval mode re-runs a prior report for a resolved/still-live delta.
Iterative refinement loop for taking a change to a high quality bar. Sequences exercise→friction, grill→decide, TDD slices, then review→soundness→simplify→architecture→test-health→docs passes — repeating until a full round finds nothing significant — under fixed discipline (authority docs sacred, commit per slice, verify every slice, reverse your own calls on evidence, capture decisions durably). Use when the user wants to build or refine something "properly", harden a change, run a multi-pass quality loop, evaluate an API as a real consumer, or asks to "harden", "do this properly", "full quality pass", "refine loop", "keep going until clean", or "production-grade" work. Gated — stops for the user's call at authority conflicts, fix decisions, architecture do/decline, and irreversible actions.
MUST be used for every git commit. Formats Conventional Commit messages, checks for breaking changes, and stages files atomically.
Collaborative specification refinement through codebase analysis, discovery interviews, and iterative red-teaming. Use when user wants to write a spec, refine requirements, design a feature, or mentions "spec", "requirements", "PRD", or "specification".
Break a plan or spec into vertical-slice tasks. Use when user wants to break down work into tasks, slice a spec into implementable pieces, or mentions "to-tasks", "break down", "task breakdown", or "slice".
Audit and improve a user-facing entry doc (README, docs-site landing, man-page intro, getting-started guide) for factual accuracy and for three reader audiences — evaluator, newcomer, returner. Use when asked to "improve/proofread/audit the readme (or docs)", "is my readme any good", "make the docs clearer / more motivating", or to check docs for stale/inaccurate information.
| name | domain-model |
| description | Stress-test a plan against the project's domain model. Challenges terminology, cross-references code, updates CONTEXT.md and ADRs inline. Use when user wants to validate a plan against domain language, sharpen terminology, or mentions "domain model". |
Grilling session that challenges a plan against the project's existing domain language and documented decisions. Updates documentation inline as decisions crystallize.
| When | Load |
|---|---|
| Skill activation | Read CONTEXT.md + docs/adr/ |
| Term resolved | context-format.md |
| ADR needed | adr-format.md |
Work from whatever plan is in conversation context — /to-spec output, GitHub issue, architecture proposal, or loose description. If no plan exists, ask user what to grill.
Find existing documentation. See context-format.md for single-context vs multi-context structure. Create files lazily — only when first term resolved or first ADR needed.
Cross-ref: /improve-architecture for structural analysis, /ubiquitous-language for batch glossary extraction.
Then begin grilling.
Interview relentlessly — one question at a time. For each question, provide recommended answer. If a question can be answered by exploring the codebase, explore instead of asking.
When user uses a term that conflicts with CONTEXT.md, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
Also surface glossary-vs-code drift: if CONTEXT.md says "Order" means X but code uses it as Y, that's a finding — one of them is wrong.
When 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."
Stress-test domain relationships with specific scenarios. Invent edge cases that force precision about boundaries between concepts.
When 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 right?"
When a term is resolved, update CONTEXT.md immediately — don't batch. Use context-format.md. Only include terms meaningful to domain experts, not implementation details.
Only when the decision passes the three-gate check. See adr-format.md for criteria and format.
All terms in the plan are sharp, no glossary conflicts remain, code-vs-plan contradictions are resolved or explicitly accepted. If new ambiguity surfaces, keep going.
