Source profileQuality 85/100Review permissions

boshu2/agentops/skills/reverse-engineer/SKILL.md

reverse-engineer

Reverse-engineer an authorized repo, binary, or product into a verifiable feature inventory and adoption map. Triggers: "reverse-engineer X", "tear down Y", "what should we steal from Z", "evaluate competitor/upstream", "should we fork/adopt/build-native".

Source repository stars
416
Declared platforms
0
Static risk flags
2
Last source update
2026-08-05
Source checked
2026-08-05

Decision brief

What it does—and where it fits

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…

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/boshu2/agentops --skill "skills/reverse-engineer"
    Safe inspection promptEditorial

    Inspect the Agent Skill "reverse-engineer" from https://github.com/boshu2/agentops/blob/c0f78fddd95ab30f8adadc5e513e27064980a529/skills/reverse-engineer/SKILL.md at commit c0f78fddd95ab30f8adadc5e513e27064980a529. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      Phase 1 — Mechanical teardown (the script)

      Produce evidence, not vibes. The script clones (pinned), scans CLI/config/artifact surface, and writes a feature inventory + machine-checkable registry + spec set.

      Produce evidence, not vibes. The script clones (pinned), scans CLI/config/artifact surface, and writes a feature inventory + machine-checkable registry + spec set.Binary mode requires --authorized (see Invocation Contract + Self-Test). Use the bundled demo fixture if you lack authorization for a real binary.
    2. 02

      Phase 2 — The steal-map (the decision)

      Map each capability the teardown found onto our surfaces. This is the part that turns research into a decision. Emit .agents/research//steal-map.md with a table; every row cites the teardown evidence and the matching surface in our repo.

      steal — we lack it and it advances our core. Steal the pattern, not the storage engine: re-express in our primitives, never vendor their runtime.park — real, but it's substrate we deliberately delegate (e.g. orchestration per ADR-0009) or downstream of an unproven bet. Name it, don't build it.reject — it conflicts with our doctrine (e.g. a self-reported completion edge where we require a verdict — "no verdict = not done").
    3. 03

      ⚠️ 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.

      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.
    4. 04

      Route one-way-door adoptions into planning

      If adopting a steal is a one-way door (an architecture fork, a new bounded context, or a migration), do not decide it here. Hand the steal-map to Plan. Dueling Idea Genies or Premortem may challenge the choice as advisory evidence. Plan alone shapes the selected option in the ex…

      If adopting a steal is a one-way door (an architecture fork, a new bounded context, or a migration), do not decide it here. Hand the steal-map to Plan. Dueling Idea Genies or Premortem may challenge the choice as adviso…
    5. 05

      Invocation Contract

      Required: productname. Common flags: --mode=repo|binary|both, --upstream-repo, --upstream-ref (pins the clone to a specific commit/tag/branch; the resolved SHA is recorded in clone-metadata.json on any clone), --output-dir (default .agents/research//), --security-audit, --materi…

      Required: productname. Common flags: --mode=repo|binary|both, --upstream-repo, --upstream-ref (pins the clone to a specific commit/tag/branch; the resolved SHA is recorded in clone-metadata.json on any clone), --output-…

    Permission review

    Static risk signals and limitations

    Runs scripts

    medium · line 20

    The documentation asks the agent to run terminal commands or scripts.

    python3 skills/reverse-engineer/scripts/reverse_engineer.py <product> --mode=repo \

    Network access

    medium · line 21

    The documentation includes network, browsing, or remote request actions.

    -upstream-repo="https://github.com/org/repo.git" --upstream-ref=v1.0.0 \

    Runs scripts

    medium · line 92

    The documentation asks the agent to run terminal commands or scripts.

    python3 "$output_dir/validate-feature-registry.py"

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score85/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars416SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    boshu2/agentops
    Skill path
    skills/reverse-engineer/SKILL.md
    Commit
    c0f78fddd95ab30f8adadc5e513e27064980a529
    License
    Apache-2.0
    Collected
    2026-08-05
    Default branch
    main
    View the original SKILL.md

    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 clones (pinned), scans CLI/config/artifact surface, and writes a feature inventory + machine-checkable registry + spec set.

    python3 skills/reverse-engineer/scripts/reverse_engineer.py <product> --mode=repo \
      --upstream-repo="https://github.com/org/repo.git" --upstream-ref=v1.0.0 \
      --output-dir=".agents/research/<product>/"
    

    Binary mode requires --authorized (see Invocation Contract + Self-Test). Use the bundled demo fixture if you lack authorization for a real binary.

    Phase 2 — The steal-map (the decision)

    Map each capability the teardown found onto our surfaces. This is the part that turns research into a decision. Emit .agents/research/<product>/steal-map.md with a table; every row cites the teardown evidence and the matching surface in our repo.

    Their capabilityOur surface todayVerdict
    <feature><our file / skill / CLI, or "none">have / gap / steal / park / reject

    Verdict rules (hard-won — apply them, do not skip):

    • steal — we lack it and it advances our core. Steal the pattern, not the storage engine: re-express in our primitives, never vendor their runtime.
    • park — real, but it's substrate we deliberately delegate (e.g. orchestration per ADR-0009) or downstream of an unproven bet. Name it, don't build it.
    • reject — it conflicts with our doctrine (e.g. a self-reported completion edge where we require a verdict — "no verdict = not done").
    • have — we already do this; confirm it still holds, move on.
    • gap — we should have it and don't. These are the steal candidates.

    Discipline that makes the map trustworthy:

    • Independently checked, not self-report. Get facts on how they implement each capability from code, cross-checked by a fresh reader — never from a README or one context's summary. Model family is optional metadata, not a trust requirement.
    • Probe the real state, don't argue from stale. Re-verify our side against the live tree before calling something a gap; every "X is missing" carries the search that proved it.
    • The steal is the pattern, not the platform. Their robustness is usually one idea (unification, a gate, a reconcile loop). Steal the idea; leave the scaffolding.

    Route one-way-door adoptions into planning

    If adopting a steal is a one-way door (an architecture fork, a new bounded context, or a migration), do not decide it here. Hand the steal-map to Plan. Dueling Idea Genies or Premortem may challenge the choice as advisory evidence. Plan alone shapes the selected option in the existing intent source; neither strategy grants readiness or continuation authority.

    Invocation Contract

    Required: product_name. Common flags: --mode=repo|binary|both, --upstream-repo, --upstream-ref (pins the clone to a specific commit/tag/branch; the resolved SHA is recorded in clone-metadata.json on any clone), --output-dir (default .agents/research/<product>/), --security-audit, --materialize-archives (authorized-only opt-in; embedded-archive extraction is off/index-only by default), --authorized (mandatory for binary mode — refuses without it). Full list: python3 skills/reverse-engineer/scripts/reverse_engineer.py --help.

    Output Specification

    Phase-1 teardown under output_dir/: feature-inventory.md, feature-registry.yaml, feature-catalog.md, spec-architecture.md, spec-code-map.md, spec-clone-vs-use.md, spec-clone-mvp.md, plus spec-cli-surface.md only when a CLI is detected and clone-metadata.json only when the script performs a clone (i.e., --upstream-repo is supplied and the target is not already checked out); --upstream-ref pins which commit, it is not what triggers the file. Security mode adds output_dir/security/: threat-model.md, attack-surface.md, dataflow.md, crypto-review.md, authn-authz.md, findings.md, reproducibility.md, validate-security-audit.sh. Phase-2: steal-map.md.

    • Artifact directory: the exact --output-dir, defaulting to $REPO/.agents/research/<product>/.

    • Filename convention: the fixed phase-1 and phase-2 names above; security files live only in the security/ child directory.

    • Serialization/schema format: registry is YAML, clone metadata is one JSON object, and inventories/specs/steal-map are nonempty Markdown files.

    • Validator command: with $output_dir, $security_audit, $sbom, and $upstream_ref_set (each flag 0|1) set:

      set -euo pipefail
      required=(feature-inventory.md feature-registry.yaml feature-catalog.md spec-architecture.md spec-code-map.md spec-clone-vs-use.md spec-clone-mvp.md analysis-root-path.txt validate-feature-registry.py steal-map.md)
      for name in "${required[@]}"; do
        test -f "$output_dir/$name"
        test ! -L "$output_dir/$name"
        test -s "$output_dir/$name"
      done
      test -f "$output_dir/docs-features.txt"
      test ! -L "$output_dir/docs-features.txt"
      test ! -L "$output_dir/spec-cli-surface.md"
      if [[ -e "$output_dir/spec-cli-surface.md" ]]; then
        test -f "$output_dir/spec-cli-surface.md"
        test -s "$output_dir/spec-cli-surface.md"
      fi
      python3 "$output_dir/validate-feature-registry.py"
      if [[ "$upstream_ref_set" == 1 ]]; then
        test -f "$output_dir/clone-metadata.json"
        test ! -L "$output_dir/clone-metadata.json"
        jq -e 'type == "object"' "$output_dir/clone-metadata.json" >/dev/null
      else
        [[ "$upstream_ref_set" == 0 ]]
      fi
      grep -Fqx '| Their capability | Our surface today | Verdict |' "$output_dir/steal-map.md"
      if [[ "$security_audit" == 1 ]]; then
        test -x "$output_dir/security/validate-security-audit.sh"
        if [[ "$sbom" == 1 ]]; then
          "$output_dir/security/validate-security-audit.sh" "$output_dir" --sbom
        else
          [[ "$sbom" == 0 ]]
          "$output_dir/security/validate-security-audit.sh" "$output_dir" --no-sbom
        fi
      else
        [[ "$security_audit" == 0 ]]
        [[ "$sbom" == 0 ]]
      fi
      
    • Downstream handoff: give the validated steal-map.md to Plan for one-way-door candidates; ordinary have, park, and reject decisions remain evidence-backed terminal rows.

    Reproducibility + fixtures

    --upstream-ref pins the clone (fetch FETCH_HEAD, record SHA) so contracts can be committed as golden fixtures and diffed across runs. Regression test: bash skills/reverse-engineer/scripts/repo_fixture_test.sh. To update a fixture when contracts legitimately change, re-run with the new pinned ref, copy the contract files into fixtures/<product>/, and commit.

    Self-Test (acceptance)

    bash skills/reverse-engineer/scripts/self_test.sh
    

    Must show: feature inventory generated, registry generated, registry validator exits 0; in security mode validate-security-audit.sh exits 0 and the secret scan passes.

    Examples

    Reverse-engineer an OSS CLI (repo mode) → steal-map

    Run the skill for cc-sdd with --mode=repo --upstream-repo="https://github.com/gotalab/cc-sdd.git" --upstream-ref=v1.0.0. It clones the pinned source, scans the surface, writes inventory/registry/specs, and maps each feature onto our surfaces (have, gap, steal, park, or reject) in steal-map.md. Supply selected steals to Plan.

    Binary analysis with security audit

    Run the skill for ao with --authorized --mode=binary --binary-path="$(command -v ao)" --security-audit. It performs authorized static analysis plus the security suite under output_dir/security/; the secret-scan check must pass.

    Troubleshooting

    ProblemCauseSolution
    Refuses binary analysisMissing --authorizedAdd --authorized (explicit written authorization required).
    No clone-metadata.json--upstream-repo not passedPass --upstream-repo (and optionally --upstream-ref).
    Fixture diff failsUpstream changed / stale goldenRe-run pinned, refresh fixtures/, commit.
    spec-cli-surface.md missingNo Node/Python/Go CLI detectedSurface is documented in spec-code-map.md instead.
    Steal-map is all "steal"Skipped the park/reject rulesSubstrate we delegate is park; doctrine conflicts are reject — not everything novel is worth adopting.

    Quality Rubric

    • Every steal-map row cites teardown evidence and our matching surface (or "none").
    • Verdicts use the full set — have/gap/steal/park/reject — not everything marked "steal".
    • Facts on how they implement come from code and a fresh independent check — not a README.
    • One-way-door adoptions are supplied to Plan, not decided here.
    • Secret-scan gate passed over all outputs; no proprietary source/prompts reproduced.

    See Also

    • plan — shape selected steals in the existing intent source
    • idea-genie — optional advisory challenge (duel mode)
    • premortem — optional advisory challenge of the exact plan
    • research — general exploration; this is its external-system specialization

    Reference Documents

    Alternatives

    Compare before choosing

    Computed 10043,034

    coreyhaines31/marketingskills

    ab-testing

    When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

    Computed 10023,835

    alirezarezvani/claude-skills

    app-store-optimization

    App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist

    Computed 100165

    JasonColapietro/suede-creator-skills

    suede-ab-testing

    Suede-owned experimentation discipline for hypotheses, sample sizing, test duration, significance, and repeatable experiment programs. Use when comparing variants, deciding whether a result is reliable, or building an experiment backlog and cadence. NOT FOR: analytics instrumentation (use suede-analytics), post-click conversion diagnosis (use suede-site-alchemy), or writing the variant copy itself (use suede-copy).

    Computed 1007

    narrative-io/narrative-skills-marketplace

    design-analysis

    Translate a fuzzy analytical question into a rigorous investigation plan. Interrogates the ask, grounds the plan in the available data dictionary, applies analytical best practices, and produces a structured brief of query specifications for a downstream query-writing skill. Plans, does not write SQL. Use when: "why did X drop", "is there a relationship between A and B", "who are our highest-value customers", "what's driving the change in Y", "investigate this trend", "design an analysis for", "