| name | product-completeness-audit |
| description | Use when a product "looks done" but you suspect flows are broken, pages are placeholders, data is hardcoded, or the frontend and backend aren't fully wired. Audits every route and component for FUNCTIONAL completeness vs visual completeness. A beautiful UI rendering hardcoded data is a demo, not a product — this skill proves it either way. Dispatches 5 agents (placeholder-hunter, route-completeness-checker, wiring-auditor, data-flow-real-vs-mock, journey-walker) with optional 3-teammate demo-vs-product debate for edge cases. Reuses exploratory-qa's Playwright MCP server. |
Product Completeness Audit
The skill that asks the question: "If a user opened this RIGHT NOW and tried to actually use it with real data, what would break?"
The Iron Law
A BEAUTIFUL UI WITH HARDCODED DATA IS A DEMO, NOT A PRODUCT.
If a user cannot complete their intended journey end-to-end with real data, the product is NOT done.
When to use
- ✅ Between
exploratory-qa (which tests flows) and final "ship" claim (which assumes the flows MEAN something real)
- ✅ When the UI looks polished but the user can't quite tell if the buttons work
- ✅ After a
prototype-to-saas migration to verify nothing is still reading from JSON fixtures in "production" mode
- ✅ Before a demo where a stakeholder will click on things expecting them to work
When NOT to use
- ❌ For visual / design fidelity (use
design-preservation instead)
- ❌ For security (use
security-review-and-fix)
- ❌ For performance (use
exploratory-qa's qa-performance-prober)
- ❌ For brutal whole-product audit (use
brutal-exhaustive-audit — this skill is more focused)
How the orchestrator should use this skill
The orchestrator dispatches after and pass — BEFORE . The order matters:
