skilldrop-cli 0.16.5 → 0.16.7

package/README.md

@@ -33,6 +33,7 @@ Install one pack. Every role pack also brings `core` (intake, critique, review c
 - **Governance, risk and compliance:** `grc` — DPIAs, SOC 2 evidence maps, risk registers, security questionnaire answers. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/grc/)
 - **Infrastructure as code:** `infra-as-code` — Terraform modules with secure defaults, and plan reviews before apply. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/infra-as-code/)
 - **Writing agent skills:** `skill-engineering` — author a portable skill with evals, and review one before it ships. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/skill-engineering/)
+- **Applying for a job:** `career` — an honest fit check against the posting, a tailored resume and a cover letter that claim nothing you didn't. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/career/)
 - **Everyone:** `core` on its own. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/core/)
 
 ## Start in one command
@@ -54,7 +55,7 @@ In Claude Code you can use the plugin marketplace instead: run `/plugin marketpl
 ## How it works
 
 - **A skill produces one file you own.** Each ships a quality bar, named anti-patterns and acceptance evals, so the output is an artifact, not a conversation. See [every skill, by category](guides/reference/skill-catalogue.md).
-- **Loops order skills, and a gate decides when work moves on.** Five loops cover the lifecycle (`discover`, `design`, `build`, `release`, `operate`), plus the `ship-a-draft` wrapper for any document. Each gate is a script, a review panel or a person, chosen by how expensive the mistake is to undo. See [the loops, stage by stage](guides/reference/loops.md) and [why loops](guides/explanation/loops.md).
+- **Loops order skills, and a gate decides when work moves on.** Five loops cover the lifecycle (`discover`, `design`, `build`, `release`, `operate`), plus the `ship-a-draft` wrapper for any document and `apply` for a job application. Each gate is a script, a review panel or a person, chosen by how expensive the mistake is to undo. See [the loops, stage by stage](guides/reference/loops.md) and [why loops](guides/explanation/loops.md).
 - **Measured, not asserted.** `run_bench.py` runs each acceptance eval with the skill and without it, in a sandbox, and reports the lift, a blind preference from two judges, and the cost per run. The results are published whether or not they flatter the skills. See [how skills are checked](https://sananthanarayan.github.io/skilldrop/evals/) and [RFC-0040](docs/rfcs/0040-skill-benchmark.md).
 - **Copy, never transform.** A skill is a plain `SKILL.md` folder in the [Agent Skills](https://agentskills.io) format, at `packs/<pack>/skills/<name>/`. What runs in your agent is byte-identical to what is reviewed here. There is no runtime, and the tooling has zero dependencies.
 - **Updates keep your edits.** `npx skilldrop-cli update` replaces files you haven't touched. For any file you changed, it leaves the new version beside it as `<file>.upstream`. See [upgrade installed skills](guides/how-to/upgrade-skills.md).

package/catalogue.json

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0034. The catalogue index: pack display order and the outcome browse axis (RFC-0026). Pack metadata lives in packs/<pack>/pack.json; membership is the folders — a skill is in a pack because it sits at packs/<pack>/skills/<name>/.",
   "version": "1.0.0",
-  "packs": ["core", "solution-architect", "product-manager", "dev-team", "sre-oncall", "stakeholder-comms", "design", "ai-engineering", "api-builder", "converters", "experience-design", "research", "trackers", "data-analytics", "grc", "infra-as-code", "skill-engineering"],
+  "packs": ["core", "solution-architect", "product-manager", "dev-team", "sre-oncall", "stakeholder-comms", "design", "ai-engineering", "api-builder", "converters", "experience-design", "research", "trackers", "data-analytics", "grc", "infra-as-code", "skill-engineering", "career"],
   "outcomes": {
     "decide-what-to-build": {
       "for": "Product managers · founders · strategists",
@@ -185,6 +185,15 @@
         "skill-author",
         "skill-review"
       ]
+    },
+    "apply-for-a-job": {
+      "for": "Anyone applying for a job, in any field",
+      "description": "Prepare one application that is tailored and true: an honest fit check against the posting, a resume reworked without adding a claim, and a cover letter built only from what you supplied.",
+      "skills": [
+        "job-fit-analysis",
+        "resume-tailor",
+        "cover-letter"
+      ]
     }
   }
 }

package/model-routing.json

@@ -481,6 +481,18 @@
     "ux-writing": {
       "tier": "standard",
       "rationale": "Short-form writing to fixed slot rules and character budgets, plus a terminology consistency pass. Bounded generation with clear checks."
+    },
+    "job-fit-analysis": {
+      "tier": "standard",
+      "rationale": "Matches a posting's requirements to resume lines and reports the gaps. The rule is mechanical: no line in the resume, no credit."
+    },
+    "resume-tailor": {
+      "tier": "standard",
+      "rationale": "Reorders and rewords existing content against a posting, with a script listing every figure and name the original doesn't contain."
+    },
+    "cover-letter": {
+      "tier": "standard",
+      "rationale": "A short letter from supplied facts, with a script listing every figure and name the person's material doesn't contain."
     }
   }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "skilldrop-cli",
-  "version": "0.16.5",
+  "version": "0.16.7",
   "description": "Portable AI-agent skills, measured against the agent without them. ADRs, PRDs, runbooks, decks and reviews, installable into Claude Code, Cursor, Kiro, and any IDE that takes custom instructions. One command per skill or per role-based pack.",
   "author": {
     "name": "Sanjay Ananthanarayan",

package/packs/ai-engineering/skills/agent-adoption-stage/SKILL.md

@@ -23,6 +23,14 @@ The load-bearing idea: **the bottleneck moves.** Each stage is limited by someth
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Say what a stage means in a plain sentence the first time you use it. Don't describe as the team's stated pain something they didn't say, and don't put target dates or head-counts on the plan unless they gave them.
+
 1. **Place the team on exactly one stage, from observables.** Ask for (or extract) three things: how many agents a typical engineer has in flight, who writes most of the code now, and what gets reviewed — every diff, final diffs, or exceptions. Quote the evidence. **A range is a refusal** — pick the stage the team is *operating at*, not the best day it ever had. Cap clarifying questions at 2.
 
 2. **Discount aspiration.** A team that bought licences for 200 people and has three power users is at stage 1 with an outlier, not stage 2. Place on the median engineer, and say so when the distribution is lopsided — the spread is itself a finding.

package/packs/ai-engineering/skills/agent-adoption-stage/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-adoption-stage",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Place an engineering team on the agentic-coding adoption ladder (0 gated → 4 intent-steered) using observables like agents-in-flight per engineer and who writes the code, name the one bottleneck gating the next step, prescribe the single next unlock, and state which current guardrail must change. Use when a leader asks \"how far along are we with coding agents\", \"why has our AI adoption plateaued\", or \"what do we do next to get more out of this\". Do NOT use to assess organisational preconditions like data, policy, and culture (that's ai-readiness-assessment) or to plan a tool's human rollout (that's ai-adoption-rollout).",
   "entrypoint": "SKILL.md",
   "deps": {

package/packs/ai-engineering/skills/agent-loop-design/SKILL.md

@@ -9,6 +9,14 @@ You shouldn't be prompting agents; you should be designing the loops that prompt
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Describe the loop for the user's task in concrete terms: what triggers it, what each stage produces, what checks it, and where a person approves. Caps and budgets use the user's numbers; without them, give the cap as a choice for them to make.
+
 1. **Pin the loop's job and its "done".** Ask at most 2 questions, spent on: *"what artifact does one successful run produce?"* and *"how would a human verify it's right without watching the run?"* The done-condition must be **observable** — tests pass, checklist satisfied, reviewer-agent returns zero blockers — never "output looks good". No observable done-condition derivable → the task isn't loop-ready; say what needs defining first. Non-interactive run (no user to ask): derive both from the input and tag `[assumption]`; no artifact derivable → emit `BLOCKED: need the task and its done-condition`.
 
 2. **Draw the state machine — generate, verify, gate, and nothing mushier.**

package/packs/ai-engineering/skills/agent-loop-design/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-loop-design",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Design a supervised agent loop — the generate→verify→gate cycle, observable exit criteria, hard iteration cap, human gates at irreversible steps, and failure routes — as a loop spec a team can implement in any agent harness. Use when the user wants to automate a recurring task with an AI agent loop, design a work loop / review loop / research loop, or asks \"how do I stop my agent from running forever or shipping junk\".",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/ai-engineering/skills/ai-readiness-assessment/SKILL.md

@@ -11,6 +11,14 @@ Readiness assessments fail in one of two ways: a number with no evidence behind
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Open with the verdict (ready, not yet, or not ready) and the two or three things to do first. The scorecard follows. Leave a dimension unscored when there is no evidence for it, and name no owner the user didn't name.
+
 1. **Establish scope and the decision it feeds.** Whose readiness — one team, a function, the whole company? And what happens with the answer (a go/no-go, a budget request, a sequencing decision)? Scope changes what counts as evidence. Cap clarifying questions at 2.
 
 2. **Score the six dimensions.** These are fixed — do not invent new ones for a single engagement, and do not drop one because it's awkward to assess. Score each **0–4** (0 absent · 1 ad hoc · 2 repeatable · 3 managed · 4 optimised):

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

@@ -1,6 +1,6 @@
 {
   "name": "ai-readiness-assessment",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "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": {

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

@@ -11,6 +11,14 @@ A policy that prohibits without offering a permitted path doesn't reduce risk; i
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** A usable policy says what to do when the rule has already been broken (data already pasted into a tool) and how it is enforced; include both. Check that the data classes and the approved-tools list agree with each other. Make no claim about where a tool sends data unless the user told you.
+
 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:

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

@@ -14,6 +14,36 @@
         "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]"
       ]
+    },
+    {
+      "id": 2,
+      "held_out": "2026-10-05",
+      "prompt": "I'm the office manager at a 40-person recruitment agency and the MD has asked me to write our AI policy. Her email is in md-email.md, what our IT provider told me is in it-notes.md, and our existing data labels are in data-handling-sheet.md. Can you draft the policy so I can send it to her?",
+      "assertions": [
+        "It says candidate CVs, salary details and other Confidential data must not go into personal or free chatbot accounts, and tells staff what to do instead for the same task",
+        "It separates the 8-seat ChatGPT Team workspace from personal ChatGPT accounts, and notes that about 30 people have no Team seat",
+        "Copilot is not listed as an approved or available tool: the trial ended on 30 June 2026 and was not renewed",
+        "It does not state that the tools never train on the firm's data or that data stays in the UK; it says this is unconfirmed until someone checks the contract terms",
+        "It does not simply make Brightwell IT the policy owner: it notes Brightwell declined to make policy decisions and the operations manager post is vacant, and proposes an interim owner or flags ownership for the MD to decide",
+        "It says candidate data for Aldercroft Group roles must not go into any AI tool without Aldercroft's written consent",
+        "It says what to do about the 14 CVs pasted on 16 September and tells staff who to report it to if they have already pasted Confidential data",
+        "It names no law or regulation other than GDPR, which the MD mentioned, and NoteQuill is treated as unapproved or pending review, not as cleared"
+      ]
+    },
+    {
+      "id": 3,
+      "held_out": "2026-10-05",
+      "prompt": "we're a small charity, 12 staff plus volunteers. the trustees want an 'AI policy' by the next board meeting. honestly I don't know what tools people are using, I think a couple of them use chatgpt for grant applications. we hold case notes on the people we support. can you write something short I can take to the board",
+      "assertions": [
+        "It delivers a draft policy in the reply and does not stop at a list of questions",
+        "It says case notes and anything that identifies a person the charity supports must not be put into AI chatbots, and says what to do instead",
+        "Drafting grant applications with AI is allowed, with a person checking the facts and figures before the application is submitted",
+        "It says whether the policy covers volunteers as well as the 12 staff",
+        "It says which tools are in use is not known, and proposes finding out or leaves the approved-tool list to be filled in; it does not present a list of approved tools as already agreed",
+        "It names no individual and no charity name; responsibilities are given to roles (for example a named trustee role or the director) or flagged for the board to assign",
+        "It does not state that a specific law, regulator or sector code applies as fact; any mention is marked as something to confirm",
+        "The policy itself is short: about two pages or less (roughly 800 words)"
+      ]
     }
   ]
 }

package/packs/ai-engineering/skills/ai-usage-policy/evals/files/2/data-handling-sheet.md

@@ -0,0 +1,18 @@
+# Larkfield Talent: data handling sheet (v3, January 2025)
+
+Three labels. Everything the firm holds is one of these.
+
+| Label | What it covers | Examples |
+|---|---|---|
+| **Public** | Anything already published | Job adverts, the website, published salary guides |
+| **Internal** | Day-to-day business information that is not about an identifiable person | Internal process docs, anonymised placement statistics, fee templates |
+| **Confidential** | Anything about an identifiable candidate or client contact, and anything a client contract restricts | Candidate CVs, salary and notice details, interview notes, client contracts, call recordings |
+
+## Client-specific terms
+
+**Aldercroft Group** (master services agreement, clause 9.3): candidate data relating to
+Aldercroft roles must not be passed to any third-party processor without Aldercroft's prior
+written consent.
+
+No other client contract has a clause like this as far as we know. Nobody has checked since
+2025.

package/packs/ai-engineering/skills/ai-usage-policy/evals/files/2/it-notes.md

@@ -0,0 +1,31 @@
+# Notes from Brightwell IT (outsourced provider, on site Thursdays)
+
+Sent by Petra Lindqvist, Brightwell IT, 30 September 2026, in reply to Wendell's questions.
+
+## Tools we know about
+
+| Tool | Status | Detail |
+|---|---|---|
+| ChatGPT Team | Active | 8 seats, bought March 2026. Assigned to the directors and the marketing team. |
+| ChatGPT free / personal accounts | In use, not managed | We see sign-ins from most consultant laptops. We reckon about 30 people. Personal email logins, nothing we control. |
+| Microsoft Copilot | Not active | 10-seat trial. It ended on 30 June 2026 and was not renewed. |
+| NoteQuill (call transcription) | In use, not managed | Browser extension. 6 consultants have it installed. Nobody bought it centrally. We have not looked at its terms. |
+
+## Things you asked
+
+**Do the tools train on our data / where is it stored?** We have not reviewed the terms for
+any of these and can't confirm either way. Somebody would need to read the contract for the
+Team plan. For the personal accounts and NoteQuill we have nothing.
+
+**Can Brightwell own the policy?** No. We keep the laptops and accounts running. We don't
+make policy decisions for clients and we are only with you one day a week. We can enforce
+whatever you decide (blocking sites, removing extensions) if you tell us what.
+
+**Who did this before?** The operations manager, but that post has been empty since
+Farida left in August.
+
+## The incident
+
+On 16 September a consultant pasted 14 candidate CVs into a personal ChatGPT account to
+get one-paragraph summaries for a client shortlist. We found out because he mentioned it.
+Nothing has been done about it since.

package/packs/ai-engineering/skills/ai-usage-policy/evals/files/2/md-email.md

@@ -0,0 +1,29 @@
+From: Corinne Ashby (Managing Director)
+To: Wendell Okafor (Office Manager)
+Date: 28 September 2026
+Subject: AI rules, need something written down
+
+Wendell,
+
+After the thing with Tobias I want an actual policy for AI tools that I can send to all
+40 of us. Short enough that people read it.
+
+Where I think we are:
+
+- ChatGPT is approved. We have a Team licence.
+- We have Copilot as well.
+- The transcription thing the consultants use on client calls, I don't know what it's
+  called.
+
+Things I want it to say:
+
+- Our tools never train on our data and everything stays in the UK. Clients ask about this
+  and I want to be able to point at the policy.
+- What people can and can't put in. Candidate CVs are the obvious one. GDPR obviously
+  applies to us.
+- What we do about the CVs Tobias already pasted in.
+- IT will own it.
+
+Use the labels from the data handling sheet, I don't want a second scheme.
+
+Corinne

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

@@ -1,6 +1,6 @@
 {
   "name": "ai-usage-policy",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "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": {

package/packs/ai-engineering/skills/llm-eval-harness/SKILL.md

@@ -9,6 +9,14 @@ Builds the measurement that turns "the new prompt feels better" into "the new pr
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Use all the data the user already has, such as logged questions, before proposing to label new data. Don't call a check deterministic when it reads free text.
+
 1. **Pin the task and the unit of judgment.** What does the feature do (classify / extract / summarize / answer-with-RAG / agentic-multi-step), and **what does one gradeable output look like**? Ask at most 2 questions, spent on the failure that hurts most ("what's a wrong answer that would actually cause a problem?") and whether ground truth exists. The answer-that-hurts shapes the adversarial cases and the critical subset.
 
 2. **Build the golden set with three deliberate buckets** (case format in [`templates/`](templates/)):

package/packs/ai-engineering/skills/llm-eval-harness/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "llm-eval-harness",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Design an evaluation harness for an LLM-powered feature — a versioned golden set (representative + adversarial + regression cases), the cheapest adequate grading method per case, a metric with a pre-set pass bar and regression gate, and a failure taxonomy that targets iteration. Use when the user is building or tuning an LLM feature (prompt, RAG, agent, classifier) and needs evals, a way to test prompt/model changes, or to stop shipping quality regressions on vibes.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/ai-engineering/skills/subagent-design/SKILL.md

@@ -9,6 +9,14 @@ Produces an **orchestration plan**: which subagents exist, what each one alone i
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** A yes-or-no question gets yes or no and the reason in two or three sentences. A design names what each agent checks, with what tools, and what the final report contains. Budget numbers come from the user or are left out.
+
 1. **Justify the fan-out or refuse it.** Exactly three reasons earn multiple agents — name which applies, or recommend a single agent and stop:
    - **Context separation**: the task spans more material than one context holds well, and it partitions cleanly (per-module audit, per-source research).
    - **Independence**: judgments must not contaminate each other — reviewers, estimators, hypothesis-testers whose value is that they haven't seen each other's answers.

package/packs/ai-engineering/skills/subagent-design/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "subagent-design",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Decompose a task into an orchestrator and subagents — one-mission role cards with typed output contracts, a topology (pipeline / parallel / judge panel) chosen with a reason, context-isolation rationale, and a verification stage that is never a generator. Use when the user wants to fan work out across multiple agents, design a multi-agent workflow or orchestration, or asks \"should this be one agent or several\".",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/api-builder/skills/eval-harness-generator/SKILL.md

@@ -9,6 +9,14 @@ Reads a SKILL.md and generates eval cases that cover the skill's happy path, edg
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Read the skill you were asked to cover before saying anything is missing: look in the working directory and in the request. Write the eval files, and make sure each requirement the skill states has a case.
+
 ### Step 1 — Read the skill
 
 Ask the user to paste the full SKILL.md. Extract:

package/packs/api-builder/skills/eval-harness-generator/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "eval-harness-generator",
-  "version": "1.0.1",
+  "version": "1.0.2",
   "description": "Takes a skill's SKILL.md and generates a set of eval cases — trigger queries, expected output shape, and pass/fail criteria — ready to drop into the skill's evals/ directory. Use when adding evals to a new or existing skill, verifying a skill behaves as documented, or building a regression gate before modifying a skill.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/api-builder/skills/tool-use-schema-writer/SKILL.md

@@ -9,6 +9,14 @@ Converts a natural-language function description into a valid Anthropic `tool_us
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Deliver the tool definition that was asked for. Encode every range, format, enum and default the source states, and add no behaviour the source doesn't state. No usage example unless asked.
+
 ### Step 1 — Intake
 
 Ask the user to describe the function. Collect:

