REA-Reconstruction-Companion

REA-Reconstruction-Companion

Understand existing software. Plan a reconstruction. Build and validate when requested.

An open-source skill for AI agents, designed to work with REA. A skill is a set of instructions and reference guides that an agent reads while working. This one helps you understand existing software and turn what you learn into a plan, a working reconstruction when requested, and checks of the result. It does not require a particular model or AI provider.

What it does · Get started · Use · Integration · Updates and recovery · Topic guides · Development

What the companion does

Use the companion when you want to understand how software behaves, plan a similar tool, rebuild a selected part, or improve a reconstruction you already have. The scope can be a whole app, one workflow, a file format, or a single function.

• Understand: turn observations, files or recordings into a clear description of behavior, requirements and unanswered questions. For example, find out what an editor keeps when a save fails.
• Plan: decide what to build first, what it depends on and how to check it. A specification describes the behavior to preserve; a reconstruction plan describes the steps for building it.
• Build when requested: implement the selected behavior in useful, testable steps. Asking to investigate or plan a possible future rebuild does not authorize implementation now.
• Validate and improve: compare results with the evidence, test relevant failures and measure proposed performance improvements. Report differences and anything still unverified.

REA supplies the tools for examining software and collecting evidence. The companion helps the same agent use that evidence for requirements, design, implementation and validation. Installing both does not create two independent background agents. You can also start from supplied REA evidence when live tools are unavailable.

Observed behavior, reasonable inferences and proposed design choices stay separate. Missing evidence remains a gap; neither a plausible reconstruction nor a passing local example proves that it matches every part of the original.

flowchart LR
    A[User goal and target] --> B[Scope and questions]
    B --> C[REA evidence]
    C --> D[Requirements and design]
    D --> E[Implementation when requested]
    E --> F[Validation and measurements]
    D -->|Evidence gap| C
    F -->|Evidence gap| C

Before you start

Use an agent that can read local skill files and, for installation or live investigation, run local commands. The core is plain Markdown in the Agent Skills format: it has no model SDK, paid API requirement, Python dependency, telemetry or background service. The installer needs Node.js 20 or newer; you do not need to run npm install.

Cost and permission limits

The skill forbids initiating actions that could add charges: purchases, subscriptions/trials, metered APIs or model calls, billable cloud/CI/storage/deployment, and indirect paid work. Existing local tools and supplied evidence come first. If an action's no-charge status cannot be established for the actual environment, the agent must skip it and explain a local alternative or limitation. An available tool or a free tier is not sufficient evidence. It does not automatically launch agents, evaluations, or scheduled jobs.

This rule is an instruction, not a billing enforcement mechanism. An AI host may itself bill tokens or usage credits, and local execution consumes resources such as electricity. The skill cannot guarantee zero total cost or control another product's billing or model compliance. It must not enable extra paid usage or alter billing settings; use host/account spending controls for an absolute spending limit. No paid exception is part of this skill's workflow.

Codex and Claude Code both support filesystem skills. Their discovery locations and invocation syntax differ; the installer handles those differences. Other agents can use the same core files through an explicit skills directory. Compatibility depends on the host's file/tool access, not just the model name. See the official Codex skill documentation and Claude Code skill documentation.

Hosted uploads and chat-only clients are different: an uploaded skill ZIP cannot generally edit a separate local REA installation. Supply both skills and evidence through that host's supported mechanisms, or use a local agent for installation and live analysis. No live-model compatibility certification is implied by the installer tests.

Two separate setup choices

• REA integration: choose whether relevant REA reconstruction requests should also load the companion. Integration adds a small marked rule to the selected REA skill. You can leave it off and invoke the companion yourself. “Off” leaves REA untouched; it does not remove an earlier rule. See integration and its recovery limits.
• Weekly update checks: off by default. If you opt in, checks happen on skill use, at most once every seven days; an idle skill runs nothing. Finding an update still requires your approval before installation. This choice is independent of integration. See weekly update checks.

Install REA separately for your client if you want live REA tools or automatic co-use. The companion does not install or configure REA for you.

Get started

Install with an AI agent

Copy the prompt below into an agent with local file and command access. It asks the agent to identify your client, explain the choices, preview the changes and verify the result. There are no placeholders to fill in. If you prefer to run commands yourself, use manual installation.

Install REA-Reconstruction-Companion from:
https://github.com/ShadowSwaps/REA-Reconstruction-Companion

Read README.md and INSTALL.md, identify my AI client and its skills
directory, and follow the documented installation workflow.

Before making installation changes, explain the optional REA integration
rule and ask me to choose:
- Enable: relevant REA reconstruction requests also load the companion,
  sharing evidence, requirements, and validation work.
- Skip: install the companion without changing REA; I can invoke it
  explicitly. This does not remove an integration rule already installed.

