/feature-completeness

Feature Completeness

Purpose

Most features ship with the happy path finished and every other path improvised. This skill turns "done" into a checkable claim by reviewing the feature across eight paths, recording evidence for each, and routing every gap to a specific fix.

When to Use

• Before building: turning a spec, ticket, or PRD into a definition of done
• Before shipping: final review of a feature branch or PR
• After shipping: a feature generates support tickets, confusion, or "it's broken" reports that turn out to be unhandled cases
• An AI agent has just generated a feature and you need to know what it skipped

Core Principles

1. A path is complete only with evidence. "Handled" means you can point to the code, the rendered state, or the test. Otherwise it is "assumed".
2. Name the feature by the user's goal, not the component. "Invite a teammate", not "InviteModal". Goals cross components; that is where gaps hide.
3. Gaps are ranked by user harm, not effort. Data loss and dead ends outrank cosmetic inconsistency.
4. Every gap has an owner skill. A review that only lists problems is half a review.
5. Not applicable is a decision. Record why a path does not apply.

Workflow

1. Define the feature

Write one sentence: who does what to achieve which outcome. Then list:

• Entry points — every way a user reaches it (nav, link, notification, deep link, empty state CTA, keyboard shortcut)
• Actions — every verb the user can perform
• Data — what it reads and writes
• Roles — who can see it, who can act

If you cannot write these, the feature is under-specified. Stop and resolve that first (see user-flows, information-architecture).

2. Walk the eight paths

For each path, answer the questions, mark a status, and record evidence.

Status values: complete · partial · missing · n/a (reason) · unknown (could not verify)

Happy path

• Can the primary goal be completed end to end without workarounds?
• Is success confirmed to the user in a way they will notice?
• After success, is the next step obvious (view result, do another, return)?

Error path

• What happens when each request fails: network, timeout, validation, 4xx, 5xx?
• Is user input preserved after an error?
• Does every error state name a next action?
• Can a failed action be retried without duplicating side effects?

Empty path

• What does a first-time user see before any data exists?
• What does a filtered or searched-to-nothing view show?
• Does the empty state lead to the action that fills it?

Loading path

• Is there feedback for every wait over ~300ms?
• Are double submissions prevented?
• Does background refresh keep existing content visible?
• What happens if the user navigates away mid-request?

Permission path

• What does each role see — including roles that cannot act?
• Are forbidden actions hidden, disabled with a reason, or discoverable with a request path? Is that choice consistent?
• Is the server enforcing what the UI hides?
• What happens when permission changes while the page is open?

Mobile path

• Does the feature work at ~360px width and with touch only?
• Do hover-only affordances have a touch equivalent?
• Does the on-screen keyboard cover inputs or primary buttons?
• Are tables, toolbars, and multi-pane layouts transformed rather than squeezed?

Accessibility path

• Can the whole goal be completed with a keyboard alone?
• Where does focus go after opening, closing, submitting, deleting, and navigating?
• Are state changes (errors, success, loading complete) announced to screen readers?
• Are all controls labeled, and is nothing conveyed by color alone?

Recovery path

• Can the user undo or reverse what they just did? If not, were they warned?
• Is unsaved work protected from refresh, back button, tab close, and session expiry?
• Can a user who abandoned midway resume later?
• If something is deleted or broken, is there a route back (trash, history, support)?

3. Gather evidence

In a codebase, look for concrete signals rather than reading everything:

If the app is runnable, exercise each path: throttle the network, block a request, log in as a lower role, resize to 360px, unplug the mouse.

4. Score and rank gaps

Rank each gap:

• P0 — harm: data loss, security exposure, irreversible mistake possible, user stuck with no way forward
• P1 — failure: goal cannot be completed on a supported path (mobile, keyboard, a role)
• P2 — confusion: goal completable but user is uncertain what happened or what to do
• P3 — inconsistency: works, but differs from the rest of the product

5. Route each gap

Checklist

• Feature defined as a user goal with entry points, actions, data, and roles
• All eight paths have a status and evidence (or a reason for n/a)
• unknown statuses are listed as things to verify, not treated as passes
• Every gap is ranked P0–P3
• Every gap is routed to a skill or a concrete fix
• P0 gaps are flagged as ship blockers

Common Mistakes

• Reviewing the component, not the goal. The modal is complete; the flow that opens it from a notification is broken.
• Counting "the button is disabled while loading" as the loading path. What about page load, refetch, and navigation mid-request?
• Checking permission in the UI only. Hidden is not forbidden.
• Marking mobile complete because the layout reflows. Reflowing is not the same as usable with a thumb and an on-screen keyboard.
• Treating accessibility as a lint pass. Automated checks catch labels and contrast, not focus order after deleting a row.
• No recovery path considered because nothing went wrong during the demo.

Example

Feature: "Export a report as CSV"

Ship blockers: duplicate export jobs from missing loading feedback.

Implementation Notes

• Turn the scorecard into a PR template or definition-of-done checklist so the paths are asked every time.
• Encode states as fixtures/stories so the empty, error, and permission paths are reviewable without breaking a real backend.
• For agents: run this skill after generating a feature and before reporting it as finished.

Output Expectations

Produce:

1. Feature definition — goal sentence, entry points, actions, data, roles.
2. Completeness scorecard — Path | Status | Evidence / Gap | Rank | Route for all eight paths (split a path into multiple rows when it has multiple gaps).
3. Ship blockers — all P0 gaps.
4. Next steps — gaps grouped by the skill that owns them, in priority order.

State plainly when evidence was unavailable (for example, the app could not be run), and which statuses are therefore unknown.