skilldrop-cli 0.9.0 → 0.9.2

package/skills/ai-readiness-assessment/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Are we ready to adopt AI?",
+    "should_trigger": true
+  },
+  {
+    "query": "Assess our AI maturity and tell me what's blocking us",
+    "should_trigger": true
+  },
+  {
+    "query": "Give me an AI readiness baseline for our engineering org",
+    "should_trigger": true
+  },
+  {
+    "query": "What do we need to fix before rolling out AI tools?",
+    "should_trigger": true
+  },
+  {
+    "query": "Which AI use cases should we build first?",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan how we roll this tool out to 200 people",
+    "should_trigger": false
+  },
+  {
+    "query": "Write our AI acceptable-use policy",
+    "should_trigger": false
+  },
+  {
+    "query": "Run a SWOT on our market position",
+    "should_trigger": false
+  }
+]

package/skills/ai-readiness-assessment/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "ai-readiness-assessment",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're a 200-person fintech. Engineering has Copilot licences that about a third of people use, we have no written AI policy, our docs are spread across Confluence and Notion, and leadership keeps asking when we'll 'be an AI company'. Are we ready?",
+      "assertions": [
+        "All six dimensions (data, tooling, skills, governance, process, culture) are scored 0-4 — none is omitted",
+        "Every score carries a one-line evidence reference drawn from the input, or is marked [insufficient evidence: <what to collect>]",
+        "Gaps are ranked by what blocks adoption first, with the dependency named — not simply sorted by lowest score",
+        "Every gap has a concrete first action and an owner expressed as a role, not a person's name",
+        "The posture sentence takes a position and names the condition that would change it",
+        "No facts are invented beyond what the prompt supplies"
+      ]
+    }
+  ]
+}

package/skills/ai-readiness-assessment/manifest.json

@@ -0,0 +1,34 @@
+{
+  "name": "ai-readiness-assessment",
+  "version": "0.1.0",
+  "description": "Score an organisation's or team's readiness to adopt AI tooling across six gating dimensions — data, tooling, skills, governance, process, and culture — with an evidence line per score and the blocking gaps ranked by what stops adoption first. Use when the user asks \"are we ready for AI\", wants an AI maturity or readiness baseline, or needs to know what to fix before rolling tools out. Do NOT use to pick which use cases to build (that's ai-use-case-triage) or to plan the rollout itself (that's ai-adoption-rollout).",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "ai-adoption-rollout",
+    "ai-usage-policy",
+    "ai-usage-report",
+    "ai-use-case-triage",
+    "strategy-analysis",
+    "tech-comparison-matrix"
+  ],
+  "tags": [
+    "ai-adoption",
+    "readiness",
+    "maturity-assessment",
+    "governance",
+    "change-management",
+    "baseline"
+  ],
+  "model": {
+    "tier": "standard",
+    "rationale": "Scores six fixed dimensions against a rubric and ranks gaps by blocking order. Bounded structured judgment, not adversarial reasoning; escalate via ambiguous-input when the evidence is thin or contested."
+  }
+}

