reverse-engineer

# Reverse Engineer Reverse-engineer an external system into two things: a **mechanically-verifiable teardown** (feature inventory + registry + specs, optionally a security audit) and a **steal-map** — what to adopt into our surfaces, what to leave behind. The teardown is the evidence; the steal-map is the decision. Separating them works because a decision row that must cite a registry entry can be re-checked by anyone, while a decision made from impressions cannot be re-checked by its own author. The original failure mode this skill exists to prevent: reading a competitor's README and "deciding" from vibes. **Triggers:** "reverse-engineer X", "tear down Y", "what should we steal from Z", "evaluate competitor/upstream", "should we fork/adopt/build-native". ## ⚠️ 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**. ## Phase 1 — Mechanical teardown (the script) Produce evidence, not vibes. The script cl...