skilldrop-cli 1.3.0 → 1.5.0

package/packs/ai-engineering/skills/subagent-design/examples/help-center-localization.md

@@ -0,0 +1,146 @@
+# Worked example: a seven-agent localization plan that grades its own work
+
+Input → output oracle for `subagent-design`. Shows a fan-out that is justified but drawn
+wrong: a translator that checks itself, a middle layer with no job, a summary agent standing
+in for a merge, and auto-publishing. It also shows the one barrier the work actually needs.
+
+## Input
+
+> We're localizing our help center with AI agents. My team lead drew up the plan below. Is
+> this the right setup? Our docs lead has to sign off, so keep it short.
+>
+> **Plan:**
+> 1. A Coordinator agent spawns three Language Leads (de, fr, ja).
+> 2. Each Language Lead spawns one Translator agent per article. The Translator translates
+>    the article, then reviews its own translation against the glossary and fixes anything it
+>    finds.
+> 3. When all 960 translations are done, a Summary agent reads them all and writes a report of
+>    quality issues for the docs lead.
+> 4. The Coordinator publishes everything to the help center.
+> 5. We want 7+ agents because more agents run faster.
+>
+> **Facts:**
+> - 320 English articles, about 1,500 words each, into three languages.
+> - A glossary of 410 product terms with an approved translation per language. Style rule: UI
+>   labels stay in English.
+> - Pilot of 40 articles into Japanese: the Translator's self-review marked all 40 "pass". Our
+>   Japanese linguist found 11 with UI labels translated, and 4 where the same term was
+>   translated two different ways in different articles.
+> - Today a linguist per language approves each article before it goes live.
+
+## Output
+
+**Not as drawn. Splitting the work per article is right, but four parts of the plan need to
+change.** Keep one translation job per article and language. A separate agent should check
+each translation instead of the translator checking itself. Code should build the report, not
+a summary agent. Drop the Language Lead layer. And nothing goes live without the linguist,
+who stays the final approval. That leaves two agent roles, each run once per article and
+language, plus code around them. The pilot is the reason: the translator passed its own work
+40 times out of 40, and the linguist found problems in at least 11 of those articles.
+
+Assumed: each article can be translated on its own, given the glossary.
+
+# Orchestration plan: help-center localization (320 articles × de, fr, ja)
+
+> Fan-out justification: **context separation**, because about 480,000 words of source won't
+> fit one context well and each article stands alone. **Role conflict** for checking, because
+> the agent that wrote a translation can't honestly grade it, as the 40/40 pilot showed.
+> Speed comes with the per-article split. It is not a reason on its own.
+
+## Role cards
+
+### orchestrator (code, not an agent)
+- **Mission:** Move each article-language pair through translation, checking and the linguist queue.
+- **Inputs:** article list, glossary, UI-label rule
+- **Denied (isolation):** it doesn't judge translation quality. It acts only on the fields each step returns
+- **Output contract:** `{ article_id: string, lang: "de"|"fr"|"ja", status: "translated"|"checked"|"flagged"|"invalid"|"queued_for_linguist" }[]`
+- **Tools/permissions:** read source articles, write to the linguist's review queue. **No publish permission**
+- **On failure:** marks the item `invalid` with the reason and carries on with the rest
+- **Model:** none needed: routing and merging are code
+
+### translator ×960
+- **Mission:** Translate one article into one language using the glossary.
+- **Inputs:** one source article, that language's glossary, the UI-label rule
+- **Denied (isolation):** other articles' translations, so each job stays small. Consistency across articles comes from the glossary and the term check below
+- **Output contract:** `{ article_id: string, lang: string, body: string, terms: [{ source: string, target: string, in_glossary: bool }], status: "ok"|"blocked", blocked_reason: string|null }`
+- **Tools/permissions:** none beyond its inputs. No write access anywhere
+- **On failure:** `status: "blocked"` with a reason. It never sends a partial translation as `ok`
+- **Model:** mid-size: translating with a fixed glossary doesn't need the largest model
+
+### checker ×960
+- **Mission:** Find every place the translation departs from the source, the glossary or the UI-label rule.
+- **Inputs:** source article, translated `body`, glossary, UI-label rule
+- **Denied (isolation):** the translator's `terms` list and status, so it checks the text instead of confirming the translator's claims about it
+- **Output contract:** `{ article_id: string, lang: string, verdict: "pass"|"fail"|"blocked", findings: [{ type: "glossary"|"ui_label"|"meaning"|"omission", source_excerpt: string, target_excerpt: string, expected: string }] }`
+- **Tools/permissions:** read-only
+- **On failure:** `verdict: "blocked"`, handled exactly like `fail`. It is never counted as a pass
+- **Model:** mid-size: a different agent from the translator, which is what makes the check independent
+
+## Topology
+
+**Shape:** a pipeline per article (translate, then check), **because** no article's
+translation depends on another's. **One barrier per language**, **because** the pilot's 4
+inconsistent terms only show up across articles. Code groups every translator's `terms` by
+source term and flags any term with more than one translation. That check needs all of a
+language's articles, and nothing else in the plan does.
+**Depth:** one level. The Language Leads would only pass articles along, and the orchestrator
+already does that.
+
+```mermaid
+flowchart LR
+    O[orchestrator] --> T["translator ×960"]
+    T --> C["checker ×960"]
+    T -. terms .-> X{"term check per language"}
+    C --> X
+    X --> L["linguist approval"]
+    L -->|approved| P[help center]
+    T -->|invalid output| F[failure list]
+    C -->|invalid output| F
+```
+
+## Aggregation & verification
+
+- **Aggregation:** code. The term check groups by `(lang, source term)`. The report for the
+  docs lead is counts of `findings` by type and language, plus the list of `fail` and
+  `invalid` articles. Output that doesn't match its schema goes to the failure list and never
+  into the report.
+- **Verification:** the checker's job is to find faults, and it never sees the translator's
+  own assessment. A failed article goes to the linguist with its findings attached.
+- **Vote rule:** a single checker. An article is flagged if it has any finding. The linguist's
+  approval gates publishing, as it does today.
+
+## Budget line
+
+No spending cap was given, so none is set here. Model sizes are on each card.
+
+**Left out of the plan:** the Coordinator publishing everything. Every article still goes
+through linguist approval before it goes live. The pilot shows why: the self-check missed all
+11 UI-label errors.
+
+**To confirm**
+- The spending cap for a full run.
+- Whether source articles mark UI labels in a way code can detect. If they do, that check
+  can move from the checker to code.
+- Who reworks a failed article: the linguist, or a second translation pass with the findings.
+
+Next step: design the run around this, meaning retries, the stop conditions and what happens
+when the cap is hit, before the first full batch.
+
+## Why this is the oracle
+
+- **The verifier is separate and adversarial, never the generator.** The plan's step 2 has
+  the translator check itself, and the pilot's 40/40 self-pass is the evidence that this
+  fails. The checker is denied the translator's own claims, so it can't just agree with them.
+- **Aggregation is code, and a barrier needs a named dependency across items.** The summary
+  agent becomes a group-by over typed `findings`. The plan's "when all 960 are done"
+  synchronisation shrinks to one barrier per language, earned by cross-article term
+  consistency, the 4 inconsistent terms no per-article check can see.
+- **Fan out only for a named reason, keep depth to one level, and take budget numbers only
+  from the user.** "More agents run faster" is rejected as a reason. The Language Lead layer
+  is cut. No cap is invented, and auto-publishing is removed and named as removed.
+
+A cheaper pass approves the seven-agent plan and tunes the prompts. It keeps self-review,
+lets a summary agent paraphrase 960 translations, and leaves the Coordinator publishing. That
+ships the pilot's UI-label errors across three languages straight to the live help center. The
+opposite cheap answer, "use one agent", fails too: 480,000 words don't fit one context, and it
+leaves the role conflict in place.

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

