skilldrop-cli 0.16.3__py3-none-any.whl

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

@@ -0,0 +1,150 @@
+# reverse-architecture — file-to-signal reference
+
+A cheat sheet for what to read first when reverse-engineering an architecture. Use this when the obvious places (README, top-level dirs) aren't enough.
+
+## Triage: 5-minute scan
+
+Before reading anything deeply, run these in order:
+
+```bash
+# 1. The tree (depth 2 — surface-level structure)
+find . -maxdepth 2 -type d -not -path '*/.*'
+
+# 2. Look for the architecture-revealing files
+ls README* ARCHITECTURE* docs/architecture* 2>/dev/null
+find . -maxdepth 3 -name 'docker-compose*.y*ml' -o -name 'serverless.yml' -o -name 'template.yaml' -o -name 'Dockerfile' 2>/dev/null
+find . -maxdepth 4 -name '*.tf' -o -name '*.bicep' -o -name 'kustomization.yaml' 2>/dev/null | head -20
+
+# 3. The stack
+ls package.json pyproject.toml requirements.txt go.mod pom.xml Gemfile Cargo.toml 2>/dev/null
+```
+
+What you find dictates the next step. If `docker-compose.yml` exists at the root, that's the highest-signal file. If you have Terraform, start there.
+
+## Per-source patterns
+
+### Terraform / OpenTofu
+
+```bash
+# What managed services are in use?
+grep -rh '^resource "' --include='*.tf' | sort -u
+
+# What's the data plane?
+grep -rh 'aws_rds\|aws_dynamodb\|aws_elasticache\|aws_s3\|aws_sqs\|aws_sns\|aws_kinesis\|aws_msk' --include='*.tf'
+
+# Ingress / public surface
+grep -rh 'aws_lb\|aws_apigateway\|aws_cloudfront\|aws_route53_record' --include='*.tf'
+
+# Networking
+grep -rh 'aws_vpc\|aws_subnet\|aws_security_group\|aws_vpc_peering' --include='*.tf'
+```
+
+For Azure: `azurerm_*`. For GCP: `google_*`. For Pulumi/CDK: read the `*.ts` / `*.py` directly — the resource constructors are the architectural signal.
+
+### Kubernetes / Helm
+
+```bash
+# All services and deployments at a glance
+grep -rE '^kind:\s+(Deployment|StatefulSet|Service|Ingress|CronJob|Job)\b' --include='*.yaml' --include='*.yml' .
+
+# Sidecars (auth, mesh, log shipping)
+grep -rB2 '- name:' --include='*.yaml' | grep -E 'istio-proxy|linkerd-proxy|envoy|fluent-bit|vector|otel-collector'
+
+# Ingresses ⇒ external surface
+grep -rB1 'host:' --include='*.yaml' | grep -A1 'kind: Ingress\|kind: VirtualService'
+```
+
+In Helm charts, `values.yaml` often has more architecture signal than the templates — features get toggled on/off there.
+
+### docker-compose
+
+The service graph IS the file. Read top to bottom; pay attention to:
+
+- `services:` — each is a node.
+- `depends_on:` — directional edge (startup, not necessarily runtime).
+- `networks:` — zones.
+- `ports:` — `"x:y"` means external, no `ports:` means internal-only.
+- `image:` — datastores (`postgres`, `redis`, `rabbitmq`) become cylinder nodes.
+
+### Package manifests
+
+These tell you the *stack*, not the topology. Use them to translate generic boxes into specific tech:
+
+| Dep seen | What it means architecturally |
+|---|---|
+| `axios`, `node-fetch`, `requests`, `httpx`, `reqwest` | Sync HTTP calls to external services |
+| `kafkajs`, `confluent-kafka`, `kafka-go`, `sarama` | Kafka producer/consumer — async edge |
+| `bullmq`, `celery`, `sidekiq`, `rq`, `dramatiq` | Job queue — worker pattern |
+| `redis`, `ioredis`, `redis-py` | Redis cache / pub-sub |
+| `pg`, `psycopg`, `pgx`, `gorm`, `sqlalchemy`, `prisma`, `typeorm` | Postgres |
+| `mongodb`, `mongoose`, `pymongo` | MongoDB |
+| `@aws-sdk/*`, `boto3`, `aws-sdk-go` | Look for which clients are imported — that's the AWS surface |
+| `passport`, `next-auth`, `auth0`, `clerk`, `oidc-client` | Auth provider |
+| `@grpc/grpc-js`, `grpcio`, `connect-go` | gRPC edges |
+| `socket.io`, `ws`, `websockets` | WebSocket edges — long-lived connection |
+| `stripe`, `twilio`, `sendgrid`, `posthog` | External SaaS dependency |
+
+### Source tree
+
+Look at the depth-1 and depth-2 directories. Common patterns:
+
+- `services/<name>/` or `apps/<name>/` — monorepo with multiple deployables; each `<name>` is a container.
+- `cmd/<binary>/` (Go) — each subdir is a separate binary, each is a container.
+- `src/`, `lib/`, `internal/` — single deployable; you're looking at component-level structure.
+- `packages/` (npm/pnpm/yarn workspaces) — libraries shared between containers, not containers themselves. Don't draw them at container level.
+
+### OpenAPI / proto / GraphQL
+
+```bash
+find . -name 'openapi.y*ml' -o -name '*.proto' -o -name '*.graphql' -o -name 'schema.graphql' | head
+```
+
+- OpenAPI `paths:` → public API surface — list 5–10 example operations to characterize the service in one line.
+- `.proto` `service { rpc ... }` → gRPC service definition.
+- GraphQL `type Query` / `type Mutation` → frontend → backend contract.
+
+### Database schema
+
+```bash
+find . -name 'schema.prisma' -o -name 'schema.sql' -o -path '*/migrations/*.sql' -o -path '*/models/*' | head -20
+```
+
+For the diagram, the key signals are:
+
+- Which entities exist (top 10–15 tables).
+- Which FK relationships span what would otherwise be two separate services — that's a sign of *coupling* worth showing on the diagram.
+- Whether there are obvious tenancy columns (`tenant_id`, `org_id`) — single-tenant vs multi-tenant matters at container level.
+
+### Config / env
+
+```bash
+# External hostnames in env config
+grep -rh 'https://\|http://' .env.example config/ application*.properties 2>/dev/null | grep -v localhost | sort -u
+```
+
+These are often the *only* signal that an external SaaS is in the loop.
+
+### CI / deploy
+
+```bash
+# Where does this thing actually deploy to?
+grep -rE 'aws-region|gcp-project|kubeconfig|cluster:|environment:' .github/workflows/ .gitlab-ci.yml 2>/dev/null
+```
+
+Useful for the deployment-level diagram (regions, environments).
+
+## Common gotchas
+
+- **Mono-repos vs. multi-repo:** if you see `services/*` directories each with their own `package.json`, treat each as a separate container. Don't merge them.
+- **Backwards Helm templates:** Helm `_helpers.tpl` and `values.yaml` are where the real config lives; the `.yaml` templates are just substrate.
+- **CDK / Pulumi:** the constructor calls (`new lambda.Function(…)`, `new aws.s3.Bucket(…)`) ARE the IaC. Read them like resource blocks.
+- **Service mesh sidecars:** if every pod has an `istio-proxy` container, don't draw it on every node — call it out once in the description and assume it.
+- **Library vs service:** something with no `Dockerfile`, no `main` entrypoint, and no `package.json` `bin` field is probably a library, not a container.
+
+## When the code is missing signal
+
+Sometimes you just don't have enough. Be explicit:
+
+> "I can see the API services and the Postgres, but no IaC is in the repo and there's no docker-compose, so I can't tell where this runs (Kubernetes? ECS? bare VMs?) or what the ingress / load balancer is. The diagram below shows containers only; deployment topology is `unknown` pending IaC or a screenshot of the cloud console."
+
+The diagram with explicit gaps is more useful than a diagram that pretends.

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

