earayu Audit Report Refresh
Use this skill when there is already an audit report or module document and the user wants a new pass based on the latest code.
If there is no prior report and the task is a fresh audit, prefer system-audit-report.
If the redesign introduced complicated runtime paths, async jobs, or reconcile loops, pair this skill with architecture-data-flow-trace.
Goal
Keep the good parts of the previous report:
- structure
- section ordering
- useful framing
- strong explanations
Replace the bad parts:
- stale facts
- outdated conclusions
- missing deltas
- gaps that the new code now closes
Core Rules
- Sync to the latest code before comparing anything.
- Treat the previous report as input material, not truth.
- Explicitly identify what changed since the previous report.
- Re-audit the subsystem from code; do not “patch” the old report blindly.
- Preserve strong structure when it still helps the reader.
Required Workflow
1. Read the Existing Report First
Extract:
- the current section structure
- strong sections worth preserving
- explicit prior conclusions
- prior blocker list
- known assumptions
2. Rebuild the Current Picture from Code
Audit the latest implementation using the same standards as system-audit-report:
- models
- services
- APIs
- migrations
- tasks
- tests
- UI if relevant
3. Compare Old Conclusions vs. Current Reality
Classify major conclusions into:
- still correct
- partially correct
- now outdated
- reversed by new code
- still unresolved
This comparison should appear in the refreshed report, usually near the beginning.
4. Rewrite, Do Not Merely Edit
When a section is materially outdated:
- rewrite it from current code
When a section is structurally strong but factually stale:
- preserve the section shape
- replace the content
When a prior conclusion is now wrong:
- say so explicitly and state what changed in the code
Required Additions in the Refreshed Report
The refreshed report should usually add:
- current code baseline
- what changed since the previous audit
- which old blockers were fixed
- which old blockers remain
- any new defects introduced by the redesign
Quality Bar
A good refresh report makes it easy to answer:
- What did we think last time?
- What is true now?
- What got better?
- What is still risky?
- What new problems appeared after the redesign?
Validation
At minimum:
- run
git diff --check
If possible, run representative tests around the redesigned area and say whether the new conclusions are supported by passing tests.
Do Not
- Do not copy old conclusions forward without re-verifying them.
- Do not keep wording that implies old architecture still exists.
- Do not preserve structure at the cost of factual accuracy.