interface-audit
Produce one evidence-backed audit of product interface boundaries. Do not
implement or launch planning.
Inputs and references
Run a fresh audit by default. --update [report-path] refreshes an existing
report. Read references/report-structure.md; for an update also read
references/update-workflow.md.
A fresh audit uses only current code, tests, docs, command output, and evidence
created for this run. Do not inspect prior audit artifacts unless the user asks
for an update.
Evidence contract
- Score concrete component boundaries, not vague subsystems.
- Verify names and numeric claims; use
partial when exact measurement adds
little value.
- Ground complexity, over-engineering, debt, confidence, and recommendations in
current evidence. Current code and tests outrank stale documentation.
- Preserve row identifiers during updates and never reuse retired identifiers.
- Protect discovered product requirements unless the user approves a behavior
change. Do not preserve stale scores for continuity.
Workflow
- Establish fresh or update mode, repository baseline, report path, and scope.
- Trace the interface chain, contracts, ownership, state, tests, failure modes,
and meaningful cleanup opportunities. Investigate directly unless coherent,
independent boundary groups benefit from read-only parallel investigation.
- Calibrate neighboring rows, update the report, and select the highest-value
coherent improvement. Revisit only evidence gaps or inconsistencies. If no
candidate justifies its cost, record
no-material-improvement.
- For a material candidate, decide whether it requires broad ownership,
protocol, data-model, cross-language, or user-workflow redesign. Recommend
that architecture only when a smaller interface improvement is insufficient;
otherwise recommend the smallest coherent improvement. State any behavior
change and require approval before it enters a plan. Include exact
/implement input as a handoff, but do not run it.
Do not edit production code, tests, docs, or memory files, widen beyond product
interfaces, or create parallel reports. Return the report path and either the
recommendation or no-material-improvement, with current evidence for every
material score and conclusion.
1---2name: interface-audit3description: Audit product interfaces as component boundaries, score complexity, over-engineering, and debt, maintain .agent-layer/tmp interface-audit reports, and finish at the final recommendation gate. Use for fresh interface cleanup audits or --update refreshes; not for implementation.4---56# interface-audit78Produce one evidence-backed audit of product interface boundaries. Do not9implement or launch planning.1011## Inputs and references1213Run a fresh audit by default. `--update [report-path]` refreshes an existing14report. Read `references/report-structure.md`; for an update also read15`references/update-workflow.md`.1617A fresh audit uses only current code, tests, docs, command output, and evidence18created for this run. Do not inspect prior audit artifacts unless the user asks19for an update.2021## Evidence contract2223- Score concrete component boundaries, not vague subsystems.24- Verify names and numeric claims; use `partial` when exact measurement adds25 little value.26- Ground complexity, over-engineering, debt, confidence, and recommendations in27 current evidence. Current code and tests outrank stale documentation.28- Preserve row identifiers during updates and never reuse retired identifiers.29- Protect discovered product requirements unless the user approves a behavior30 change. Do not preserve stale scores for continuity.3132## Workflow33341. Establish fresh or update mode, repository baseline, report path, and scope.352. Trace the interface chain, contracts, ownership, state, tests, failure modes,36 and meaningful cleanup opportunities. Investigate directly unless coherent,37 independent boundary groups benefit from read-only parallel investigation.383. Calibrate neighboring rows, update the report, and select the highest-value39 coherent improvement. Revisit only evidence gaps or inconsistencies. If no40 candidate justifies its cost, record `no-material-improvement`.414. For a material candidate, decide whether it requires broad ownership,42 protocol, data-model, cross-language, or user-workflow redesign. Recommend43 that architecture only when a smaller interface improvement is insufficient;44 otherwise recommend the smallest coherent improvement. State any behavior45 change and require approval before it enters a plan. Include exact46 `/implement` input as a handoff, but do not run it.4748Do not edit production code, tests, docs, or memory files, widen beyond product49interfaces, or create parallel reports. Return the report path and either the50recommendation or `no-material-improvement`, with current evidence for every51material score and conclusion.
conn-castle