@@ -0,0 +1,52 @@
+# Architecture Description
+
+> Output shape: feeds directly into `/architecture-diagrams` if the user wants to switch notation.
+> Source: reverse-engineered from `{repo / files}` on `{YYYY-MM-DD}`.
+
+## What the system is
+{One sentence.}
+
+## Actors and external systems
+- `{User type}` interacts via `{channel}` — e.g. browser, mobile app, partner API.
+- `{External system}` — relationship: `{consumer / provider / both}`.
+
+## Containers (the deployables)
+For each, one line:
+
+- **`{name}`** — `{language/runtime}` — purpose: `{one phrase}` — runs on: `{platform if known}`.
+
+## Datastores and state
+- **`{name}`** — `{engine}` — owned by: `{service name}` — purpose: `{e.g. "checkout transactional store"}`.
+
+## Inbound surface
+- Public ingress: `{HTTPS via {ALB | CloudFront | API Gateway | Ingress controller}}` — routes to: `{services}`.
+- Authentication: `{mechanism, e.g. "Cognito JWT", "Auth0 OIDC", "internal session cookie"}`.
+
+## Internal traffic
+- `{service A} → {service B}` — `{protocol}` — purpose: `{what call is being made}`.
+- `{service C} ⇢ {queue} ⇢ {worker}` — `{async, e.g. via Kafka topic "orders.created"}`.
+
+## External dependencies (third-party SaaS)
+- `{vendor}` — used for: `{purpose}` — called from: `{service}`.
+
+## Deployment topology (if known)
+- Cloud: `{AWS | Azure | GCP | on-prem | mixed}`.
+- Regions: `{list}`.
+- Compute: `{EKS cluster name / ECS service / Lambda functions / VMs}`.
+- Network: `{VPC layout if discernible}`.
+
+## Trust boundaries
+- {Where does data cross a security/trust boundary — e.g. "client → API Gateway", "internal → vendor", "account A → account B"}.
+
+## Known unknowns
+- {Anything in the extraction's "What I couldn't see" — verbatim, so the next reader knows the diagram's limits.}
+
+---
+
+## Drawing hints for the diagram
+
+- **Direction:** `LR` (request flow reads left-to-right) for container level, `TD` (deployment stack) for deployment level.
+- **Group by:** {VPC | cluster | account | region — whichever boundary is most load-bearing in this system}.
+- **Edge style:** solid for sync, dashed for async.
+- **Label edges that cross a boundary** (trust, network, account) — that's where the value of the diagram concentrates.
+- **Cap at ~15 nodes.** If this description has more, split — typically into `{Frontend stack}` and `{Backend stack}`, or by domain.

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

@@ -0,0 +1,55 @@
+# Architecture Extraction
+
+> Reverse-engineered from: `{repo path or set of input files}`
+> Level: `{context | container (default) | component | deployment}`
+> Extracted: `{YYYY-MM-DD}`
+
+## System purpose
+{One sentence — what the system does. From README if available, verified against code.}
+
+## External actors
+- `{Actor name}` — {role, e.g. "end user", "partner system", "admin tool"} — _evidence: `{file path}`_
+
+## Nodes
+
+For each: name · type · stack/tech · evidence path.
+
+| # | Name | Type | Stack | Evidence |
+|---|---|---|---|---|
+| 1 | `{name}` | service / job / queue / cache / db / external | {language/runtime} | `{path/to/file:line}` |
+| 2 | | | | |
+
+**Type vocabulary:**
+- `service` — long-running process serving requests
+- `job` — periodic / triggered batch
+- `worker` — long-running consumer of a queue
+- `queue` — Kafka topic, SQS queue, RabbitMQ exchange, etc.
+- `db` — datastore (Postgres, Mongo, Dynamo, …)
+- `cache` — Redis, Memcached, in-memory
+- `object-store` — S3, GCS, blob storage
+- `external` — third-party SaaS or system outside the codebase
+
+## Edges
+
+For each: source → target · protocol · sync/async · evidence.
+
+| # | From | To | Protocol | Sync/Async | Evidence |
+|---|---|---|---|---|---|
+| 1 | `{node}` | `{node}` | HTTPS / gRPC / Kafka / SQS / SQL / Redis | sync / async | `{path}` |
+| 2 | | | | | |
+
+## Zones / boundaries
+- **{Zone name}** ({type: VPC / account / region / cluster / trust boundary}) — contains: `{node, node, node}` — _evidence: `{path}`_
+
+## Datastores (detail)
+- `{db name}` — {engine + version} — owns: `{top 5 tables/entities}` — _evidence: `{schema file}`_
+
+## Inferred / unverified
+Things present in code/config but not fully confirmed. The diagram marks these with `?` or dashed edges.
+
+- `{node or edge}` — _signal: `{what made you think it exists}`_ — _why unverified: `{what's missing}`_
+
+## What I couldn't see
+- {e.g. "No IaC in repo — deployment topology unknown"}
+- {e.g. "No load-test artifacts — actual scale targets unknown"}
+- {e.g. "Async paths suspected (kafka-go in go.mod) but no topic config found"}

skilldrop_cli/data/packs/solution-architect/skills/tech-comparison-matrix/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: tech-comparison-matrix
+description: Produce a weighted comparison matrix for a technology selection question (e.g., "Postgres vs DynamoDB", "Kafka vs Kinesis vs RabbitMQ", "Snowflake vs Databricks"). Surfaces criteria, weights, per-option scores, totals, and a recommended pick. Use when the user is choosing between technologies, vendors, frameworks, or architectural approaches.
+---
+
+# tech-comparison-matrix
+
+You help the user make defensible tech-selection decisions by producing a weighted comparison matrix that they can paste into a design doc, ADR, or steering-committee deck.
+
+## How to respond
+
+1. **Pin down the question.** Make sure you have:
+   - **The options** (2–5 — past 5 the matrix becomes noise; cut the long-shots first)
+   - **The use case in one sentence** ("primary OLTP store for a multi-tenant SaaS app, ~10k writes/sec, latency p99 < 50ms")
+   - **Hard constraints** (e.g., "must run on-prem", "must be open source", "team has zero ops capacity for self-hosting")
+
+   Ask at most 2 clarifying questions. If the user only gave you the options without a use case, ask for the use case — it determines the criteria.
+
+2. **Pick the criteria.** Default to a balanced set across these axes (8–10 criteria is the sweet spot — fewer feels shallow, more becomes noise):
+
+   | Axis | Example criteria |
+   |---|---|
+   | **Capability fit** | Throughput, latency, query model, consistency model, schema flexibility |
+   | **Operational** | Self-hosted vs managed, scaling story, backup/restore, observability |
+   | **Cost** | License, infrastructure, support, total cost of ownership at scale |
+   | **Risk** | Vendor lock-in, ecosystem maturity, hiring market, our team's familiarity |
+
+   Mention any criteria you intentionally **excluded** so the user can challenge it. ("I left out 'community size' — let me know if that matters for you.")
+
+3. **Apply weights.** Use 1–5 (5 = critical to the decision, 1 = nice-to-have). Tie the weights to the use case in writing. *"Latency is weighted 5 because the use case demands sub-50ms p99"* makes the matrix audit-able; bare numbers don't.
+
+4. **Score each option per criterion** on a 1–5 scale. Justify every 5 and every 1 in one phrase — the body of the deliverable is the *reasoning*, not the numbers.
+
+5. **Total it up.** `Total = sum(weight × score)`. Highest total ≠ automatic winner — if the gap is small (< 5%), call that out and let the user pick on gut feel.
+
+6. **Recommend explicitly.** End with a "Recommendation" paragraph: which option, why, and what would change the answer.
+
+## Output format
+
+Use [`templates/matrix.md`](templates/matrix.md) as the skeleton. The deliverable should fit on **one screen** when rendered — if it doesn't, you have too many criteria.
+
+## Quality bar
+
+- **Every score has a one-line justification.** A bare "4/5" is not a comparison.
+- **Tie scores are fine** — don't force differentiation that isn't there.
+- **The recommendation is one sentence, not a paragraph of hedging.**
+- **Show your weights** — a matrix with hidden weights is just an opinion.
+- **No false precision.** If a number is a guess, say "rough" or "directional".
+
+## Anti-patterns to avoid
+
+- ❌ Scoring every criterion 3/5 ("balanced") — the matrix exists to differentiate, not to be polite.
+- ❌ Picking criteria that all favour the option you secretly want to win.
+- ❌ Including "community popularity" as a top-weighted criterion when the use case doesn't care.
+- ❌ Recommending an option whose score wasn't highest, without explaining the override.
+- ❌ Inventing benchmarks. If you don't have a number, say "estimated" and source the estimate.

skilldrop_cli/data/packs/solution-architect/skills/tech-comparison-matrix/evals/eval_queries.json

@@ -0,0 +1,30 @@
+[
+  {
+    "query": "Postgres vs DynamoDB for our multi-tenant OLTP store — build me a weighted matrix",
+    "should_trigger": true
+  },
+  {
+    "query": "We're choosing between Snowflake and Databricks; score them against our criteria",
+    "should_trigger": true
+  },
+  {
+    "query": "Compare three observability vendors and recommend one for our team",
+    "should_trigger": true
+  },
+  {
+    "query": "Which frontend framework should we pick — React, Vue, or Svelte — for this app? Show the scoring",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the business case for whether to invest in a data platform at all",
+    "should_trigger": false
+  },
+  {
+    "query": "Record the decision to adopt Kafka as an architecture decision record",
+    "should_trigger": false
+  },
+  {
+    "query": "Write a design doc proposing the new event-driven architecture for review",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/solution-architect/skills/tech-comparison-matrix/evals/evals.json

@@ -0,0 +1,18 @@
+{
+  "skill_name": "tech-comparison-matrix",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Help us pick a message broker: Kafka (self-managed), Amazon Kinesis, or RabbitMQ. Use case: order-event streaming for a multi-tenant SaaS app at Acme, about 5k events/sec at peak, consumers need replay for up to 7 days, ordering per tenant matters. Hard constraints: we run on AWS, and the platform team is two people with no capacity to run self-hosted clusters on call.",
+      "assertions": [
+        "Uses 8 to 10 criteria spanning capability fit, operational, cost, and risk, and names any criteria deliberately excluded",
+        "Shows a 1-5 weight for every criterion with the weight tied in writing to the use case or constraints (e.g. operational burden weighted high because the platform team is two people)",
+        "Every score has a one-line justification, and every 5 and every 1 is explained",
+        "Totals are computed as sum(weight x score), and a gap under 5% between the top options is called out",
+        "Ties are allowed where options genuinely don't differ; scores are not uniformly 3/5",
+        "The recommendation is one sentence and says what would change the answer; if it isn't the top scorer, the override is explained",
+        "Numbers that are estimates are marked 'rough' or 'directional'; no benchmarks are invented beyond the figures in the prompt"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/solution-architect/skills/tech-comparison-matrix/examples/queue-selection.md

@@ -0,0 +1,41 @@
+# Worked example — weighted comparison of message queues
+
+Input → output oracle for `tech-comparison-matrix`. Shows shown weights, a one-line
+justification per score, honest "rough" markers, and a one-sentence recommendation.
+
+## Input
+
+> "We need a message queue for an order-processing pipeline: ~5k msg/s, must not
+> lose messages, small team, already on AWS. Compare [managed-broker-A],
+> [self-hosted-broker-B], and [cloud-queue-C]."
+
+## Output
+
+**Weights** (sum to 100, set by the stated constraints — durability and ops-load dominate because the team is small and messages can't be lost):
+
+| Criterion | Weight | Why this weight |
+|---|--:|---|
+| Durability / no message loss | 30 | Hard requirement — order data. |
+| Operational load | 25 | Small team; running a broker is a tax. |
+| Throughput headroom | 15 | 5k/s is modest; all three clear it, so it's not decisive. |
+| Delivery semantics / ordering | 15 | Orders need per-key ordering. |
+| Ecosystem fit (AWS) | 15 | Already on AWS; native integration saves glue. |
+
+**Scores** (1–5, each justified; ties kept where real):
+
+| Criterion | Wt | [managed-broker-A] | [self-hosted-broker-B] | [cloud-queue-C] |
+|---|--:|--:|--:|--:|
+| Durability | 30 | 5 — replicated, managed | 5 — replicated *if* configured right | 5 — replicated, managed |
+| Ops load | 25 | 4 — managed, some tuning | 2 — you patch/scale/monitor it | 5 — fully serverless |
+| Throughput (rough) | 15 | 4 — ~tens of k/s | 5 — highest ceiling | 4 — ample for 5k/s |
+| Semantics/ordering | 15 | 4 — ordered per partition | 5 — most flexible | 3 — FIFO variant, lower quotas |
+| AWS fit | 15 | 3 — runs on AWS, not native | 2 — self-run on EC2/EKS | 5 — native service |
+| **Weighted total** | | **4.15** | **3.55** | **4.45** |
+
+**Recommendation:** Pick **[cloud-queue-C]** — its serverless ops profile decisively fits a small team with a modest, durability-critical load, and the only real gap (ordering quotas) is manageable at 5k/s.
+
+*Directional note:* throughput scores are rough (order-of-magnitude, not benchmarked); if load is likely to 10× within a year, re-weight throughput up and re-score — [self-hosted-broker-B]'s ceiling starts to matter.
+
+## Why this passes the quality bar
+
+Weights are shown and tied to the question; every score carries a one-line justification; ties (durability 5/5/5) are left as ties; the guessed throughput numbers are flagged "rough"/"directional"; and the recommendation is one decisive sentence, not hedged.

skilldrop_cli/data/packs/solution-architect/skills/tech-comparison-matrix/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "tech-comparison-matrix",
+  "version": "0.1.0",
+  "description": "Produce a weighted comparison matrix for a technology selection question (e.g., \"Postgres vs DynamoDB\", \"Kafka vs Kinesis vs RabbitMQ\", \"Snowflake vs Databricks\"). Surfaces criteria, weights, per-option scores, totals, and a recommended pick. Use when the user is choosing between technologies, vendors, frameworks, or architectural approaches.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": [],
+  "tags": ["decisions", "comparison", "tech-selection", "vendor-evaluation"],
+  "model": { "tier": "heavy", "rationale": "Weighted multi-criteria judgment with a recommendation. Mis-weighting is the failure mode. Never downgrade." }
+}

skilldrop_cli/data/packs/solution-architect/skills/tech-comparison-matrix/templates/matrix.md

@@ -0,0 +1,45 @@
+# {Decision title — e.g. "Primary OLTP datastore for ProjectX"}
+
+**Use case:** {one sentence describing the workload / constraints — this is what the weights are tuned to}
+
+**Hard constraints:** {bulleted list of things that must be true; an option failing any of these is eliminated, not scored}
+
+**Options evaluated:** {Option A}, {Option B}, {Option C}
+**Options excluded (and why):** {e.g. "MongoDB — single-region writes only, fails the multi-region constraint"}
+
+## Scoring scheme
+
+- **Weight (1–5):** how much this criterion matters for *this* use case. Justified inline.
+- **Score (1–5):** how well the option meets the criterion. Each 5 and 1 has a one-line justification.
+
+## Matrix
+
+| Criterion | Weight | {Option A} | {Option B} | {Option C} |
+|---|---:|---:|---:|---:|
+| Throughput (writes/sec at p99 < 50ms) — *weight 5: directly stated in use case* | 5 | 5 — published bench 50k/s | 3 — caps around 15k/s | 4 — 30k/s with read replicas |
+| Consistency model fit — *weight 5: financial data, no eventual consistency tolerated* | 5 | 5 | 2 — eventual by default | 5 |
+| Operational complexity (self-hosted) — *weight 4: team has 1 SRE* | 4 | 3 | 4 — fully managed | 2 — manual sharding |
+| Cost at projected scale — *weight 3: budget approved but not unlimited* | 3 | 4 | 2 — egress fees | 5 |
+| Team familiarity — *weight 3: shortens ramp* | 3 | 5 | 2 | 3 |
+| Vendor lock-in — *weight 2: prefer portable but not blocking* | 2 | 5 — open source | 2 — proprietary | 4 |
+| Ecosystem / tooling — *weight 2* | 2 | 5 | 4 | 3 |
+| Backup & restore story — *weight 4: compliance requirement* | 4 | 4 | 5 | 3 |
+| **Weighted total** | | **{=Σ w·s}** | **{=Σ w·s}** | **{=Σ w·s}** |
+
+## Justifications for outlier scores
+
+- *{Option A}, Throughput = 5:* {one-line evidence — link to vendor bench, internal load test, or known reference deployment}
+- *{Option B}, Consistency = 2:* {one-line evidence}
+- *{Option C}, Operational complexity = 2:* {one-line evidence}
+
+## Recommendation
+
+**Pick {Option X}** — it's strongest on the two highest-weighted criteria (throughput + consistency) and acceptable on the rest. The gap to {next option} is meaningful (~{N}%), so this is not a close call.
+
+**What would change this answer:**
+- If managed-ness becomes the top constraint (e.g., SRE leaves), reconsider {Option B}.
+- If we relax the latency target above 100ms, {Option C} becomes viable and cheaper.
+
+## Open questions
+
+- {Question for stakeholders — e.g., "Is multi-region active-active in scope for v1, or v2+?"}

skilldrop_cli/data/packs/solution-architect/skills/threat-model/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: threat-model
+description: Produce a STRIDE threat model from a design doc, architecture description, or feature spec — assets and trust boundaries first, threats anchored to boundary crossings with concrete attack scenarios, severity-ranked with verifiable mitigations. Use when the user asks to threat-model a design, run a security review of an architecture, ask "how could this be attacked", or needs security sign-off input before build.
+---
+
+# threat-model
+
+Finds the attacks a design permits *before* the code exists, when fixes are a diagram edit instead of a migration. Design-phase counterpart to `devils-advocate` (which attacks written code); consumes `design-doc` or `reverse-architecture` output directly. Threats live where data crosses a trust boundary — the model is anchored there, not in a generic checklist.
+
+## How to respond
+
+1. **Establish the system before any threats.** From the input, extract and state:
+   - **Assets** — what an attacker wants (credentials, PII, payment data, compute, availability), ranked by damage-if-lost
+   - **Entry points** — every way data or commands get in (APIs, queues, file uploads, admin panels, CI/CD, third-party webhooks)
+   - **Trust boundaries** — every line where the trust level changes (internet→edge, service→service, app→DB, human→system, tenant→tenant)
+   Ask at most 2 questions, and spend them on trust boundaries — misplaced boundaries invalidate the whole model. Tag everything else `[assumption]`.
+
+2. **Enumerate boundary crossings, then run STRIDE per crossing** using the question banks in [`reference.md`](reference.md) — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Not every category applies at every crossing; say "n/a" with one word of why rather than padding.
+
+3. **Write each threat as a concrete attack scenario**: actor → path → result. ✅ *"A tenant crafts a report name containing `../`, the export service writes to another tenant's S3 prefix, cross-tenant data exposure"* — ❌ *"Path traversal is possible"*. A threat that can't be narrated as a scenario isn't understood yet.
+
+4. **Severity-rank with the shared markers** — 🟥 critical (unauthenticated or cross-tenant compromise of a top asset), 🟧 high (authenticated bypass, single-tenant data exposure), 🟨 medium (requires chaining or insider position), ⚪ low/accepted. Likelihood × impact, judged against *this* system's assets — not CVSS theater. If everything is 🟥, the ranking failed.
+
+5. **Assess existing mitigations honestly** before recommending new ones. Each threat gets: what already mitigates it (and whether that's verified or assumed), then the recommended mitigation with a **verification step** — ✅ *"Presigned URLs scoped to tenant prefix; verify with a cross-tenant fetch test in CI"* — ❌ *"Use proper access controls"*.
+
+6. **Force the insider and authz passes.** Two systematic blind spots, swept explicitly: what can a *legitimate authenticated user* do to another tenant or to escalate (authn is not authz), and what can a malicious or compromised insider/CI-token do. One finding or an explicit all-clear for each.
+
+7. **Emit the model in one message**: system summary (assets / entry points / boundaries), findings grouped by severity, the n/a ledger, **assumptions**, **out of scope**, and **questions for the team** — the unknowns that block a finding from being confirmed or dismissed. End with the revisit trigger: the model is stale when a new entry point, boundary, or asset class appears.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — STRIDE question banks per boundary type + common-mitigation table
+- [`examples/document-upload.md`](examples/document-upload.md) — worked example: upload feature → 6 ranked findings
+
+## Quality bar
+
+- **Every threat is anchored** to a named trust-boundary crossing or asset. An unanchored finding is checklist residue — cut it.
+- **Every threat narrates a scenario** with actor, path, and result. "X is possible" is not a finding.
+- **Severity spread is honest.** A model where everything is critical (or nothing is) hasn't ranked anything; the 🟥 set is what you'd halt the build for.
+- **Every recommended mitigation has a verification step** a reviewer can run or check. Advice without verification is a wish.
+- **Existing mitigations are credited** — and marked verified vs assumed. A model that ignores what the design already does right teaches the team to ignore the model.
+- **The insider and authz sweeps produced output** — findings or an explicit reasoned all-clear, never silence.
+
+## When to use this skill
+
+- ✅ A design doc or RFC needs security scrutiny before implementation starts
+- ✅ "How could this be attacked?" for a new feature, integration, or entry point
+- ✅ Input for a formal security review / sign-off gate
+- ✅ A `reverse-architecture` extraction of a legacy system that never had a threat model
+
+## When NOT to use this skill
+
+- ❌ Reviewing written code for vulnerabilities — that's `devils-advocate` (its security lens) or `sonar-review`
+- ❌ Compliance attestation (SOC2, PCI evidence) — this models attacks, it doesn't certify controls
+- ❌ Incident analysis after an exploit — that's `postmortem-generator`
+- ❌ Pen-testing a live system — this is paper analysis; it tells the pen test where to aim
+
+## Anti-patterns to avoid
+
+- ❌ **OWASP-checklist dumping** — twenty generic items ("ensure input validation") untied to any boundary in *this* system. Volume isn't rigor.
+- ❌ **Stopping at authentication.** "Users must log in" answers spoofing only; the authz pass (tenant→tenant, user→admin) is where real findings live.
+- ❌ **"Use encryption" as a mitigation.** Of what, where, against which threat? Encryption at rest does nothing for a tampered request in flight.
+- ❌ **Modeling only the happy architecture.** Admin panels, CI/CD pipelines, support tooling, and webhook receivers are entry points — usually the softest ones.
+- ❌ **Inflating severity to be taken seriously.** One cried-wolf 🟥 and the next model gets skimmed.
+- ❌ **One-and-done modeling.** A threat model without a revisit trigger expires silently the first time the design changes.

skilldrop_cli/data/packs/solution-architect/skills/threat-model/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Threat model this design",
+    "should_trigger": true
+  },
+  {
+    "query": "Run STRIDE on this architecture before we build it",
+    "should_trigger": true
+  },
+  {
+    "query": "What could an attacker do to this system as designed?",
+    "should_trigger": true
+  },
+  {
+    "query": "Security review of this design doc, with trust boundaries and attack scenarios",
+    "should_trigger": true
+  },
+  {
+    "query": "Review this diff for exploitable security bugs",
+    "should_trigger": false
+  },
+  {
+    "query": "Threat model my AI agent's tool and data access",
+    "should_trigger": false
+  },
+  {
+    "query": "Audit this UI for accessibility barriers",
+    "should_trigger": false
+  },
+  {
+    "query": "Convene a council to deliberate this architecture",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/solution-architect/skills/threat-model/evals/evals.json

@@ -0,0 +1,18 @@
+{
+  "skill_name": "threat-model",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Threat model this design: a multi-tenant reporting service where customers upload CSVs, we process them in a worker, and results are served from an S3 bucket via signed URLs.",
+      "assertions": [
+        "Assets, entry points, and trust boundaries are established before any threat is listed",
+        "Every threat is anchored to a named trust-boundary crossing or asset — unanchored checklist residue is cut",
+        "Every threat narrates a scenario with actor, path, and result; 'X is possible' is not accepted as a finding",
+        "STRIDE is applied per boundary crossing rather than as a flat checklist",
+        "Severity is calibrated to this system's assets rather than CVSS theater — not everything is critical",
+        "Existing mitigations are credited as verified or assumed, and every recommendation carries a verification step",
+        "The authorization sweep (tenant-to-tenant, authn is not authz) and the insider/compromised-credential sweep are both run"
+      ]
+    }
+  ]
+}