package/skills/ai-usage-policy/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: ai-usage-policy
+description: Draft an organisation's AI acceptable-use policy — three data-sensitivity tiers with what may be put into a tool at each, permitted and prohibited uses stated as behaviours, a human-review matrix keyed to consequence, an approved-tool list with an exception route, and a named owner per rule. Use when a team needs rules for what people may put into AI tools, or asks for an AI acceptable-use or governance policy. Do NOT use to write a repo's agent-tooling policy (that's agents-md-generator) or to analyse one agent's capability surface (that's agent-threat-model).
+---
+
+# ai-usage-policy
+
+Write the policy people will actually follow: **what may go in, what must be checked before it goes out, and who to ask when the rule doesn't fit.** The audience is every employee, not the security team — so it reads as rules for a job, not controls for an auditor.
+
+A policy that prohibits without offering a permitted path doesn't reduce risk; it moves the same work onto personal accounts where nobody can see it. Every prohibition here carries an alternative.
+
+## How to respond
+
+1. **Establish scope and the regulatory floor.** Which population, which tools, and any regime already binding (sector rules, customer contracts, an existing data-classification scheme). If the organisation already classifies data, **reuse those tier names** rather than inventing a parallel scheme — two classification systems means neither is followed. Cap clarifying questions at 2.
+
+2. **Define three data tiers and what may enter a tool at each.** Three, because five is not memorable and one is not a policy:
+
+   | Tier | Examples | Rule |
+   |---|---|---|
+   | **Open** | public docs, published marketing, open-source code | any approved tool |
+   | **Internal** | internal docs, non-personal telemetry, private repo code | approved tools with data-retention off / enterprise terms |
+   | **Restricted** | personal data, credentials, customer content under contract, regulated records | never pasted; only via a named reviewed integration, if at all |
+
+   Give each tier **two concrete examples from this organisation's actual work** — abstract tiers are the reason policies get ignored.
+
+3. **State permitted and prohibited uses as behaviours.** ✅ "Drafting a first version of a customer email, then editing before sending." ❌ "Inappropriate use." Every prohibition names the **permitted alternative**: "Do not paste customer records to summarise them — use the approved integration, which does the same thing without the data leaving."
+
+4. **Build the human-review matrix on consequence, not on technology.** What must a human check before an AI-assisted output is acted on? Key it to blast radius: reaches a customer · commits money or a legal position · changes production · informs a personnel decision. Each row says who reviews and what "reviewed" means. Low-consequence internal drafting needs no gate — say so, or the policy loses credibility everywhere else.
+
+5. **List approved tools, and give an exception route.** Named tools with the tier they're cleared to. Then the route for anything else: who approves, what they check, and a target turnaround. **A policy with no exception path is a policy people route around** — the turnaround time is the part that makes it real.
+
+6. **Name an owner per section, a review date, and the disclosure rule.** Owners as roles. A review date, because tool terms change. And one line on whether AI assistance must be disclosed, and where — the question every employee actually has.
+
+## Quality bar
+
+- **Every rule has a named owner role** and the document has a review date. An unowned policy is a document, not a control.
+- **Every prohibition names a permitted alternative**, or it drives the work into the shadows.
+- **Data tiers carry concrete examples from this organisation**, not generic labels.
+- **The review matrix is keyed to consequence, not to tool or model.** Model names age out in months; consequences don't.
+- **There is an exception route with a turnaround time.**
+- **Written for the whole staff.** If a non-technical reader hits an unexplained term, rewrite it — the audience is everyone, and unread rules govern nothing.
+- **No invented regulation.** Cite only regimes the user named; where applicability is unclear, mark `[confirm with counsel]` rather than asserting a legal position.
+
+## When to use this skill
+
+- ✅ "What are people allowed to put into these tools?" — the question every rollout hits in week one.
+- ✅ Standing up governance before or alongside an AI rollout.
+- ✅ Replacing an informal "be sensible" norm with something reviewable.
+
+## When NOT to use this skill
+
+- ❌ Writing a repository's agent-tooling policy (`AGENTS.md` — build commands, conventions, what agents may edit) — that's `agents-md-generator`.
+- ❌ Threat-modelling one agent's data reach and exfiltration paths — that's `agent-threat-model`.
+- ❌ Planning how the tool reaches people — that's [`ai-adoption-rollout`](../ai-adoption-rollout/SKILL.md).
+- ❌ Assessing whether governance is mature enough yet — that's [`ai-readiness-assessment`](../ai-readiness-assessment/SKILL.md).
+- ❌ A security review of a design — that's `threat-model`.
+
+## Anti-patterns to avoid
+
+- ❌ **Prohibition without an alternative.** "Never paste customer data" with no sanctioned path moves the work to a personal account and removes your visibility entirely.
+- ❌ **Naming models and versions in the rules.** They change quarterly; consequence-based rules survive. Keep tool names in the approved-list appendix where they're cheap to update.
+- ❌ **Five or more tiers.** Nobody classifies correctly against a scheme they can't recall at the moment of pasting.
+- ❌ **Writing for auditors.** A policy in control language gets filed, not followed. Plain rules for a working day.
+- ❌ **No exception route.** Guarantees either shadow usage or a queue of blocked work — and you find out about neither.
+- ❌ **Requiring review of everything.** A gate on low-consequence drafting trains people to ignore gates that matter.
+
+**Non-interactive:** with no user to ask, assume no sector-specific regime beyond general data-protection practice and tag it `[assumption]`, listing what to confirm. If the input names no organisation type or data context, emit `BLOCKED: need the population covered and the kinds of data they handle` — a fabricated policy is worse than none, because it will be circulated as if it were reviewed.

package/skills/ai-usage-policy/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write our AI acceptable-use policy",
+    "should_trigger": true
+  },
+  {
+    "query": "What are people allowed to put into these AI tools?",
+    "should_trigger": true
+  },
+  {
+    "query": "We need AI governance rules before we roll this out",
+    "should_trigger": true
+  },
+  {
+    "query": "Draft data-handling tiers for AI tool usage",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate the AGENTS.md for this repository",
+    "should_trigger": false
+  },
+  {
+    "query": "Threat model our agent's data access and exfiltration paths",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan the rollout cohorts and enablement",
+    "should_trigger": false
+  },
+  {
+    "query": "Assess whether our governance is mature enough",
+    "should_trigger": false
+  }
+]