Wait for my choice unless I have already provided it. Then install using
that setting, preview changes with --dry-run, preserve existing work and
backups, and verify with --check. Explain any missing prerequisites or
access limitations. Report what was installed, where, and whether the
integration was enabled. Do not claim success unless verified.
Also explain the optional weekly update check (included since v1.2.0)
and ask whether I want it enabled. Keep it off unless I choose it.
This checks on skill use and still asks me before installing an update.
Do not incur additional charges: use existing local tools and do not
activate billing, paid services, metered APIs, or automatic paid usage.
If a step could incur a charge and that cannot be ruled out, stop that
step and explain a no-charge alternative.

You can include "Enable integration" or "Skip integration" with the prompt to choose upfront. The integration explanation describes its purpose and benefits. A chat-only assistant without local file and command access can guide you through installation but cannot perform it itself.

Share the repository: github.com/ShadowSwaps/REA-Reconstruction-Companion.

Install

Download and extract the ZIP from Releases, or clone this repository. Run commands from the extracted folder or repository root. On Windows, macOS, and Linux, the installer commands are the same.

For automatic co-use, first install REA for your client. Choose the command for your client and integration preference:

# Claude Code, with the optional integration
node install.mjs --client claude-code --integration on

# Codex, with the optional integration
node install.mjs --client codex --integration on

# Companion only; no changes to REA
node install.mjs --client claude-code --integration off

Before installing, add --dry-run to your chosen command to inspect the paths and changes without writing files. For example: node install.mjs --client codex --integration on --dry-run. In the preview, companionChanges lists files to add, modify or remove, with paths relative to the companion directory. It also lists local files that replacement would move into the backup. When the preview is right, run the command without --dry-run, then add --check to verify the installation. For example: node install.mjs --client codex --integration on --check. A missing REA skill or ambiguous choice stops integrated installation before the companion is installed. Differently cased paths to the same REA file are treated as one candidate; genuinely separate installations still require an explicit selection.

claude_code, as used by REA, is accepted as an alias for claude-code by the installer and updater. Plans, receipts and newly saved update settings use claude-code.

node install.mjs --client generic --integration on --skills-dir "/path/to/skills" --rea-skill "/path/to/reverse-engineer-anything/SKILL.md"

Use

You can explicitly invoke $rea-reconstruction-companion in Codex or /rea-reconstruction-companion in Claude Code. With integration enabled, a relevant request to REA also instructs the agent to load the companion.

Describe the software and what you want to achieve in ordinary language. The companion uses available REA tools or supplied evidence, points out missing information, and keeps the work at your requested scope. These examples are illustrations, not required prompts: paraphrases, casual wording, minor typos and follow-ups should work in context. Say what you want to understand or build; you do not need to name a mode or reproduce a template. Explicit corrections and exclusions take precedence, and a possible future rebuild does not request implementation now.

The agent must report missing tools or evidence instead of claiming live analysis or complete equivalence. A build request does not authorize deployment, releases, installation changes, paid tools, or additional charges. Those actions require their own authority; the cost and permission limits still apply.

If the original has awkward behavior, say which compatibility matters and what you want improved—for example, “Keep exports readable by my existing tools, but make failed saves clear.” The companion separates observed behavior from intended changes, checks affected dependencies, and keeps unresolved or deferred work visible. See the worked quirk decisions.

Screenshots, recordings and incomplete descriptions can also provide a starting point. The companion separates visible states and demonstrated transitions from assumptions, asks about gaps that change the result, and keeps visual similarity distinct from working behavior. See the bounded visual-evidence example; supplied images do not require a whole-app rebuild or imply access to its server.

For selected interfaces, the companion also separates keyboard operation, focus, labels, errors and status feedback from visual fidelity. The accessibility worked slice demonstrates a small intentional improvement with live keyboard evidence and explicit unrun screen-reader checks.

Understand and plan

Ask for a description of the behavior, requirements linked to evidence, unanswered questions and a staged roadmap. To stop before implementation, say so:

Use REA and the companion to understand the desktop notes app I have open
so I can plan a similar app later. Focus on creating, editing, searching,
and saving notes. Link requirements to the evidence, separate observations
from inferences, and list unanswered questions and a staged build roadmap.
Stop after the specification and plan.

Build a similar app

A build request authorizes implementation within the requested scope. Expect code in testable steps, checked against observed requirements, with gaps and differences reported:

Use REA and the companion to investigate the desktop notes app I have open
and build a local web app with similar note creation, editing, search,
and save behavior in this workspace. I need to trust today's notes first:
it must work offline and reopen my saved notes. Start with that working
journey, including save failures, then add search and the remaining
features in testable increments. Animations can wait. Validate against
the evidence and report differences and anything you could not verify.

For a broad request, expect a compact plan around the first useful outcome, its essential dependencies and design-changing unknowns, with evidence-linked checks and deferred work kept visible. Explicit hard requirements remain binding. If finding existing notes matters most, that can lead instead of creating new ones; you do not need to use priority labels or complete a feature inventory. See the worked prioritization example for a plan and its limits.

Investigate one function or feature

Keep a narrow investigation narrow. Expect a contract: what inputs it accepts, what it returns or changes, how it fails, and what remains unknown. Ask for representative cases that can later check an implementation:

