skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/solution-architect/skills/data-contract/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: data-contract
+description: Draft a data contract for a dataset, table, or event stream consumed by others — schema with per-field semantics and units, measurable quality SLAs (freshness, completeness, validity, distribution), a schema-evolution policy that says what breaks consumers, a named owner, and PII classification. Use when the user is publishing a dataset/table/topic other teams depend on, needs a data contract, or wants to stop downstream pipelines breaking on silent schema or quality changes.
+---
+
+# data-contract
+
+Treats a dataset, table, or topic as a **product with an owner and a guarantee** — the agreement a producing team makes to everyone reading their data. Distinct from `api-contract-draft` (synchronous request/response + webhook interfaces): this governs *data at rest and in motion* — the warehouse table, the Kafka topic, the daily export — where the failure mode isn't a 500, it's a downstream model silently trained on a column whose meaning changed last Tuesday.
+
+## How to respond
+
+1. **Establish producer, consumers, and the asset.** What dataset (table / topic / file feed), who produces it, and **who consumes it** — because the consumer list is what makes a change "breaking". Ask at most 2 questions, spent on the asset's update mechanism (batch / streaming / CDC) and whether any consumer is outside the producing team's control (another team, a partner, a trained model). A dataset with unknown consumers can't have a contract — surfacing that is the first value.
+
+2. **Specify schema with semantics, not just types.** Types prevent crashes; semantics prevent silent wrongness. Every field gets: name, type, **nullability**, **unit or allowed-values**, and a **one-line meaning**. ✅ *"`amount` — int64, not null, minor currency units (cents), the net charged after discounts"* — ❌ *"`amount` — integer"* (cents or dollars? gross or net? the model that assumed dollars is now off by 100×). Mark every field's `[required]` vs `[optional]` and whether `null` is a valid value distinct from absent.
+
+3. **Set quality guarantees as measurable SLAs** (catalog in [`reference.md`](reference.md)) — each with a threshold, a check, and a **breach action**:
+   - **Freshness** — max acceptable lag ("partition for day D lands by 06:00 D+1")
+   - **Completeness** — expected volume / no gaps ("row count within ±10% of trailing-7-day median; no missing partitions")
+   - **Validity** — % rows passing field constraints ("≥99.9% of `email` rows match the format")
+   - **Uniqueness** — the key that's actually unique ("`event_id` unique; duplicates are a contract breach, not a dedup hint")
+   - **Distribution** — drift bounds on the columns consumers depend on ("`country` cardinality and null-rate within historical band")
+   A quality SLA without a breach action ("page the producer" / "quarantine the partition" / "alert consumers") is a wish; name the action.
+
+4. **Write the schema-evolution policy — the section that earns the contract.** State precisely what's safe and what isn't, *for data consumers specifically*: adding an optional column is usually safe; adding a `not null` column without a default breaks every writer; **changing a field's meaning while keeping its name and type is the silent killer** and is always breaking; removing or renaming is breaking; narrowing an enum is breaking, widening may be. Every breaking change requires a **version bump + a deprecation window + consumer notification** — and the contract names the window (e.g. "30 days, or until all registered consumers ack").
+
+5. **Make ownership and classification first-class.** Named owner (team/role, not a person), an on-call or contact, PII/sensitivity classification per field, retention period, and residency if constrained — the same discipline as `nfr-spec`, scoped to this asset. An unowned dataset is an incident waiting for a quarter-end.
+
+6. **Specify delivery.** Where it lives, format (Parquet/Avro/JSON), partitioning scheme, update cadence, and how a consumer registers as a dependent (so the breaking-change notification has an address list). For streams: delivery semantics (at-least-once default — consumers dedupe on the unique key), ordering guarantees, and retention.
+
+7. **Emit with [`templates/data-contract.md`](templates/data-contract.md)** in one message: header (asset, owner, consumers), schema table with semantics, quality SLA table with breach actions, evolution policy, delivery spec, classification. Where the asset already exists, note which guarantees are *aspirational* vs *currently met* — an honest contract beats a flattering one.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — the data-quality dimension catalog, the schema-evolution safe/breaking matrix, and field-semantics rules
+- [`templates/data-contract.md`](templates/data-contract.md) — the contract skeleton with schema and SLA tables
+
+## Quality bar
+
+- **Every field has a meaning and a unit/allowed-values**, not just a type. The cents-vs-dollars class of bug is designed out at contract time.
+- **Every quality SLA has a threshold, a check, and a breach action.** "High quality" is not an SLA; "freshness < 6h, checked hourly, breach pages the owner" is.
+- **The evolution policy names the silent killer** — meaning-change-under-stable-name — as breaking. Most contracts miss it and most data incidents are it.
+- **Consumers are enumerated**, so "breaking" is defined and notifications have an address. Unknown consumers are flagged, not assumed away.
+- **The asset has a named owner and per-field classification.** No owner, no contract.
+- **Existing-asset contracts mark aspirational vs met.** Claiming a freshness SLA the pipeline doesn't hit is how the contract loses its authority on day one.
+
+## When to use this skill
+
+- ✅ Publishing a table/topic/feed other teams or models will depend on
+- ✅ "We need a data contract for X" / stopping downstream breakage from schema drift
+- ✅ Formalizing the guarantee on a dataset that's already widely consumed
+- ✅ A data-mesh / data-as-a-product initiative needing per-asset contracts
+
+## When NOT to use this skill
+
+- ❌ A synchronous REST/RPC API or webhook — that's `api-contract-draft`
+- ❌ The physical schema migration (expand/backfill/contract) — that's `migration-plan`
+- ❌ System-wide NFRs for a service — that's `nfr-spec`; this is one data asset's guarantee
+- ❌ A private dataset with exactly one consumer inside the same team — a comment in the code may suffice
+
+## Anti-patterns to avoid
+
+- ❌ **Types without semantics.** `status: string` with no allowed-values list means every consumer invents their own set and one of them is wrong.
+- ❌ **Quality as an adjective.** "Clean, reliable data" — unmeasurable, unenforceable, unfalsifiable. Dimensions with thresholds or nothing.
+- ❌ **Ignoring meaning-change.** Renaming the *concept* behind `revenue` from gross to net while the column name and type hold — the most expensive data bug there is, and zero schema validators catch it. The evolution policy must.
+- ❌ **The orphan dataset.** No owner, no consumer list — so no one can be paged and no one can be warned. That's not a product, it's a liability.
+- ❌ **Aspirational SLAs on a pipeline that misses them.** A freshness promise the batch job blows nightly trains consumers to ignore the whole contract.
+- ❌ **Treating additive as automatically safe.** A new `not null` column with no default breaks every existing writer; a new column can break a `SELECT *` consumer's schema check. Additive ≠ free in data.

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

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write a data contract for this table",
+    "should_trigger": true
+  },
+  {
+    "query": "We have downstream consumers of this dataset — define the contract and its SLAs",
+    "should_trigger": true
+  },
+  {
+    "query": "Define the schema and quality guarantees for this event stream",
+    "should_trigger": true
+  },
+  {
+    "query": "What should our producers promise consumers about this data?",
+    "should_trigger": true
+  },
+  {
+    "query": "Draft the OpenAPI spec for our REST API",
+    "should_trigger": false
+  },
+  {
+    "query": "Design the database schema and indexes from our access patterns",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the product requirements document",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan our observability and alerting",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/solution-architect/skills/data-contract/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "data-contract",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We publish an `orders_daily` table that three downstream teams consume. Write the data contract.",
+      "assertions": [
+        "Every field carries a meaning plus a unit or allowed-values, not merely a type — the cents-vs-dollars class of bug is designed out",
+        "Every quality SLA states a threshold, a check, and a breach action; 'high quality' is rejected as an SLA",
+        "The evolution policy explicitly names meaning-change-under-a-stable-name as a breaking change",
+        "The contract names the owner and the consumers it is a promise to",
+        "Freshness, completeness, validity, and distribution are each addressed or explicitly marked not-applicable"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/solution-architect/skills/data-contract/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "data-contract",
+  "version": "0.1.0",
+  "description": "Draft a data contract for a dataset, table, or event stream consumed by others — schema with per-field semantics and units, measurable quality SLAs (freshness, completeness, validity, distribution), a schema-evolution policy that says what breaks consumers, a named owner, and PII classification. Use when the user is publishing a dataset/table/topic other teams depend on, needs a data contract, or wants to stop downstream pipelines breaking on silent schema or quality changes.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["api-contract-draft", "migration-plan", "nfr-spec"],
+  "tags": ["data-contract", "data-engineering", "schema", "data-quality", "data-mesh", "governance"],
+  "model": { "tier": "standard", "rationale": "Schema + SLA synthesis against fixed quality dimensions and an evolution matrix. Semantics capture needs care; bounded by the catalog. Escalate via large-input on wide schemas." }
+}

skilldrop_cli/data/packs/solution-architect/skills/data-contract/reference.md

@@ -0,0 +1,46 @@
+# data-contract reference — quality dimensions, evolution matrix, field semantics
+
+## Data-quality dimension catalog
+
+Each dimension on the contract gets: a **threshold**, a **check** (how/when measured), and a **breach action**. Pick the dimensions that matter for this asset; mark the rest n/a with a reason.
+
+| Dimension | What it guarantees | Threshold example | Check | Breach action examples |
+|---|---|---|---|---|
+| **Freshness** | data is recent enough to trust | partition D lands by 06:00 D+1 | scheduler SLA / landing-time monitor | page owner; mark stale on the dashboard |
+| **Completeness** | nothing silently missing | row count within ±10% of trailing-7d median; all partitions present | post-load count check | quarantine partition; block downstream |
+| **Validity** | values satisfy field constraints | ≥99.9% rows pass per-field rules | constraint suite per load | reject load; alert; route bad rows to DLQ |
+| **Uniqueness** | the key is actually unique | `event_id` 100% unique | dup-count query | breach = contract violation, not silent dedup |
+| **Consistency** | cross-field/cross-table invariants hold | `ends_at` ≥ `starts_at`; FK resolves | invariant assertions | alert; hold publish |
+| **Distribution / drift** | columns consumers model don't shift unannounced | null-rate, cardinality, mean within historical band | drift monitor vs baseline | alert consumers; investigate before publish |
+| **Timeliness of correction** | how fast a known-bad load is fixed | corrected within {N}h of detection | incident clock | comms to consumers (→ `incident-comms`) |
+
+A dimension with no breach action is decoration. The breach action is the part consumers actually rely on.
+
+## Schema-evolution safe/breaking matrix (for DATA consumers)
+
+"Breaking" here means: a downstream query, pipeline, or trained model could silently produce wrong results or fail. Data consumers are more fragile than API clients — `SELECT *`, positional reads, and models that learned a column's distribution all break in ways HTTP clients don't.
+
+| Change | Safe? | Notes |
+|---|---|---|
+| Add optional/nullable column **with** default or documented null-meaning | usually safe | still breaks strict `SELECT *` schema checks — notify |
+| Add `NOT NULL` column without default | **breaking** | every existing writer fails |
+| Remove or rename a column | **breaking** | rename = remove + add; positional/`*` consumers break |
+| Change type (even "widening") | **breaking** | int→float shifts joins, aggregations, model features |
+| **Change the meaning** behind a stable name+type | **breaking — the silent killer** | gross→net, UTC→local, cents→dollars: no validator catches it; only the contract can |
+| Narrow an enum (remove an allowed value) | **breaking** | consumers branching on it lose a case |
+| Widen an enum (add an allowed value) | maybe breaking | breaks consumers with exhaustive switches; declare enum open/closed |
+| Tighten a constraint (e.g. now `NOT NULL`) | **breaking** | historical rows / lenient writers violate it |
+| Loosen a constraint | usually safe | but consumers assuming the old guarantee may break |
+| Change partitioning / sort | **breaking for performance** | consumer queries may table-scan or time out |
+
+**Every breaking change requires:** version bump → deprecation window (name it, e.g. 30 days or until all registered consumers ack) → notification to the registered consumer list → both versions available during the window where feasible. This mirrors `migration-plan`'s expand/contract — apply it to the schema.
+
+## Field-semantics rules (the cents-vs-dollars firewall)
+
+Every field on the contract states:
+- **Unit** for any quantity — currency + minor/major units, time unit, byte/bit, percentage-as-0-1-vs-0-100. The single most common silent data bug is a unit assumption.
+- **Allowed values** for any categorical — the full enum, open or closed.
+- **Null semantics** — is `null` "unknown", "not applicable", or "zero"? These are three different facts; pick one and write it.
+- **Timezone** for any timestamp — UTC unless stated; name the zone, never leave it implicit.
+- **Meaning** — one line a new consumer reads instead of guessing. "`status`: lifecycle state of the order, see allowed values" beats inferring from the name.
+- **Identity** — which field(s) uniquely identify a row, and whether IDs are stable across reloads.

skilldrop_cli/data/packs/solution-architect/skills/data-contract/templates/data-contract.md

@@ -0,0 +1,69 @@
+# Data-contract template
+
+A dataset is a product. This is its label, its warranty, and its change policy.
+
+```markdown
+# Data contract: {asset name}
+
+**Asset:** {warehouse table | Kafka topic | file feed | view} — `{fully.qualified.name}`
+**Owner:** {team/role} · **Contact / on-call:** {channel}
+**Producer:** {pipeline/service} · **Update mechanism:** {batch | streaming | CDC}
+**Version:** {v1} · **Status:** {proposed | active | deprecated}
+
+## Consumers (defines what "breaking" means)
+
+| Consumer | Team | Usage | Notify on change |
+|---|---|---|---|
+| {dashboard/model/pipeline} | {team} | {what they read it for} | {channel} |
+
+⚠ {Flag any unknown/unregistered consumers — a change can't be safely made until known.}
+
+## Schema (types + semantics)
+
+| Field | Type | Req? | Null means | Unit / allowed values | Meaning |
+|---|---|---|---|---|---|
+| `event_id` | string | required | — | opaque UUID | unique row identity, stable across reloads |
+| `amount` | int64 | required | — | minor units (cents), {currency} | net charged after discounts |
+| `country` | string | optional | unknown | ISO-3166-1 alpha-2, open enum | billing country |
+| `occurred_at` | timestamp | required | — | UTC, ISO-8601 | when the event happened (not when ingested) |
+
+**Identity:** {field(s) that uniquely identify a row}
+**Grain:** {one row per … }
+
+## Quality SLAs
+
+| Dimension | Threshold | Check | Breach action | Met today? |
+|---|---|---|---|---|
+| Freshness | partition D by 06:00 D+1 | landing monitor | page owner | ✅ / aspirational |
+| Completeness | rows within ±10% of 7d median | post-load count | quarantine partition | … |
+| Validity | ≥99.9% pass field rules | constraint suite | reject load, alert | … |
+| Uniqueness | `event_id` 100% unique | dup query | contract breach | … |
+| Distribution | null-rate/cardinality in band | drift monitor | alert consumers | … |
+
+{Mark each "Met today?" honestly: ✅ currently met, or "aspirational — pipeline does not yet meet this".}
+
+## Schema-evolution policy
+
+- Safe (notify only): {additive nullable columns with documented null-meaning}
+- Breaking (version bump + deprecation window + consumer ack): removals, renames, type changes, **meaning changes under a stable name**, enum narrowing, constraint tightening, partition changes.
+- Deprecation window: {e.g. 30 days, or until all registered consumers ack}; both versions live during the window where feasible.
+- Meaning-change clause: a field's documented meaning is part of the contract; changing it (e.g. gross→net) is breaking even if name and type are unchanged.
+
+## Delivery
+
+- **Location / format:** {path or topic} · {Parquet | Avro | JSON}
+- **Partitioning:** {scheme}
+- **Cadence:** {hourly | daily 06:00 | continuous}
+- **Streaming only:** delivery {at-least-once → dedupe on identity}; ordering {per-key | none}; retention {N days}
+- **Register as a consumer:** {how — so breaking-change notices reach you}
+
+## Classification & retention
+
+| Field(s) | Classification | Retention | Residency |
+|---|---|---|---|
+| {field} | {PII / sensitive / public} | {period} | {constraint or none} |
+
+## Open questions
+
+- {unknowns blocking sign-off — e.g. undiscovered consumers, an SLA not yet measurable}
+```

skilldrop_cli/data/packs/solution-architect/skills/db-schema-design/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: db-schema-design
+description: Design a database schema from access patterns — paradigm chosen deliberately (relational/document/key-value/wide-column/graph), keys and partitioning driven by the actual queries, indexes mapped to predicates, money/time types right, and every read path verified to have a supporting access path. Use when the user is designing a data model, schema, or tables for a feature, choosing a database, or asks how to structure/store data.
+---
+
+# db-schema-design
+
+Designs the storage layer **from the queries backward** — because a schema is right or wrong only relative to how it's read and written, and the most expensive schema mistakes are the access paths nobody designed for. Distinct from `data-contract` (the guarantee on a *published* dataset) and `api-contract-draft` (the sync interface): this is the table/collection/key design underneath. Hands evolution off to `migration-plan` and the published-dataset guarantee to `data-contract`.
+
+## How to respond
+
+1. **Collect the access patterns before drawing a single table.** The deliverable starts as a list: each read and write the feature needs, with **frequency**, **latency sensitivity**, **selectivity** (one row / a range / a scan), and **consistency need** (read-your-writes? eventual ok?). Ask at most 2 questions, spent on the highest-frequency query and the largest-growth entity. A schema designed from the entity diagram instead of the queries is how you get a clean model that can't serve its hottest path.
+
+2. **Choose the paradigm deliberately, with a reason** (selection matrix in [`reference.md`](reference.md)). Relational is the correct default for most transactional features and needs no defense; reaching *past* it does. ✅ *"Document store — the entity is read and written whole, no cross-entity queries, and the shape varies per type"* — ❌ *"NoSQL because scale"* (scale is a property of access patterns and data size, not a vibe). For NoSQL especially, the access patterns *are* the schema — you cannot add a query later for free the way SQL lets you.
+
+3. **Design keys from the queries.**
+   - **Relational:** surrogate key (e.g. `bigint`/ULID) as PK by default; natural keys get a unique constraint, not the clustered PK. Avoid random UUIDv4 as a clustered/primary key — it scatters writes and splits pages; use a time-ordered ID (ULID/UUIDv7) when you need a UUID and ordered inserts.
+   - **NoSQL:** partition key + sort key derived directly from the access patterns, chosen to spread load (no hot partition) and to co-locate what's read together. State the query each key shape serves.
+
+4. **Normalize to 3NF, then denormalize only for a named read pattern — and name the sync obligation.** 3NF is the default because it makes writes correct and anomalies impossible. Every denormalization is a deliberate trade for a specific hot read, and it incurs a duplicate-keeping-in-sync debt that must be stated: ✅ *"Cache `order_count` on `customer` for the dashboard's top query; kept in sync by the order-write transaction / a trigger"* — ❌ a denormalized field with no answer to "what updates the copy?".
+
+5. **Index for the actual predicates, joins, and sorts — not speculatively.** Every index pays a write cost and storage; an unused index is pure overhead. Rules (full set in [`reference.md`](reference.md)): index the columns in `WHERE`/`JOIN`/`ORDER BY` of real queries; **composite index column order is equality-first, then range, then sort**; consider a covering index for a hot read; don't index low-selectivity columns alone. Map each index to the query it serves — an index with no query is a guess.
+
+6. **Get the types and constraints right at the schema, not in app code.** Money as integer minor units or `decimal`, **never float** (echoes `data-contract`); timestamps with explicit timezone (store UTC); enums as a constrained type or lookup table, not free strings; `NOT NULL` + defaults + `CHECK` + foreign keys express invariants the database enforces for every writer, including the ones you'll add later. Right-size types (don't `text` a 2-char country code).
+
+7. **State the scale and multitenancy decisions.** Name the table that grows unbounded and its plan (partition by time, archive cold data); the partition/shard strategy if any (and why it's not premature); and the **multitenancy isolation model** (shared-table + `tenant_id` with row-level security / schema-per-tenant / db-per-tenant) with its trade — this is an early decision that's brutal to reverse, so it's explicit, not defaulted.
+
+8. **Verify every access pattern has a supporting path, and emit with [`templates/schema-design.md`](templates/schema-design.md)** in one message: access-pattern table, paradigm + rationale, the schema (tables/collections with columns, types, keys, constraints), relationships/cardinality, indexes mapped to queries, scale + multitenancy decisions, and the **verification table** — each access pattern → the key or index that serves it, with any that fall to a full scan flagged. Evolution → `migration-plan`; published-to-consumers → `data-contract`.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — paradigm-selection matrix, key-design rules, the normalization/denormalization ladder, indexing rules, multitenancy options, and the schema anti-pattern catalog
+- [`templates/schema-design.md`](templates/schema-design.md) — the design skeleton with access-pattern, schema, index, and verification tables
+
+## Quality bar
+
+- **Access patterns are listed before the schema**, with frequency and selectivity. A schema with no query list was designed blind.
+- **The paradigm choice has a reason tied to access patterns** — and relational-by-default needs none while every move past it does.
+- **Keys are justified by queries**, and no random UUIDv4 sits as a clustered PK without a noted reason.
+- **Every index maps to a real query**; every denormalization names what keeps the copy in sync.
+- **Money is never float, timestamps carry timezone, invariants are DB constraints** — not left to application discipline.
+- **Multitenancy and the unbounded-growth table have explicit plans.** The expensive-to-reverse decisions are made on purpose.
+- **The verification table shows each access pattern's supporting path**, with full scans flagged rather than hidden.
+
+## When to use this skill
+
+- ✅ Designing tables/collections/keys for a new feature or service
+- ✅ Choosing a database paradigm for a known set of access patterns
+- ✅ "How should I structure / store this data?" with real queries in mind
+- ✅ Reworking a schema whose hot query has no supporting index
+
+## When NOT to use this skill
+
+- ❌ Governing a dataset other teams consume (quality SLAs, evolution policy) — that's `data-contract`
+- ❌ The sync API/event shape over the data — that's `api-contract-draft`
+- ❌ Executing a schema change on a live system (expand/backfill/contract) — that's `migration-plan`
+- ❌ Picking a specific managed product (Aurora vs Cloud SQL) — that's `tech-comparison-matrix`; this designs the model, not the vendor
+
+## Anti-patterns to avoid
+
+- ❌ **Entity-first, query-never.** A beautiful normalized ER diagram whose top query needs four joins and a full scan. Design from the access patterns.
+- ❌ **"NoSQL for scale" with no access-pattern argument.** NoSQL trades ad-hoc query flexibility for scale on *known* patterns; choosing it blind buys the downside without the upside.
+- ❌ **UUIDv4 as the clustered primary key.** Random keys scatter inserts and fragment the index; use a time-ordered ID when you need a UUID.
+- ❌ **EAV / the god table.** Entity-attribute-value "flexible" schemas and 80-column catch-all tables are queryability and integrity sold for a flexibility you'll regret.
+- ❌ **JSON-blob-as-schema-avoidance.** Dumping everything in a `jsonb` column to skip design, then writing queries that dig into it with no index — schema design deferred, not avoided, and now unindexable.
+- ❌ **Speculative indexing.** Indexing every column "to be safe" taxes every write and bloats storage; index the queries you have.
+- ❌ **Float money / naked timestamps / stringly-typed enums.** The same three regrets as `data-contract`, baked in at the storage layer where they're hardest to fix.
+- ❌ **Deferring the multitenancy decision.** Shared-table-vs-isolated is near-impossible to change after data lands; an unmade decision is the riskiest one.

skilldrop_cli/data/packs/solution-architect/skills/db-schema-design/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Design the database schema for this feature",
+    "should_trigger": true
+  },
+  {
+    "query": "What tables, keys, and indexes do I need for these queries?",
+    "should_trigger": true
+  },
+  {
+    "query": "Should this be relational or document, given our access patterns?",
+    "should_trigger": true
+  },
+  {
+    "query": "Model the data layer for this access pattern list",
+    "should_trigger": true
+  },
+  {
+    "query": "Write a data contract for the table our consumers read",
+    "should_trigger": false
+  },
+  {
+    "query": "Draft the OpenAPI contract for the service",
+    "should_trigger": false
+  },
+  {
+    "query": "Diagram our system architecture",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan the migration from the old schema",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/solution-architect/skills/db-schema-design/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "db-schema-design",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Design the schema for an order-history feature. Queries: fetch one order by id, list a customer's orders newest-first, and report daily totals by region.",
+      "assertions": [
+        "Access patterns are listed before the schema, with frequency and selectivity",
+        "The paradigm choice is justified against those access patterns — relational-by-default needs no defence, every move past it does",
+        "Keys and partitioning are justified by the actual queries; a random UUIDv4 clustered primary key is not used without a stated reason",
+        "Every index maps to a real predicate from the listed queries rather than being speculative",
+        "Denormalization, where proposed, names the read it serves and the write cost it adds"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/solution-architect/skills/db-schema-design/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "db-schema-design",
+  "version": "0.1.0",
+  "description": "Design a database schema from access patterns — paradigm chosen deliberately (relational/document/key-value/wide-column/graph), keys and partitioning driven by the actual queries, indexes mapped to predicates, money/time types right, and every read path verified to have a supporting access path. Use when the user is designing a data model, schema, or tables for a feature, choosing a database, or asks how to structure/store data.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["api-contract-draft", "data-contract", "migration-plan", "tech-comparison-matrix"],
+  "tags": ["database", "schema-design", "data-model", "indexing", "sql", "nosql"],
+  "model": { "tier": "standard", "rationale": "Design synthesis from access patterns against a fixed paradigm/indexing/anti-pattern reference. Paradigm and denormalization judgment is bounded; escalate via ambiguous-input on contested scale/consistency tradeoffs." }
+}

skilldrop_cli/data/packs/solution-architect/skills/db-schema-design/reference.md

@@ -0,0 +1,56 @@
+# db-schema-design reference — paradigm matrix, keys, indexing, multitenancy, anti-patterns
+
+## Paradigm-selection matrix (relational is the default; justify moving past it)
+
+| Paradigm | Fits when | Access-pattern signal | Cost of choosing it |
+|---|---|---|---|
+| **Relational** (Postgres, MySQL) | transactional data, ad-hoc queries, joins, strong consistency | "we'll query this many ways, some not yet known"; integrity matters | vertical-scale ceiling (far off for most); needs sharding eventually at very high write volume |
+| **Document** (Mongo, DynamoDB doc, Firestore) | entity read/written whole, varying shape per item, few cross-entity queries | "always fetch the whole order with its lines by order id" | ad-hoc cross-document queries are slow/absent; you design for the queries you know |
+| **Key-value** (Redis, DynamoDB KV) | get/put by a single key, caching, sessions, very high throughput | "look up by exact id, nothing else" | no querying beyond the key; not a system of record alone |
+| **Wide-column** (Cassandra, Bigtable) | massive write volume, time-series-ish, known query keys, linear scale | "billions of rows, query by partition+time, no joins" | one table per query pattern; data duplicated across tables; eventual consistency |
+| **Graph** (Neo4j) | relationship traversal is the query (friends-of-friends, paths, recommendations) | "find all X connected to Y within N hops" | overkill for tabular data; operational maturity cost |
+| **Time-series** (Timescale, Influx) | append-heavy metrics/events keyed by time, downsampling, retention | "ingest events, query ranges, roll up by window" | narrow purpose; pair with a relational store for the rest |
+
+Polyglot is legitimate (Postgres for the system of record + Redis cache + a search index) — but each store needs its own access-pattern justification, and you now own the consistency between them.
+
+## Key design
+
+- **Surrogate vs natural (relational):** surrogate PK (`bigint` identity, or ULID/UUIDv7) by default — stable, opaque, join-friendly. Natural keys (email, SKU) get a `UNIQUE` constraint, not the role of clustered PK (they change, and they leak into URLs/logs).
+- **Avoid random UUIDv4 as a clustered/primary key:** random order scatters inserts across the B-tree, causing page splits and write amplification. Use **UUIDv7/ULID** (time-ordered) when you need a UUID with ordered inserts, or a `bigint` sequence.
+- **NoSQL partition + sort key:** derive from access patterns. Partition key must spread load — a low-cardinality or monotonically-increasing partition key creates a **hot partition**. Sort key co-locates and orders what's read together (e.g. PK=`customer_id`, SK=`order#<ts>` to list a customer's orders by time). One access pattern that doesn't fit the key shape = a new table or a secondary index, decided now.
+- **Composite/natural uniqueness:** enforce real-world uniqueness (one active subscription per customer) with a partial/unique index, not app-code checks that race.
+
+## Normalization / denormalization ladder
+
+1. **Start at 3NF.** Each fact in one place; no update anomalies. This is the correct default for a system of record.
+2. **Denormalize only for a named hot read**, and only after the normalized form is shown to be the bottleneck (or obviously will be). Examples: a counter cache (`order_count`), a duplicated display field to avoid a join on the top query, a materialized view.
+3. **Every denormalization states its sync mechanism** — transaction, trigger, application code, or scheduled rebuild — and accepts the staleness window. A duplicated value with no sync owner *will* drift.
+4. **NoSQL is denormalized by design** — you duplicate across items/tables to serve each access pattern; the "sync obligation" becomes a write-path responsibility (write to all copies, or accept eventual reconciliation).
+
+## Indexing rules
+
+- Index the columns that appear in `WHERE`, `JOIN`, and `ORDER BY` of **actual** queries.
+- **Composite column order: equality predicates first, then the range predicate, then the sort column.** `WHERE tenant_id = ? AND created_at > ? ORDER BY created_at` → index `(tenant_id, created_at)`.
+- A **covering index** (includes the selected columns) turns a hot read into an index-only scan — worth it for a top query, costly to maintain for a rare one.
+- **Don't index low-selectivity columns alone** (a boolean, a 3-value status) — the scan is cheaper than the index hop; combine with a selective column instead, or use a partial index (`WHERE status = 'active'`).
+- Every index taxes **every write** and consumes storage. The right count is "one per real query shape," not zero and not all-columns.
+- Foreign-key columns are usually worth indexing (joins + cascade performance).
+
+## Multitenancy isolation (decide early — expensive to reverse)
+
+| Model | Isolation | Cost / blast radius | Fits |
+|---|---|---|---|
+| Shared table + `tenant_id` (+ row-level security) | logical, enforced by RLS/query | cheapest; a query bug = cross-tenant leak (see `threat-model`) | many small tenants, SaaS default |
+| Schema-per-tenant | stronger; separate tables per tenant | migrations × N schemas; noisy-neighbor still shared | tens–hundreds of mid tenants |
+| Database-per-tenant | strongest; separate DBs | highest ops cost; per-tenant backup/restore is a feature | few large/regulated/enterprise tenants |
+
+State the choice and its trade. If shared-table, the `tenant_id` predicate is non-negotiable on every query and belongs in RLS, not developer discipline.
+
+## Schema anti-pattern catalog
+
+- **EAV (entity-attribute-value)** — rows of `(entity, attribute, value)` to be "flexible." Kills types, constraints, and queryability. Use real columns, or a typed `jsonb` column with documented shape and expression indexes — not a generic triple store.
+- **The god table** — 60+ columns, half null for any given row, modeling several entities at once. Split by entity.
+- **JSON-blob-as-schema-avoidance** — `jsonb` for everything to skip modeling, then unindexed queries digging into it. JSON is for genuinely variable/sparse sub-structure, with expression indexes on what you query.
+- **Premature sharding** — operational complexity for scale you don't have. Vertical + read replicas + partitioning usually buy years first.
+- **Index-everything / index-nothing** — both are failures; index the real query shapes.
+- **Soft-delete everywhere without thought** — `is_deleted` flags leak into every query and every unique constraint; decide per table, and use partial indexes (`WHERE NOT is_deleted`).

