agentsclimarketplace

Reverse engineer

Skill pooyagolchian/specforge/plugins/specforge/skills/reverse-engineer

Spec-driven AI development lifecycle for Claude Code — spec-kit + AI-DLC fused, with hook-enforced human-approval gates. Installable plugin + marketplace.

Install
npx -y skills add pooyagolchian/specforge --skill reverse-engineer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 13 days oldThe repository was created 13 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Seed the SpecForge spec store from an existing codebase (brownfield onboarding). Use when the user wants to adopt SpecForge on an existing project, reverse-engineer specs from current code, document what a system already does, or capture as-built architecture before changing it. Analyzes the repo and writes baseline spec/design artifacts.

SKILL.md

2.5 KB, as published. Nobody here has run it

/specforge:reverse-engineer — brownfield onboarding

Most real adoption is on existing code, not greenfield. This skill analyzes the current repo and produces a baseline set of artifacts so the team can move forward under the lifecycle. Delegate the heavy analysis to the reverse-engineer subagent to keep the main context clean.

When to use

  • Adopting SpecForge on an existing project.
  • The user wants an as-built spec/architecture snapshot before making changes.

Preconditions

  • A specforge/ workspace exists (run /specforge:init first).

Steps

  1. Survey the repo: languages, frameworks, entry points, module boundaries, external dependencies, data stores, and public interfaces (APIs/CLIs/events). Prefer reading manifests (package.json, pyproject, go.mod, etc.) and directory structure over reading every file.
  2. Create a baseline feature specforge/specs/000-baseline/ (number 000 marks the as-built snapshot) containing:
    • business-overview.md — what the system does, for whom (inferred; mark guesses).
    • architecture.md — components, data flow, a diagram, key dependencies.
    • code-structure.md — directory map and module responsibilities.
    • api-documentation.md — observed public interfaces / contracts.
    • code-quality-assessment.md — notable risks, tech debt, missing tests.
  3. Populate specforge/inputs/tech-environment.md from what you actually observe (language, framework, package manager, test framework, conventions). Flag anything uncertain with [NEEDS CLARIFICATION].
  4. Update specforge/state.md (| 000-baseline | reverse-engineer | done | <date> |) and append an audit row.
  5. Recommend next steps: review the baseline with the user, then /specforge:specify the first real change on top of the as-built understanding.

Guardrails

  • This is a read-only analysis of the codebase — do not modify application code.
  • Distinguish observed fact from inference; mark every guess with [NEEDS CLARIFICATION].
  • Keep it high-signal: a navigable map beats an exhaustive file dump.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.