@@ -1,11 +1,11 @@
 {
   "name": "subagent-design",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "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": [] },
   "env": { "required": [], "optional": [] },
   "related": ["agent-budget", "agent-loop-design", "council-review", "devils-advocate", "feature-implement-loop"],
   "tags": ["subagents", "orchestration", "multi-agent", "fan-out", "agentic", "role-cards"],
-  "model": { "tier": "standard", "rationale": "Design synthesis against a fixed topology catalog and role-card template. The fan-out-or-refuse judgment is bounded by the three-reasons rule; escalate via ambiguous-input on genuinely novel workflow shapes." }
+  "model": { "tier": "heavy", "rationale": "Measured (RFC-0073): on its held-out evals the heavy tier met 100% and 100% of checks in two tier trials, against standard's 86% and light's 85% and 86%, more than 5 points ahead both times; moved once its examples/ oracle shipped (RFC-0074)." }
 }

package/packs/api-builder/skills/prompt-caching-advisor/SKILL.md

@@ -75,6 +75,10 @@ Produce:
 1. **Annotated structure** — show the messages array with `cache_control` placements marked and commented
 2. **Cache strategy summary** — one paragraph: what is cached, why, expected hit rate, and the dominant cost driver before and after
 
+## Useful references in this skill
+
+- [`examples/support-bot-block-order.md`](examples/support-bot-block-order.md) — worked example: a breakpoint under the minimum size and a per-customer block splitting a shared cache, fixed by reordering
+
 ## Anti-patterns
 
 - **Caching dynamic content.** If a user query, timestamp, or per-request database result is inside a cached block, every request is a cache miss — the structure defeats itself. Identify and flag before recommending.