skilldrop_cli/data/packs/solution-architect/skills/db-schema-design/templates/schema-design.md

@@ -0,0 +1,75 @@
+# Schema-design template
+
+Access patterns first, schema second, verification last — every query must end the document with a supporting path.
+
+```markdown
+# Schema design: {feature / domain}
+
+**Paradigm:** {relational | document | key-value | wide-column | graph | time-series}
+**Rationale:** {tied to the access patterns below — relational needs none; anything else justifies}
+**Engine (if decided):** {Postgres 16 | DynamoDB | …} `[assumption if not confirmed]`
+
+## Access patterns (the spec the schema is judged against)
+
+| # | Query / write | R/W | Frequency | Selectivity | Latency | Consistency |
+|---|---|---|---|---|---|---|
+| Q1 | get order with lines by order id | R | very high | 1 row + children | <50ms | read-your-writes |
+| Q2 | list a customer's orders, newest first | R | high | range | <200ms | eventual ok |
+| W1 | create order + lines | W | high | — | — | atomic |
+
+## Schema
+
+### {table / collection: orders}
+
+| Column | Type | Null | Key/constraint | Notes |
+|---|---|---|---|---|
+| id | bigint / ULID | no | PK | surrogate; time-ordered |
+| customer_id | bigint | no | FK → customers(id), indexed | |
+| total_minor | bigint | no | CHECK (>= 0) | minor units, currency below — never float |
+| currency | char(3) | no | CHECK (ISO-4217) | |
+| status | text | no | CHECK in (pending,paid,shipped,cancelled) | enum, not free string |
+| created_at | timestamptz | no | default now() | UTC |
+
+{Repeat per table/collection. For NoSQL: state PK (partition) + SK (sort) and the access pattern each serves.}
+
+## Relationships
+
+- customers 1 —< orders 1 —< order_lines  (cascade: delete order → delete its lines)
+- {cardinality + cascade/restrict per relationship}
+
+## Indexes (each maps to a query)
+
+| Index | Columns (order matters) | Serves | Type |
+|---|---|---|---|
+| idx_orders_customer_created | (customer_id, created_at) | Q2 (equality then sort) | btree |
+| pk_orders | (id) | Q1 | primary key (clustered/index-organized only on engines that support it — Postgres heaps don't) |
+
+{Note any covering/partial index and why. No index without a query.}
+
+## Denormalizations (if any)
+
+| Field | On | For query | Kept in sync by |
+|---|---|---|---|
+| order_count | customers | dashboard top read | order-write transaction |
+
+## Scale & multitenancy
+
+- **Unbounded-growth table:** {orders} — plan: {partition by created_at month; archive > 24mo to cold storage}.
+- **Partition/shard:** {none yet — vertical + read replica suffices to ~Nx; revisit at {trigger}} or {strategy + why not premature}.
+- **Multitenancy:** {shared-table + tenant_id + RLS | schema-per-tenant | db-per-tenant} — trade: {…}. `tenant_id` predicate enforced by {RLS policy}.
+
+## Verification — every access pattern has a path
+
+| # | Supported by | Full scan? |
+|---|---|---|
+| Q1 | pk_orders + FK index on lines | no |
+| Q2 | idx_orders_customer_created | no |
+| W1 | insert; FK indexes present | no |
+
+⚠ {Any pattern with no supporting index/key — flag it and resolve before build.}
+
+## Evolution
+
+- Migrations / rollout of changes → `migration-plan`.
+- If this data is published to other teams → wrap it in a `data-contract`.
+```

