Use reverse-architecture

Reverse-engineer a system's architecture from what already exists

Reverse-engineer a system's architecture from what already exists — a code repo, Terraform / CloudFormation / Pulumi / Bicep, Kubernetes manifests, docker-compose, a database schema, an OpenAPI spec, or a package manifest — and produce a renderable diagram (Mermaid / C4 / PlantUML) plus a written description suitable for handing to architecture-diagrams.

Reach for it when the user wants to draw the system that exists, not one they're proposing — for onboarding docs, audit reviews, migration planning, or filling in a missing "as-is" architecture diagram.

Install it

npx skilldrop-cli install reverse-architecture                 # Claude Code, your user folder
npx skilldrop-cli install reverse-architecture --project       # Claude Code, this repo
npx skilldrop-cli install reverse-architecture --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Solution architect pack: --pack solution-architect installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Reverse-engineer the architecture from this repo"
• "Work out our system diagram from the Terraform and k8s manifests"
• "What does our actual architecture look like based on the code?"
• "Build a diagram from our existing infrastructure-as-code"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Draw a diagram from this written description of the system"
• "Read our Figma file and list the frames"
• "Write an ADR for the architecture we chose"

If another skill answers instead, ask for this one by name: "use reverse-architecture".

Check what you get

A good result:

• Every node has a source-of-truth file path. No node may appear in the diagram without an evidence reference. "I think there's also a worker" is not a node.
• Edges have direction and protocol where the source reveals them. payments-api --HTTPS--> stripe-api beats payments-api → stripe.
• Group by deployment boundary, not by application-layer concern. Subgraphs are VPC / cluster / account, not "data layer" vs "service layer" — the latter is component-level, not container-level.
• Don't pretend you saw what you didn't. If config says REDIS_URL=… but no Redis is in IaC, mark it external (unverified) rather than silently drawing it as "managed Redis".
• Cite the README's claims rather than parrot them. "README claims X uses Kafka. Verified: kafka-go in go.mod and Confluent client config in config/prod.yaml:14." Or: "README claims X uses Kafka — not verified, no Kafka client found in dependencies."

Use something else when

• When the user is proposing something new — that's architecture-diagrams from a written description, not this.
• When the system is too small to need diagramming (one binary, one DB, no external deps). Tell the user a sentence is enough.
• When the only source is a deployed environment with no code/IaC access — this skill reads files; it doesn't introspect live AWS accounts.

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: architecture-diagrams, design-doc

Edit this page on GitHub · View source