tuana-vn Resume Reverse Engineering — 4.0
Purpose
Use this skill at the beginning of a NEW Copilot session when reverse-engineering work already exists in the repository.
The previous Copilot session is NOT a source of truth.
The repository is the persistent memory.
This skill restores working context from the existing 4.0 artifacts so that subsequent skills can continue from the current verified baseline.
Core Rule
FRESH SESSION
↓
REHYDRATE FROM REPOSITORY
↓
LOAD PROMOTED BASELINE
↓
LOAD WORKFLOW STATE
↓
LOAD ONLY RELEVANT SUPPORTING ARTIFACTS
↓
CONTINUE WITH NEXT 4.0 SKILL
Do NOT restart /full-reverse-engineering merely because the session is new.
Do NOT rely on conversational memory from another Copilot session.
Do NOT treat hypotheses, proposals, drafts, or rejected findings as promoted architecture facts.
Step 1 — Load 4.0 Operating Instructions
Read, when present:
.github/copilot-instructions.md
Read the active system-reverse-engineer agent instructions.
Read this skill and any 4.0 skill explicitly referenced by the current workflow state.
Do not load every skill into working context unless necessary.
Step 2 — Locate the Canonical Reverse-Engineering Workspace
Locate:
docs/reverse-engineering/
Prefer the repository's existing paths and filenames.
Do not invent replacement files if equivalent 4.0 files already exist.
Identify the current canonical artifacts, especially:
00_current_understanding.md
00_master_decision_matrix.md
00_evidence_ledger.md
00_hypotheses.md
00_open_questions.md
workflow_state.yaml
00_investigation_coverage.md
Also locate, when present:
02_representative_runtime_flows.md
03_integration_selection.md
04_boundaries.md
05_error_retry_fallback.md
07_adversarial_baseline_audit.md
08_final_reverse_engineered_baseline.md
If filenames differ slightly in the repository, use the actual 4.0 files rather than creating duplicates.
Step 3 — Establish Baseline Identity
Determine the source identity associated with the existing baseline.
Prefer, in order:
- baseline commit recorded in 4.0 artifacts
- repository commit recorded in workflow state
- current Git HEAD if no baseline identity is recorded
Report:
repository
branch
current HEAD
baseline commit/version
If current HEAD differs from the recorded baseline, DO NOT silently assume the baseline is current.
Record the difference in the resume summary.
Do not automatically run baseline maintenance.
Step 4 — Rehydrate Canonical Knowledge
Load and summarize internally:
Promoted architecture facts
From:
00_current_understanding.md
Only promoted/verified knowledge is treated as established architecture.
Routing / selection facts
From:
00_master_decision_matrix.md
Use only promoted routing decisions.
Evidence history
From:
00_evidence_ledger.md
Use this to understand:
- claim IDs
- verification status
- superseded/rejected claims
- baseline version
- promotion state
Do not promote a claim during resume.
Hypotheses
From:
00_hypotheses.md
Treat these as NON-CANONICAL.
Open questions
From:
00_open_questions.md
Use these only to understand unresolved work.
Do not assume an old open question is still unresolved if current source or later artifacts already resolved it.
Workflow state
From:
workflow_state.yaml
00_investigation_coverage.md
Determine:
- completed phases
- current phase
- pending phase
- last successful skill/workflow
- known blockers
- expected next action
- baseline readiness status
- HIGH/CRITICAL unknowns and closure states
- coverage gaps from
00_investigation_coverage.md
If any HIGH/CRITICAL item is SOURCE_SEARCH_PENDING or SOURCE_SEARCH_IN_PROGRESS, do not report the baseline as ready. Recommend /resolve-high-impact-unknowns.
Step 5 — Load Only Relevant Supporting Evidence
Do NOT flood the context with the entire reverse-engineering repository.
Based on the current workflow state and the user's next task, selectively read supporting artifacts.
Examples:
Runtime-flow task
Read:
02_representative_runtime_flows.md
Integration/boundary task
Read:
03_integration_selection.md
04_boundaries.md
Failure/retry task
Read:
05_error_retry_fallback.md
Baseline trust/review task
Read:
07_adversarial_baseline_audit.md
08_final_reverse_engineered_baseline.md
Patch/design/review task
Load only the baseline sections and evidence relevant to the changed feature or subsystem.
Current source remains authoritative whenever re-verification is required.
Step 6 — Detect Staleness Without Rebuilding the Baseline
Check whether the repository has materially changed since the recorded baseline.
Use lightweight Git/source inspection.
Examples:
- current HEAD differs from baseline commit
- files referenced by promoted claims changed
- relevant integration classes changed
- branch changed
Classify:
BASELINE_CURRENT
BASELINE_POTENTIALLY_STALE
BASELINE_STALE_FOR_CURRENT_TASK
Do NOT automatically run /baseline-source-of-truth-maintenance.
If maintenance is needed, recommend it as the next 4.0 action.
For a patch or unmerged diff, do NOT treat patch behavior as current canonical truth.
Step 7 — Resume State
Produce an internal working state containing:
Baseline identity
Promoted architecture summary
Relevant decision-matrix entries
Relevant evidence IDs
Relevant unresolved questions
Workflow phase/status
Baseline freshness
Baseline readiness
High-impact unknown closure state
Likely next 4.0 skill
Do not create a new reverse-engineering baseline during resume.
Do not update canonical files.
Search Discipline
If a referenced artifact says something is UNKNOWN but the user's next task requires that fact:
baseline UNKNOWN
↓
inspect CURRENT SOURCE
↓
resolve if source contains the answer
Do not preserve an UNKNOWN merely because an old document contained it.
However, this resume skill itself should remain lightweight.
Deep source tracing belongs to the subsequent task skill unless the fact is necessary to determine the correct resume state.
Canonical vs Non-Canonical Inputs
Canonical
Prefer:
promoted current understanding
promoted decision matrix
evidence ledger promoted claims
verified final baseline
current source
Non-canonical unless explicitly verified
Do NOT use as architecture truth merely because they exist:
proposals/
draft TDDs
patch review outputs
requirement review outputs
hypotheses
rejected designs
temporary notes
AI-generated reports
unmerged patches
These may be task inputs, but they do not replace the promoted baseline.
Completion Output
Do NOT print a large baseline dump to console.
Return only a concise resume summary:
Reverse-engineering context resumed.
Baseline:
- Commit/version: ...
- Current HEAD: ...
- Freshness: BASELINE_CURRENT | BASELINE_POTENTIALLY_STALE | BASELINE_STALE_FOR_CURRENT_TASK
Workflow:
- Last completed phase: ...
- Current/pending phase: ...
Relevant architecture:
- <3-8 concise points relevant to the likely/current task>
Open items relevant to continuation:
- <only relevant unresolved items>
Ready for:
- /<recommended-next-skill>
If the user has already supplied a task in the same prompt, do NOT wait.
After rehydrating context, immediately execute the requested 4.0 skill.
Example:
Use /resume-reverse-engineering, then use /patch-impact-review for patch/abc.diff.
In that case:
- resume context
- do not print a separate long resume report
- execute
/patch-impact-review - return the normal output of that skill
Safety / Integrity Rules
Never:
- restart full reverse engineering solely because this is a fresh session
- promote hypotheses during resume
- overwrite canonical baseline
- infer old chat context that is absent from repository
- treat proposal documents as promoted evidence
- treat unmerged patch code as current baseline
- silently ignore baseline/current-HEAD mismatch
The repository-backed 4.0 baseline is the persistent memory. The Copilot conversation is disposable working context.