skilldrop_cli/data/packs/solution-architect/skills/design-doc/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: design-doc
+description: Generate a Google-style engineering design doc (problem, goals/non-goals, options considered, recommended approach, risks, rollout) from a feature brief or short description. Use when the user wants to draft a design doc, technical proposal, or one-pager for an engineering review.
+---
+
+# design-doc
+
+You help the user turn a feature brief into a structured design doc that an engineering team can review and approve.
+
+## How to respond
+
+1. **Understand the brief.** Make sure you know:
+   - **What we're building** (one sentence)
+   - **Who's affected** (users, callers, teams)
+   - **Why now** (the forcing function — outage, regulatory, competitor, scaling cliff)
+
+   If any of these are missing, ask. Don't draft a design doc without a *why now*.
+
+2. **Default to the standard structure** in [`templates/design-doc.md`](templates/design-doc.md):
+   1. Title + status (Draft / In Review / Approved) + author + date
+   2. **TL;DR** — three bullets, readable in 30 seconds
+   3. **Context** — why is this being proposed
+   4. **Goals / Non-goals** — explicit non-goals matter as much as goals
+   5. **Proposal** — the actual design (this is the longest section)
+   6. **Alternatives considered** — at least 2 alternatives with why-not
+   7. **Risks & mitigations**
+   8. **Rollout plan** — staged rollout, feature flag, rollback criteria
+   9. **Open questions**
+
+3. **Length discipline.** A good design doc is **2–5 pages** rendered. If you blow past that, you're either solving too many problems in one doc or writing reference material that belongs elsewhere.
+
+4. **Show, don't tell.** Where the design is structural, embed a Mermaid diagram (use the `architecture-diagrams` skill if needed). Where it's about flows, embed a sequence diagram. Where it's about API shape, embed a small example request/response.
+
+5. **End with explicit asks.** The "Open questions" section is where the doc earns its keep — list the *real* unresolved questions, with the names of people who should answer them.
+
+## Quality bar
+
+- **Non-goals are real, not throat-clearing.** If your non-goals list reads "we're not solving world hunger", delete it. Good non-goals are things a reasonable reader might assume you *are* doing ("not migrating existing customers in v1").
+- **Alternatives have a why-not, not just a description.** Two sentences each: what is it, why didn't we pick it.
+- **Risks have mitigations.** A bare list of "things that could go wrong" is anxiety, not engineering.
+- **Rollout criteria are concrete.** "We'll monitor closely" is not a criterion. "Roll forward to 100% if p99 < 80ms for 48h after 10% rollout" is.
+
+## Anti-patterns to avoid
+
+- ❌ Starting with implementation detail before establishing the problem.
+- ❌ "Future work" sections that double the doc length with hypotheticals.
+- ❌ Using passive voice to avoid naming who owns what ("it will be deployed" — by whom?).
+- ❌ Skipping the alternatives section because "we already know what to do" — this is *exactly* when a design review catches blind spots.
+- ❌ More than ~5 pages. Cut, link out, or split into multiple docs.

