From designpowers
Maintains a living design debt register in design-state.md, tracking deferred minor issues and notes from critiques and accessibility reviews for iteration planning.
npx claudepluginhub owl-listener/designpowers --plugin designpowersThis skill uses the workspace's default tool permissions.
Design debt is every conscious compromise the team makes and every minor issue deferred to "next time." Like technical debt, it compounds. Unlike technical debt, most teams don't track it — so it disappears into the gap between what was shipped and what was intended.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Audits ECC Tools repo for cost burns from runaway PR creation, quota bypasses, premium-model leakage, duplicate jobs, and GitHub App spikes.
Design debt is every conscious compromise the team makes and every minor issue deferred to "next time." Like technical debt, it compounds. Unlike technical debt, most teams don't track it — so it disappears into the gap between what was shipped and what was intended.
This skill maintains a living register that captures debt as it's created, tracks it across iterations, and surfaces it when decisions are being made.
The design-critic classifies findings as Critical, Major, Minor, and Note. Critical and Major get fixed. Minor and Note get a shrug and "fix if time allows." They rarely get fixed because no one remembers them.
The accessibility-reviewer does the same — Minor issues with specific fixes that never happen because they're buried in a report that no one reopens.
Every "fix if time allows" is a promise to a persona. This skill makes those promises visible.
Design debt lives in a ## Design Debt Register section in design-state.md. One register per project. It persists across iterations.
## Design Debt Register
_Items: [count] | Critical: [count] | Oldest: [date]_
| ID | Date | Source | Severity | What | Who is affected | Suggested fix | Status | Notes |
|----|------|--------|----------|------|----------------|---------------|--------|-------|
| DD-001 | 2025-01-15 | design-critic | Minor | Settings form shows all fields at once — cognitive load | Persona: Jamie (cognitive disability) | Progressive disclosure with sections | Open | Deferred from v1 — setup is one-time flow |
| DD-002 | 2025-01-15 | accessibility-reviewer | Minor | Category colour strips lack icon backup | Users with colour vision deficiency | Add icon per category alongside colour | Open | |
| DD-003 | 2025-01-16 | design-critic | Note | Empty state illustration is placeholder | All users | Commission illustration that matches brand | Open | Low priority — functional without it |
| DD-004 | 2025-01-15 | accessibility-reviewer | Minor | Toast notifications auto-dismiss before screen reader finishes | Screen reader users | Extend timeout to 8s or add persistent log | Resolved | Fixed in v1.1 |
| Field | What goes here |
|---|---|
| ID | Sequential identifier (DD-001, DD-002, ...). Never reuse IDs |
| Date | When the debt was recorded |
| Source | Which agent or review identified it (design-critic, accessibility-reviewer, design-lead, user, etc.) |
| Severity | The original severity classification: Minor or Note (Critical and Major should be fixed, not deferred) |
| What | Specific description of the issue — not "needs improvement" but "form shows 12 fields at once" |
| Who is affected | Which personas or user groups bear the cost of this debt. Be specific |
| Suggested fix | Actionable recommendation from the original review |
| Status | Open, Resolved, Accepted, or Escalated |
| Notes | Why it was deferred, context, related items |
| Status | Meaning |
|---|---|
| Open | Identified, not yet addressed. This is a promise to come back |
| Resolved | Fixed in a subsequent iteration. Record which iteration |
| Accepted | Consciously decided this is not worth fixing. Requires user approval and a rationale |
| Escalated | Was Minor, but accumulated evidence or changing context makes it Major. Needs attention |
When the design-critic or accessibility-reviewer completes a review:
design-state.mdDo not capture items that are being fixed. The register tracks debt, not the fix list. If it's getting fixed now, it doesn't belong here.
When starting a new iteration or planning cycle:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DESIGN DEBT SUMMARY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Open items: [count]
By severity: [X] Minor, [Y] Note
Oldest unresolved: [date] ([age])
ACCESSIBILITY DEBT:
• [count] items affecting users with disabilities
• Most affected: [persona or user group]
TOP CANDIDATES FOR THIS CYCLE:
1. [DD-XXX] [description] — [why now]
2. [DD-XXX] [description] — [why now]
3. [DD-XXX] [description] — [why now]
ESCALATED (was Minor, now needs attention):
• [DD-XXX] [description] — [escalation reason]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Debt items should be escalated from Minor to Major when:
| Trigger | Example |
|---|---|
| Age | Item has been Open for 3+ iterations without resolution |
| Accumulation | Multiple debt items affect the same persona or the same screen |
| Context change | A new persona or use case makes the issue more impactful |
| User complaint | The user or stakeholder mentions the issue independently |
| Compound effect | Two Minor items together create a Major experience gap |
When escalating:
When a debt item is fixed:
design-state.mdWhen the user consciously decides an item is not worth fixing:
Accessibility debt requires explicit acknowledgement. If a debt item affects users with disabilities, the user must explicitly accept the trade-off. Do not silently accept accessibility debt.
designpowers-critique (Minor/Note findings), accessibility-reviewer (Minor findings), verification-before-shipping (deferred items)writing-design-plans (debt items become plan tasks), design-retrospective (debt trends are retrospective data)design-state.md (Design Debt Register section)using-designpowers (after reviews, at project start, on user request)| Pattern | Why It Fails |
|---|---|
| Capturing Critical issues as debt | Critical issues block access. They get fixed now, not tracked for later |
| Deferring the same item 3+ times | That's not debt management, that's avoidance. Escalate it |
| Accepting accessibility debt without user acknowledgement | Accessibility compromises affect real people. The user decides, not the system |
| Deleting resolved items | Resolved items are history. They show the team addresses its promises |
| Not reviewing debt at project start | Starting a new iteration without checking old promises means those promises are broken |
| Tracking everything | Not every observation needs tracking. Notes that are genuinely informational ("consider X someday") can stay in the critique report. Debt is for specific, actionable items that affect specific people |