package/skills/ai-usage-policy/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "ai-usage-policy",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write an AI acceptable-use policy for our 500-person company. We handle customer support data including names and order history, and people are already pasting things into chatbots.",
+      "assertions": [
+        "Exactly three data tiers are defined, each with concrete examples drawn from the organisation described",
+        "Permitted and prohibited uses are stated as behaviours, not abstractions like 'inappropriate use'",
+        "Every prohibition names a permitted alternative path for the same work",
+        "The human-review matrix is keyed to consequence (customer-facing, financial, production, personnel) rather than to tool or model names",
+        "An approved-tool list is accompanied by an exception route with an approver and a turnaround time",
+        "Every section names an owner role and the document carries a review date",
+        "The disclosure rule states whether and where AI assistance must be declared",
+        "No regulation is asserted beyond what the prompt names; unclear applicability is marked [confirm with counsel]"
+      ]
+    }
+  ]
+}

package/skills/ai-usage-policy/manifest.json

@@ -0,0 +1,33 @@
+{
+  "name": "ai-usage-policy",
+  "version": "0.1.0",
+  "description": "Draft an organisation's AI acceptable-use policy — three data-sensitivity tiers with what may be put into a tool at each, permitted and prohibited uses stated as behaviours, a human-review matrix keyed to consequence, an approved-tool list with an exception route, and a named owner per rule. Use when a team needs rules for what people may put into AI tools, or asks for an AI acceptable-use or governance policy. Do NOT use to write a repo's agent-tooling policy (that's agents-md-generator) or to analyse one agent's capability surface (that's agent-threat-model).",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "agent-threat-model",
+    "agents-md-generator",
+    "ai-adoption-rollout",
+    "ai-readiness-assessment",
+    "threat-model"
+  ],
+  "tags": [
+    "ai-adoption",
+    "governance",
+    "acceptable-use",
+    "policy",
+    "data-classification",
+    "compliance"
+  ],
+  "model": {
+    "tier": "standard",
+    "rationale": "Drafts a policy document against a fixed structure (tiers, behaviours, review matrix, exception route). Bounded generation; escalate via ambiguous-input where a regulatory regime is named or contested."
+  }
+}