skilldrop_cli/data/packs/solution-architect/skills/design-doc/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Draft a design doc for this feature",
+    "should_trigger": true
+  },
+  {
+    "query": "Write a Google-style engineering design document from this brief",
+    "should_trigger": true
+  },
+  {
+    "query": "I need a technical design with goals, non-goals, alternatives, and rollout",
+    "should_trigger": true
+  },
+  {
+    "query": "Turn this feature brief into a design doc the team can review",
+    "should_trigger": true
+  },
+  {
+    "query": "Write an ADR recording this one decision",
+    "should_trigger": false
+  },
+  {
+    "query": "Draft the product requirements document for this feature",
+    "should_trigger": false
+  },
+  {
+    "query": "Critique the design doc I already wrote",
+    "should_trigger": false
+  },
+  {
+    "query": "Split this epic into user stories",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/solution-architect/skills/design-doc/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "design-doc",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Draft a design doc for a notification service that consumes domain events and delivers email and push notifications for about 1M events/day.",
+      "assertions": [
+        "Non-goals are real scope boundaries a reader might otherwise assume are in scope, not throat-clearing",
+        "Each alternative carries a two-sentence what-it-is and why-we-didn't-pick-it",
+        "Every risk has a mitigation, not a bare list of concerns",
+        "Goals are stated with measurable targets rather than adjectives",
+        "The rollout section names stages and what would halt it",
+        "Facts not supplied by the user are marked as open questions rather than invented"
+      ]
+    }
+  ]
+}