skilldrop-cli 1.4.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/dev-team/loops/release/LOOP.md

@@ -5,7 +5,7 @@ description: Take merged code to live users through a planned, reversible rollou
 
 # release
 
-This loop covers the step between `build`, which ends when a human merges, and `operate`,
+This loop covers the step between `build`, which ends when a human merges, and running the service,
 which assumes the service is already live. A merge can be undone with a revert. A launch that
 has touched users or data often cannot be undone, so this loop gets its own gates instead of
 being folded into either neighbour.
@@ -39,8 +39,8 @@ being folded into either neighbour.
    `council-review`. `RECONSIDER` means it is ready but this is the wrong time, and the work
    waits instead of going back to `plan`.
 
-After `PROCEED`, the change is live and the work moves to `operate`. Gaps that G3 sent to
-`observability-plan` or `runbook-generator` are the first things `operate` picks up.
+After `PROCEED`, the change is live and the work moves to running it. Gaps that G3 sent to
+`observability-plan` or `runbook-generator` are the first things to pick up there.
 
 ## Verdicts
 
@@ -83,7 +83,7 @@ which end in `BLOCKED`.
 - **Rollback exists before readiness is judged.** A plan with no way back is the one thing that cannot be fixed after launch.
 - **Readiness rests on evidence.** Every check links to something; "we're good" is `not met`.
 - **Can and should are separate gates.** G3 says whether it can ship; G3.1 says whether it should ship now.
-- **Detection gaps leave this loop as hand-offs.** `operate` picks them up first, rather than discovering them during the first incident.
+- **Detection gaps leave this loop as hand-offs.** Running the service starts with them, rather than discovering them during the first incident.
 
 ## Anti-patterns to avoid
 

package/packs/dev-team/loops/release/loop.json

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0031. Covers the step between build (ends at merge, G2.1) and operate (starts at instrument). Its gates are G3 and G3.1: the whole number places the loop in the lifecycle (discover G0 through operate G4), and a decimal is a second gate inside the same loop (RFC-0044).",
   "name": "release",
-  "version": "0.4.0",
+  "version": "0.4.1",
   "description": "Take merged code to live users through a planned, reversible rollout — plan the phases and the rollback, judge readiness on evidence, draft the release notes, then a human makes the go/no-go call. Use when the user has merged a change and asks how to roll it out, whether they are ready to launch, or for a go/no-go decision.",
   "entrypoint": "LOOP.md",
   "kind": "loop",

package/packs/dev-team/skills/bug-triage/SKILL.md

@@ -33,6 +33,7 @@ Converts the bug report someone *sent* into the ticket an engineer can *start*
 ## Useful references in this skill
 
 - [`templates/bug-ticket.md`](templates/bug-ticket.md) — the ticket skeleton with the severity/priority matrix and the no-repro diagnostics list
+- [`examples/export-row-limit-escalation.md`](examples/export-row-limit-escalation.md) — worked example: a VP's S1/P1 for "exports losing data" that the log shows is a 10,000-row CSV cap, filed S3/P2
 
 ## Quality bar
 

package/packs/dev-team/skills/bug-triage/examples/export-row-limit-escalation.md