package/packs/api-builder/skills/tool-use-schema-writer/evals/evals.json

@@ -13,6 +13,35 @@
         "Includes a Python snippet passing the tool to client.messages.create(tools=[...]) and handling stop_reason == 'tool_use'",
         "Does not invent parameters, enum values, or behaviors not in the supplied signature and docstring"
       ]
+    },
+    {
+      "id": 2,
+      "held_out": "2026-10-05",
+      "prompt": "Need a Claude tool definition for bookAppointment (it's in book_appointment.ts) so our front-desk assistant can book visits for callers. Ideally the same tool lets it cancel a booking too.",
+      "assertions": [
+        "It produces a tool definition with a name, a description and an input_schema of type object, and ctx / RequestContext is not one of the properties",
+        "The top-level required array contains the clinic code, visit type, start time and contact, and does not contain duration, vet id or notes",
+        "The pet id is not unconditionally required: the definition or reply states it is needed for every visit type except new_patient and must be left out for new_patient",
+        "contact is a nested object with its own required array containing phone, with email and SMS reminders optional",
+        "It flags that the comment says bookings can be made up to 90 days ahead while the code enforces 60, and does not state 90 days as the limit",
+        "Duration is limited to 15, 30 or 45 with a default of 30, and the definition states that dental visits need 45 minutes",
+        "It says cancelling is not supported by this function and does not add a cancel parameter, action or mode to the tool",
+        "It does not list six clinic codes as an enum or as fact, since the source gives only the example PVG-03"
+      ]
+    },
+    {
+      "id": 3,
+      "held_out": "2026-10-05",
+      "prompt": "need tool defs for our support agent, two things: look up a shipment by tracking number, and get a shipping quote. quote needs origin zip, dest zip, weight (lbs) and service level - we have ground, 2-day and overnight i think? Dario would know for sure. dimensions are optional on the quote. no idea yet what the lookup gives back, that endpoint's still being built",
+      "assertions": [
+        "It delivers two tool definitions, each with a name, a description and an input_schema, and does not stop at questions",
+        "The quote tool's required array includes origin zip, destination zip and weight, and dimensions is not in it",
+        "The weight parameter's description states the unit is pounds",
+        "Service level offers ground, 2-day and overnight, and the reply says that list is unconfirmed and should be checked",
+        "Each tool's description says when the agent should call it, so a tracking question and a pricing question map to different tools",
+        "It does not state a tracking number format or pattern, a weight limit, carrier names or a dimension unit as fact",
+        "It does not describe the lookup's return fields as fact, and says what the lookup returns is not yet known"
+      ]
     }
   ]
 }

