reverse-engineering-coverage-audit
Skill0 starsChanged 2 months agoMITView on GitHub
Audit reverse-engineering completeness by finding important architectural domains, entry points, implementations, configuration paths, boundaries, persistence areas, or lifecycle behaviors that were never investigated deeply enough.
In this repository33 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- adversarial-baseline-auditSkill
- architecture-drift-detectionSkill
- architecture-reconstruction-and-diagramsSkill
- artifact-detailed-designSkill
- baseline-source-of-truth-maintenanceSkill
- claim-verification-and-promotionSkill
- configuration-source-traceSkill
- contract-impact-test-designSkill
- current-state-tdd-synthesisSkill
- design-artifact-decompositionSkill
- design-artifact-decomposition-verificationSkill
- detailed-design-verificationSkill
- full-reverse-engineeringSkill
- implementation-readiness-certificationSkill
- incident-root-cause-analysisSkill
- integration-selection-analysisSkill
- observability-traceability-analysisSkill
- patch-impact-reviewSkill
- persistence-schema-reverse-engineeringSkill
- post-readiness-adversarial-auditSkill
- regression-test-designSkill
- requirement-compliance-reviewSkill
- resolve-high-impact-unknownsSkill
- resume-reverse-engineeringSkill
- reverse-engineering-bootstrapSkill
- run-engineering-workflowSkill
- runtime-binding-verificationSkill
- runtime-flow-analysisSkill
- technical-design-proposalSkill
- technical-design-verificationSkill
- wbs-generationSkill
- wbs-verificationSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 6 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 40
all materially distinct integration implementations
- Distinctive: line 58
Search for source clusters and evidence chains absent from the baseline:
- Distinctive: line 92
only a representative external endpoint is documented
- Distinctive: line 113
Check whether endpoint/operation-specific conditions are recorded independently.
- Distinctive: line 132
Use only states applicable to the domain.
- Very specific: line 169
Create/open a question and return it to /resolve-high-impact-unknowns.
- Distinctive: line 171
Treat unresolved provenance or exposure closure as HIGH/CRITICAL when it can change:
- Very specific: line 185
Update 00_investigation_coverage.md and 00_workflow_state.md.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Reverse Engineering Coverage Audit — 4.0
Mission
Challenge completeness, not just correctness.
Ask:
What important architecture did the previous investigation fail to look at?Inputs
Review compactly:
00_investigation_coverage.md
00_current_understanding.md
00_master_decision_matrix.md
00_open_questions.md
00_evidence_ledger.mdCompare against current repository topology and source search.
Coverage Domains
Assess applicability and depth for:
- inbound surfaces
- startup/bootstrap
- major business/service modules
- representative runtime flows
- all materially distinct integration implementations
- factories/providers/registries/DI
- configuration sources/defaults/precedence
- external boundaries
- boundary → exposure closure for important downstream operations
- field/data provenance for externally meaningful values
- request/input semantics for externally visible interfaces
- persistence/schema
- error/retry/fallback
- lifecycle/concurrency
- auth/security
- observability/audit
- compatibility/version/model branches
- background/internal jobs
- tests revealing alternate behavior
Adversarial Coverage Search
Search for source clusters and evidence chains absent from the baseline:
- implementations never referenced by decision matrix
- config keys never traced to consumers
- DB/DAO/schema packages not represented
- process/HTTP/socket/CLI clients not represented
- entry points not represented
- downstream boundaries with unresolved invocation sites
- shared runtime methods with only one external caller documented
- response/output fields with no provenance chain
- conditional output claims with no retrieval/mapping evidence
- factories/providers without verified routing claims
- background workers not represented
- model/version switches not represented
- endpoint-specific conditions generalized across sibling operations
Required Cross-Cutting Coverage Checks
In addition to architecture domains, audit these evidence dimensions:
A. Exposure Closure Coverage
For important downstream boundaries, ask:
boundary
← all direct invocation sites
← all caller chains
← all external entry points / proven internal rootsCoverage is incomplete when:
- one invocation site is unresolved
- only a representative external endpoint is documented
- a no-impact claim lacks a terminating reverse trace
B. Field / Data Provenance Coverage
For externally meaningful fields/data, ask whether baseline artifacts prove:
trigger
→ retrieval/source
→ parse
→ transform
→ mapping/state
→ serialization/output
→ observable resultCoverage is incomplete if a promoted behavior claim skips a material link.
C. Scope-Isolation Coverage
Check whether endpoint/operation-specific conditions are recorded independently. Shared implementation does not prove shared contract semantics.
Coverage Matrix
| Domain / Evidence Dimension | Source Evidence It Exists | Existing RE Coverage | Depth | Gap | Impact | Required Follow-up |
Depth:
NOT_APPLICABLE
DISCOVERED
TRACED
PROVENANCE_TRACED
EXPOSURE_CLOSED
VERIFIEDUse only states applicable to the domain; do not force provenance/exposure states where irrelevant.
Gap impact:
CRITICAL
HIGH
MEDIUM
LOW
NONEConsumer-Model Coverage
Also audit whether the verified evidence has been converted into a usable system model. Check:
5 mandatory diagram artifacts present
major subsystem responsibilities modeled
primary runtime flows modeled
known external integrations modeled
behavior-changing configuration selectors modeled
persistence/state ownership modeled
diagram nodes/edges evidence-linked
CURRENT_STATE_TDD references the model artifactsA baseline with complete evidence tables but missing architecture synthesis is not complete.
Gate
Any CRITICAL/HIGH source-resolvable coverage gap or mandatory consumer-model gap means baseline readiness is:
NOT_READY_HIGH_IMPACT_GAPSCreate/open a question and return it to /resolve-high-impact-unknowns.
Treat unresolved provenance or exposure closure as HIGH/CRITICAL when it can change:
- externally observable behavior
- API/entry-point impact scope
- routing/integration conclusions
- compatibility or migration decisions.
Output
Create:
docs/reverse-engineering/11_reverse_engineering_coverage_audit.mdUpdate 00_investigation_coverage.md and 00_workflow_state.md.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