package/packs/api-builder/skills/prompt-caching-advisor/examples/support-bot-block-order.md

@@ -0,0 +1,120 @@
+# Worked example: a cache breakpoint that "didn't move the bill"
+
+Input → output oracle for `prompt-caching-advisor`. Shows a breakpoint that never caches
+because its prefix is under the minimum size, a per-customer block that splits a shared cache
+in two, and the fix as a reordering, not an extra marker.
+
+## Input
+
+> Our support bot runs on Haiku. We added `cache_control` to the instructions block because
+> that's the static part, and the input bill didn't move. Should we add another one on the
+> catalogue? Numbers: about 150,000 requests a day, conversations average 6 turns with a turn
+> every 1–2 minutes, busy all day and quiet overnight. The catalogue is rebuilt once a night
+> at 02:00.
+
+```python
+def build_request(customer, session, question):
+    system = [
+        {"type": "text", "text": INSTRUCTIONS,                # ~3,200 characters
+         "cache_control": {"type": "ephemeral"}},
+        {"type": "text", "text": render_profile(customer)},   # ~1,400 characters, per customer
+        {"type": "text", "text": load_catalogue()},           # ~62,000 characters
+    ]
+    messages = session.history + [{"role": "user", "content": question}]
+    return {"model": MODEL, "max_tokens": 800, "system": system, "messages": messages}
+```
+
+## Output
+
+**Don't add a second marker yet. Fix the order first.** Two things are wrong, and a marker on
+the catalogue in its current position would only fix half of it.
+
+1. **Your current breakpoint caches nothing.** A breakpoint caches the whole prefix up to and
+   including its block. Here that is the instructions alone: 3,200 characters, or about 800
+   tokens. Haiku's minimum is about 1,024 tokens, so the API processes it as normal input,
+   with no error and no saving. That is why the bill didn't move.
+2. **The customer profile sits in front of the catalogue.** The profile differs for every
+   customer, so any breakpoint after it makes a separate cache entry per customer. A marker
+   on the catalogue where it sits now would cache instructions + profile + catalogue together.
+   It would hit only on later turns of the same conversation, and every customer's first turn
+   would pay to write 16,600 tokens to the cache.
+
+Move the catalogue above the profile, put one breakpoint at the end of the catalogue, and put
+a second, moving breakpoint on the latest user turn.
+
+### Annotated structure
+
+| Block | Size (~4 chars/token) | Class | Cached by |
+|---|---|---|---|
+| Instructions | 3,200 ch ≈ 800 tok | Static | BP1 (as part of its prefix) |
+| Catalogue | 62,000 ch ≈ 15,500 tok | Static until the 02:00 rebuild | BP1 |
+| Customer profile | 1,400 ch ≈ 350 tok | Quasi-static (per conversation) | BP2 |
+| Earlier turns | grows each turn | Fixed once sent | BP2 |
+| Latest question | varies | Dynamic | written by BP2 for the *next* turn to read |
+
+```python
+def build_request(customer, session, question):
+    system = [
+        # Static. ~800 tokens: under Haiku's ~1,024 minimum, so no marker of its own.
+        # It is still cached, because BP1's prefix includes it.
+        {"type": "text", "text": INSTRUCTIONS},
+        # Static until the 02:00 rebuild. ~15,500 tokens.
+        {"type": "text", "text": load_catalogue(),
+         "cache_control": {"type": "ephemeral"}},   # BP1: instructions + catalogue, ~16,300 tokens,
+                                                    # identical for every customer
+        # Quasi-static: the same for a whole conversation, different per customer.
+        # It sits after BP1 so it can't split the shared entry.
+        {"type": "text", "text": render_profile(customer)},
+    ]
+    latest = {
+        "role": "user",
+        "content": [{"type": "text", "text": question,
+                     "cache_control": {"type": "ephemeral"}}],  # BP2: profile + all earlier turns + this one
+    }
+    # session.history stores turns WITHOUT cache_control. If the marker is saved into history,
+    # markers pile up turn after turn, and from turn 4 the request carries more than the API's
+    # limit of four breakpoints.
+    messages = session.history + [latest]
+    return {"model": MODEL, "max_tokens": 800, "system": system, "messages": messages}
+```
+
+BP2 is not caching dynamic content. It writes the conversation so far, so that the next turn,
+where this question is now fixed history, can read it. Nothing that changes between requests
+sits in front of BP1, and that is the prefix every customer shares.
+
+Two breakpoints, one per logical boundary: content shared by everyone, then content shared
+within a conversation. A third marker on the instructions would add nothing, because they are
+under the minimum and already inside BP1's prefix.
+
+### Cache strategy summary
+
+BP1 caches the instructions and catalogue, about 16,300 tokens, as one entry shared by every
+customer. At about 150,000 requests a day it stays warm all through the busy hours, so its hit
+rate is near 100%. It misses on the first request after the 02:00 rebuild and after any
+overnight gap longer than the cache's five-minute lifetime. BP2 caches each conversation's
+profile and earlier turns. With turns 1–2 minutes apart, turns 2–6 read it, about 5 of 6
+requests. Before the change, about 16,600 tokens of instructions, profile and catalogue were
+processed at full price on every request, roughly 2.5 billion input tokens a day. After it,
+almost all of that is a cache read, billed at about a tenth of the normal input price. The
+largest costs left are output tokens and each turn's new question. This answer gives no dollar
+figure: the request didn't include prices, and the hit rates above are estimates until the
+response `usage` fields (`cache_read_input_tokens`, `cache_creation_input_tokens`) confirm
+them.
+
+## Why this is the oracle
+
+- **The last block caches everything before it.** The user's mental model, "mark the static
+  block", is per block. A breakpoint marks a prefix. That one rule explains why the
+  instructions marker did nothing (its prefix is 800 tokens) and why a catalogue marker in
+  the current order would be keyed per customer (its prefix includes the profile).
+- **Check the size before recommending a cache.** The fix removes the user's existing marker,
+  because it is under Haiku's minimum. The instructions still get cached, inside BP1.
+- **Never let dynamic or per-user content split a shared prefix.** The profile is not dynamic
+  per request, but it is per customer. Moving it below BP1 turns a per-conversation cache into
+  a shared one. The comment on `session.history` heads off the four-breakpoint error that a
+  moving breakpoint causes when it is stored.
+
+A cheaper pass answers the question as asked: "Yes, add `cache_control` to the catalogue
+block." That gives each conversation a cache entry of its own, a premium cache write on every
+first turn, and a bill that drops far less than expected. The team blames caching, and the
+dead instructions marker stays in the code.

