メニュー
Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology, record an architectural decision, or when another skill needs to maintain the domain model.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Drive a subject to convergence by repeatedly completing its critique-generated Dex epic, re-running the same critique, and reporting what changed — until it's clean or hits a stop condition. Use when asked to "loop the critique", "keep fixing until clean", "re-critique after the fixes", "iterate on the design/UX until it converges", "complete the epic then re-run the critic", or "run the critique loop". Works with any critique that emits the shared report contract (ui-design-critique, ux-critique, …).
Design critique for user interfaces that produces a prioritized, strict report of design issues. Use when asked to "critique this design", "review the UI", "design review", "roast my UI", "is this AI slop", "does this look AI-generated", "audit the visual design", or evaluate a screen, page, or screenshot against brand guidelines or a DESIGN.md spec. Classifies every finding as a gap, inconsistency, suggestion, or strength and ranks it by impact. Runs deterministic DOM detectors to catch broken layout (overflow, overlap, clipping) and evaluates visually via browser/devtools capture and against design tokens.
Convert a prioritized critique or findings report into a Dex epic with tasks. Use when asked to "turn this critique into tasks", "make a dex epic from these findings", "create tasks from the design review", "add these to dex", or "backlog this critique". Works with any prioritized findings list — including the ui-design-critique report — by normalizing to a common contract, then creating a Dex epic with priority-ranked, well-contextualized tasks.
Interview the user to create a unique DESIGN.md that defines an app's look. Use when asked to "grill me for a design.md", "create a design spec", "define the app's look", "make a DESIGN.md", "build a brand/design system doc", or "interview me for a visual identity". Grills one question at a time toward a committed, non-generic identity, then authors a valid DESIGN.md (tokens + prose) and lints it. Actively steers away from AI-slop defaults.
Interview the user to define who an app's users actually are. Use when asked to "define our users", "identify the users", "who is this for", "create user personas", "make a USERS.md", "define the target audience", or "what user types do we have". Grills one question at a time to produce a USERS.md — multiple distinct user types with their goals, context, proficiency, motivations, frustrations, and the cues that make each feel "this is for me".
UX critique for interfaces and flows that produces a prioritized, strict report of experience issues. Use when asked to "critique the UX", "UX review", "usability review", "heuristic evaluation", "why is this flow confusing", "is this hard to use", "find friction", or evaluate whether a user can complete a task. Walks the actual flow, classifies every finding as a gap, inconsistency, suggestion, or strength, and ranks by impact on task success. Flags dark patterns. Shares the critique report contract with ui-design-critique so critique-to-dex ingests it directly.
| name | domain-modeling |
| description | Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology, record an architectural decision, or when another skill needs to maintain the domain model. |
Actively build and sharpen the project's domain model as you design. This is the active discipline: challenge terms, invent edge-case scenarios, and write the glossary and decisions down the moment they crystallize.
Merely reading CONTEXT.md for vocabulary is not this skill. This skill is for when you are changing the model, not just consuming it.
Most repos have a single context:
/
|-- CONTEXT.md
|-- docs/
| `-- adr/
| |-- 0001-event-sourced-orders.md
| `-- 0002-postgres-for-write-model.md
`-- src/
If a CONTEXT-MAP.md exists at the root, the repo has multiple contexts. The map points to where each one lives:
/
|-- CONTEXT-MAP.md
|-- docs/
| `-- adr/ # system-wide decisions
`-- src/
|-- ordering/
| |-- CONTEXT.md
| `-- docs/adr/ # context-specific decisions
`-- billing/
|-- CONTEXT.md
`-- docs/adr/
Create files lazily, only when you have something to write. If no CONTEXT.md exists, create one when the first term is resolved. If no docs/adr/ exists, create it when the first ADR is needed.
When the user uses a term that conflicts with the existing language in CONTEXT.md, call it out immediately.
Example: "Your glossary defines 'cancellation' as X, but you seem to mean Y. Which is it?"
When the user uses vague or overloaded terms, propose a precise canonical term.
Example: "You're saying 'account'. Do you mean the Customer or the User? Those are different things."
When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
When the user states how something works, check whether the code agrees. If you find a contradiction, surface it.
Example: "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. Do not batch these up. Use the format in CONTEXT-FORMAT.md.
CONTEXT.md should be totally devoid of implementation details. Do not treat CONTEXT.md as a spec, scratch pad, or repository for implementation decisions. It is a glossary and nothing else.
Only offer to create an ADR when all three are true:
If any of the three is missing, skip the ADR. Use the format in ADR-FORMAT.md.