@@ -0,0 +1,126 @@
+# Worked example: an escalated "exports are losing data" report
+
+Input → output oracle for `bug-triage`. Shows severity judged from the evidence rather than
+the escalation, a paraphrased error replaced by the verbatim string, and a three-symptom
+thread split into one bug, one more bug and one feature request.
+
+## Input
+
+> Can you turn this into a ticket for the Reports squad? Our VP of Customer Success wants it
+> filed as S1/P1 today. Tallow & Finch renew next month and they're furious.
+>
+> **#cs-escalations (pasted):**
+>
+> **Dana (CSM), 09:12:** Tallow & Finch say exports are losing data. Their ops lead exported
+> the Shipment Activity report for October and "half the shipments are gone". Got some random
+> error when it finished. Started after last week's release I think.
+>
+> **Dana, 09:14:** Also their dates come out as MM/DD in the CSV even though their account is
+> set to DD/MM. And they asked again for scheduled exports to SFTP.
+>
+> **Dana, 09:20:** Screenshot text from their ops lead: "Export ready. Some rows may not be
+> included. (EXPORT_ROW_LIMIT_REACHED)"
+>
+> **Marco (support engineer), 09:41:** Pulled the job log:
+>
+> ```
+> 2026-11-04T08:57:31Z export_job id=exp_88213 tenant=tallow-finch.example
+>   report=shipment_activity range=2026-10-01..2026-10-31 format=csv status=completed
+>   rows_matched=14212 rows_written=10000 warning=EXPORT_ROW_LIMIT_REACHED app=5.18.2
+> ```
+>
+> **Marco, 09:43:** The shipments are all there in the app, btw. The report shows 14,212 rows
+> on screen.
+
+## Output
+
+Filed as **S3/P2, not S1/P1.** Nothing stored was lost: the app still shows all 14,212 rows.
+The export file stops at 10,000. That is a real bug with a likely workaround. The VP can raise
+the priority to P1 for the renewal, but that changes priority only. The severity stays S3.
+The thread also held two other items, split out at the bottom.
+
+```markdown
+# CSV export of Shipment Activity stops at 10,000 rows (EXPORT_ROW_LIMIT_REACHED); remaining rows missing from file
+
+**Severity:** S3 — the export file is incomplete, stored data is intact, and splitting the date range likely works around it
+**Priority:** P2 — one tenant confirmed, renewal next month; a workaround CS can hand over today removes the need to drop current work
+**Blast radius:** any export over 10,000 rows, on any tenant `[assumption]`; one tenant confirmed `[verified]`
+**Component (best guess):** report export job `[assumption]`
+
+## Summary
+
+A customer ops lead exported October's Shipment Activity report as CSV. The file holds 10,000
+of the 14,212 matching rows `[verified: job log exp_88213]`. The dialog warned that rows "may
+not be included" `[reported: screenshot text]`. All 14,212 rows still show in the app
+`[verified: Marco, on screen]`.
+
+## Environment
+
+| Field | Value | Tag |
+|---|---|---|
+| App version | 5.18.2 | `[verified]` |
+| Tenant | tallow-finch.example | `[verified]` |
+| Report / range / format | shipment_activity, 2026-10-01..2026-10-31, CSV | `[verified]` |
+| Time | 2026-11-04 08:57:31 UTC | `[verified]` |
+| First seen / last worked | "after last week's release" | `[reported]` |
+
+## Reproduction
+
+**No repro yet.** One occurrence is confirmed in the log and nobody has reproduced it. Collect:
+- An export of any report with more than 10,000 matching rows on a test tenant, run on 5.18.2.
+  Record rows_matched and rows_written from the job log.
+- The downloaded file from exp_88213, to count its rows and check whether it ends cleanly at
+  row 10,000 or mid-row
+- Export job logs from the 30 days before last week's release, filtered on
+  `rows_written=10000`
+- A screenshot of the full export dialog, to check whether it states the limit or only "may
+  not be included"
+
+## Expected vs actual
+
+**Expected:** the CSV contains all 14,212 rows the report shows, or the export refuses and names the limit
+**Actual:** the CSV contains 10,000 rows, the job status is `completed`, and the dialog shows a vague warning
+**Error (verbatim):** `Export ready. Some rows may not be included. (EXPORT_ROW_LIMIT_REACHED)`
+
+## Hypotheses (≤3 — each with a 5-minute check; none of these is a conclusion)
+
+| # | Hypothesis | Quick check |
+|---|---|---|
+| H1 | 10,000 is a deliberate cap that was never documented | Search the export service config and docs for `10000` or `EXPORT_ROW_LIMIT` |
+| H2 | The cap or its warning arrived in a recent release | Filter export logs before last week's release for `rows_written=10000` |
+| H3 | Pagination stops after a fixed number of pages rather than a fixed row count | Export 10,001 rows and then 25,000 rows on a test tenant and compare rows_written |
+
+## Questions for reporter (≤3, ranked by diagnostic value)
+
+1. Has the ops lead had a complete export of more than 10,000 rows before? When was the last one?
+2. Do two half-month exports (Oct 1–15 and Oct 16–31) each come out complete?
+3. What does the file feed: a person reading it, or another system that will treat it as complete?
+
+## Duplicate-search hints
+
+`EXPORT_ROW_LIMIT_REACHED` · `export missing rows` · `csv export 10000`
+
+## Split out (if the report contained more than one issue)
+
+- CSV export writes dates as MM/DD when the account date format is DD/MM → to be filed as its own bug
+- Scheduled exports to SFTP → feature request, not a bug; route to the product backlog
+```
+
+## Why this is the oracle
+
+- **Severity is judged on worst plausible impact, and priority is judged separately.** The
+  reporter's words ("losing data", "half gone") and the VP's pressure both point at S1. The
+  evidence shows an incomplete file over intact data with a likely workaround, so the ticket
+  says S3. The VP's urgency is a legitimate input to priority, so the reply leaves that lever
+  with the VP and does not let it move severity.
+- **Tags separate reported from verified.** "Half the shipments are gone" is `[reported]`. The
+  log shows 10,000 of 14,212, about 70%, written. "After last week's release" stays a
+  hypothesis with a check (H2), not a stated cause.
+- **The verbatim error replaces the paraphrase, and one bug gets one ticket.** The "random
+  error" is quoted as the exact string, which is also the best duplicate-search term. The date
+  bug and the SFTP request get split out.
+
+A cheaper pass titles it "Exports losing data", files S1/P1 as asked, writes "Cause: 10k row
+limit introduced in 5.18" as fact, invents repro steps nobody ran, and puts the date bug in
+the same ticket. That ticket gets fixed in a rush on a guessed cause, and the date bug goes
+nowhere.