package/packs/api-builder/skills/prompt-caching-advisor/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "prompt-caching-advisor",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "description": "Analyzes a prompt or conversation structure and identifies the highest-value cache breakpoints — where to insert cache_control checkpoints to minimize repeated token processing. Use when designing or optimizing a Claude API integration that uses prompt caching, when input costs are dominated by a static system prompt or few-shot block, or when a multi-turn conversation reprocesses the same context on every turn.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
   "related": ["token-budget-estimator"],
   "tags": ["claude-api", "caching", "cost", "optimization", "prompt-engineering"],
-  "model": { "tier": "standard", "rationale": "Structural analysis of a prompt with threshold arithmetic and pattern matching — above light (needs API-specific judgment), no need for heavy." }
+  "model": { "tier": "heavy", "rationale": "Measured (RFC-0073): on its held-out evals the heavy tier met 90% and 90% of checks in two tier trials, against standard's 63% and light's 83% and 73%, more than 5 points ahead both times; moved once its examples/ oracle shipped (RFC-0074)." }
 }

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

@@ -1,11 +1,11 @@
 {
   "name": "tool-use-schema-writer",
-  "version": "1.0.2",
+  "version": "1.0.3",
   "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. Adds a Python client.messages.create(tools=[...]) snippet only when asked. 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": [] },
   "env": { "required": [], "optional": [] },
   "related": ["agent-loop-design", "subagent-design"],
   "tags": ["claude-api", "tool-use", "json-schema", "sdk", "agents"],