package/skills/ai-use-case-triage/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: ai-use-case-triage
+description: Turn a pile of candidate AI use cases into a ranked portfolio — each scored on value, feasibility, and risk with the weights shown, a recommended first slice that can prove or kill the thesis, and an explicit not-yet list with the condition that would promote each entry. Use when a team has more AI ideas than capacity and needs to choose, or asks "where should we actually start with AI". Do NOT use to assess whether the organisation is ready at all (that's ai-readiness-assessment) or to price a single decision (that's business-case).
+---
+
+# ai-use-case-triage
+
+Most AI adoption stalls not from lack of ideas but from too many, all sounding equally promising. This produces a **ranked portfolio with rejections**: what to do first, what to hold, and the condition that would move a held item onto the list.
+
+A triage that promotes everything has triaged nothing. The not-yet list is the deliverable's spine.
+
+## How to respond
+
+1. **Inventory the candidates.** From whatever the user brought — a brainstorm, a backlog, interview notes. Each candidate is stated as **a workflow and a person**, not a technology: ✅ "Support agents drafting first-response replies" — ❌ "Use LLMs in support." If a candidate is a technology looking for a job, say so and either recast it or drop it.
+
+2. **Score each on three axes, 1–5, and show the weights.** Default weights: **value 40 · feasibility 35 · risk 25**. State them, and restate them if the user's context justifies different ones (a regulated environment legitimately weights risk higher). Hidden weights make a ranking an opinion.
+   - **Value** — time recovered, quality lifted, or revenue/cost moved. Quantify where the input allows; mark `directional` where it doesn't. Never invent a number.
+   - **Feasibility** — is the input data reachable, is the output checkable, does the workflow already have a review step? A task whose output nobody can verify is not feasible, however easy the prompt.
+   - **Risk** — blast radius if the output is wrong and someone acts on it. Score the *consequence*, not the technology's reputation.
+
+3. **Rank, then sanity-check the top.** The highest score wins only if its **failure is survivable and visible**. A high-value, high-risk item where a wrong answer reaches a customer unreviewed is not a first slice, whatever the arithmetic says — demote it and say why.
+
+4. **Name the first slice, and what it proves.** One use case, with the observable that would confirm or kill the thesis and a time box. ✅ "Draft first-response replies for the top 3 ticket categories; the thesis dies if agents edit more than half the draft body after 4 weeks." A first slice with no kill condition is a pilot that runs forever.
+
+5. **Write the not-yet list with promotion conditions.** Every rejected candidate gets one line saying what would change the answer — "when the knowledge base is deduplicated", "when a human review step exists in the workflow". A rejection with no condition reads as a permanent no and gets re-litigated next quarter.
+
+6. **Hand off.** The first slice's economics → `business-case`; how success will be measured → `success-metrics`; how it reaches people → [`ai-adoption-rollout`](../ai-adoption-rollout/SKILL.md); whether the output can be evaluated at all → `llm-eval-harness`.
+
+## Quality bar
+
+- **The weights are shown and justified in one line.** A ranking with hidden weights is an opinion wearing a table.
+- **Every score has a one-line reason.** A bare 4 is not a judgement anyone can challenge.
+- **The not-yet list is non-empty**, and every entry carries a promotion condition. If nothing was rejected, the triage didn't happen.
+- **Each candidate names a workflow and a person**, not a technology.
+- **The first slice has a kill condition** with an observable and a time box.
+- **Unknown numbers are marked `directional`**, never invented — a fabricated ROI figure poisons every decision downstream.
+
+## When to use this skill
+
+- ✅ More AI ideas than capacity, and the team needs a defensible order.
+- ✅ "Where should we start with AI?" from a leader who has heard a dozen pitches.
+- ✅ Re-triaging a stalled portfolio where three pilots are half-running.
+
+## When NOT to use this skill
+
+- ❌ Assessing whether the organisation can adopt anything yet — that's [`ai-readiness-assessment`](../ai-readiness-assessment/SKILL.md).
+- ❌ Pricing one option properly (build vs buy, Option 0, cost layers) — that's `business-case`.
+- ❌ Planning the human rollout of a chosen use case — that's [`ai-adoption-rollout`](../ai-adoption-rollout/SKILL.md).
+- ❌ Writing requirements for the thing you picked — that's `prd-draft`.
+
+## Anti-patterns to avoid
+
+- ❌ **A portfolio with no rejections.** Ranking ten ideas 1–10 and calling it a roadmap is capacity denial, not triage.
+- ❌ **Scoring the technology instead of the workflow.** "RAG: 5/5" is not a use case. The unit is a person doing a job.
+- ❌ **Invented value numbers.** A confident "$400k/yr saved" with no source is the single fastest way to lose a room that includes a finance lead.
+- ❌ **Ignoring verifiability.** Feasibility is not "can a model produce this?" — it is "can someone tell whether it's right, before it matters?"
+- ❌ **A first slice that can't fail.** If no observable would kill it, it isn't a pilot; it's a commitment with a pilot's label.
+
+**Non-interactive:** with no user to ask, use the default weights and tag them `[assumption]`. If the input contains no candidate use cases — only a general request to "use AI" — emit `BLOCKED: need at least three candidate workflows to triage` rather than inventing a portfolio.

package/skills/ai-use-case-triage/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Which AI use cases should we do first?",
+    "should_trigger": true
+  },
+  {
+    "query": "Rank these AI ideas by value and feasibility",
+    "should_trigger": true
+  },
+  {
+    "query": "We have more AI ideas than capacity — help us choose",
+    "should_trigger": true
+  },
+  {
+    "query": "Where should we actually start with AI?",
+    "should_trigger": true
+  },
+  {
+    "query": "Are we ready to adopt AI at all?",
+    "should_trigger": false
+  },
+  {
+    "query": "Build the business case for this one investment",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the PRD for the feature we picked",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan the rollout to our support team",
+    "should_trigger": false
+  }
+]

