agentleFS
tuana-vntuana-vn/system-reverse-engineer/.github/skills/reverse-engineering-coverage-audit/SKILL.md

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.

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
  1. Distinctive:

    all materially distinct integration implementations

    line 40
  2. Distinctive:

    Search for source clusters and evidence chains absent from the baseline:

    line 58
  3. Distinctive:

    only a representative external endpoint is documented

    line 92
  4. Distinctive:

    Check whether endpoint/operation-specific conditions are recorded independently.

    line 113
  5. Distinctive:

    Use only states applicable to the domain.

    line 132
  6. Very specific:

    Create/open a question and return it to /resolve-high-impact-unknowns.

    line 169
  7. Distinctive:

    Treat unresolved provenance or exposure closure as HIGH/CRITICAL when it can change:

    line 171
  8. Very specific:

    Update 00_investigation_coverage.md and 00_workflow_state.md.

    line 185

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.md

Compare 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 roots

Coverage 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 result

Coverage 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 DimensionSource Evidence It ExistsExisting RE CoverageDepthGapImpactRequired Follow-up

Depth:

NOT_APPLICABLE
DISCOVERED
TRACED
PROVENANCE_TRACED
EXPOSURE_CLOSED
VERIFIED

Use only states applicable to the domain; do not force provenance/exposure states where irrelevant.

Gap impact:

CRITICAL
HIGH
MEDIUM
LOW
NONE

Consumer-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 artifacts

A 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_GAPS

Create/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.md

Update 00_investigation_coverage.md and 00_workflow_state.md.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.