| name | legacy-audit-check |
| description | Use before marking any backend, frontend, or ingestion feature as "complete." Checks the change against the Legacy Capability Audit to prevent regression. |
Legacy Audit Check Procedure
When to Use
Invoke this skill before marking ANY feature as complete or closing ANY task related to backend restoration, frontend wiring, ingestion, or onboarding. The Legacy Capability Audit (historical, single-agent era) tracks what was lost during the legacy-to-production transition; when bound, load it from the source org retired spec if present — this pack does not ship agents/_archive/.
Check Steps
- Load the Legacy Capability Audit from your bound org (often under
product_internal_docs/ or an internal archive). Portable pack: that file is not included here — defer parity claims until the User binds a checkout, or work from PRODUCT_CONTEXT + code. For coordination, default Engineering lead is Engineering Orchestrator (Mike) — agents/core/engineering-orchestrator.md.
- Identify which audit items your change relates to
- For each related item:
- Verify the capability is fully restored (not just the table exists, but CRUD routes work, tests pass, frontend wires to real data)
- Update the audit item status:
lost -> in_progress -> ported
- Add evidence (test file, route path, commit hash)
- Check for partial restoration — the most common failure:
- Table exists but no CRUD routes (V1.5.1 pattern)
- Module exists but not imported by any route handler
- Frontend component exists but wired to noop/placeholder
- Test exists but only tests the happy path
Anti-Regression Checklist
Before declaring any item "ported":
Critical Rule
"Exists but unwired" is NOT "ported." A table without routes, a module without imports, or a component without API calls is NOT a restored capability. It is a stub.
Filing
Update the Legacy Capability Audit table in your bound org after each verification. Include the date, commit, and test evidence.