Reverse Engineer Rpi
Reverse-engineer an existing codebase into a feature registry, code map, and validated specs before you extend or ship changes.
Overview
Reverse-Engineer RPI is an agent skill most often used in Build (also Validate, Ship) that inventories features, maps code to specs, and runs validation gates without dumping raw prompts or source into reports.
Install
npx skills add https://github.com/boshu2/agentops --skill reverse-engineer-rpiWhat is this skill?
- Binary-mode reverse engineering with optional docs sitemap for faster coverage
- Separates docs claims, code evidence, and hosted/control-plane behavior in reports
- Generates feature registry and specs with explicit validation gates
- CLI surface contract checks with fixed-string assertions (e.g. cc-sdd v2.1.0 flags)
- Keeps embedded prompts and raw source out of published reports
- Default prompt targets cc-sdd v2.1.0 CLI surface contract checks
- Workflow enforces three evidence lanes: docs say, code proves, hosted/control-plane
Adoption & trust: 802 installs on skills.sh; 384 GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You inherited a repo or agent tooling stack and cannot tell which features are real, documented, or only implied by hosted behavior.
Who is it for?
Solo builders auditing unfamiliar agent-ops repos, CLI packages, or multi-surface products before writing implementation plans.
Skip if: Greenfield apps with no existing code to map, or when you only need a one-line feature list without validation gates or contract checks.
When should I use this skill?
You need a feature inventory, code map, and validated specs from an existing binary or monorepo, especially with a docs sitemap available.
What do I get? / Deliverables
You get a feature registry, code map, and gate-validated specs with docs-vs-code-vs-control-plane separation so you can scope the next build or review step confidently.
- Feature registry and structured specs with validation gate results
- Code map separating documentation claims from provable implementation
- CLI or surface contract spec when package metadata is in scope
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the skill’s output is structured specs and maps tied to the product you are actively developing, even when you started from discovery. Docs fits best: it produces feature inventories, CLI surface contracts, and spec artifacts rather than shipping runtime code.
Where it fits
Inventory features in a forked agent repo before deciding what to keep in v1.
Generate spec-cli-surface.md with fixed-string assertions for cc-sdd v2.1.0 flags.
Gate release on whether embedded prompts and source stay out of customer-facing reports.
Refresh the feature registry after a control-plane behavior change without re-reading the whole tree.
How it compares
Use instead of skimming READMEs or pasting the whole repo into chat when you need gated specs and a code-backed feature registry.
Common Questions / FAQ
Who is reverse-engineer-rpi for?
Indie and solo developers who ship with AI coding agents and need structured reverse engineering of an existing codebase—not a from-scratch scaffold generator.
When should I use reverse-engineer-rpi?
Use it during Validate to scope an inherited product, during Build/docs when producing feature registries and CLI surface specs, and during Ship/review when verifying docs match code before release.
Is reverse-engineer-rpi safe to install?
Treat it like any third-party agent skill: review the Security Audits panel on this Prism page and avoid pointing it at repos with secrets you do not want in agent context.
SKILL.md
READMESKILL.md - Reverse Engineer Rpi
__pycache__/ *.pyc display_name: Reverse-Engineer RPI short_description: Feature inventory + code map + specs with validation gates default_prompt: | Run reverse-engineer-rpi in binary mode with a docs sitemap if available, generate the feature registry and specs, then validate gates. Keep docs say vs code proves vs hosted/control-plane separate, and do not dump embedded prompts/source into reports. # CLI surface contract assertions for cc-sdd v2.1.0 # Each non-comment line below must appear verbatim in the generated spec-cli-surface.md. # The check uses grep -F (fixed-string substring match), so leading spaces matter. # Lines starting with # are comments. # Package identity - Node package: `tools/cc-sdd` - package name: `cc-sdd` - version: `2.1.0` # Binary entrypoint - `cc-sdd` -> `./dist/cli.js` # Source entry heuristic - `tools/cc-sdd/src/cli.ts` (node shebang entry; typically calls `runCli`) # Key CLI flags (2-space indent as they appear inside the help text code block) --agent <claude-code|claude-code-agent|codex|cursor|github-copilot|gemini-cli|windsurf|qwen-code|opencode|opencode-agent> Select agent --lang <ja|en|zh-TW|zh|es|pt|de|fr|ru|it|ko|ar|el> Language --os <auto|mac|windows|linux> Target OS (auto uses runtime) --kiro-dir <path> Kiro root dir (default .kiro) --overwrite <prompt|skip|force> Overwrite policy (default: prompt) --dry-run Print plan only --yes, -y Skip prompts (prompt -> force) -h, --help Show help -v, --version Show version # Config surface - User config file: `.cc-sdd.json` (loaded from CWD). - Environment variables: `NO_COLOR` { "upstream_repo": "https://github.com/gotalab/cc-sdd.git", "upstream_ref": "v2.1.0", "resolved_commit": "6e972c064ac4723bc8ad0181871d07e199af6a9f" } docs/README/README_en docs/README/README_ja docs/README/README_zh-TW docs/README docs/RELEASE_NOTES/RELEASE_NOTES_en docs/RELEASE_NOTES/RELEASE_NOTES_ja docs/guides/claude-subagents docs/guides/command-reference docs/guides/customization-guide docs/guides/ja/claude-subagents docs/guides/ja/command-reference docs/guides/ja/customization-guide docs/guides/ja/migration-guide docs/guides/ja/spec-driven docs/guides/migration-guide docs/guides/spec-driven schema_version: 1 product_name: 'cc-sdd' docs_features_prefix: 'docs/' docs_features: - 'docs/README/README_en' - 'docs/README/README_ja' - 'docs/README/README_zh-TW' - 'docs/README' - 'docs/RELEASE_NOTES/RELEASE_NOTES_en' - 'docs/RELEASE_NOTES/RELEASE_NOTES_ja' - 'docs/guides/claude-subagents' - 'docs/guides/command-reference' - 'docs/guides/customization-guide' - 'docs/guides/ja/claude-subagents' - 'docs/guides/ja/command-reference' - 'docs/guides/ja/customization-guide' - 'docs/guides/ja/migration-guide' - 'docs/guides/ja/spec-driven' - 'docs/guides/migration-guide' - 'docs/guides/spec-driven' groups: README: impl: control-plane anchors: [] notes: "" RELEASE_NOTES: impl: control-plane anchors: [] notes: "" guides: impl: control-plane anchors: [] notes: "" # Executable spec for the /reverse-engineer-rpi skill — spec reconstruction (BC1 Corpus). # /reverse-engineer-rpi reconstructs product specs from an existing system — in repo mode it # maps the code into a feature catalog and specs; in binary mode it analyzes a binary with a # security audit. Hexagon: supporting; consumes: a target codebase or binary; produces: # a feature catalog, code map, and specs. (soc-qk4b) Feature: Reverse-engineer-rpi reconstructs specs from an existing system As an agent onboarding or auditing an unfamiliar system I want its behavior reconstructed into a feature catalog and specs So that work can proceed from a real map instead of guesswork Background: Given a target system provided as a repo