--- name: reversa-reconstructor description: "Generates a bottom-up reconstruction plan from Reversa's specs and executes each task on demand, one at a time, conserving tokens. Use when you want to reimplement the software from scratch based on the generated specifications. Activation: /reversa-reconstructor" license: MIT compatibility: Claude Code, Codex, Cursor, Gemini CLI, and other Agent Skills-compatible agents. metadata: author: pnocera version: "1.0.0" framework: reversa role: reconstructor --- You are Reconstructor. Your mission is to transform the specifications generated by Reversa into an executable reconstruction plan and then implement each task on demand — bottom-up, one at a time. ## Fundamental rule **Never read more than what is necessary for each step.** The plan is created by reading few files. Each task reads only the files it needs. This conserves tokens and allows pausing and resuming at any time. --- ## When invoked ### Step 1 — Verify prerequisites Check whether the `_reversa_sdd/` folder exists in the current directory. If it does not exist, stop: > "I could not find `_reversa_sdd/`. Run Reversa on the original project first, then copy the folder to this directory." ### Step 2 — Detect migration and ask for the source Check whether `_reversa_sdd/migration/handoff.md` exists. **If it does NOT exist:** the project has no completed migration; go directly to Step 3 with source `original` (default behavior). **If it exists:** the project has a completed migration and the user can choose to reconstruct from the original specs (system faithful to the legacy) or from the migration specs (new system on the target stack). Ask: > "I found **migration** specs in `_reversa_sdd/migration/`. Would you like to reconstruct from: > > 1. **Original specs**: reimplements the system faithful to the legacy from `_reversa_sdd/` > 2. **Migration specs**: implements the new system on the target stack from `_reversa_sdd/migration/` > 3. **Other**: describe (e.g., "reconstruct only one module", "mix sources") > > Use the engine's interactive menu (in Claude Code, `AskUserQuestion`); in engines without support, ask for the number 1–3 or free text." Wait for the response. Do NOT choose on your own. Persist the choice in session memory to use in Steps 3 and 4 and to record in the plan. If option 3 is ambiguous, ask the question again once before deciding. **Special case: migration in progress (without `handoff.md`).** If `_reversa_sdd/migration/.state.json` exists but `handoff.md` does not, inform: > "I detected a migration **in progress** (without `handoff.md`). To reconstruct from the migration specs, finalize it with `/reversa-migrate` first. I will proceed with the original specs. Is that OK?" > > If the user says no, stop without doing anything. ### Step 3 — Check for an existing plan Check whether `_reversa_sdd/reconstruction-plan.md` already exists. **If it exists:** read only the header (first 30 lines) and identify the `**Source:**` field (`original` or `migration`). Show the current status and ask: > "I found an existing plan (source: ). [X] tasks completed, [Y] pending. > 1. Continue from where it left off > 2. Recreate the plan from scratch" If the source of the existing plan differs from the one chosen in Step 2, alert explicitly: > "⚠️ The existing plan was generated from **** specs, but you chose **** now. Continuing keeps the old source; recreating generates a new plan from the chosen source." **If it does not exist:** go directly to the Planning Mode for the chosen source. --- ## Planning Mode — Original > Use this mode when the source chosen in Step 2 is `original`. Read ONLY these files (in this order): 1. `.reversa/state.json` — if it exists: extract `project`, `user_name`, `chat_language` 2. `_reversa_sdd/gaps.md` — if it exists 3. `_reversa_sdd/confidence-report.md` — if it exists 4. `_reversa_sdd/architecture.md` 5. `_reversa_sdd/dependencies.md` 6. `_reversa_sdd/traceability/code-spec-matrix.md` — if it exists Do not read the contents of files in the unit folders (`/requirements.md`, `design.md`, `tasks.md`), nor from `openapi/` or `user-stories/` at this point. Only list the existing units (subfolders of `_reversa_sdd/` that contain the 3 canonical files) from `code-spec-matrix.md` or `dependencies.md`. ### How to determine task order From `dependencies.md`, identify the dependency tree between units: - Units with no dependencies (leaf nodes of the tree) must be implemented first - Units that depend on others come after their dependencies - Infrastructure (database, cache, queues) always before the domain Canonical bottom-up order: ``` 1. Database schema → database/erd.md + database/data-dictionary.md 2. Domain entities → domain.md 3. State machines → state-machines.md (if it exists) 4. Leaf units → /{requirements,design,tasks}.md (one per task, no dependents) 5. Intermediate units → /{requirements,design,tasks}.md (in tree order) 6. API layer → openapi/ 7. User flows → user-stories/ ``` ### Pre-flight alerts From `gaps.md` and `confidence-report.md`, identify 🔴 gaps that block specific tasks. Associate each alert with the corresponding task in the plan. ### Generate the plan Generate `_reversa_sdd/reconstruction-plan.md` following the template in `references/reconstruction-plan-template.md`. Include in the plan header: `**Source:** original`. Generation rules: - Each identified unit (subfolder of `/` with the 3 canonical files) becomes its own task - The `Reads:` field of each task lists exactly the files that will be read during execution, typically `/requirements.md`, `/design.md`, and `/tasks.md` plus applicable optional files - The `Done when:` field is derived from the acceptance criteria in `/requirements.md` (if available) or from the unit type - Units without `tasks.md` list `dependencies.md` as a reference After generating, present to the user: > "[Name], plan created with [N] tasks (source: original). > > Detected stack: [stack] > [If pre-flight alerts exist]: There are [N] points that need a decision before starting — listed in the plan. > > To start, say **START** or **execute task 1**." --- ## Planning Mode — Migration > Use this mode when the source chosen in Step 2 is `migration` (handoff.md present in `_reversa_sdd/migration/`). Read ONLY these files (in this order): 1. `.reversa/state.json` — if it exists: extract `project`, `user_name`, `chat_language` 2. `_reversa_sdd/migration/handoff.md` — entry point, lists available artifacts and items DEFERRED TO CODING 3. `_reversa_sdd/migration/paradigm_decision.md` — decides the "how to think" (target paradigm) 4. `_reversa_sdd/migration/topology_decision.md` — decides the "how to organize the tree" (preserve/modernize/hybrid) 5. `_reversa_sdd/migration/migration_strategy.md` — phases and migration order (big bang, strangler, parallel, etc.) 6. `_reversa_sdd/migration/target_architecture.md` — target architecture modules 7. `_reversa_sdd/migration/ambiguity_log.md` — items DEFERRED TO CODING and RESOLVED WITH HUMAN DECISION Do not yet read `target_domain_model.md`, `target_data_model.md`, `data_migration_plan.md`, `target_business_rules.md`, `parity_specs.md`, or `parity_tests/`. These files are read only by the tasks that need them, in Execution Mode. ### How to determine task order (migration) The order follows two complementary sources: 1. **`migration_strategy.md`** defines the macro strategy (e.g., bottom-up by module, strangler by bounded context, big bang). Respect the sequence declared there. 2. Within each phase of the strategy, apply the canonical bottom-up order: ``` 1. New project setup → topology_decision.md + paradigm_decision.md 2. Target database schema → target_data_model.md 3. Data migration plan → data_migration_plan.md (script/job generation) 4. Target domain entities → target_domain_model.md + target_business_rules.md 5. Target architecture modules → target_architecture.md (one task per module, in dependency order) 6. Cutover → cutover_plan.md 7. Parity validation → parity_specs.md + parity_tests/.feature ``` To extract modules from `target_architecture.md`, identify sections/headings that describe components or services and create one task per module. If there are declared dependencies between modules, respect them (leaves first). If the target architecture differs from the legacy (e.g., monolith → microservices), use ONLY the target structure, ignoring the legacy topology. ### Pre-flight alerts (migration) In `ambiguity_log.md`, identify: - Items in **PENDING** (they should not exist after Inspector finishes; if they do, alert critically) - Items in **DEFERRED TO CODING** — they become pre-flight alerts for specific tasks (associate by module/context) In `handoff.md`, re-read the "DEFERRED TO CODING" section to ensure coverage. ### Generate the plan (migration) Generate `_reversa_sdd/reconstruction-plan.md` following the template in `references/reconstruction-plan-migration-template.md`. Include in the plan header: `**Source:** migration`. Generation rules: - Each module identified in `target_architecture.md` becomes its own task - The `Reads:` field of each task lists exactly the files that will be read during execution. For modules, typically `target_architecture.md` (module section), `target_domain_model.md`, and `target_business_rules.md` - The `Done when:` field is derived from `parity_specs.md` when the module has a documented parity flow, or from the acceptance criterion described in `target_architecture.md` - Cutover task reads `cutover_plan.md` in full - Parity task reads `parity_specs.md` plus the corresponding `.feature` files After generating, present to the user: > "[Name], reconstruction plan created from the **migration** specs with [N] tasks. > > - Target paradigm: [paradigm] > - Topology: [preserve/modernize/hybrid] > - Stack: [stack from brief] > - Strategy: [big bang / strangler / parallel / other] > [If pre-flight alerts exist]: There are [N] items DEFERRED TO CODING listed in the plan. > > To start, say **START** or **execute task 1**." --- ## Execution Mode Activated when the user says "START", "CONTINUE", "execute task N", or equivalent. ### Step 1 — Identify the task Read `_reversa_sdd/reconstruction-plan.md` (header + task list) and locate: - Identify the `**Source:**` declared in the header (`original` or `migration`). Use this only to adjust the base paths (`_reversa_sdd/...` vs `_reversa_sdd/migration/...`); the execution itself follows the rule "read only what the task's `Reads:` field says". - If the user specified a number: the task with that number - If they said "continue" or "start": the first task with `pending` status If there are no pending tasks: > "All [N] tasks have been completed. The reconstruction is complete." ### Step 2 — Execute 1. Mark the task as `in_progress` in `reconstruction-plan.md` 2. Read **only** the files listed in that task's `Reads:` field 3. Inform: `"Executing Task [N/Total]: [name]..."` 4. Implement strictly based on the specs read 5. For each 🔴 GAP encountered: pause and ask the user before continuing 6. Upon completion: mark the task as `done` in `reconstruction-plan.md` 7. Inform: > "Task [N] completed: [name] > Next: Task [N+1] — [name] > Type CONTINUE to proceed." **Stop and wait.** Never advance automatically to the next task. ### Fidelity rule Implement exactly what the specs say. Do not invent undocumented behaviors. If a spec is incomplete at some point, flag it as a gap and wait for instruction from the user. --- ## Output - `_reversa_sdd/reconstruction-plan.md` — created in Planning Mode, updated after each completed task - Code files implemented as each task is executed Reconstructor does not modify any other file in `_reversa_sdd/`.