メニュー
[Project Management] Use when you need to create UI/UX design specifications from requirements, PBIs, or user stories. Use --mode=wireframe to convert hand-drawn/digital wireframes or UI sketches into structured specs.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/duc01226/EasyPlatform --skill design-specコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
| name | design-spec |
| description | [Project Management] Use when you need to create UI/UX design specifications from requirements, PBIs, or user stories. Use --mode=wireframe to convert hand-drawn/digital wireframes or UI sketches into structured specs. |
Codex compatibility note:
- Invoke repository skills with
$skill-namein Codex; this mirrored copy rewrites legacy Claude/skill-namereferences.- Task tracker mandate: BEFORE executing any workflow or skill step, create/update task tracking for all steps and keep it synchronized as progress changes.
- User-question prompts mean to ask the user directly in Codex.
- Ignore Claude-specific mode-switch instructions when they appear.
- Strict execution contract: when a user explicitly invokes a skill, execute that skill protocol as written.
- Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required
spawn_agentsubagent(s) for that task.- Do not skip, reorder, or merge protocol steps unless the user explicitly approves the deviation first.
- For workflow skills, execute each listed child-skill step explicitly and report step-by-step evidence.
- If a required step/tool cannot run in this environment, stop and ask the user before adapting.
Codex uses static project-reference loading instead of runtime-injected project docs. When coding, planning, debugging, testing, or reviewing, open project docs explicitly using this routing.
Always read:
docs/project-config.json (project-specific paths, commands, modules, and workflow/test settings)docs/project-reference/docs-index-reference.md (routes to the full docs/project-reference/* catalog)docs/project-reference/lessons.md (always-on guardrails and anti-patterns)Missing/stale context route: If docs/project-config.json, the docs index, lessons.md, CLAUDE.md, AGENTS.md, or any task-required reference doc is missing or stale, auto-run $project-init or the narrow setup route ($project-config, $docs-init, $scan-all, $scan --target=<key>, $claude-md-init) before ordinary project-specific work. If Codex mirrors or AGENTS.md are missing/stale, ask the user to run $sync-codex; do not auto-run it.
Situation-based docs:
backend-patterns-reference.md, domain-entities-reference.md, project-structure-reference.mdfrontend-patterns-reference.md, scss-styling-guide.md, design-system/README.mddocs/specs/ pathing, or TC format: feature-spec-reference.md, spec-system-reference.md, spec-principles.mdworkflow-spec-test-code-cycle-reference.md plus the spec docs abovespec-system-reference.md and source Feature Specs under docs/specs/integration-test-reference.mde2e-test-reference.mdcode-review-rules.md plus domain docs above based on changed filesDo not read all docs blindly. Start from docs-index-reference.md, then open only relevant files for the task.
[BLOCKING] Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. [BLOCKING] Before each step or sub-skill call, update task tracking: set
in_progresswhen step starts, setcompletedwhen step ends. [BLOCKING] Every completed/skipped step MUST include brief evidence or explicit skip reason. [BLOCKING] If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions.
Goal: Create structured UI/UX design specification documents from requirements or PBIs for developer handoff.
Workflow:
team-artifacts/design-specs/Key Rules:
$figma-design for context extraction--mode=wireframe (see "Mode: wireframe" below)visual analysis tooling for design extractiondocs/project-reference/design-system/docs/project-reference/frontend-patterns-reference.mddocs/project-reference/spec-principles.md §3 — describe components by UX role, not framework/library names; source paths and class names appear ONLY in evidence fields (**Evidence**, [Source:]), frontmatter, and Mermaid.Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).
Create structured UI/UX design specification documents from requirements or PBIs for developer handoff.
$figma-design; wireframes are handled internally via --mode=wireframe — no need to call a separate skillfrontend-designweb-design-guidelinesRead before executing:
docs/project-reference/design-system/ -- project design tokens (if applicable)team-artifacts/design-specs/ for format consistencyWhen this task involves frontend or UI changes,
docs/project-reference/frontend-patterns-reference.mddocs/project-reference/scss-styling-guide.mddocs/project-reference/design-system/README.mdRead source input & route by type
| Input Detected | Detection | Action |
|---|---|---|
| Figma URL | figma.com/design or figma.com/file in text | Activate $figma-design to extract context, then continue |
| Image/screenshot | Image file attached to prompt | Use visual analysis tooling to extract design guidelines, then continue |
| Hand-drawn wireframe | Image + "wireframe"/"sketch" keyword | Run --mode=wireframe (internal — see "Mode: wireframe" section) |
| PBI/story text | Acceptance criteria present | Extract UI requirements from text, continue |
| Verbal/text requirements | No image, no URL, no PBI | Clarify with user, then continue |
For ANY visual input: extract design context FIRST, then proceed to spec generation.
Determine spec complexity
IF single form or simple component → Quick Spec (sections 1-4 only)
IF full page or multi-component view → Full Spec (all 7 sections)
IF multi-page flow → Full Spec + Flow Diagram
Build component inventory
Define states and interactions
Extract design tokens
Document responsive behavior
Save artifact — pick the filename variant by artifact type:
team-artifacts/design-specs/{YYMMDD}-designspec-{feature-slug}.mdteam-artifacts/design-specs/{YYMMDD}-ux-audit-{feature-slug}.mdteam-artifacts/design-specs/{YYMMDD}-ux-component-{component-name}.mdApplies to Writes under
team-artifacts/design-specs/.
team-artifacts/design-specs/ · Type: designspec · Role token: ux.claude/docs/team-artifacts/templates/design-spec-template.md{YYMMDD}-ux-{type}-{slug}.md (general artifact-path pattern: {YYMMDD}-{role}-{type}-{slug}.md)- [ ] All states documented · - [ ] Design tokens specified · - [ ] Accessibility notes included · - [ ] Responsive breakpoints definedInvoke with
--mode=wireframe(or whenever a hand-drawn wireframe, digital wireframe, or UI sketch is the input). This mode is an INPUT adapter: it analyzes the image, then flows into the normal spec sections (Output Format) and the M1-M5 compliance gate.design-specis the canonical owner of wireframe→spec conversion.
| Input | Detection | Action |
|---|---|---|
| Hand-drawn sketch photo | Image with rough/organic lines | Analyze with wireframe prompts (this mode) |
| Digital wireframe | Image with clean lines/shapes | Analyze with wireframe prompts (this mode) |
| Wireframe tool export | Image from Excalidraw/Balsamiq/MockFlow | Analyze with wireframe prompts (this mode) |
| Figma URL | figma.com in text | Route to $figma-design instead |
| App screenshot | Polished UI with real data | Route to $design --mode=screenshot instead |
Use visual analysis tooling with these prompts:
Prompt 1: Layout Extraction — "Analyze this wireframe image. Identify: (1) page layout regions (header, sidebar, main, footer), (2) all UI elements with approximate position and type (button, input, table, card, dropdown, modal, tabs), (3) content hierarchy (what is primary vs secondary), (4) interactive elements, (5) any text labels or annotations, (6) navigation patterns."
Prompt 2: Component Identification — "From the wireframe, list every distinct UI component. For each: name it descriptively, classify its complexity (primitive=single element, composite=grouped elements, section=page region), note its purpose."
After image analysis, generate (per the SYNC:ui-wireframe-protocol block below):
Apply the M1-M5 Compliance for UI Specs gate (below) to all wireframe-derived prose: business-level component names, no code-prop refs, map to feature logic by logical ID, observable state transitions, rebuild-from-spec.
Emit this table linking each interactive component to the feature operations/rules it drives (logical ID is the primary spine; mark [UNVERIFIED — needs feature-spec mapping] when the wireframe alone cannot determine it):
| Interactive Component | Interaction (observable) | Feature Operation / Rule (logical ID) | Notes |
|---|---|---|---|
| Primary Button | Click → submit form | OP-XX | Triggers create/update operation |
| Filter Dropdown | Select → reload list | OP-XX | Drives query/search operation |
| Row Action Menu | Click → confirm dialog | BR-XX | Guarded by authorization rule |
## UI Layout section compatible with PBI/story templates (consumed by $pbi-mockup).team-artifacts/design-specs/{YYMMDD}-wireframe-spec-{slug}.md.# Design Spec: {Feature Name}
**Source:** {PBI/story reference}
**Date:** {YYMMDD}
**Status:** Draft | Review | Approved
## 1. Overview
{1-2 sentence summary of what this UI does}
## 2. Component Inventory
| Component | Type | Source | Notes |
| --------- | -------- | ---------------- | --------------------------- |
| UserCard | New | Feature-specific | Displays user avatar + name |
| DataTable | Existing | shared library | Reuse with custom columns |
## 3. Layout
{Description or ASCII wireframe of layout structure}
- Desktop: {layout description}
- Tablet: {layout changes}
- Mobile: {layout changes}
## 4. Design Tokens
| Token | Value | Usage |
| ---------- | -------------- | --------------------- |
| $primary | #1976D2 | Action buttons, links |
| $text-body | 14px/1.5 Inter | Body text |
| $gap-md | 16px | Section spacing |
## 5. States & Interactions
| Element | Default | Hover | Active | Disabled | Error |
| -------- | ---------- | ---------- | ---------- | ---------------- | ----- |
| Save btn | Blue/white | Darken 10% | Scale 0.98 | Gray/50% opacity | -- |
## 6. Accessibility
- Keyboard navigation order
- ARIA labels for interactive elements
- Color contrast compliance notes
## 7. Open Questions
- {Any unresolved design decisions}
See .claude/skills/shared/sdd-artifact-contract.md → "AI-SDD Mandates (M1-M6)" for BLOCKING criteria. A UI spec MUST satisfy these before handoff:
**Evidence**/[Source:] carriers, frontmatter, and Mermaid.OP-/BR-/FR-) — link UI behavior back to the feature spec, not to handler code. Keep any [Source: namespace/service/id] abstract anchor strictly in the Evidence carrier — never physical code coordinates or repository-root paths.Define every state by what a user can SEE (color, icon, position, text), the business meaning, and the operation/rule that triggers it — NEVER by CSS class or component-state prop:
| State | Visual Markers (observable) | Business Meaning | Triggering Operation / Rule (logical ID) |
|---|---|---|---|
| Default | Primary fill color, enabled label, no spinner | Action available to the actor | OP-XX (entry state) |
| Loading | Spinner icon replaces label, control non-interactive | Operation in progress, awaiting result | OP-XX (request submitted) |
| Disabled | Muted/gray fill, label dimmed, no pointer affordance | Precondition not met / actor not permitted | BR-XX (authorization or guard rule) |
| Error | Error-color border, inline message text, alert icon | Operation rejected or validation failed | BR-XX (validation rule) |
| Empty | Placeholder illustration + guidance text, no data rows | No records exist for the current view | OP-XX (query returned zero results) |
| Success | Confirmation toast/checkmark, updated visible data | Operation completed and persisted | OP-XX (operation succeeded) |
Every interactive component MUST document all 7 states by their observable appearance and business meaning — never by CSS class or framework prop (see M2):
For an accessibility-audit deliverable, produce this checklist report and save it as {YYMMDD}-ux-audit-{feature-slug}.md:
## Accessibility Audit: {Feature}
**Date:** {Date}
**Auditor:** {Name}
**Standard:** WCAG 2.1 AA
### Criteria Checklist
#### Perceivable
- [ ] 1.1.1 Non-text Content: Alt text for images
- [ ] 1.3.1 Info and Relationships: Semantic HTML
- [ ] 1.3.2 Meaningful Sequence: Logical reading order
- [ ] 1.4.1 Use of Color: Not sole means of conveying info
- [ ] 1.4.3 Contrast (Minimum): 4.5:1 text, 3:1 large text
- [ ] 1.4.4 Resize Text: Readable at 200% zoom
- [ ] 1.4.11 Non-text Contrast: 3:1 for UI components
#### Operable
- [ ] 2.1.1 Keyboard: All functions keyboard accessible
- [ ] 2.1.2 No Keyboard Trap: Can navigate away
- [ ] 2.4.1 Bypass Blocks: Skip navigation available
- [ ] 2.4.3 Focus Order: Logical tab sequence
- [ ] 2.4.4 Link Purpose: Clear from link text
- [ ] 2.4.6 Headings and Labels: Descriptive
- [ ] 2.4.7 Focus Visible: Clear focus indicator
#### Understandable
- [ ] 3.1.1 Language of Page: lang attribute set
- [ ] 3.2.1 On Focus: No unexpected context change
- [ ] 3.2.2 On Input: No unexpected context change
- [ ] 3.3.1 Error Identification: Clear error messages
- [ ] 3.3.2 Labels or Instructions: Form labels present
#### Robust
- [ ] 4.1.1 Parsing: Valid HTML
- [ ] 4.1.2 Name, Role, Value: ARIA where needed
### Issues Found
| # | Criterion | Issue | Severity | Recommendation |
| --- | --------- | ----- | -------- | -------------- |
| 1 | | | P1/P2/P3 | |
### Audit Status: PASS / FAIL / CONDITIONAL
**Remediation Priority:**
{List items by severity}
Input: "Design spec for customer onboarding form"
Output: Quick Spec with sections 1-4 covering form fields (name, email, company name, plan-tier dropdown), validation rules, submit/cancel actions, and mobile stacking behavior.
Input: "Design spec for order pipeline dashboard with drag-and-drop columns"
Output: Full Spec covering Kanban board layout, order cards (component inventory), drag-and-drop interactions, column states (empty, populated, over-limit), filter bar, responsive collapse to list view on mobile, and accessibility for keyboard drag operations.
| Skill | When to use instead |
|---|---|
figma-design | Extract specs from Figma designs |
frontend-design | Build the actual UI implementation |
interface-design | Product UI design (dashboards, apps) |
web-design-guidelines | Review existing UI for compliance |
MANDATORY IMPORTANT MUST ATTENTION — NO EXCEPTIONS: If you are NOT already in a workflow, you MUST ATTENTION use a direct user question to ask the user. Do NOT judge task complexity or decide this is "simple enough to skip" — the user decides whether to use a workflow, not you:
- Run the design sequence (Recommended) —
$design-spec→$interface-design(product UIs) or$frontend-design(marketing/creative) →$workflow-review-changes- Execute
$design-specdirectly — run this skill standalone
[IMPORTANT] Use task tracking to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.
AI Mistake Prevention — Failure modes to avoid on every task:
Re-read files after context changes. Context compaction, resume, or long-running work can make memory stale; verify current files before acting. Verify generated content against source evidence. AI hallucinates APIs, names, claims, and document facts. Check the relevant source before documenting or referencing. Check downstream references before deleting or renaming. Removing an artifact can stale docs, generated mirrors, configs, and callers; map references first. Trace the full impact chain after edits. Changing a definition can miss derived outputs and consumers. Follow the affected chain before declaring done. Verify ALL affected outputs, not just the first. One green check is not all green checks; validate every output surface the change can affect. Assume existing values are intentional — ask WHY before changing. Before changing a constant, limit, flag, wording, or pattern, read nearby context and history. Surface ambiguity before acting — don't pick silently. Multiple valid interpretations require an explicit question or stated assumption with risk. Keep shared guidance role-relevant. Universal guidance must help every receiving skill or agent; code-specific obligations belong only in code-specific protocols.
UI System Context — For ANY task touching
.ts,.html,.scss, or.cssfiles:MUST ATTENTION READ before implementing:
docs/project-reference/frontend-patterns-reference.md— component base classes, stores, formsdocs/project-reference/scss-styling-guide.md— BEM methodology, SCSS variables, mixins, responsivedocs/project-reference/design-system/README.md— design tokens, component inventory, iconsReference
docs/project-config.jsonfor project-specific paths.
UI Wireframe Protocol — Wireframe-to-implementation flow: (1) Process design input (Figma/screenshot/sketch via visual analysis tooling). (2) Create ASCII wireframe with box-drawing chars. (3) Build component inventory with tier classification (Common/Domain-Shared/Page). (4) Document states (Default/Loading/Empty/Error). (5) Map to design tokens. (6) Define responsive breakpoints. Search existing component libraries before creating new. Progressive detail by skill level (idea=sketch, story=full tree+specs).
Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.
IMPORTANT MUST ATTENTION follow wireframe protocol: ASCII wireframe, component inventory with tiers, states table, design tokens, responsive breakpoints.
MUST ATTENTION apply critical + sequential thinking — every claim needs appropriate traced evidence (file:line for repo/code claims; source URL or artifact section for research, product, content, and docs claims); confidence >80% to act, <60% DO NOT recommend. Anti-hallucination: never present guess as fact, admit uncertainty freely, cross-reference independently, stay skeptical of own confidence.
MUST ATTENTION apply AI mistake prevention — verify generated content against evidence, trace downstream references before deleting or renaming, verify all affected outputs, re-read files after context loss, and surface ambiguity before acting.
IMPORTANT MUST ATTENTION follow declared step order for this skill; NEVER skip, reorder, or merge steps without explicit user approval
IMPORTANT MUST ATTENTION for every step/sub-skill call: set in_progress before execution, set completed after execution
IMPORTANT MUST ATTENTION every skipped step MUST include explicit reason; every completed step MUST include concise evidence
IMPORTANT MUST ATTENTION if Task tools unavailable, maintain an equivalent step-by-step plan tracker with synchronized statuses
IMPORTANT MUST ATTENTION Goal: Create structured, tech-agnostic UI/UX design specification documents from requirements or PBIs for developer handoff.
Protocols in force (concise digest of the SYNC/shared blocks this skill carries):
AI Mistake Prevention: verify generated content against evidence, trace downstream references, verify all affected outputs, re-read after context loss, surface ambiguity.
UI System Context: read frontend-patterns, scss-styling, design-system before any UI change.
UI Wireframe: ASCII wireframe, tiered component inventory, states table, tokens, responsive breakpoints.
Critical Thinking: traced file:line proof per claim, confidence >80% to act.
MANDATORY IMPORTANT MUST ATTENTION break work into small todo tasks using task tracking BEFORE starting
MANDATORY IMPORTANT MUST ATTENTION search codebase for 3+ similar patterns before creating new code
MANDATORY IMPORTANT MUST ATTENTION cite file:line evidence for every claim (confidence >80% to act)
MANDATORY IMPORTANT MUST ATTENTION add a final review todo task to verify work quality
[TASK-PLANNING] Before acting, analyze task scope and systematically break it into small todo tasks and sub-tasks using task tracking.
[IMPORTANT] Analyze how big the task is and break it into many small todo tasks systematically before starting — this is very important.
Source: .claude/.ck.json + .claude/skills/shared/sync-inline-versions.md (:full blocks) + .claude/scripts/lib/hookless-prompt-protocol.cjs
Generic portability boundary: Reusable skills and protocol text stay project-neutral; project-specific conventions are discovered from docs/project-config.json and docs/project-reference/. Apply shared AI-SDD from shared/sdd-artifact-contract.md. Read docs/project-config.json and docs/project-reference/docs-index-reference.md, then open the project reference docs named there. For spec, test-case, behavior-change, public-contract, or docs/specs/ work, route through the local spec docs named by the docs index: feature-spec-reference.md, spec-system-reference.md, spec-principles.md, and workflow-spec-test-code-cycle-reference.md when specs/tests/code must stay synchronized. If either file or a required reference doc is missing or stale, auto-run $project-init (or the narrow lower-level route such as $project-config, $docs-init, $scan-all, or $scan --target=<key>) before ordinary project-specific work. Any supported AI tool may execute when this shared context and local docs are available.
$start-workflow <workflowId>; for a selected skill, invoke that skill; for a custom workflow, sequence custom steps directly; for direct execution, proceed with the task.Source: .claude/skills/shared/sync-inline-versions.md
AI-SDD Artifact Contract — Shared spec-driven development rules stay portable and source-owned.
- Keep reusable AI-SDD principles in
.claude; put repository-specific paths, commands, owners, products, and formats in project config/reference docs.- Preserve cycle:
spec -> plan -> tasks -> implement -> verify -> update spec/docs.- Trace every requirement or invariant through decision, task, TC/test, source evidence, and docs/spec update.
- Treat code-to-spec extraction as reference-only until accepted by the canonical spec owner.
- Any supported AI tool may plan, implement, review, or verify with synced context; using multiple tools is optional.
- Update
.claudesource first, then sync generated mirrors; do not manually edit.agents,.codex, orAGENTS.md. — why: mirrors are generated artifacts; hand-edits are overwritten on the next sync- If
docs/project-config.json, root instruction files, or a required project-reference doc is missing or stale, auto-run$project-initor the narrow lower-level route before ordinary project-specific work.Active reference:
shared/sdd-artifact-contract.mdin the active skills root.
shared/sdd-artifact-contract.md; keep reusable AI-SDD in .claude and local rules in project docs..claude source before syncing generated mirrors; do not manually edit .agents, .codex, or AGENTS.md.$project-init or the narrow setup route automatically.
[TASK-PLANNING] [MANDATORY] BEFORE executing any workflow or skill step, create/update task tracking for all planned steps, then keep it synchronized as each step starts/completes.Break work into small tasks (task tracking) before starting. Add final task: "Analyze AI mistakes & lessons learned".
Extract lessons — ROOT CAUSE ONLY, not symptom fixes:
$learn.$code-review/$code-simplifier/$security-review/$lint catch this?" — Yes → improve review skill instead.$learn.
[CRITICAL-THINKING-MINDSET] Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act.
Anti-hallucination principle: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.
AI Attention principle (Primacy-Recency): Put the 3 most critical rules at both top and bottom of long prompts/protocols so instruction adherence survives long context windows.
Goal-driven execution: Define success criteria first, loop until verified, and stop only when observable checks pass.
Tests verify intent: Tests must protect business rules/invariants and fail when the protected intent breaks, not only mirror current behavior.$start-workflow <workflowId>. NEVER answer or write code before checking. Skip = protocol violation.SOC 職業分類に基づく