Reverse Engineer

Reverse Engineer

Reverse-engineer an external system into two things: a teardown (the evidence: feature inventory, machine-checkable registry and specs, optionally a security audit) and a steal-map (the decision: what to adopt into our surfaces and what to leave behind). A decision row that must cite evidence can be re-checked by anyone; a decision made from impressions cannot be re-checked by its own author. Deciding from a competitor's README is the failure this skill exists to prevent.

⚠️ Constraints — Hard Guardrails (MANDATORY)

• Only operate on code/binaries you own or have explicit written authorization to analyze — this matters because unauthorized teardown is the legal/IP line.
• Do not provide steps to bypass protections/ToS or to extract proprietary source/system prompts.
• Do not output reconstructed proprietary source or embedded prompts (index only; redact in reports) — to prevent reproducing protected IP.
• Redact secrets/tokens/keys if encountered; run the secret-scan gate over outputs to prevent credential leakage.
• Always separate docs say vs code proves vs hosted/control-plane.

Evidence rules

• Tag every capability by its source. code: their source, binary or teardown registry shows it; cite the file:line or registry entry and record what the code actually does, which is often narrower than the claim. docs: a README, doc page or announcement says it; unverified. hosted: a service or control plane you cannot inspect.
• No code access, no steal. With only docs, a README or a landing page, every row about their implementation is docs and unverified. It can be gap, park or reject, never steal.
• Prove our side on the live tree. A have row cites our file. Every "missing" row carries the search that proved it (command and scope). Check what our current stack already offers before calling anything missing.
• Independently checked, not self-report. Facts on how they implement a capability come from code, cross-checked by a fresh reader, never from one context's summary. Model family is optional metadata, not a trust requirement.
• The steal is the pattern, not the platform. Their robustness is usually one idea (unification, a gate, a reconcile loop). Re-express it in our primitives; never vendor their runtime or storage engine.

Phase 1 — teardown