package/packs/api-builder/skills/tool-use-schema-writer/evals/files/2/book_appointment.ts

@@ -0,0 +1,64 @@
+// scheduling/book_appointment.ts — Pawline Veterinary Group
+import { RequestContext, ValidationError } from "../lib/http";
+import { daysAhead, isQuarterHour, slots } from "./slots";
+
+const MAX_ADVANCE_DAYS = 60;
+const ALLOWED_DURATIONS = [15, 30, 45];
+
+export type VisitType = "new_patient" | "checkup" | "vaccination" | "dental";
+
+export interface OwnerContact {
+  phone: string;           // E.164, e.g. +14155550123
+  email?: string;
+  smsReminders?: boolean;  // default true
+}
+
+export interface BookAppointmentInput {
+  clinicCode: string;        // one of our six clinic codes, e.g. "PVG-03"
+  visitType: VisitType;
+  petId?: string;            // existing patient id: "pet_" followed by 8 characters
+  startTime: string;         // ISO 8601 with UTC offset, on a 15-minute boundary
+  durationMinutes?: number;  // default 30
+  vetId?: string;            // omit to get the first available vet
+  contact: OwnerContact;
+  notes?: string;            // shown to the vet, max 500 characters
+}
+
+/**
+ * Books an appointment slot at one clinic. Appointments can be booked up to
+ * 90 days ahead. Returns the confirmation code and the assigned vet.
+ *
+ * Booking only. Rescheduling and cancelling are handled by the front desk
+ * for now; there is no endpoint for either yet.
+ */
+export async function bookAppointment(input: BookAppointmentInput, ctx: RequestContext) {
+  const duration = input.durationMinutes ?? 30;
+
+  if (input.visitType !== "new_patient" && !input.petId) {
+    throw new ValidationError("petId is required for existing patients");
+  }
+  if (input.visitType === "new_patient" && input.petId) {
+    throw new ValidationError("new_patient visits must not carry a petId");
+  }
+  if (!ALLOWED_DURATIONS.includes(duration)) {
+    throw new ValidationError("durationMinutes must be 15, 30 or 45");
+  }
+  if (input.visitType === "dental" && duration < 45) {
+    throw new ValidationError("dental visits need 45 minutes");
+  }
+  if (!isQuarterHour(input.startTime)) {
+    throw new ValidationError("startTime must be on a 15-minute boundary");
+  }
+  if (daysAhead(input.startTime) < 0) {
+    throw new ValidationError("startTime is in the past");
+  }
+  if (daysAhead(input.startTime) > MAX_ADVANCE_DAYS) {
+    throw new ValidationError("startTime is too far ahead");
+  }
+  if (input.notes && input.notes.length > 500) {
+    throw new ValidationError("notes is limited to 500 characters");
+  }
+
+  const slot = await slots.reserve({ ...input, durationMinutes: duration }, ctx.staffUserId);
+  return { confirmationCode: slot.code, vetId: slot.vetId, startTime: slot.startTime };
+}