package/skills/ai-use-case-triage/evals/evals.json

@@ -0,0 +1,18 @@
+{
+  "skill_name": "ai-use-case-triage",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Our support org has five AI ideas: draft first replies, auto-tag tickets, summarise call recordings, generate KB articles, and predict churn from ticket sentiment. Where do we start?",
+      "assertions": [
+        "Each candidate is restated as a workflow and a person, not a technology",
+        "Every candidate is scored on value, feasibility, and risk with the weights shown and justified",
+        "Every score carries a one-line reason",
+        "The not-yet list is non-empty and each entry names the condition that would promote it",
+        "The recommended first slice names an observable kill condition and a time box",
+        "Feasibility reasoning addresses whether the output can be verified before it matters",
+        "Value figures absent from the input are marked directional rather than invented"
+      ]
+    }
+  ]
+}

package/skills/ai-use-case-triage/manifest.json

@@ -0,0 +1,34 @@
+{
+  "name": "ai-use-case-triage",
+  "version": "0.1.0",
+  "description": "Turn a pile of candidate AI use cases into a ranked portfolio — each scored on value, feasibility, and risk with the weights shown, a recommended first slice that can prove or kill the thesis, and an explicit not-yet list with the condition that would promote each entry. Use when a team has more AI ideas than capacity and needs to choose, or asks \"where should we actually start with AI\". Do NOT use to assess whether the organisation is ready at all (that's ai-readiness-assessment) or to price a single decision (that's business-case).",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "ai-adoption-rollout",
+    "ai-readiness-assessment",
+    "business-case",
+    "llm-eval-harness",
+    "prd-draft",
+    "success-metrics"
+  ],
+  "tags": [
+    "ai-adoption",
+    "prioritization",
+    "use-cases",
+    "portfolio",
+    "value-vs-feasibility",
+    "pilot"
+  ],
+  "model": {
+    "tier": "standard",
+    "rationale": "Scores candidates on weighted axes and forces a rejection list. Structured comparison with stated weights; escalate via ambiguous-input when candidates are numerous or the value data is contested."
+  }
+}

package/skills/api-contract-draft/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Draft the OpenAPI spec for this API",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the REST contract for these endpoints",
+    "should_trigger": true
+  },
+  {
+    "query": "I need an API contract with a proper error catalog and pagination decided",
+    "should_trigger": true
+  },
+  {
+    "query": "Turn this user story into an OpenAPI 3.1 definition",
+    "should_trigger": true
+  },
+  {
+    "query": "Define the contract for this Kafka topic our team publishes",
+    "should_trigger": false
+  },
+  {
+    "query": "Design the Postgres schema and indexes for this feature",
+    "should_trigger": false
+  },
+  {
+    "query": "What latency and availability targets should this service have?",
+    "should_trigger": false
+  },
+  {
+    "query": "Review this API implementation for security bugs",
+    "should_trigger": false
+  }
+]

package/skills/api-contract-draft/evals/evals.json

@@ -0,0 +1,18 @@
+{
+  "skill_name": "api-contract-draft",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Draft the OpenAPI contract for our orders API — clients need to create an order, fetch one, and list a customer's orders.",
+      "assertions": [
+        "The emitted YAML is parseable OpenAPI 3.1 and every $ref resolves",
+        "Paths are resource-oriented rather than RPC-style verbs in the URL",
+        "Every operation enumerates its 4xx set with stable machine-switchable code values — not a bare '400: Bad Request'",
+        "Errors follow RFC 9457 problem-details shape",
+        "Pagination, idempotency, and versioning are each decided explicitly rather than deferred",
+        "Every operation carries at least one example",
+        "Each decision in the log has a rationale, and any deviation from the skill's conventions is logged rather than made silently"
+      ]
+    }
+  ]
+}

package/skills/architecture-diagrams/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Draw an architecture diagram for this system",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate a Mermaid diagram of these services",
+    "should_trigger": true
+  },
+  {
+    "query": "Create a C4 container diagram from this description",
+    "should_trigger": true
+  },
+  {
+    "query": "Diagram the sequence flow I just described",
+    "should_trigger": true
+  },
+  {
+    "query": "Reverse-engineer the architecture from our Terraform and repo",
+    "should_trigger": false
+  },
+  {
+    "query": "Read the frames in our Figma file",
+    "should_trigger": false
+  },
+  {
+    "query": "Threat model this design",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the design doc for this system",
+    "should_trigger": false
+  }
+]

