skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/solution-architect/skills/figma-diagrams/scripts/post_comment.py

@@ -0,0 +1,52 @@
+#!/usr/bin/env python3
+"""Post a comment on a Figma file.
+
+Usage:
+    python post_comment.py <FILE_KEY_OR_URL> "<message>" [--node-id NODE_ID]
+
+If --node-id is given, the comment is pinned to the centroid of that node.
+"""
+
+from __future__ import annotations
+
+import argparse
+import sys
+
+from _figma_client import extract_file_key, get, post
+
+
+def main(argv: list[str]) -> int:
+    ap = argparse.ArgumentParser(description=__doc__)
+    ap.add_argument("file", help="Figma file URL or bare file key")
+    ap.add_argument("message", help="Comment text")
+    ap.add_argument("--node-id", help="Node ID to pin the comment to (e.g. 1:23)")
+    args = ap.parse_args(argv)
+
+    file_key = extract_file_key(args.file)
+
+    body: dict = {"message": args.message}
+
+    if args.node_id:
+        nodes = get(f"/v1/files/{file_key}/nodes", params={"ids": args.node_id})
+        node = nodes.get("nodes", {}).get(args.node_id, {}).get("document", {})
+        box = node.get("absoluteBoundingBox")
+        if not box:
+            sys.stderr.write(
+                f"error: could not resolve node {args.node_id} in file {file_key}\n"
+            )
+            return 1
+        body["client_meta"] = {
+            "node_id": args.node_id,
+            "node_offset": {
+                "x": box["width"] / 2,
+                "y": box["height"] / 2,
+            },
+        }
+
+    resp = post(f"/v1/files/{file_key}/comments", body)
+    print(f"posted: comment_id={resp.get('id')}")
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main(sys.argv[1:]))

skilldrop_cli/data/packs/solution-architect/skills/figma-diagrams/templates/figjam-import.json

@@ -0,0 +1,20 @@
+{
+  "_comment": "Example spec consumable by a FigJam plugin that turns it into shapes + connectors. Pair this with a tiny Figma plugin (or use a community plugin that accepts this shape) to materialize the diagram. Not a Figma REST API call — REST cannot create nodes.",
+  "title": "Three-tier web app on AWS",
+  "nodes": [
+    { "id": "n_internet", "label": "Internet",  "shape": "ELLIPSE",   "x": 0,    "y": 0   },
+    { "id": "n_alb",      "label": "ALB",       "shape": "RECTANGLE", "x": 200,  "y": 0   },
+    { "id": "n_web",      "label": "ECS web",   "shape": "RECTANGLE", "x": 400,  "y": -60 },
+    { "id": "n_worker",   "label": "ECS worker","shape": "RECTANGLE", "x": 400,  "y":  60 },
+    { "id": "n_rds",      "label": "RDS",       "shape": "CYLINDER",  "x": 640,  "y":  0  },
+    { "id": "n_sqs",      "label": "SQS",       "shape": "PARALLELOGRAM", "x": 400, "y": 200 }
+  ],
+  "edges": [
+    { "from": "n_internet", "to": "n_alb",    "label": "HTTPS" },
+    { "from": "n_alb",      "to": "n_web",    "label": "HTTP"  },
+    { "from": "n_web",      "to": "n_rds",    "label": "SQL"   },
+    { "from": "n_web",      "to": "n_sqs",    "label": "enqueue" },
+    { "from": "n_sqs",      "to": "n_worker", "label": "dequeue" },
+    { "from": "n_worker",   "to": "n_rds",    "label": "SQL"   }
+  ]
+}

