---
name: reconstruct
description: "Reconstruct one or more prototype screens 1:1 by dispatching the screen-reconstructor subagent, then integrate the result as single writer. Usage: /reconstruct [route-or-screen-name]"
argument-hint: "[route-or-screen-name] (omit to take the next ☐ from the registry)"
---
> **Specialization:** Read `CLAUDE.md` first and bind every `<…>` placeholder and every "per `CLAUDE.md`" reference from it (stack, project/module names, paths, design-system prefix + shared primitive directory, the reconstruction-workflow doc, naming grammar). This file hard-codes no project value. If a needed value is missing from `CLAUDE.md`, STOP-and-ask. See `SPECIALIZE.md`.

You are the orchestrator for screen reconstruction. The user ran `/reconstruct $ARGUMENTS`.

## 1. Resolve target(s)
- If `$ARGUMENTS` names a route/screen, resolve it against `docs/SCREEN_REGISTRY.md`. Multiple names → multiple targets (you may fan out).
- If `$ARGUMENTS` is empty, pick the next `☐ Not started` row from `docs/SCREEN_REGISTRY.md` (top-to-bottom, foundation/core modules first).
- If no match, list the closest registry routes and stop.

## 2. Claim
For each target, edit `docs/SCREEN_REGISTRY.md` to set its Status to `◐ In progress`. You are the only writer of the registry.

## 3. Dispatch
Dispatch the `screen-reconstructor` agent (subagent_type: `screen-reconstructor`) once per target, passing the route id + screen name + archetype + Source hint from the registry row. For 2+ targets, dispatch them in a single message to run concurrently. Each agent reconstructs its screen and returns a structured report; agents edit no trackers.

## 4. Integrate (single writer)
For each returned report:
- Run the fidelity-gate review against the project's reconstruction-workflow doc (the per-screen method named in `CLAUDE.md`, authored under `docs/design-system/`). If the report's evidence is incomplete or a hard rule was violated, send the agent back (or fix inline) before accepting.
- **Gate the flip on the branch ledger, not the screenshot.** The report must carry a ledger of **every state key the screen's source owns** → `reproduced` or `out-of-scope + reason + evidence`. Spot-check it against the source yourself (the agent's own enumeration is the thing under test); re-derive the key set with the project's prototype conditional/state idiom and confirm the counts agree. A missing or unjustified key is a **Blocked**, never a Done — **the screenshot cannot show you an absent branch**, so accepting on visual evidence alone is exactly how a screen reaches ✅ with a whole modal missing. Record the ledger's key count in the registry note so a later completeness sweep can re-check it cheaply.
- On Done: set the registry row to `✅` + today's date (Verified). On Blocked: leave `◐` and record the blocker.
- Append a `PROGRESS.md` activity-log line (newest first, `Get-Date` timestamp).
- Graduate any returned Insights → `INSIGHTS.md`, Lessons → `LESSONS.md` (Mistake/Trigger/Rule). A lesson that is stable + broadly binding → promote to a hard rule in `CLAUDE.md` or `.claude/agents/screen-reconstructor.md`.
- If a returned lesson identifies a flaw in the reconstruction workflow itself (a missing step, a too-weak gate), also edit the project's reconstruction-workflow doc (and the agent if needed) — the workflow is versioned, not frozen.
- Add each design-system class flagged `candidate-for-graduation` to the `PROGRESS.md` "Graduation queue". When a design-system pattern has appeared on **two or more screens** (or is obviously reusable), graduate it into a named primitive in the project's shared primitive directory (named in `CLAUDE.md`) using the `graduation` skill, then update the queue.
- **CSS reconciliation (parallel fan-out).** Concurrent agents can't see each other's uncommitted CSS, so siblings independently author the same helper (a recurring fan-out hazard). After integrating, grep the project's design-system stylesheet for **duplicate definitions** of each newly-queued class; if the duplicates are identical, collapse to one canonical rule; if they differ, that's a fidelity conflict to resolve (don't silently keep-last). Treat every newly-queued design-system class as shared vocabulary.
- **Single-writer-per-row, not whole-file.** When several integrations land at once, the trackers raise "modified since read". Re-read the narrow region and make targeted, additive, uniquely-anchored edits (one registry row / one activity line above the newest sibling entry) — never a section rewrite, which clobbers a peer.

## 5. Report
Give a concise integration summary: screens done/blocked, registry deltas, new graduation-queue entries, and any prototype-vs-spec conflicts to surface.