Use REA and the companion to investigate the CSV import feature in the
app I have open. Trace how it handles headers, quoted fields, duplicate
rows, and malformed input. Document inputs, outputs, side effects, error
behavior, and representative acceptance cases, citing the evidence.
Keep this to an investigation; do not implement changes.

Optional REA integration

Choose one during installation:

• On — --integration on: adds a marked instruction block to your selected REA SKILL.md. Relevant REA reconstruction requests then ask the agent to load the companion without you naming it separately.
• Off — --integration off: installs only the companion and leaves REA untouched. Choose this to invoke the companion yourself or manage your own routing rules.

The rule applies when you want to understand software for reconstruction, plan a similar implementation, or rebuild selected behavior. It helps the agent reuse evidence, connect each requirement to a test, and return to REA when design or testing reveals an unanswered question. An ordinary explanation, comparison or diagnostic question stays at that scope.

This is an instruction-based integration. It does not override client policies, grant tool permissions, connect MCP servers, guarantee model compliance, or force parallel execution. Without the rule, invoking the companion still tells the agent to use REA. The rule supplies the reverse direction: relevant REA work also loads the companion.

REA skill refreshes can remove this rule. After a refresh, check the integration before relying on automatic loading. The known canonical-file warning below is specific to the inspected REA version; do not dismiss other doctor errors.

After rea setup, rea update, or another REA skill refresh, recheck the selected integration and, if needed, restore only its block using the matching verified companion package; see verification and scoped recovery. Do not restore an entire old REA backup over newer instructions. If routing disappeared, explicitly invoke the companion or run the manual check. The optional on-use warning cannot run if the companion/helper is never invoked.

off means do not manage REA, not “remove a rule already installed.” To disable an earlier integration, remove only the block between <!-- rea-reconstruction-companion:begin --> and <!-- rea-reconstruction-companion:end --> in the selected REA SKILL.md, including the markers. Keep the rest of REA intact.

Updates, backups, and recovery

Choose between optional update notifications and a manual reinstall. Both preserve the documented consent, backup and recovery boundaries. Review the printed paths and receipts before any recovery.

Manual updates and backups

• Repeating the same installation is safe and does not duplicate the integration block.
• Differing companion files require --replace; the installer backs up the entire prior companion directory before replacing it.
• REA edits preserve everything outside the marked integration block. The exact earlier pre-release rule can also be migrated; customized unmarked rules require review.
• Backups and a receipt are stored in .rea-reconstruction-companion-installer/ next to the parent skills directory. The installer prints the exact transaction path.
• Failed commits attempt REA and companion recovery independently, so an unreadable or missing REA file does not prevent restoring the prior companion. Backups remain available; a detected concurrent edit is retained and reported rather than overwritten.
• Updating REA may replace its skill instructions. Follow verification and scoped recovery after a refresh. Nothing monitors or rewrites REA in the background.

For manual recovery, use the printed receipt to locate the selected paths. Restore companion-before to the companion's former location if appropriate. Restore rea-before.md only when REA has no later changes you need to retain; otherwise remove or repair just the integration block. If a process was killed and left an install.lock, make sure no installer is running before removing that exact lock file and retrying.

Optional weekly update checks (since v1.2.0)

Starting with v1.2.0, the updater is bundled inside the skill, including installations for Codex, Claude Code and generic clients. Enable it once after installation if you want release notifications. The host calls a small local helper when the skill is used; it contacts GitHub only when seven days have elapsed. An idle skill runs nothing. Earlier versions do not gain this automatically: manually install a published v1.2.0-or-later package first.

With checks enabled and recorded integration on, the current helper also inspects the recorded REA rule locally before cooldown or network decisions. Missing, changed/malformed, or unreadable/unsafe rules return integration-needs-attention without repair, state changes or networking. Disabled checks and integration off do not inspect REA. This warning is available only in versions containing this change and only when the companion/helper is invoked; it is not a background monitor or a full rea doctor check.

When a newer stable release is found, the agent offers Update now / Remind me next week / Skip this version / Disable checks. No answer means no update. Approval is tied to the offered release and asset; changed assets require a new offer. Local customizations stop automatic replacement. Successful updates retain backups, verify the result and preserve your selected client and REA integration setting.

Checks are off by default, independent of integration, and require existing Node.js 20+. There is no npm dependency, model/API key, paid service, extra model call, background daemon or scheduled AI task. Online operations also require confirmation that the actual network/tool environment cannot add charges. Unknown-cost or unavailable access is skipped; this is not an unconditional zero-resource-cost or billing-enforcement guarantee.

Read the setup, commands, state location and recovery guide. Host instruction-following and local command access are required; the helper cannot force every AI host to invoke it or authenticate a human response. Installation refresh behavior depends on the host. The project owner's release approval process remains unchanged.

Find guidance by topic

Choose guidance for the part you are investigating or building. Each entry links to the method and a worked example. These examples have finite coverage and disclose prior source exposure; local results do not establish a match with the original, real-service behavior or general host/model compatibility.

…