Skip to the usage guide
Design Debt Auditby owl-listener

Design Debt Audit Skill.

Inventory product design inconsistencies and prioritize their repair.

  • Design Debt
  • Prioritization
Source Review · design-debt-auditSKILL.md
Task Inventory product design inconsistencies and prioritize their repair. Produces A scoped inventory of screens, states and recurring design problems. Before You Start The source separates research and prioritization from a fix sprint.
Editorial summary · source reviewed 2026-11-02 · not a generated example

01 What It Does

Inventory product design inconsistencies and prioritize their repair

Create a design debt register covering visual, structural, accessibility and documentation issues, with severity, frequency and effort.

Source-based workflowNot an execution benchmark

The Working Approach

Design Debt Audit surveys the gap between a product's current interface and the standard it should meet. It covers visual inconsistency, outdated structure, accessibility gaps, documentation mismatch and design-related implementation problems. A screen can carry more than one kind of debt, so the audit classifies issues rather than reducing everything to visual polish.

The outcome is a prioritized register and remediation plan. The source uses severity, frequency and effort to identify useful repair work, then separates quick fixes from structural projects and deliberately deferred items. It explicitly treats auditing and remediation as different activities.

Expected Deliverables

  • A scoped inventory of screens, states and recurring design problems.
  • A debt register with category, severity, affected areas, ownership and status.
  • A prioritized plan separating quick wins, structural work and documented deferrals.
See the Example Brief

From Brief to Review

  1. 01
    Define and capture the scope

    Choose a product area or platform and catalogue its screens and states. Capture the evidence needed to show where each issue occurs.

  2. 02
    Classify and size the debt

    Record category, severity, frequency and estimated effort. Distinguish observed occurrence from estimated user reach or business risk.

  3. 03
    Prioritize with engineering input

    Use the source's severity-by-frequency relative to effort approach to surface a short repair list. Invite engineering judgment where implementation cost is uncertain.

  4. 04
    Maintain a living register

    Assign owners and target milestones as the team agrees them. Keep deferred items visible and revisit the register as the product changes.

02 When to Use It

When to Use It

The source separates research and prioritization from a fix sprint.

A Good Fit

  • Before a redesignA team needs evidence of the actual cleanup scope before committing to a broad redesign.
  • Accumulated inconsistencyDifferent feature areas have drifted in components, navigation or documentation.

Limits to Check

  • Audit is not repairThe source separates research and prioritization from a fix sprint.
  • Estimates need groundingUser reach, effort and risk are assessment inputs, not numbers to invent.
  • Specialist follow-upToken coverage and detailed accessibility work have separate companion skills.

Bring These Inputs

  • Product scopeName the screens, platform or feature area to inspect.
  • Expected standardsProvide the design system and relevant specifications.
  • Planning contextInclude engineering estimates, known redesigns and available ownership information.

03 Decisions That Matter

Decisions That Matter

  1. Categorized evidence

    Structural and documentation problems remain visible beside styling inconsistencies.

  2. Actionable order

    Frequency and effort help identify work with a useful repair payoff.

  3. Explicit deferral

    Low-priority debt can be documented with a reason rather than disappearing.

04 Try a Focused Brief

Try a Focused Brief

The example brief below has not been tested. Check the skill’s setup before using it.

Review the Source and Setup

Name the screens, platform or feature area to inspect.

Upstream Source File
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-ops/skills/design-debt-audit/SKILL.md

The reference below opens the upstream instructions. Review the repository setup before using them; it is not an installation command.

Start With One Deliverable

Adapt the scope, source material and constraints in this brief before running the skill.

Example Brief
Use design-debt-audit to review our account-management area before we plan its redesign. Inventory the current screens and important states, comparing them with the shared design system. Classify findings as visual, structural, accessibility, documentation or implementation debt. Record affected locations, observed frequency and severity, and mark effort estimates that need engineering input. Produce a short prioritized repair list and a living debt register. Separate quick fixes from larger structural work and explain any proposed deferrals. Do not change product code during this audit.

Inspect the Result

Check the actual output against these observable criteria.

  • Every debt item is tied to an observed screen, state or artifact.
  • Priority reasoning distinguishes observed frequency from uncertain estimates.
  • Deferred issues retain a reason, owner when known and review context.

OpenDesign provides a local design workspace for coding agents. This listing does not mean the skill is bundled or that its external tools, credentials and software dependencies are included.

05 Source and License

Source and License

This page describes the pinned source revision linked below. Upstream behavior and requirements can change.

Source Owner
owl-listener
Skill File
SKILL.md
License
MIT
Reviewed Snapshot
2026-11-02 · 9a6930cf84a8
Editorial Source Summary
Inventory product design inconsistencies and prioritize their repair.

Original summary by OpenDesign, based on the linked source. Repository stars are a dated popularity signal, not skill usage or a quality score.

06 Questions Before You Start

Questions Before You Start

Does the audit automatically fix the issues?

No. The source explicitly separates auditing from remediation.

Can documentation mismatch count as debt?

Yes. Outdated specifications, undocumented components and decisions held only in memory are included.

How are repairs prioritized?

The source considers severity multiplied by frequency relative to effort, supplemented by risk and engineering judgment.

OpenDesign

Keep Your Brief and Design Work Together.

Keep your brief, source material and design work together in a local workspace. Check the skill’s own setup before adding it to your workflow.

Upstream Source File
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-ops/skills/design-debt-audit/SKILL.md