What does this skill do, and when should you use it?
rea-tool-design is one of the skills bundled in the REA (Reverse Engineer Anything) repository. Its job is tool design for REA itself: defining tool boundaries, input/result contracts, provider ownership, and Evidence semantics. It does not analyze binaries or apps; it is a design-and-convention skill aimed at contributors and maintainers. The repository is installed via npx rea-agents setup, which registers the MCP server, and is MIT licensed. If you only want to reverse engineer an app, this skill is not the entry point; if you want to add or modify REA tools, it is the required specification.
- Reads the repo's tool-design guide (docs/tool-design.md) for tool boundaries, contract semantics, provider ownership, and discoverability
- Inspects the current contract and the nearest existing tool relevant to the analyst question before designing
- For a design request, returns the proposed boundary, input/result shape, Evidence semantics, nearest alternative, and verification approach
- Implements designs when requested, preserving user scope and existing authorization
- Points implementation/verification work at the testing guide and CONTRIBUTING.md for generated-file ownership
- A contributor adding a new tool to REA who must settle the tool boundary and contract shape before writing code
- A maintainer changing an existing tool's input/result shape who needs to keep Evidence semantics consistent
- A reviewer checking whether a proposed tool duplicates the nearest existing tool in the catalog
- A developer implementing or verifying a tool change who needs the correct consumer/provider testing lanes from the testing guide
- Regular users who just want to reverse engineer an app or binary — this skill provides no analysis capability; analysis comes from REA's MCP server tools
- External users who won't read or modify the REA repository — all content references in-repo docs, making it meaningless in isolation
How do you install this skill?
- This skill is design guidance only; its real value depends on unreviewed docs/tool-design.md and docs/testing.md, which users should confirm exist and match the current version.
- Reverse engineering carries legal and authorization risks; the skill requires preserving existing authorization, and users remain responsible for lawful targets.
- Native analysis depends on Hopper/Ghidra/IDA, whose download and licensing reachability may be limited in some regions including mainland China.
- The publisher is unverified by the FollowSkills registry; maintenance responsibility and update path cannot be independently confirmed.
- Shell / CLI
- Local filesystem
Node.js 22.x (>=22.19) / 24.x / 26+npmrea-agents CLI (npx rea-agents setup)
The README documents installation of the whole REA collection only; no standalone install command for this skill is documented:
Any agent with local MCP support (Claude Code, Codex, Cursor, Gemini CLI, etc.)
npx rea-agents setupnpm global CLI
npm install --global rea-agents
rea --helpHow do you use this skill?
Once installed, send your agent any of these to trigger it:
- Design a new crash-log analysis tool for REA, giving the tool boundary, input/result shape, and Evidence semantics
- Check the existing analyze-javascript-application contract and whether the field I want to add duplicates the nearest tool
- I'm changing a tool's result shape — per the tool-design guide, what Evidence semantics and verification approach apply?
The skill ships as .agents/skills/rea-tool-design/SKILL.md and is installed with the collection via setup. Trigger it by asking your agent a tool-design question. The flow: consult the tool-design guide → inspect the current contract and nearest existing tool (source, docs, and live catalogs may describe different versions) → produce a design covering boundary, input/result shape, Evidence semantics, nearest alternative, and verification approach → implement only when requested, preserving the user's scope and existing authorization. For implementation or verification, consult the testing guide and CONTRIBUTING.md; read other provider/workflow guides only as needed.
What are this skill's strengths and limitations?
- Gives the REA tool ecosystem an explicit contract and Evidence-semantics standard, lowering the contribution barrier
- Requires checking the nearest existing tool first, preventing duplicate designs
- Design output includes a verification approach; design and implementation are kept separate, respecting user scope and authorization
- Produces no analysis results itself; its value is entirely dependent on the REA repository and its docs existing
- Heavy use of relative-path links to in-repo docs means standalone installation breaks the reference chain
- The README does not state the skill's version or alignment with REA releases, so docs and code may be out of sync
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| REA Tool Design Skill this page | 51 · Use with care | ★ 71k | today | MIT |
| REA: Reverse Engineer Anything | 59 · Recommended | ★ 71k | today | MIT |
| Pulser — SKILL.md Linter | 50 · Use with care | ★ 18 | 3mo ago | MIT |
| BlockWatch | 67 · Recommended | ★ 29 | 3d ago | MIT |
| CodeRabbit Review Skill | 53 · Use with care | ★ 35 | 2mo ago | Unlicense |
The source offers no direct competitor to compare against; the other skills in the REA collection handle actual reverse-engineering work, while this one only defines tool-design conventions.
How did FollowSkills review this skill?
The skill contains only design guidance: no file writes, network access, or destructive operations, and it explicitly instructs preserving user scope and existing authorization. However, its substance depends entirely on repository docs (tool-design.md, testing.md) not shown in this review, so permission boundaries and rollback cannot be independently verified; scored accordingly.
Instructions are self-consistent and give a clear deliverable contract (boundary, input/result shape, Evidence semantics, nearest alternative, verification). Key paths point to unreviewed guides whose existence and consistency could not be statically confirmed, and failure feedback on abnormal input is unverifiable; capped at 10 for static review.
The scenario is clear (designing or changing REA investigation tools, CLI/MCP contracts, Evidence semantics), and trigger semantics match the name. Non-fit boundaries, example inputs/outputs, and environment requirements are undeclared; reachability of the upstream toolchain (Hopper/Ghidra/IDA) from mainland-China networks is unaddressed, hence the deduction.
The skill is generated by scripts/generate-skill-metadata.mjs with CI metadata checks, MIT license is clear, and repository governance (CI, tests, contributing) is visible. The skill file itself lacks versioning, changelog, examples, and known-limitation disclosure, and maintenance responsibility rests on an unverified publisher; scored accordingly.
The design-request checklist is directly reusable and offers some marginal value, but output quality depends on unreviewed guide content and statically unverifiable claims; the 7-point static ceiling applies.
The repository contains real CI workflows and extensive tests, but none covering this skill file's key paths. Claims about contract semantics and verification approach cannot be independently reproduced in a static read; scored accordingly.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →