reverse-engineer
Skill453 starsChanged 4 months agoApache-2.0View on GitHub
Tear down a competitor''s repo or product into a feature inventory and adoption choices. Use when: comparing us to another tool or asking what to steal.
22 other projects use a version of this.
Adopted by
Most recently taken up by
- Firzus/agent-skillstheir own version, first seen Nov 1, 2026
- afonsoft/skillstheir own version, first seen Nov 1, 2026
- patrick-fu/awesome-skillstheir own version, first seen Nov 1, 2026
- loootai/reverse-engineertheir own version, first seen Nov 1, 2026
- umararshad4/honey-stacktheir own version, first seen Nov 1, 2026
- laaielichter/Reverseporttheir own version, first seen Oct 20, 2026
Used with
Projects with it also use debug-issue, prototype and 1 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
NVIDIASkilldebug-issue
Use when the user asks to debug, investigate, or fix a GitHub issue or supplies a repository bug report.
Also in 3 projects that use this
GoogleSkillprototype
Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
Also in 4 projects that use this
MicrosoftSkillhandoff
Compact the current conversation into a handoff document for another agent to pick up.
Also in 3 projects that use this
Other versions22 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 22
- patrick-fu/awesome-skills★ 69same name
- laaielichter/Reverseport★ 18same name
- kevinbadi/open-edits★ 17same name
- afonsoft/skills★ 14same name
- rade-nugroho/Agentic-Enteprises-Skill★ 9same name
- xfstudio/skills★ 9same name
- daemon-blockint-tech/Agentic-Enteprises-Skill★ 8same name
- tstapler/dotfiles★ 8same name
- alvinhayy/Mobile-ReverseSkill★ 6same name
- umararshad4/honey-stack★ 5same name
12 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository32 other files it gives its agents.
- AGENTS.mdAGENTS.md
- cli/AGENTS.mdAGENTS.md
- agent-nativeSkill
- agy-nativeSkill
- architectureSkill
- claude-execSkill
- codex-execSkill
- councilSkill
- craft-goalSkill
- docSkill
- domainSkill
- ergonomicsSkill
- idea-genieSkill
- implementSkill
- interviewSkill
- memorySkill
- navigateSkill
- orchestrateSkill
- planSkill
- postmortemSkill
- premortemSkill
- refactorSkill
- researchSkill
- reviewSkill
- rpiSkill
- securitySkill
- skill-builderSkill
- skill-evalSkill
- testSkill
- triageSkill
- using-gcSkill
- validateSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 6 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 18 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 37
Only operate on code/binaries you own or have explicit written authorization to analyze — this matters because unauthorized teardown is the …
- Distinctive: line 38
Do not provide steps to bypass protections/ToS or to extract proprietary source/system prompts.
- Distinctive: line 39
Do not output reconstructed proprietary source or embedded prompts (index only.
- Distinctive: line 41
Always separate docs say vs code proves vs hosted/control-plane.
- Distinctive: line 134
When two seem to fit, reject beats park, and park beats steal or gap.
- Very specific: line 139
After authoring steal-map.md, validate the complete output with $output_dir, $security_audit, $sbom, and $upstream_ref_set (each numeric …
- Distinctive: line 157
If adopting a steal is a one-way door (an architecture fork, a new bounded context, a storage or data migration), do not decide it here: …
“Common” is measured: kept by at least 6 in 10 of the 18 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Reverse Engineer
Reverse-engineer an external system into two things: a teardown (feature inventory, a registry of where to read, CLI and contract 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. The output validator runs this skill's
scripts/security/scan_secrets.shover the whole output dir in every phase; a hit fails it until you redact. - Always separate docs say vs code proves vs hosted/control-plane.
Evidence rules
- Tag every capability by its source.
code: their source or binary shows it; cite the file:line (for a binary, the teardown output line) you opened 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. - The registry is an index, not evidence. It lists where to read. In repo
mode its groups start
impl: unclassified(binary mode writesclientgroups anchored tobinary-symbols.txt, still notcodeevidence);clientormixedneeds anchors, andcontrol-planemeanshosted. A registry entry alone never makes a rowcode. - No code access, no steal. With only docs, a README or a landing page,
every row about their implementation is
docsand unverified. It can begap,parkorreject, neversteal. - Prove our side on the live tree. A
haverow 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. - Re-open before a steal. Re-open each cited file before marking
steal; a summary from memory is not evidence. - 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
<skill-dir> is the directory that contains this SKILL.md. Claude Code shows it
as "Base directory for this skill"; Codex lists this skill's SKILL.md path; in
an AgentOps source checkout it is skills/reverse-engineer. Replace
<skill-dir> with that absolute path before running a command. The working
directory stays the user's repository. If the host did not show where this
skill is installed, use the directory of the SKILL.md you read. If you cannot
determine it, do not guess a path or run a same-named script from the current
repository; say the bundled script is unavailable and build the inventory and
steal-map by hand as in docs-only mode below.
With an authorized clone or binary, the script clones (pinned), scans the CLI/config/artifact surface and validates the teardown:
python3 "<skill-dir>/scripts/reverse_engineer.py" <product> --mode=repo \
--upstream-repo="https://github.com/org/repo.git" --upstream-ref=v1.0.0 \
--output-dir=".agents/scratch/reverse-engineer/<product>/"A passing teardown is not a populated one. The inventory and registry index
the target's docs pages (--docs-sitemap-url, else its docs/**/*.md); with
no docs they are empty. spec-architecture.md and spec-code-map.md are
templates you fill. The code anchors are in contracts/repo-contract.json and
spec-cli-surface.md.
The clone lands in .tmp/<product>/ under the current directory unless
--local-clone-dir names another place; keep it out of your commits. Binary
mode requires --authorized; without written authorization, do not run binary
mode; use docs-only mode below. Flags, the full output list, fixtures and tests
are in the invocation reference.
Without code access (only a README, docs site or landing page), skip the
script: build the inventory and steal-map by hand with each row tagged docs
or hosted, and say that no teardown validator ran. When the code is readable
but the script cannot run on it, read the code directly and cite file:line
for each code row; the validator gap still gets reported.
Phase 2 — steal-map
Map each capability onto our surfaces in
.agents/scratch/reverse-engineer/<product>/steal-map.md. The script stops
after validating Phase 1; it cannot truthfully decide whether our live tree
has, lacks, or should adopt a capability. The caller authors the map from the
teardown, the code it points to, and a fresh read of our repository. A missing or malformed map is an
incomplete skill result, not a script success relabelled as a decision.
| Their capability | Our surface today | Verdict |
<feature> (code: <file:line>), (docs) or (hosted) | <our file / skill / CLI>, or "none: <search command>" (the search that proved it) | have / gap / steal / park / reject |
Each row gets exactly one verdict:
- have — our live tree already does it; cite the file and confirm it still holds.
- steal — we lack it,
codeevidence shows how they do it, and it advances our core. Take the pattern, re-expressed in our primitives. - gap — we lack it and would want it if it holds up, but steal is not
earned: their mechanism is
docsorhostedonly, or its value to our core is unshown. Name the evidence that would decide it. - park — real, but deliberately not ours to build now: substrate we delegate (for AgentOps, ADR-0009 keeps scheduling, supervision and queues external) or downstream of a bet we have not made. Name it, don't build it.
- reject — conflicts with our doctrine (e.g. a completion edge with no check behind it, where we require checks and CI, plus one fresh judgment for a costly mistake).
When two seem to fit, reject beats park, and park beats steal or gap; between steal and gap, the evidence rules decide.
Validation and handoff
After authoring steal-map.md, validate the complete output with
$output_dir, $security_audit, $sbom, and $upstream_ref_set (each
numeric flag 0|1):
bash "<skill-dir>/scripts/validate-output.sh" \
--output-dir "$output_dir" --phase complete \
--security-audit "$security_audit" --sbom "$sbom" \
--upstream-ref-set "$upstream_ref_set"It fails any table row without a source tag or one of the five verdicts, any
steal without code evidence, and any none without a backticked search;
with an upstream ref it requires the resolved commit in clone-metadata.json.
With --security-audit 1, first fill every _TBD under security/; each
finding in findings.md needs Evidence: and Fix: lines. It must exit 0
before handoff, or the report says it did not run (docs-only mode).
If adopting a steal is a one-way door (an architecture fork, a new bounded
context, a storage or data migration), do not decide it here: hand the
validated steal-map to Plan, which shapes the selected
option in the existing intent source. Idea Genie duel
mode or Premortem may challenge it as advisory
evidence; neither grants readiness or continuation authority. Ordinary have,
park and reject rows are evidence-backed terminal decisions.
For general exploration rather than one external system, use Research. The scenarios in reverse-engineer.feature document the behavior; the invocation reference lists the tests that check it.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