skilldrop_cli/data/packs/solution-architect/skills/nfr-spec/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: nfr-spec
+description: Sweep a feature or system through the full non-functional requirements catalog — performance, throughput, availability, durability, privacy/retention, accessibility, i18n, observability, operability, compatibility, cost — forcing every category to a measurable target, an explicit n/a, or a tagged default. Use when the user needs NFRs, quality attributes, "how fast/reliable does it need to be", SLO targets for a feature, or the requirements everyone forgets until they're incidents.
+---
+
+# nfr-spec
+
+Gathers the requirements nobody volunteers: the business says what the feature does, this skill pins down **how well** — with numbers. Every category in the catalog ends in exactly one of three states: a **measurable target with a verification method**, an explicit **n/a with a reason**, or an **accepted default tagged `[assumption]`**. Silence is the one forbidden state. Downstream of `prd-draft`; feeds `design-doc` (targets shape the architecture), `test-plan-generator` (verification methods become test cases), and `threat-model` (security depth lives there, not here).
+
+## How to respond
+
+1. **Classify the system first** — the archetype sets the defaults: customer-facing SaaS, internal tool, public API, batch/pipeline, mobile/edge. Ask at most 2 questions, spent on the two answers that move the most targets: **user-facing or internal**, and **what happens when it's down for an hour** (the honest availability requirement hides in that answer). Everything else: archetype default + `[assumption]`.
+
+2. **Sweep every category in [`reference.md`](reference.md)** — performance/latency, throughput/capacity, availability/SLO, durability/backup/DR, privacy/retention/residency, accessibility, i18n/l10n, observability, operability, compatibility, cost. For each: target, verification, or n/a-with-reason. The output includes the **full ledger** so a reviewer sees the sweep happened — a skipped category is indistinguishable from a forgotten one otherwise.
+
+3. **Force numbers tied to business reality, not aspiration.** ✅ *"p95 search < 800ms at 2× current peak (peak = 120 rps `[data: April dashboard]`)"* — ❌ *"sub-second response times"* (which percentile? at what load?) — ❌ *"99.999% availability"* for an internal tool whose users sleep at night (five nines costs 100× three nines; the archetype default exists to stop this).
+
+4. **Attach a verification method to every target** — the method that would prove it before launch, not after: load test at stated volume, chaos drill, restore-from-backup rehearsal, axe-core scan + screen-reader pass, locale pseudo-translation run, cost projection at target volume. An NFR without a verification is a hope with units. These methods hand straight to `test-plan-generator`.
+
+5. **Make retention and deletion first-class.** For every data class the feature touches: what's stored, how long, where (residency), and **how deletion actually happens** (user-triggered, TTL, legal hold override). "We keep it forever" is a decision with legal weight — make it visible, never implicit.
+
+6. **State observability as requirements, not tooling.** What must be answerable at 3am: ✅ *"On-call can see per-tenant error rate and the last deploy time within 2 minutes of an alert"* — ❌ *"Use Datadog"*. The instrument choice is `design-doc`'s; the questions-it-must-answer are NFRs.
+
+7. **Point, don't duplicate, for security.** One line stating the auth/data-classification posture, then hand depth to `threat-model`. An NFR doc with a 3-page security section has stolen another skill's job and done it worse.
+
+8. **Emit with [`templates/nfr-spec.md`](templates/nfr-spec.md)**: summary table (category / target / verification / state), per-category detail, the n/a ledger, assumptions log, and the handoff map.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — the category catalog with per-archetype defaults and the verification menu
+- [`templates/nfr-spec.md`](templates/nfr-spec.md) — the ledger-style output skeleton
+
+## Quality bar
+
+- **Every category lands in one of three states** — target, n/a-with-reason, or tagged default. The ledger shows all of them; silence fails the doc.
+- **Every target has a percentile, a load condition, and a verification.** A latency number without load is a screenshot of a quiet day.
+- **Availability matches the down-for-an-hour answer**, not the marketing instinct. The cost of each extra nine is named when the target exceeds the archetype default.
+- **Every data class has a retention period and a deletion mechanism.** "Indefinite" is written as the decision it is.
+- **Accessibility names level and scope** — "WCAG 2.2 AA on all agent-facing screens, axe + manual screen-reader pass" — not "accessible".
+- **Cost has a number at target volume**, or a tagged `[assumption]` placeholder that explicitly hands the sizing to `capacity-cost-model`. Either way the line is present — an NFR spec that's silent on cost has delegated it to the first invoice.
+
+## When to use this skill
+
+- ✅ A PRD is done and the quality targets need pinning before design
+- ✅ "How fast / how reliable / how much does this need to be?"
+- ✅ Defining SLOs for a new service or feature
+- ✅ A legacy system getting its implicit NFRs written down for the first time
+
+## When NOT to use this skill
+
+- ❌ Functional requirements — that's `prd-draft`
+- ❌ Security threat depth — one posture line here, the analysis is `threat-model`
+- ❌ Designing the architecture that meets the targets — `design-doc`
+- ❌ Writing the verification tests themselves — hand the methods to `test-plan-generator`
+
+## Anti-patterns to avoid
+
+- ❌ **"As fast as possible."** That's a budget of infinity. Every performance target gets a percentile, a number, and a load.
+- ❌ **Five-nines cargo cult.** Availability copied from a FAANG blog onto an internal CRUD tool — each nine multiplies cost; the down-for-an-hour question calibrates honestly.
+- ❌ **Uniform targets.** The same p95 for search, checkout, and a monthly export means nobody thought about any of them.
+- ❌ **"GDPR compliant" as the entire privacy section.** Which data, retained how long, deleted how, stored where — compliance is the output of those answers, not a substitute for them.
+- ❌ **Tool names as observability requirements.** "Use Prometheus" survives a migration to nothing; "alert fires within 2 min of error-rate breach" survives any tool.
+- ❌ **Untestable NFRs.** "The system shall be maintainable" — if no verification method exists, it's culture, not a requirement; cut it or make it measurable.

