メニュー
Plan the UX and UI for a feature before writing code. Runs a structured discovery interview, then produces a design brief that guides implementation. Use during the planning phase to establish design direction, constraints, and strategy before any code is written.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
Compact the current conversation into a handoff document for another agent to pick up.
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
Build a throwaway prototype to flesh out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".
| name | shape |
| description | Plan the UX and UI for a feature before writing code. Runs a structured discovery interview, then produces a design brief that guides implementation. Use during the planning phase to establish design direction, constraints, and strategy before any code is written. |
Use $impeccable, which contains design principles, anti-patterns, and the Context Gathering Protocol. Follow the protocol before proceeding. If no design context exists yet, you MUST use $impeccable teach first.
Shape the UX and UI for a feature before any code is written. This skill produces a design brief: a structured artifact that guides implementation through discovery, not guesswork.
Scope: Design planning only. This skill does NOT write code. It produces the thinking that makes code good.
Output: A design brief that can be handed off to $impeccable craft, $impeccable, or any other implementation skill.
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply first, so implementation is precise.
Do NOT write any code or make any design decisions during this phase. Your only job is to understand the feature deeply enough to make excellent design decisions later.
Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. STOP and ask the user to clarify.
After the interview, synthesize everything into a structured design brief. Present it to the user for confirmation before considering this skill complete.
1. Feature Summary (2-3 sentences) What this is, who it's for, what it needs to accomplish.
2. Primary User Action The single most important thing a user should do or understand here.
3. Design Direction
How this should feel. What aesthetic approach fits. Reference the project's design context from .impeccable.md and explain how this feature should express it.
4. Layout Strategy High-level spatial approach: what gets emphasis, what's secondary, how information flows. Describe the visual hierarchy and rhythm, not specific CSS.
5. Key States List every state the feature needs: default, empty, loading, error, success, edge cases. For each, note what the user needs to see and feel.
6. Interaction Model How users interact with this feature. What happens on click, hover, scroll? What feedback do they get? What's the flow from entry to completion?
7. Content Requirements What copy, labels, empty state messages, error messages, and microcopy are needed. Note any dynamic content and its realistic ranges.
8. Recommended References Based on the brief, list which impeccable reference files would be most valuable during implementation (e.g., spatial-design.md for complex layouts, motion-design.md for animated features, interaction-design.md for form-heavy features).
9. Open Questions Anything unresolved that the implementer should resolve during build.
STOP and ask the user to clarify. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
Once confirmed, the brief is complete. The user can now hand it to $impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use $impeccable craft instead, which runs this skill internally.)