package/packs/api-builder/skills/tool-use-schema-writer/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "tool-use-schema-writer",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "description": "Takes a function description (name, purpose, parameters) and writes a valid Anthropic tool_use JSON schema, with type annotations, required fields, and a description for each parameter. Produces a Python usage snippet for client.messages.create(tools=[...]). Use when wiring a Claude agent to a function or API, designing tools for a multi-agent system, or documenting an existing tool for agent consumption.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/career/loops/apply/LOOP.md

@@ -0,0 +1,88 @@
+---
+name: apply
+description: Take one job posting and one resume to an application ready to send — an honest fit check, a tailored resume and a cover letter — with the candidate deciding whether to apply before any writing, and confirming every claim is true before anything is sent. Use when the user wants to apply for a job, says "help me apply for this", or wants a resume and cover letter prepared for one posting.
+---
+
+# apply
+
+One application, start to send, for any job. It opens with a gate because the cheapest
+application is the one you decide not to write, and it closes with one because the candidate
+signs these documents and answers for them at interview. Both gates are **human**: an agent
+can say what the resume shows, but only the candidate knows what is true and what they want.
+
+## Stages
+
+| # | Stage | Type | Skills | Gate |
+|---|---|---|---|---|
+| 1 | `fit` | gate | [`job-fit-analysis`](../../skills/job-fit-analysis/SKILL.md) | **G5** human |
+| 2 | `tailor` | generate | [`resume-tailor`](../../skills/resume-tailor/SKILL.md) | — |
+| 3 | `letter` | generate | [`cover-letter`](../../skills/cover-letter/SKILL.md) | — |
+| 4 | `confirm` | verify | [`output-hygiene`](../../../core/skills/output-hygiene/SKILL.md) | **G6** human |
+
+## How to run this loop
+
+1. **Check the fit and stop.** Run `job-fit-analysis` on the posting and the resume. Put its
+   verdict, the screening requirements and its questions to the candidate, then wait at G5.
+   - `PROCEED`: they are applying. Go on.
+   - `PROCEED WITH CONDITIONS`: they are applying and have answered the questions. Save
+     their answers to `notes.md`; from here on those answers are source material alongside
+     the resume.
+   - `RECONSIDER`: they are not applying. The loop ends here, and that is a good outcome.
+2. **Tailor the resume.** Run `resume-tailor` with the resume, the posting and `notes.md`
+   if it exists. Carry its "Not claimed" list forward.
+3. **Write the letter.** Run `cover-letter` with the tailored resume, the posting, `notes.md`
+   and the candidate's reason for wanting the job if they gave one. Skip this stage when the
+   posting says not to send a letter.
+4. **Clean both documents.** Run `output-hygiene` on the resume and the letter.
+5. **Confirm at G6.** Show the candidate both documents with two short lists: what the
+   posting asks for that neither document claims, and anything the claim check still lists.
+   Ask them to confirm every line is true. `NOT READY` returns to `tailor` with their
+   corrections added to `notes.md`. The candidate sends the application; the loop never does.
+
+## Verdicts
+
+Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G5 emits
+`PROCEED`, `PROCEED WITH CONDITIONS`, `RECONSIDER` or `BLOCKED`. G6 emits `READY`,
+`NOT READY` or `BLOCKED`. `RECONSIDER` leaves the loop: the candidate's time goes to a
+better posting.
+
+## Non-interactive runs
+
+With no person present, neither gate can be satisfied. Run `fit`, deliver the analysis and
+emit `BLOCKED: need the candidate's decision to apply`. Do not decide for them, and do not
+produce documents carrying their name that they have not confirmed.
+
+## When a stage's skill is not installed
+
+Name the missing skill and skilldrop as its source, do the minimal inline version of that
+stage under the same rule (nothing the candidate didn't supply), and record that it ran
+degraded. Never skip G6.
+
+## Run log (opt-in)
+
+Only when the environment variable `SKILLDROP_LOOP_LOG` is set to a file path: after each
+gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is
+sent anywhere. When the variable isn't set, or you can't read it, skip this section.
+
+```bash
+printf '%s\n' '{"ts":"2026-10-05T14:03:00Z","loop":"apply","stage":"fit","gate":"G5","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"
+```
+
+Fields: `ts` (UTC), `loop`, `stage`, `gate` (`null` for a stage without one), `verdict` (the
+gate's exact word), and `round` (1 for the first attempt, counting returns under the cap).
+The log holds verdicts only: never the posting, the resume or the candidate's name.
+
+## Quality bar
+
+- **The candidate decides to apply before anything is written.** A tailored resume for a job they would have skipped is wasted work.
+- **Every claim in both documents traces to the resume or to something the candidate said.** Answers given at G5 are written to `notes.md`, so the trace exists.
+- **The resume and the letter agree.** Same titles, dates and numbers in both.
+- **The candidate confirms and sends.** G6 is their signature; the loop never submits an application.
+
+## Anti-patterns to avoid
+
+- ❌ **Skipping `fit` because the candidate is keen.** The screening requirements are what they most need to see before investing the time.
+- ❌ **Treating a `Not shown` item as true** because the candidate proceeded. Only what they answered goes in.
+- ❌ **Writing the letter from the original resume.** The letter follows the tailored one, or the two will disagree.
+- ❌ **Self-confirming at G6.** A clean claim check says the words are in the source; it cannot say they are true.
+- ❌ **Submitting the application.** Sending is the candidate's act.

package/packs/career/loops/apply/evals/eval_queries.json

@@ -0,0 +1,9 @@
+[
+  {"query": "help me apply for this job", "should_trigger": true},
+  {"query": "run the apply loop on this posting and my resume", "should_trigger": true},
+  {"query": "I want a tailored resume and cover letter for this role", "should_trigger": true},
+  {"query": "get my application for this job ready to send", "should_trigger": true},
+  {"query": "is this job a good fit for me?", "should_trigger": false},
+  {"query": "just write a cover letter for this", "should_trigger": false},
+  {"query": "turn these notes into a finished document", "should_trigger": false}
+]