skilldrop_cli/data/packs/solution-architect/skills/nfr-spec/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "What are the non-functional requirements for this service?",
+    "should_trigger": true
+  },
+  {
+    "query": "Sweep the NFRs — latency, availability, privacy, accessibility, operability",
+    "should_trigger": true
+  },
+  {
+    "query": "Set performance and availability targets for this feature",
+    "should_trigger": true
+  },
+  {
+    "query": "We keep forgetting the -ilities; give me the full NFR ledger",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the functional requirements and user stories",
+    "should_trigger": false
+  },
+  {
+    "query": "Draft the OpenAPI contract for this service",
+    "should_trigger": false
+  },
+  {
+    "query": "Design the dashboards, SLOs, and alerts we should build",
+    "should_trigger": false
+  },
+  {
+    "query": "Model the capacity and cost for this workload",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/solution-architect/skills/nfr-spec/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "nfr-spec",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Sweep the non-functional requirements for our new checkout service.",
+      "assertions": [
+        "Every category in the catalog lands in one of three states — a target, not-applicable with a reason, or a tagged default; silence in any category is a failure",
+        "Every target states a percentile, a load condition, and how it will be verified — a latency number with no load condition is rejected",
+        "The availability target matches the honest answer to what an hour of downtime costs, not a marketing instinct",
+        "Privacy and retention are given concrete periods rather than 'per policy'",
+        "The output is a reviewable ledger covering all categories, not a prose paragraph about quality"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/solution-architect/skills/nfr-spec/manifest.json

@@ -0,0 +1,16 @@
+{
+  "name": "nfr-spec",
+  "version": "0.1.0",
+  "description": "Sweep a feature or system through the full non-functional requirements catalog — performance, throughput, availability, durability, privacy/retention, accessibility, i18n, observability, operability, compatibility, cost — forcing every category to a measurable target, an explicit n/a, or a tagged default. Use when the user needs NFRs, quality attributes, \"how fast/reliable does it need to be\", SLO targets for a feature, or the requirements everyone forgets until they're incidents.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["capacity-cost-model", "design-doc", "prd-draft", "test-plan-generator", "threat-model"],
+  "handoff": [
+    { "to": "design-doc", "when": "the quality targets are set", "purpose": "Design against the stated numbers rather than against taste.", "fallback": "If design-doc is absent, restate each target beside the design choice that serves it." },
+    { "to": "threat-model", "when": "the design has a trust boundary worth attacking", "purpose": "Attack the design before it is ratified.", "fallback": "If threat-model is absent, list the trust boundaries and one abuse case per boundary inline." },
+    { "to": "test-plan-generator", "when": "the targets need verifying, not just stating", "purpose": "Turn each quality target into a coverage entry.", "fallback": "If test-plan-generator is absent, name the test that would falsify each target." }
+  ],
+  "tags": ["nfr", "requirements", "slo", "performance", "availability", "quality-attributes"],
+  "model": { "tier": "standard", "rationale": "Rubric-driven sweep with archetype defaults; the judgment is calibrating targets to business reality. Bounded by the catalog; escalate via ambiguous-input on contested SLOs." }
+}

skilldrop_cli/data/packs/solution-architect/skills/nfr-spec/reference.md

@@ -0,0 +1,74 @@
+# nfr-spec reference — category catalog, archetype defaults, verification menu
+
+Defaults are starting points, always tagged `[assumption]` in the output. The archetype row is chosen once in step 1 and reused everywhere.
+
+## Archetypes
+
+| Archetype | Examples | Posture |
+|---|---|---|
+| customer-facing SaaS | checkout, dashboards | user-perceived latency and availability dominate |
+| internal tool | admin panels, back-office | availability honesty — business hours usually suffice |
+| public API | partner integrations | contract stability, rate limits, versioning weight |
+| batch / pipeline | ETL, reports, billing runs | completion deadlines and replayability, not latency |
+| mobile / edge | apps, POS | offline behavior, payload size, OS-version spread |
+
+## Category catalog (sweep all 11 — every one lands in target / n/a+reason / default+tag)
+
+### 1. Performance / latency
+Target shape: `p50/p95 < N ms for {operation} at {load}`. Per key operation, not uniform.
+Defaults: SaaS interactive p95 < 500ms; internal tool p95 < 2s; API p95 < 300ms; batch n/a → see deadline; mobile interaction < 100ms perceived.
+
+### 2. Throughput / capacity
+Target shape: `sustains N rps / M jobs/hr at target latency; designed headroom ×K`.
+Defaults: 2× current peak headroom; batch: completes within window at 3× current data volume.
+
+### 3. Availability / SLO
+Target shape: `N% monthly, measured at {user-visible boundary}; error budget stated`.
+Defaults: SaaS 99.9%; internal tool 99.5% business-hours; public API 99.95%; batch: deadline-based ("billing run completes by 06:00, 99% of months").
+Calibrate with the down-for-an-hour answer; name the cost when exceeding the default — each nine roughly 10×es the engineering.
+
+### 4. Durability / backup / DR
+Target shape: `RPO ≤ N min, RTO ≤ M min; backup restore rehearsed {cadence}`.
+Defaults: transactional data RPO ≤ 5 min / RTO ≤ 1h; derived/rebuildable data RPO n/a with reason "recomputable from source in N h".
+
+### 5. Privacy / retention / residency
+Per data class: what's stored · classification (PII? payment? health?) · retention period · deletion mechanism (user-triggered / TTL / legal hold) · residency constraint.
+Default: no new PII without a named retention period; "indefinite" written explicitly as a decision.
+
+### 6. Accessibility
+Target shape: `WCAG {version} {level} on {scope}; verified by {automated + manual}`.
+Defaults: customer-facing WCAG 2.2 AA; internal tools AA for core flows `[assumption — confirm with HR/legal jurisdiction]`.
+
+### 7. Internationalization / localization
+Target shape: locales supported at launch; text expansion tolerance; date/number/currency handling; RTL yes/no.
+Default: single-locale launch is fine **if stated**; unicode-correct storage is non-negotiable either way.
+
+### 8. Observability
+Requirement shape: the 3am questions — `on-call can answer {question} within {time}` — plus alert conditions with thresholds and a paging severity. Tool names excluded.
+Default minimum: error rate, latency, and saturation per surface; alert before users notice (burn-rate, not static threshold, for SLO'd surfaces); every alert maps to a runbook entry (→ `runbook-generator`).
+
+### 9. Operability
+Deploy/rollback time targets, config-change blast radius, feature-flag kill switch, dependency-down behavior (degrade vs fail closed — chosen per dependency).
+Default: rollback ≤ 15 min; every new external dependency gets an explicit down-behavior.
+
+### 10. Compatibility
+Browsers/devices/OS floor; API consumer versions honored; data-format backward compatibility window.
+Default: SaaS = last 2 major browser versions; API = no breaking change without version bump (→ `api-contract-draft` policy).
+
+### 11. Cost
+Target shape: `≤ $N/month at target volume; alert at 80%`. Include the per-unit driver (per-tenant, per-GB, per-1k-requests).
+Default: projection required before launch; "we'll see" fails the ledger.
+
+## Verification menu (every target picks at least one)
+
+| Method | Proves |
+|---|---|
+| Load test at stated volume + headroom | latency, throughput |
+| Chaos / dependency-kill drill | availability, dependency-down behavior |
+| Backup-restore rehearsal (timed) | RPO/RTO are real, not configured |
+| Deletion end-to-end test (incl. backups/replicas) | retention/deletion actually deletes |
+| axe-core + manual screen-reader pass | accessibility level on scope |
+| Pseudo-locale build (text expansion, RTL) | i18n readiness |
+| Game-day: answer the 3am questions on a stage incident | observability requirements |
+| Timed rollback drill | operability targets |
+| Cost projection reviewed against first month's bill | cost model honesty |

skilldrop_cli/data/packs/solution-architect/skills/nfr-spec/templates/nfr-spec.md

@@ -0,0 +1,56 @@
+# NFR-spec template
+
+The ledger is the contract: all 11 categories appear, each in exactly one state — **target** / **n/a (reason)** / **default `[assumption]`**.
+
+```markdown
+# NFR spec: {feature / system}
+
+**Archetype:** {customer-facing SaaS | internal tool | public API | batch | mobile/edge}
+**Down-for-an-hour answer:** {verbatim from stakeholder — calibrates availability} `[reported]`
+**Date:** {YYYY-MM-DD} · **Feeds:** design-doc, test-plan-generator, threat-model
+
+## Ledger (all 11 — no silent rows)
+
+| # | Category | State | Target / reason | Verification |
+|---|---|---|---|---|
+| 1 | Performance | target | p95 < 800ms search @ 2× peak (120 rps) | load test |
+| 2 | Throughput | default `[assumption]` | 2× peak headroom | load test |
+| 3 | Availability | target | 99.9% monthly, user-visible boundary | chaos drill + SLO dashboard |
+| 4 | Durability/DR | target | RPO ≤ 5min, RTO ≤ 1h | timed restore rehearsal |
+| 5 | Privacy/retention | target | see data-class table | deletion end-to-end test |
+| 6 | Accessibility | target | WCAG 2.2 AA, all customer screens | axe + screen-reader pass |
+| 7 | i18n | n/a | single-locale launch, stated in PRD non-goals | — |
+| 8 | Observability | target | 3am questions below | game-day |
+| 9 | Operability | default `[assumption]` | rollback ≤ 15 min; per-dep down-behavior | rollback drill |
+| 10 | Compatibility | default `[assumption]` | last 2 major browsers | CI matrix |
+| 11 | Cost | target | ≤ $N/mo @ target volume, alert at 80% | projection vs first bill |
+
+## Per-category detail
+
+{One block per non-n/a row: the target restated with its load condition and
+source of the numbers, the verification method, and who owns it.}
+
+## Data classes (category 5 expanded)
+
+| Data | Classification | Retention | Deletion mechanism | Residency |
+|---|---|---|---|---|
+| {what} | {PII/payment/none} | {period or "indefinite — explicit decision"} | {TTL / user-triggered / legal-hold-aware} | {constraint or none} |
+
+## 3am questions (category 8 expanded)
+
+- On-call can answer "{question}" within {time}, from {alert/dashboard}.
+- Alert: {condition + threshold + paging severity} → runbook entry: {ref}.
+
+## Security posture (one line — depth lives in threat-model)
+
+{e.g. "Authn via platform SSO; tenant-scoped authz; PII per table above. Full analysis: threat-model."}
+
+## Assumptions log
+
+- [assumption] {default taken} — confirm with {role} by {date}
+
+## Exceeding-default justifications
+
+{Required whenever a target beats the archetype default: "99.95% chosen over 99.9%
+because {contractual SLA}; accepted cost: {on-call rotation, multi-AZ spend}."}
+```

skilldrop_cli/data/packs/solution-architect/skills/reverse-architecture/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: reverse-architecture
+description: 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.
+---
+
+# reverse-architecture
+
+You help the user produce an accurate "as-is" architecture diagram by reading what's actually in the repo or infra files — not by asking them to describe the system from memory.
+
+This skill pairs with two others:
+- **[`architecture-diagrams`](../architecture-diagrams/SKILL.md)** — takes the *written description* this skill emits and renders the final notation. You can either hand off, or render inline using its templates.
+- **[`design-doc`](../design-doc/SKILL.md)** — when the as-is diagram is going into a design doc's "Current state" section.
+
+## How to respond
+
+1. **Find the highest-signal source files first.** Most systems leak their architecture through 4–6 files. Read these in order, stopping when you have enough:
+
+   | Source | What you learn | Where to look |
+   |---|---|---|
+   | **Infrastructure-as-code** | Cloud topology, account/region/VPC layout, managed services in use | `*.tf`, `*.tfvars`, `cdk/*`, `serverless.yml`, `template.yaml`, `*.bicep`, `pulumi/*`, `cloudformation/*.yaml` |
+   | **Kubernetes manifests / Helm** | Service-to-service topology, ingress, sidecars | `k8s/`, `manifests/`, `*.yaml` with `kind: Deployment\|Service\|Ingress`, `helm/*/templates/`, `kustomization.yaml` |
+   | **docker-compose** | Local/small-deploy service graph | `docker-compose.y*ml`, `compose.y*ml` |
+   | **Package manifest** | Stack, frameworks, key libraries (auth, ORM, queue clients) | `package.json`, `pyproject.toml`, `requirements.txt`, `go.mod`, `pom.xml`, `Gemfile`, `Cargo.toml` |
+   | **Top-level source structure** | Module / service boundaries, internal vs external API split | `src/`, `services/`, `apps/`, `cmd/`, `internal/` |
+   | **API surface** | External contracts, request flows | `openapi.y*ml`, `*.proto`, `*Controller.*`, `routes/`, `handlers/`, `gql/`, `*.graphql` |
+   | **Database schema** | Data model, key entities, FK relationships | `migrations/`, `schema.sql`, `prisma/schema.prisma`, `models/`, `*.entity.ts` |
+   | **Config / env** | External dependencies (queues, caches, third-party APIs) | `.env.example`, `config/*.y*ml`, `application*.properties`, `settings.py` |
+   | **CI / deploy** | Deploy targets, environments, build artifacts | `.github/workflows/*`, `.gitlab-ci.yml`, `Jenkinsfile`, `Dockerfile`, `buildspec.yml` |
+   | **README** | Author's intent (verify against the code, don't trust uncritically) | `README*`, `ARCHITECTURE*`, `docs/architecture*` |
+
+   See [`reference.md`](reference.md) for the patterns to grep when each signal isn't obvious.
+
+2. **Confirm the level you're drawing.** Ask the user which C4 level they want (if they don't say) — answers below dictate which signals matter:
+
+   - **Context** — what external actors and systems talk to this thing. Inputs: README + IaC ingress + OpenAPI.
+   - **Container** (most common default) — each deployable + its datastore + how they talk. Inputs: IaC + k8s/compose + config.
+   - **Component** — internal modules inside one container. Inputs: source tree + key code files.
+   - **Deployment** — physical/cloud topology with regions, AZs, subnets. Inputs: IaC.
+
+3. **Extract the topology as a structured list before drawing.** Use [`templates/extraction.md`](templates/extraction.md) — fill in:
+
+   - **Nodes** (services, datastores, queues, external systems) — each with type and source-of-truth file path
+   - **Edges** (who calls whom, sync vs async, protocol)
+   - **Zones / boundaries** (VPC, account, region, trust boundary)
+   - **External actors** (users, partner systems)
+
+   Tag each item with its evidence: `service: payments-api (k8s/payments/deployment.yaml:12)`. The path is the audit trail — if the user disputes a node, they can jump straight to where you saw it.
+
+4. **Flag what you couldn't see.** Code/IaC tells you *what runs*, not always *how it's used*. Be explicit about gaps:
+
+   - Async vs sync — usually inferable from the client library (e.g. `kafka-go` ⇒ async; `axios` ⇒ sync) but verify.
+   - Authentication boundaries — sometimes obvious (Cognito, IAM auth on an API Gateway), sometimes implicit in middleware code.
+   - Caching layers — Redis sometimes appears only as an env var, not in IaC.
+   - Cross-account / cross-org calls — easy to miss if the only signal is an env var pointing at `https://….`
+
+   Put these in a `## Inferred / unverified` block in the extraction.
+
+5. **Emit two artifacts:**
+
+   a. **Written description** in the shape `architecture-diagrams` expects — system purpose, actors, components, flows, zones. Use [`templates/description.md`](templates/description.md). The user can hand this directly to `/architecture-diagrams` if they want to switch notation later.
+
+   b. **A first-draft diagram** — Mermaid `flowchart` by default for container-level; C4-PlantUML for context or deployment level. Cap at ~15 nodes; if you'd exceed that, split into two diagrams (e.g. "Frontend stack" + "Backend stack") rather than producing an unreadable single diagram.
+
+6. **Tell the user what to verify.** End with 3–5 bullets the user should sanity-check, prioritized by likelihood of being wrong:
+
+   - Asynchronous edges (often invisible in code)
+   - External dependencies behind env vars
+   - Anything in the `## Inferred / unverified` block
+
+## Useful references
+
+- [`reference.md`](reference.md) — File-to-signal mapping with concrete grep patterns and example extractions per stack (Terraform, k8s, docker-compose, Spring, Django, Next.js, etc.)
+- [`templates/extraction.md`](templates/extraction.md) — Structured node/edge/zone extraction form
+- [`templates/description.md`](templates/description.md) — Written description shaped for `architecture-diagrams`
+
+## Quality bar
+
+- **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."
+
+## When to use this skill
+
+- ✅ Onboarding doc / "how does this thing work" question for a system you didn't write.
+- ✅ Filling in the "Current state" section of a `design-doc` before proposing a change.
+- ✅ Pre-migration / pre-refactor — establishing the baseline before any "to-be" diagram is drawn.
+- ✅ Audit / compliance review where the diagram has to match reality, not the slide deck from two years ago.
+
+## When NOT to use this skill
+
+- ❌ 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.
+
+## Anti-patterns to avoid
+
+- ❌ Trusting the README without verifying against code. READMEs lie; code doesn't.
+- ❌ Drawing every node in `package.json`. Most dependencies are libraries, not architectural elements. A node should be something that runs as its own process, holds state, or crosses a network boundary.
+- ❌ Inventing service names not in the source. If a service is referenced only by env var URL, name it `external (<host>)`, not `MysteriousService`.
+- ❌ One mega-diagram with 40 nodes. Split by level (context / container / deployment) or by domain.
+- ❌ Skipping the "what I couldn't see" section because it looks negative. It's the most useful section for the reviewer who knows the system.

skilldrop_cli/data/packs/solution-architect/skills/reverse-architecture/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Reverse-engineer the architecture from this repo",
+    "should_trigger": true
+  },
+  {
+    "query": "Work out our system diagram from the Terraform and k8s manifests",
+    "should_trigger": true
+  },
+  {
+    "query": "What does our actual architecture look like based on the code?",
+    "should_trigger": true
+  },
+  {
+    "query": "Build a diagram from our existing infrastructure-as-code",
+    "should_trigger": true
+  },
+  {
+    "query": "Draw a diagram from this written description of the system",
+    "should_trigger": false
+  },
+  {
+    "query": "Read our Figma file and list the frames",
+    "should_trigger": false
+  },
+  {
+    "query": "Write an ADR for the architecture we chose",
+    "should_trigger": false
+  },
+  {
+    "query": "Review this code for bugs",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/solution-architect/skills/reverse-architecture/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "reverse-architecture",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Reverse-engineer the architecture of this repo — it has Terraform, Kubernetes manifests, and an OpenAPI spec.",
+      "assertions": [
+        "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"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/solution-architect/skills/reverse-architecture/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "reverse-architecture",
+  "version": "0.1.0",
+  "description": "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.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["architecture-diagrams", "design-doc"],
+  "tags": ["diagrams", "reverse-engineering", "architecture", "as-is", "terraform", "kubernetes", "c4", "mermaid"],
+  "model": { "tier": "standard", "rationale": "Extracts architecture from code/IaC. Escalates to opus on large codebases where cross-file inference is heavy." }
+}