// Use before declaring any design work complete, fixed, or ready — requires running verification and confirming output before making any success claims. Evidence before assertions, always
| name | verification-before-shipping |
| description | Use before declaring any design work complete, fixed, or ready — requires running verification and confirming output before making any success claims. Evidence before assertions, always |
Do not say it is done until you have proof. This skill prevents the most common failure mode in design work — declaring completion based on intent rather than evidence.
NEVER claim work is complete, fixed, passing, or ready without running verification and confirming the output. "I believe this works" is not verification. "I ran these checks and here are the results" is.
If a design plan exists:
Reference the design brief:
Run — do not guess:
If code exists:
If design artefacts only:
For each persona from the inclusive-personas phase:
Before declaring the project shippable, review the Design Debt Register in design-state.md:
Present verification results to the user:
## Verification Report: [Feature/Task]
**Date:** [YYYY-MM-DD]
### Plan Completion
[All tasks complete / X tasks remaining]
### Brief Alignment
[Aligned / Gaps identified]
### Accessibility Results
- Automated scan: [Pass/Fail — specific issues]
- Keyboard: [Pass/Fail — specific issues]
- Screen reader: [Pass/Fail — specific issues]
- Zoom: [Pass/Fail — specific issues]
- Motion: [Pass/Fail — specific issues]
### Content Status
[Complete / Gaps identified]
### Persona Walkthrough
[Summary of persona-by-persona evaluation]
### Design Debt Status
- Open items shipping with this release: [count]
- Escalated items: [count] — [resolved/accepted]
- Accessibility debt accepted: [count] — [summary]
- Oldest unresolved: [DD-XXX] from [date]
### Verdict
[Ready to ship / Issues to resolve first]
designpowers-critique, design-handoffIf you cannot produce evidence that the design works for the identified personas — including those at the margins of the ability spectrum — it is not done. Go back and verify.
MUST run before any other Designpowers skill — shows welcome, checks taste profile, and routes to the correct first skill. Triggers on ANY design-related message. No other Designpowers skill may run until the welcome sequence has completed
You MUST use this before any creative or design work — building features, creating components, designing interfaces, modifying user-facing behaviour. Explores intent, constraints, users, and context before any design decisions are made
Use when starting a new project or when taste decisions are made — accumulates the user's aesthetic preferences, recurring patterns, and design instincts across projects so each new project starts with what the system already knows about their taste
Use when any Designpowers agent starts work or completes work — maintains the shared design state file that all agents read from and write to. Invoke to initialise, read, or update the living design state document
Use when setting design direction — establishing principles, competitive positioning, experience mapping, or aligning stakeholders on what the design should achieve and why
Use when calibrating aesthetic direction — capturing design references, quality benchmarks, and the subjective qualities that make a design feel elevated. Invoked between strategy and design to give agents a shared sense of what "good" looks and feels like for this project