-  "model": { "tier": "standard", "rationale": "Schema generation from a natural-language description — structured output task that fits standard tier." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 94% and 94% of checks in two tier trials, against standard's 96% and heavy's 97% and 97%, within 5 points of the best both times." }
 }

package/packs/career/skills/application-form-answers/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "application-form-answers",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Prepare the answers to a job application form from the person's resume: each question in the form's own order with either a drafted answer and the resume line behind it, or a note that it is theirs alone to answer (right to work, sponsorship, salary, declarations, monitoring questions), plus the questions that could screen the application out and the ones their resume already bears on. Works for any occupation. Use when the user says \"help me fill in this application form\", \"answer these application questions\", \"what do I put for these screening questions\", or pastes the questions from an online job application.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -25,7 +25,7 @@
     "job-search"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Sorts questions into three kinds and drafts short answers from the resume. The hard rule is mechanical: a declaration is never answered for the person."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 88% and 94% of checks in two tier trials, against standard's 88% and heavy's 81% and 81%, within 5 points of the best both times."
   }
 }

package/packs/career/skills/cover-letter/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "cover-letter",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Write a cover letter for one job from the person's resume and the posting: under a page, opening on the strongest evidence for the role, two or three specifics matched to what the employer asked for, and no enthusiasm, company facts or experience the person didn't supply. A script lists every figure and name in the letter that their own material doesn't contain. Works for any occupation and level. Use when the user says \"write a cover letter for this job\", \"draft a covering letter\", \"write the cover note for my application\", or needs an application email to go with a resume.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -31,7 +31,7 @@
     "notes": "Reads the draft, source and posting files it is given. Writes nothing."
   },
   "model": {
-    "tier": "standard",
-    "rationale": "A short letter from supplied facts, with a script listing every figure and name the person's material doesn't contain."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 100% and 100% of checks in two tier trials, against standard's 100% and heavy's 100% and 100%, within 5 points of the best both times."
   }
 }

package/packs/career/skills/resume-tailor/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "resume-tailor",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Tailor a resume or CV to one job posting without adding anything that isn't true: reorder, cut and reword what the person has already done so the posting's needs are answered first, keep every employer, title, date and number as it was, and report what the posting asks for that the resume cannot claim. A script lists every figure and name in the draft that the original doesn't contain. Works for any occupation and level. Use when the user says \"tailor my resume for this job\", \"adapt my CV to this posting\", \"rewrite my resume for this role\", or pastes a job description next to their resume.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -31,7 +31,7 @@
     "notes": "Reads the draft, source and posting files it is given. Writes nothing."
   },
   "model": {
-    "tier": "standard",
-    "rationale": "Reorders and rewords existing content against a posting, with a script listing every figure and name the original doesn't contain."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 100% and 100% of checks in two tier trials, against standard's 100% and heavy's 100% and 100%, within 5 points of the best both times."
   }
 }

package/packs/converters/skills/md-to-docx/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "md-to-docx",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "Turn a Markdown draft into a Word document (.docx) that someone outside engineering can open, edit and track changes in, with real Heading styles so the navigation pane and table of contents work, live hyperlinks, numbered and bulleted lists, tables, code blocks, embedded images and optional brand fonts and colours, and a warning for everything that could not be carried over. Use when the user wants a Markdown file as a Word doc, says \"send this as a .docx\", \"convert to Word\", \"legal needs it in Word\", or \"make this editable for the client\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -39,7 +39,7 @@
   ],
   "permissions": {"network": [], "commands": [], "files": "named-paths"},
   "model": {
-    "tier": "standard",
-    "rationale": "A stdlib script does the conversion; the model restructures the Markdown so it converts cleanly (heading levels, footnotes, HTML), reads each warning and explains the losses. Bounded editing, no open-ended generation."
+    "tier": "heavy",
+    "rationale": "Measured (RFC-0073): on its held-out evals the heavy tier met 79% and 93% of checks in two tier trials, against standard's 64% and light's 71% and 79%, more than 5 points ahead both times."
   }
 }

