HQ Reverse Engineering — System Deconstruction & Intelligence Extraction

Support agents (launched alongside or after):

• search-specialist — Broad web research to supplement findings
• competitive-intelligence-analyst — Market positioning context

Use this skill directly (without agent) for:

• Quick classification of input type (video, product, tutorial)
• Deciding whether reverse engineering is the right approach vs simpler research
• Reviewing and routing completed intelligence reports

When to Reverse Engineer vs When to Research

USER WANTS COMPETITIVE INTELLIGENCE
  |
  +-- Is the information publicly documented (pricing, features, blog posts)?
  |     YES --> Use competitive-intelligence-analyst agent (standard research)
  |     NO  --> Continue
  |
  +-- Is the user providing VAGUE or UNSTRUCTURED input (video, demo, tutorial)?
  |     YES --> Use reverse-engineer agent (this skill)
  |     NO  --> Continue
  |
  +-- Does the user want to understand HOW something was built (architecture, patterns)?
  |     YES --> Use reverse-engineer agent (this skill)
  |     NO  --> Use search-specialist or competitive-intelligence-analyst
  |
  +-- Does the user want to REPLICATE or IMPROVE on a competitor's approach?
        YES --> Use reverse-engineer agent, then route output to blueprinting
        NO  --> Standard competitive intelligence is sufficient

Input Types Accepted

Confidence Scoring System

Every finding MUST be tagged with a confidence level:

Rule: Never present SPECULATIVE findings as facts. Always label confidence explicitly.

Anti-Patterns

1. Confidence Inflation: Treating a YouTube creator's claim as HIGH confidence without corroboration. One source = LOW unless it's code or official documentation.
2. Architecture Assumption: Assuming a competitor uses a specific technology based on UI alone. UI reveals patterns, not implementations.
3. Ignoring Business Model: Reverse engineering only the technology while missing the business model that makes it work. Technical architecture serves business goals.
4. Analysis Paralysis: Spending 10 hours reverse engineering when 2 hours would yield 80% of the insights. Diminishing returns apply heavily.
5. Building Without Validating: Taking reverse engineering output directly to implementation without validating key assumptions. Always flag LOW/SPECULATIVE items for validation before building.
6. Survivorship Bias: Only analyzing successful competitors skews architecture assumptions. Research shows ~40% of "best practices" attributed to winners are actually irrelevant to their success (they succeeded despite those choices, not because of them). Always include at least one failed or pivoted competitor in the analysis set to calibrate what actually matters vs what is incidental.
7. Source Circularity: Three articles citing the same original blog post is 1 source, not 3. Failing to trace citations back to their origin overestimates confidence by 20-30%. Before upgrading any finding from LOW to MEDIUM or MEDIUM to HIGH based on "multiple sources," verify the sources are genuinely independent — different authors, different data, different observation dates.
8. Reverse Anchoring: The first architecture interpretation frames all subsequent analysis, causing confirmation bias in ~65% of multi-source analyses. Mitigate by writing down at least 2 alternative hypotheses BEFORE deep inference begins (see ACH framework in analysis-framework.md). If you catch yourself dismissing contradictory evidence as "probably wrong," you are anchored.