package/skills/architecture-diagrams/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "architecture-diagrams",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Draw the architecture for a checkout service: an API gateway, an orders service, a payments service calling Stripe, and a Postgres primary with a read replica.",
+      "assertions": [
+        "The diagram fits on one screen; beyond roughly 15 nodes it is split into separate Context and Container diagrams rather than crammed",
+        "Arrows show direction of data flow, not undirected connections",
+        "Every arrow crossing a trust boundary is labelled",
+        "The diagram is generated from the written description provided — no components are invented beyond it",
+        "A named format is produced (Mermaid, PlantUML, or C4) and renders as valid syntax"
+      ]
+    }
+  ]
+}

package/skills/audience-profile/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Who is my audience and what rules should the deck follow?",
+    "should_trigger": true
+  },
+  {
+    "query": "What are the structural rules for presenting to a board versus engineers?",
+    "should_trigger": true
+  },
+  {
+    "query": "Profile this audience so I know how technical to go",
+    "should_trigger": true
+  },
+  {
+    "query": "We have a mixed exec and technical room — how should I pitch it?",
+    "should_trigger": true
+  },
+  {
+    "query": "Build the PowerPoint for the board meeting",
+    "should_trigger": false
+  },
+  {
+    "query": "Outline the slides for this deck",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the one-page executive summary",
+    "should_trigger": false
+  },
+  {
+    "query": "Map the customer's journey through our product",
+    "should_trigger": false
+  }
+]

package/skills/audience-profile/evals/evals.json

@@ -0,0 +1,15 @@
+{
+  "skill_name": "audience-profile",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're presenting our platform strategy to a mixed room — the board plus two engineering leads. What audience rules should we design to?",
+      "assertions": [
+        "Output is concrete and structural (slide count ranges, density, tone, must-have sections, things to avoid) rather than advice like 'keep it short'",
+        "A mixed audience resolves to the least-technical archetype, with the more-technical material moved to an appendix",
+        "No new archetype is invented for a one-off case — the closest existing one is chosen and the divergence noted",
+        "The profile is reusable across deliverables rather than being a deck or summary itself"
+      ]
+    }
+  ]
+}

package/skills/brief-intake/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Turn this Slack thread into a structured brief",
+    "should_trigger": true
+  },
+  {
+    "query": "I have a messy transcript — get it into shape for the design-doc skill",
+    "should_trigger": true
+  },
+  {
+    "query": "Structure this raw context into a brief before I run the next skill",
+    "should_trigger": true
+  },
+  {
+    "query": "Take this half-written Notion page and extract a clean brief",
+    "should_trigger": true
+  },
+  {
+    "query": "Extract the decisions, owners, and due dates from this discussion",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the ADR itself from this context",
+    "should_trigger": false
+  },
+  {
+    "query": "Critique this brief's quality",
+    "should_trigger": false
+  },
+  {
+    "query": "Summarize this thread for the executive team",
+    "should_trigger": false
+  }
+]

package/skills/brief-intake/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "brief-intake",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Here's a messy Slack thread about our caching problem — turn it into a brief I can hand to design-doc.",
+      "assertions": [
+        "Extracted fields marked [explicit] or [implied] carry a short verbatim snippet from the source so nothing is hallucinated",
+        "Relative dates are converted to absolute YYYY-MM-DD, marked implied where computed",
+        "Gaps are named as missing rather than filled in with plausible invention",
+        "The output names the downstream skill the brief is shaped for",
+        "The brief is structured into the fields that downstream skill needs, not a summary"
+      ]
+    }
+  ]
+}

package/skills/bug-triage/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Turn this vague bug report into an actionable ticket",
+    "should_trigger": true
+  },
+  {
+    "query": "A customer says it's broken on mobile sometimes — triage it",
+    "should_trigger": true
+  },
+  {
+    "query": "Write up this Slack complaint as a proper bug with repro steps",
+    "should_trigger": true
+  },
+  {
+    "query": "Triage and prioritize this support ticket",
+    "should_trigger": true
+  },
+  {
+    "query": "Review this diff for bugs and edge cases",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the blameless postmortem for the outage",
+    "should_trigger": false
+  },
+  {
+    "query": "Split this epic into user stories",
+    "should_trigger": false
+  },
+  {
+    "query": "Write a test plan for this release",
+    "should_trigger": false
+  }
+]