package/packs/dev-team/skills/bug-triage/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "bug-triage",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Turn a vague bug report (Slack message, support ticket, \"it's broken on mobile sometimes\") into an actionable ticket — searchable symptom title, numbered repro steps from a clean state, expected vs actual, severity separated from priority, evidence tagged reported-vs-verified, and labeled hypotheses instead of root-cause guesses. Use when the user wants to triage a bug, write up a bug report, turn a complaint into a ticket, or make a flaky issue actionable.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -10,5 +10,5 @@
     { "to": "feature-implement-loop", "when": "the defect is reproduced and scoped", "purpose": "Fix the triaged defect through the same capped loop a story gets.", "fallback": "If feature-implement-loop is absent, fix inline with a regression test that fails before the fix." }
   ],
   "tags": ["bug-triage", "bug-report", "ticket", "qa", "repro", "severity"],
-  "model": { "tier": "standard", "rationale": "Extraction plus judgment calls (severity vs priority, hypothesis ranking) — same shape as brief-intake: above light, below heavy." }
+  "model": { "tier": "heavy", "rationale": "Measured (RFC-0073): on its held-out evals the heavy tier met 92% and 92% of checks in two tier trials, against standard's 76% and light's 70% and 86%, more than 5 points ahead both times; moved once its examples/ oracle shipped (RFC-0074)." }
 }

package/packs/product-manager/skills/prd-draft/SKILL.md

@@ -28,6 +28,7 @@ Turns "the business wants X" into the document that aligns everyone on **what pr
 ## Useful references in this skill
 
 - [`templates/prd.md`](templates/prd.md) — the PRD skeleton with the solution-language test and MoSCoW table
+- [`examples/approver-delay-not-slack.md`](examples/approver-delay-not-slack.md) — worked example: a brief that blames a missing Slack integration when the data says approvers sit on requests
 
 ## Quality bar