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. Use 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.
In Claude Code, with the solution-architect plugin installed, invoke it as:
/solution-architect:reverse-architecture
Try it
A realistic prompt from the skill's acceptance evals:
Reverse-engineer the architecture of this repo — it has Terraform, Kubernetes manifests, and an OpenAPI spec.
What a good result looks like
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."
How it's checked
Measured against plain Claude Code (2026-10-23): it met 59% of its checks, against 48% without it, and a blind judge preferred the agent without it. How skills are checked
19 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
Every node carries a source-of-truth file path as evidence; nothing appears in the diagram without a reference
Inferred components are marked as inferred rather than asserted as fact
Edges carry direction and, where the source reveals it, protocol
Nodes are grouped by deployment boundary as the artifacts reveal it
The output is derived from the supplied artifacts, not from a written description of intent
as-is.md is saved with one Mermaid diagram and a description of no more than about 300 words
The diagram shows the services defined in docker-compose.yml (proxy, web, worker, db, cache), with both web and worker connecting to the database and Redis
Notes that the README's RabbitMQ does not appear in the files and that the worker uses Redis (rq) as its queue
Flags that nginx routes /admin/ to an 'admin' service that is not defined in docker-compose.yml, rather than drawing it as a working service without comment
Marks legacy-reports as not started by default (it sits in the 'manual' profile)
Shows the payment gateway, the SMTP server and the seat-map host as external dependencies
Does not invent components that are not in the files (for example load balancers, Kubernetes, monitoring or extra databases)
Explains that the sensors are read every 10 minutes and the readings saved to files on the Pi
Explains that the data is copied to a backup server every night at 2am
Explains that watering runs every day at 6:30am, switched by a relay, with a configured duration of 90 seconds
Points out that alerts are switched off, so nobody is notified if something goes wrong
Says what cannot be told from these files (for example what the scripts do inside, or what happens on the backup server) rather than guessing
Does not invent devices, services or behaviour that are not in the crontab or config
Is short and in plain language for a non-programmer
When it should and shouldn't activate
Should activate:
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
Should leave to another skill:
Draw a diagram from this written description of the system