package/packs/core/loops/ship-a-draft/evals/evals.json

@@ -20,6 +20,34 @@
         "Explains that re-drafting from the same incomplete brief reproduces the same gaps",
         "Does not run output-hygiene on a draft that is about to be rewritten"
       ]
+    },
+    {
+      "id": "ship-a-draft-adr-from-thread",
+      "held_out": "2026-11-04",
+      "prompt": "Can you turn this Slack thread (slack-thread.txt) into a proper ADR for moving the nightly statements job? It goes to the architecture review group on Thursday and I want it finished and ready to send, not a first draft I have to fix up.",
+      "assertions": [
+        "Produces a structured intake brief from the thread before drafting, and the ADR is written from that brief",
+        "The month-end queue capacity question Marta raised is carried into the brief and the ADR as open or a risk, not as settled",
+        "The ADR records option B as the decision, option A as rejected because it does not fix the 3h40m runtime, and option C as rejected for lack of approved budget, and keeps the unchanged statement file format and idempotent retries as requirements",
+        "After drafting, the ADR is critiqued with findings tied to sections and a G5 verdict in the critique's own terms (such as SHIP IT, SHIP WITH CHANGES or MAJOR REWRITE)",
+        "Any changes the critique calls for are made before the polish pass, and the polish pass runs last, on the revised ADR",
+        "The final ADR carries none of the thread's machine residue: no 'Generated with ExampleAI' or 'Summarised by ExampleBot' line and no 'Hope this helps' closer",
+        "Does not invent figures, dates or owners not in the thread, such as a queue capacity number, a migration date or a deadline for Marta's check"
+      ]
+    },
+    {
+      "id": "ship-a-draft-announcement-unsettled",
+      "held_out": "2026-11-04",
+      "prompt": "Need the customer announcement email for scheduled exports, to go to Team plan admins. Everything's in the ticket (ticket-PRD-412.md). Marketing want final copy today so please give me something finished I can just hand over.",
+      "assertions": [
+        "The intake brief, written before any drafting, flags the launch date, the price, and whether SFTP delivery is in as unsettled in the ticket",
+        "The draft leaves those three as clearly marked placeholders or open items instead of picking a value",
+        "The critique gate does not return SHIP IT; its verdict holds the email back (such as SHIP WITH CHANGES or MAJOR REWRITE) and names the unsettled date, price and scope as the reason",
+        "Tells the user plainly that the email is not ready to go to customers, and who in the ticket has to settle each item: Hannah and Oskar on SFTP scope and date, finance (Gwen, after the 10 November pricing committee) on price",
+        "If the polish pass runs, the placeholders survive it, and the reply does not present the email as final copy",
+        "Does not stop to ask questions; the brief, draft and critique are delivered in this run",
+        "Does not invent a launch date, price or feature scope the ticket has not settled, such as stating 12 November, 26 November or $15 a month as fact"
+      ]
     }
   ]
 }

package/packs/core/loops/ship-a-draft/evals/files/ship-a-draft-adr-from-thread/slack-thread.txt

