
Writing Design Plans
- 11 installs
- 233 repo stars
- Updated June 23, 2026
- owl-listener/designpowers
Helps with ai & agent building tasks during AI-assisted development.
About
writing-design-plans is a Claude Code skill for ai & agent building. It helps developers move faster with AI-assisted coding.
- writing-design-plans
- AI & Agent Building
- AI-coding skill
Writing Design Plans by the numbers
- 11 all-time installs (skills.sh)
- Ranked #11,769 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 1, 2026 (Skillselion catalog sync)
npx skills add https://github.com/owl-listener/designpowers --skill writing-design-plansAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 11 |
|---|---|
| repo stars | ★ 233 |
| Last updated | June 23, 2026 |
| Repository | owl-listener/designpowers ↗ |
What it does
Helps with ai & agent building tasks during AI-assisted development.
Files
Writing Design Plans
A design plan breaks an approved design direction into discrete, reviewable tasks. Each task is small enough to evaluate clearly and specific enough that the result is predictable.
When to Use
- After design-discovery and/or design-strategy have produced an approved direction
- Before any implementation work begins
- When a design task is too large to complete and review in one step
Process
Step 1: Review Inputs
Gather:
- Design brief (from design-discovery)
- Strategy document (from design-strategy, if applicable)
- Personas (from inclusive-personas)
- Existing design system inventory
Step 2: Identify Design Tasks
Break the work into categories:
1. Structure tasks — information architecture, page hierarchy, navigation 2. Component tasks — individual UI components that need designing 3. Layout tasks — how components compose into screens 4. Interaction tasks — states, transitions, feedback patterns 5. Content tasks — copy, labels, error messages, help text 6. Accessibility tasks — specific inclusive design requirements per component
Step 3: Order the Work
Design work has natural dependencies:
Structure → Layout → Components → Interactions → Content → Review
↑ accessibility woven through each step, not a final phase ↑Order tasks so that:
- Foundation work (structure, layout) comes before detail work (interactions, content)
- Each task can be reviewed independently
- Accessibility is addressed within each task, not deferred
Step 4: Write the Plan
# Design Plan: [Feature/Project Name]
> **For agentic workers:** REQUIRED: Use designpowers:designpowers-critique to review completed work against this plan.
**Goal:** [One sentence — what this plan delivers]
**Design Direction:** [Reference to the design brief or strategy]
**Personas:** [Reference to personas this plan serves]
---
## Task 1: [Task Name]
**Files:** [Which files will be created or modified]
- [ ] Step 1: [Specific action]
- [ ] Step 2: [Specific action]
- [ ] Step 3: [Specific action]
**Accessibility check:** [What inclusive design criteria this task must meet]
**Verification:** [How to confirm this task is complete and correct]
---
## Task 2: [Task Name]
...Step 5: Task Sizing
Each task should be:
- 2-5 minutes of focused work — small enough to hold in your head
- Independently reviewable — someone can evaluate it without seeing everything else
- Specifically described — exact files, exact components, exact acceptance criteria
- Accessibility-inclusive — each task addresses its own inclusive design requirements
If a task takes longer than 5 minutes, break it down further.
Step 6: Save and Review
Save to: docs/designpowers/plans/YYYY-MM-DD-<feature>-plan.md
Present the plan to the user. Walk through:
- Does the task order make sense?
- Are any tasks missing?
- Are the accessibility checks appropriate for each task?
- Is the scope right, or should anything be deferred?
User must approve the plan before execution begins.
Integration
- Called by:
design-discovery,design-strategy - Calls: Implementation begins via the relevant design skills (
ui-composition,interaction-design, etc.) - Pairs with:
designpowers-critique(reviews work against the plan)
Anti-Patterns
| Pattern | Problem |
|---|---|
| Tasks without accessibility checks | Every task affects the user experience. Every task has accessibility implications |
| Tasks that say "make it look good" | Vague tasks produce vague results. Be specific about what "good" means |
| Accessibility as the final task | By then it is too late. Accessibility is in every task |
| Plan without persona references | If you do not know who you are designing for, you cannot verify the design works |