Purpose
Use this skill when a product, UI, or workflow decision needs a stable decision surface before implementation.
Trigger
- A feature touches user flows, screens, copy, navigation, forms, dashboards, or visual hierarchy
- Multiple implementation lanes need one agreed product/interface contract
- Acceptance criteria exist, but the desired interaction states or content hierarchy are still fuzzy
- A redesign or frontend change needs accessibility and responsive behavior called out before coding
Workflow
- Identify target users, core job, success signal, and non-goals.
- Map the primary workflow from entry through success and recovery paths.
- Define interface decisions by surface, including empty, loading, error, disabled, and success states.
- Capture content hierarchy, navigation, controls, responsive behavior, and accessibility constraints.
- Mark assumptions and open questions separately from firm decisions.
- Attach implementation owners, affected files or surfaces, and verification evidence.
- Recommend whether to persist the result to
.omg/state/blueprint.md before team-plan or team-prd.
Output Template
## Product Frame
- Target users:
- Core job:
- Success signal:
- Non-goals:
## Workflow Map
| Flow | Entry | Steps | Exit / Success | Failure / Recovery |
| --- | --- | --- | --- | --- |
## Interface Decisions
| Surface | Decision | Rationale | State Coverage | Owner | Evidence |
| --- | --- | --- | --- | --- | --- |
## Content / IA
- ...
## Accessibility / Responsiveness
- ...
## Open Questions
- ...
## Handoff
- Recommended next command:
- Taskboard sync:
- Verification notes:
1---2name: blueprint3description: Purpose4---56## Purpose78Use this skill when a product, UI, or workflow decision needs a stable decision surface before implementation.910## Trigger1112- A feature touches user flows, screens, copy, navigation, forms, dashboards, or visual hierarchy13- Multiple implementation lanes need one agreed product/interface contract14- Acceptance criteria exist, but the desired interaction states or content hierarchy are still fuzzy15- A redesign or frontend change needs accessibility and responsive behavior called out before coding1617## Workflow18191. Identify target users, core job, success signal, and non-goals.202. Map the primary workflow from entry through success and recovery paths.213. Define interface decisions by surface, including empty, loading, error, disabled, and success states.224. Capture content hierarchy, navigation, controls, responsive behavior, and accessibility constraints.235. Mark assumptions and open questions separately from firm decisions.246. Attach implementation owners, affected files or surfaces, and verification evidence.257. Recommend whether to persist the result to `.omg/state/blueprint.md` before `team-plan` or `team-prd`.2627## Output Template2829```markdown30## Product Frame31- Target users:32- Core job:33- Success signal:34- Non-goals:3536## Workflow Map37| Flow | Entry | Steps | Exit / Success | Failure / Recovery |38| --- | --- | --- | --- | --- |3940## Interface Decisions41| Surface | Decision | Rationale | State Coverage | Owner | Evidence |42| --- | --- | --- | --- | --- | --- |4344## Content / IA45- ...4647## Accessibility / Responsiveness48- ...4950## Open Questions51- ...5253## Handoff54- Recommended next command:55- Taskboard sync:56- Verification notes:57```
Joonghyun-Lee-Frieren