@@ -0,0 +1,47 @@
+#reporting-eng — thread started by Priya Raman, Mon 2 Nov 2026
+
+Priya Raman  10:12
+ok we need to stop pretending the nightly statements job is fine. it failed again on the 22nd. that's twice in October (9th and 22nd), both times because reports-01 got rebooted for patching mid-run and the cron job just died. ~1,900 customers didn't get their statement until we reran it by hand at 10am
+
+Tom Lindqvist  10:15
+and it's getting slower. last night's run was 3h40m. the window is 01:00 to 06:00 UTC because the finance team pulls the statements at 06:30. at the rate customer count is growing we're going to blow the window sometime next year
+
+Marta Szabo  10:21
+options I can see:
+A) keep cron on reports-01, add a second box with a lock so only one runs, plus retry on failure
+B) move it onto the job queue we already run for the email service. one job per customer, workers pick them up, failed ones retry on their own
+C) use the cloud provider's managed scheduler + functions
+
+Tom Lindqvist  10:24
+C is nice but there's no budget approved for it this year, I asked in September and got a no. not worth writing up as anything but rejected
+
+Priya Raman  10:26
+A fixes the reboot problem but not the runtime. it's still one process doing 3h40m of work
+
+Tom Lindqvist  10:30
+B gets us both. per-customer jobs means a reboot only kills the in-flight ones and they get retried, and we can add workers if we're getting close to the window
+
+Marta Szabo  10:33
+I'm fine with B in principle. my worry is month-end. the email service hammers the same queue on the 1st of every month (invoice emails). if statements and invoice emails land on the same night, does the queue keep up? I don't actually know its capacity
+
+Priya Raman  10:35
+can you find out?
+
+Marta Szabo  10:36
+I'll check with platform
+
+Jonas Weber  10:52
+dropping in the AI summary of the thread from the meeting notes bot, in case it helps:
+
+> **Summary:** The team is evaluating three options for the nightly statements job. Option B (job queue) is the leading candidate because it addresses both reliability and runtime. Option C is rejected due to budget. Open question: queue capacity at month-end.
+> Hope this helps! Let me know if you need anything else.
+> — Summarised by ExampleBot · Generated with ExampleAI (notes.example.com)
+
+Priya Raman  11:02
+so B, pending Marta's capacity check. we also need to keep the output the same, finance's import breaks if the statement file format changes. I'll write it up as an ADR for architecture review
+
+Tom Lindqvist  11:04
+👍 one more thing for the ADR: we'd need idempotent jobs, because a retried job must not send the same customer two statements
+
+Priya Raman  11:05
+yep

package/packs/core/loops/ship-a-draft/evals/files/ship-a-draft-announcement-unsettled/ticket-PRD-412.md

@@ -0,0 +1,44 @@
+# PRD-412 — Launch: scheduled exports for Team plan
+
+**Type:** Launch  **Status:** In progress  **Reporter:** Hannah Ito (Product)  **Assignee:** Hannah Ito
+**Labels:** team-plan, exports, launch-q4
+
+## Description
+
+Team plan customers can set up a recurring export (daily, weekly or monthly) of their project data as CSV, delivered by email link or to an SFTP server they own. Replaces the manual "Export all" button that customers currently run by hand.
+
+Top customer asks (from the feedback board):
+- "We export every Monday for our finance team. Please let us schedule it." — 41 upvotes
+- "Need this to land on our SFTP so our BI tool can pick it up" — 17 upvotes
+- "Weekly CSV by email would be enough for us" — 12 upvotes
+
+What's in:
+- Daily / weekly / monthly schedules, choose the time of day
+- CSV format, same columns as today's manual export
+- Delivery by emailed download link (link valid 7 days)
+- Delivery to customer SFTP — see comments
+
+Help-centre article: help.example.com/scheduled-exports (draft, not published)
+
+## Comments
+
+**Hannah Ito (Product)** — 20 Oct
+Target launch Nov 12. Marketing will send the announcement email to Team plan admins on launch day.
+
+**Oskar Brenner (Eng lead)** — 22 Oct
+Nov 12 isn't realistic with SFTP in. Email delivery is done and in QA. SFTP destination still needs key management and the retry logic. If we cut SFTP from v1, earliest is Nov 26. With SFTP, I can't give a date yet.
+
+**Hannah Ito (Product)** — 23 Oct
+SFTP is the thing the bigger customers asked for, I don't want to launch without it. Let's discuss.
+
+**Oskar Brenner (Eng lead)** — 23 Oct
+Fine, but then the date moves. Need a decision from you.
+
+**Hannah Ito (Product)** — 27 Oct
+Pricing proposal: add-on at $15/month per workspace. Sent to finance.
+
+**Gwen Adeyemi (Finance)** — 29 Oct
+Not approved yet. We're also looking at including it in Team at no extra charge as a retention play. Will have an answer after the pricing committee on Nov 10.
+
+**Hannah Ito (Product)** — 3 Nov
+Marketing is asking for final copy for the announcement. Can someone draft it?

package/packs/core/skills/output-hygiene/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "output-hygiene",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite. Use when the user wants to clean up AI-generated output, asks to remove a Claude watermark, attribution footer, or \"Generated with\" line, wants a draft that does not read as machine-written, or needs a pre-ship hygiene pass on a document, commit message, or pasted chat answer.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -28,7 +28,7 @@
   ],
   "permissions": {"network": [], "commands": [], "files": "named-paths", "notes": "Writes only with --fix, which rewrites the files it was given, in place."},
   "model": {
-    "tier": "standard",
-    "rationale": "The mechanical pass is a deterministic script; the model does bounded rewriting of flagged prose against a fixed tell list, not adversarial review."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 100% and 100% of checks in two tier trials, against standard's 92% and heavy's 100% and 92%, within 5 points of the best both times."
   }
 }

package/packs/data-analytics/loops/measure/evals/evals.json

@@ -23,6 +23,36 @@
         "Reviews the changed query again at G9 before returning to sign-off",
         "Counts the return under the cap of 3"
       ]
+    },
+    {
+      "id": "measure-retention-dashboard",
+      "held_out": "2026-11-04",
+      "prompt": "we need a dashboard for the Monday win-back meeting. Anouk's request is in request.md, the queries we use now are in sql/ and the schema's in schema.md. Can you make sure these numbers are right before Sana's team builds it? Postgres.",
+      "assertions": [
+        "Runs the stages in order: the dashboard spec first, then the SQL review, then a sign-off request to the metric owners. Fixes from the review go back into the metric definitions in the spec",
+        "The spec says which decision the dashboard serves (which plan cohorts get this week's win-back offer), gives one chart for each of Anouk's four questions in her order, and leaves page views and app downloads off, saying why",
+        "Catches that net_revenue_by_plan.sql inflates revenue: joining order_items repeats each order total once per line item, and the refunds join repeats it again for orders with more than one refund",
+        "Catches that NOT IN (SELECT subscriber_id FROM subs.test_accounts) returns no rows because test_accounts.subscriber_id can be NULL. Gives a NOT EXISTS (or equivalent) fix",
+        "Catches the integer division in weekly_churn_rate.sql (cancelled / active_start), which rounds churn down to 0 for nearly every week. Gives corrected SQL",
+        "Flags that date_trunc('week', ...) on UTC timestamps does not match the Monday-to-Sunday UK-time week Anouk asked for, and gives a fix that sets the time zone to Europe/London",
+        "Asks the named owners to sign off each metric definition (Anouk for churn and active subscribers, Callum Reyes for net revenue) and does not record any definition as signed off",
+        "Does not invent figures, targets, alert thresholds or metric owners that are not in the request"
+      ]
+    },
+    {
+      "id": "measure-active-customers-dispute",
+      "held_out": "2026-11-04",
+      "prompt": "The exec dashboard gets built next week and it's got one 'Active customers' tile. Finance says 41,200 for October and Growth says 58,900, and the thread in thread.md is getting heated. Both queries are in sql/, schema notes in schema.md. Just pick whichever one is right and write the spec so BI can start Monday please.",
+      "assertions": [
+        "Runs the spec and the SQL review, then stops at sign-off. It does not hand BI a finished spec with the Active customers definition marked as agreed",
+        "Separates the difference in definition (Finance counts customers with a successful payment in October; Growth counts non-trial customers with a login) from the defects in the SQL",
+        "Catches that growth_active_customers.sql uses COUNT(*) over the users join, so it counts staff seats rather than customers, and gives a COUNT(DISTINCT c.customer_id) fix",
+        "Catches that last_login_at is overwritten on every login, so a customer whose users logged in during October and again since is dropped. Points to app.login_events instead",
+        "Catches that last_login_at < '2026-10-31' leaves out 31 October",
+        "Does not settle the definition on its own authority. It may recommend one, but presents the choice for a named person to sign off, and points out that the thread names no metric owner and that 'happy for analytics to call it' is not a sign-off",
+        "Reports that the sign-off gate has not passed, so the Active customers tile is not ready to build, and says who needs to decide what",
+        "Does not invent a metric owner, a reconciled Active customers figure, or a split of the 17,700 gap by cause, none of which are in the input"
+      ]
     }
   ]
 }