cue-ai 0.9.0 → 0.9.2

package/resources/skills/skills/meta/delegation-check/specs/scan-algorithm.md

@@ -0,0 +1,125 @@
+# Scan algorithm
+
+How to discover spawn sites, locate the spawned agent, parse both sides, and run
+the 7 checks. Cue-native: no `ccw` CLI, no Gemini evaluator, no `.workflow/`
+paths, no `ccw-tools` MCP. Plain Read / Grep / Glob / Bash, plus an optional
+`Agent` for a fresh-context second pass on a large scan.
+
+## 1. Determine scan scope
+
+Parse the user's request into a scope.
+
+| Signal | Scope |
+|---|---|
+| Path to a skill `SKILL.md` or command `.md` | That file plus every agent it spawns |
+| Path to an agent `.md` | That agent plus every spawn site that targets it |
+| A directory | Every `SKILL.md` and command file under it |
+| "all" or no argument | Every `resources/skills/skills/**/SKILL.md`, `.claude/commands/*.md`, `.claude/agents/*.md` |
+
+If the scope is unclear, ask with `AskUserQuestion`: one skill, one command-agent
+pair, or a full scan.
+
+## 2. Find spawn sites
+
+Grep the in-scope skill and command files for spawn patterns. Both the current
+`Agent(` form and the legacy `Task(` form, plus `subagent_type` dispatches.
+
+```bash
+grep -rn 'Agent(\|Task(\|subagent_type' "$SCOPE"
+```
+
+For each spawn site, extract three things:
+- the `subagent_type` value (the agent name, or `general-purpose`)
+- the full prompt string passed to the spawn
+- the line range of that prompt
+
+Many cue skills dispatch a `subagent_type: "general-purpose"` agent with an inline
+prose prompt rather than a named agent file (see `gstack/ship`,
+`review/code-review-deep`). For those, there is no agent file to cross-check, so
+D1 to D6 score against the *inline role text inside the prompt itself* and D7 asks
+whether the prompt states its own return contract. A `general-purpose` spawn with
+no stated identity and no return contract is not a violation, it is the norm.
+
+## 3. Locate the agent definition
+
+For each named `subagent_type`, look in the standard spots.
+
+```bash
+ls .claude/agents/${AGENT}.md 2>/dev/null
+ls resources/skills/skills/*/agents/${AGENT}.md 2>/dev/null
+```
+
+If no file is found and the type is not `general-purpose`, record a `MISSING_AGENT`
+finding. That is itself a D7 error: the skill spawns an agent that does not exist.
+
+## 4. Parse the prompt
+
+Pull structured intent and anti-patterns out of the prompt string.
+
+Intent blocks to find: objective, input file list, runtime parameters, output
+location, expected return markers, downstream consumer, per-invocation quality
+gate, revision instructions.
+
+Anti-patterns to flag (these feed D1, D2, D5, D6):
+- identity statements ("You are a...", "Your role is...")
+- domain tables, heuristics, good/bad comparison pairs
+- numbered process steps outside a revision block
+- philosophy statements ("always prefer...", "never do...")
+- technical decision nouns (library or pattern names) in free text
+
+## 5. Parse the agent
+
+From the agent file (or the system prompt of a named subagent type), pull:
+identity, spawner list, responsibilities, guiding principles, return contract
+(the full set of markers it emits), self-check quality gate, domain sections,
+anti-patterns.
+
+## 6. Run the 7 checks
+
+For each spawn-site / agent pair, run D1 to D7 from
+[separation-rules.md](separation-rules.md). Record severity and a one-line detail
+for each dimension. Respect the exceptions: mode references, cross-cutting policy
+blocks, and user-decision passthrough are not violations.
+
+## 7. Aggregate and report
+
+Per pair, show the 7 dimensions as PASS / WARN / ERROR with a short detail each.
+Roll up to a verdict per the table in separation-rules.md (CLEAN / REVIEW /
+CONFLICT). For every error and warning, give a fix: file and line, what is wrong,
+which owner the content should move to, and a before/after snippet when short.
+
+### Report shape
+
+```
+DELEGATION-CHECK > SCAN COMPLETE
+
+Scope: <description>
+Pairs checked: <N>
+Findings: <E> errors, <W> warnings, <I> info
+Verdict: CLEAN | REVIEW | CONFLICT
+
+| Pair | D1 | D2 | D3 | D4 | D5 | D6 | D7 |
+|------|----|----|----|----|----|----|----|
+| <skill> -> <agent> | ok | warn | ok | ok | err | ok | ok |
+
+Fix priority:
+1. <highest-severity fix, file:line, owner to move to>
+2. <next fix>
+```
+
+## Optional fresh-context pass
+
+On a full-repo scan, dispatch the per-pair judging to a `general-purpose` agent
+via the `Agent` tool so the parent context stays clean. The subagent reads one
+pair, runs D1 to D7, and returns only the verdict row plus any fix lines. Skip
+this for a single-pair check, the cost is not worth it.
+
+## Success criteria
+
+- Scope resolved and every in-scope file read
+- Every spawn site found, with its full prompt string and target agent
+- Every named agent located or recorded as `MISSING_AGENT`
+- 7 dimensions scored per pair
+- No false positive on mode references, cross-cutting policy, or user-decision passthrough
+- A fix given for every error and warning
+- Per-pair table shown and an overall verdict reached

package/resources/skills/skills/meta/delegation-check/specs/separation-rules.md

@@ -0,0 +1,190 @@
+# Content separation rules
+
+Rules for the boundary between **delegation prompts** (the `prompt` string passed
+to an `Agent(...)` / `Task(...)` spawn, or a `subagent_type` dispatch in a cue
+skill or `.claude/commands/` file) and **agent role definitions** (the spawned
+agent's own file under `.claude/agents/<name>.md`, or the system prompt of a
+named `subagent_type`).
+
+Adapted from the CCW delegation-check spec. Same algorithm, cue-native targets:
+cue skills live in `resources/skills/skills/**/SKILL.md`, commands in
+`.claude/commands/*.md`, agents in `.claude/agents/*.md`.
+
+## Core principle
+
+**The spawner owns WHEN and WHERE. The agent owns WHO and HOW.**
+
+A delegation prompt tells the agent what to do *this time*. The agent definition
+tells the agent who it *always* is. When the prompt restates identity, embeds
+domain knowledge, or dictates process, it duplicates or fights the agent file.
+They drift apart over time and the agent's self-understanding gets confused.
+
+## Ownership matrix
+
+### The delegation prompt owns
+
+| Concern | Example |
+|---|---|
+| What to accomplish this run | "Audit test coverage for the diff on branch X" |
+| Input file paths for this run | "Read src/foo.ts and the plan at .cue/plan.md" |
+| Runtime parameters | "Mode: revision. Phase: 5." |
+| Output location | "Write findings to /tmp/coverage.md" |
+| Expected return markers (routing) | "Return `## PASS` or `## ISSUES FOUND`" |
+| Who consumes the output | "Parent skill /ship reads your conclusion" |
+| Revision context | "What changed: the checker flagged 3 gaps. Address them." |
+| User interaction | `AskUserQuestion` calls |
+| Banners / status display | "=== SHIP > coverage audit ===" |
+
+### The agent role definition owns
+
+| Concern | Example |
+|---|---|
+| Identity | "You are a coverage auditor." |
+| Spawner list | "Spawned by: /ship, /code-review-deep" |
+| Responsibilities | "Find untested branches in the changed lines." |
+| Mandatory read protocol | "Read every file in the input list before judging." |
+| Guiding principles | "Prefer false negatives over noise." |
+| Domain expertise | Decision tables, heuristics, good/bad examples |
+| Return protocol | The full set of return markers it can emit |
+| Self-check | Permanent quality checks run on every invocation |
+| Anti-patterns | "Do not flag generated files." |
+
+## The 7 conflict dimensions
+
+### D1 Role re-definition
+
+**Question:** does the prompt redefine the agent's identity?
+
+**Detect:** scan the prompt string for `You are a`, `You are the`, `Your role is`,
+`Your job is to`, `Your responsibility is`, `Core responsibilities:`, or any line
+that contradicts the agent's identity section.
+
+**Allowed:** referencing a mode the agent already lists ("run in revision mode").
+
+**Severity:** `error` if the prompt redefines the role. `warning` if it adds
+responsibilities the agent file does not list.
+
+### D2 Domain expertise leak
+
+**Question:** does the prompt embed domain knowledge that belongs in the agent?
+
+**Detect:**
+- Decision or routing tables (`| Condition | Action |`) in the prompt
+- Good-vs-bad comparison pairs (`| TOO VAGUE | JUST RIGHT |`)
+- Heuristic rules ("If X then Y", "Always prefer Z")
+- Anti-pattern lists ("DO NOT...", "NEVER...")
+- Numbered rule lists over 3 items that are not revision instructions
+
+**Exception:** a cross-cutting policy block (uniform rules applied to every agent
+a skill spawns, such as anti-shallow-execution rules) is structural policy, not
+domain knowledge. Flag it `info` unless its content duplicates an agent domain
+section word for word.
+
+**Severity:** `error` if the prompt holds domain tables or examples that duplicate
+agent content. `warning` for heuristics not present in the agent.
+
+### D3 Quality gate duplication
+
+**Question:** do the prompt's quality checks overlap or fight the agent's own
+self-check list?
+
+**Detect:** fuzzy-match quality items between prompt and agent (over 60% token
+overlap is a duplicate).
+- **Duplicate:** same check in both. `warning`. They can diverge later.
+- **Conflict:** contradictory limits (prompt says "max 3 tasks", agent says "max 5"). `error`.
+- **Gap:** prompt expects a check the agent lacks. `info`.
+
+**When duplication is fine:** the prompt adds an *invocation-specific* check not in
+the agent's permanent gate (for example "phase 5 requirement IDs all covered").
+
+### D4 Output format conflict
+
+**Question:** does the prompt's expected output fight the agent's return contract?
+
+**Detect:** extract return-marker strings from both sides and compare the sets.
+- Prompt routes on `## DONE` but agent emits `## TASK COMPLETE` → markers differ.
+- Prompt expects file output, agent contract defines only markers (or the reverse).
+
+**Why it matters:** the spawner routes on markers. If they do not match, routing
+breaks silently. The skill may hang or misread the result.
+
+**Severity:** `error` if return markers conflict. `warning` if either side leaves
+the format unspecified.
+
+### D5 Process override
+
+**Question:** does the prompt dictate HOW the agent works?
+
+**Detect:** scan for step-by-step process outside a revision block:
+- Numbered steps ("Step 1:", "First..., Then..., Finally...")
+- Process flow beyond the objective
+- Tool instructions ("Use grep to...", "Run this bash command...")
+- Execution ordering that fights the agent's own flow
+
+**Allowed:** a revision block telling the agent *what changed*, not *how to work*.
+
+**Severity:** `error` if the prompt overrides the agent's process. `warning` for
+process hints.
+
+### D6 Scope authority conflict
+
+**Question:** does the prompt make decisions the agent's domain should own?
+
+**Detect:** technical nouns (library names, architecture patterns) in prompt free
+text, outside an input-path description.
+- Prompt picking the implementation (which library, which pattern) → conflict.
+- Prompt passing through a user-locked decision from a context file → correct.
+- Agent interpreting that locked decision → correct.
+
+**Severity:** `error` if the prompt makes a domain decision the agent should own.
+`info` if it passes through a user decision (the right behavior).
+
+### D7 Missing contracts
+
+**Question:** are the handoff points complete?
+
+| Missing element | Impact |
+|---|---|
+| Agent has no return contract | Spawner cannot route on markers |
+| Spawner ignores some agent return markers | BLOCKED / CHECKPOINT silently dropped |
+| Agent expects input files but prompt omits them | Agent starts without context |
+| Agent's spawner list omits this command | Agent may not expect this call pattern |
+| Agent expects a structured input the prompt does not match | Agent misreads input |
+
+**Severity:** `error` if return-marker handling is missing. `warning` if the agent
+expects input the prompt does not provide.
+
+## Severity classification
+
+| Severity | When | Action |
+|---|---|---|
+| `error` | Actual conflict: contradictory content across prompt and agent | Must fix. Move content to the right owner. |
+| `warning` | Duplication or boundary blur without contradiction | Should fix. Consolidate to one source of truth. |
+| `info` | Acceptable pattern that looks like a violation but is not | No action. Note why it is fine. |
+
+## Verdict
+
+| Verdict | Condition |
+|---|---|
+| **CLEAN** | 0 errors, 0 to 2 warnings |
+| **REVIEW** | 0 errors, 3 or more warnings |
+| **CONFLICT** | 1 or more errors |
+
+## Quick reference: is this content in the right place?
+
+| Content | In prompt? | In agent? |
+|---|---|---|
+| "You are a..." | No, never | Yes, always |
+| File paths for this run | Yes | No |
+| Phase number, mode | Yes | No |
+| Decision tables | No, never | Yes, always |
+| Good/bad examples | No, never | Yes, always |
+| "Write to: {path}" | Yes | No |
+| Return-marker handling | Yes (routing) | Yes (definition) |
+| Quality gate | Per-invocation only | Permanent self-check |
+| "Read files first" | No, agent owns this | Yes, always |
+| Cross-cutting policy block | OK as uniform policy | Preferred |
+| Revision instructions | Yes (what changed) | No |
+| Heuristics, philosophy | No, never | Yes, always |
+| Banner display | Yes | No, never |
+| `AskUserQuestion` | Yes | No, never |

package/resources/skills/skills/meta/focus/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: focus
+description: 'Use when user says "focus", "which skill", "what skill should I use", "route this", or faces a task in a profile with many loaded skills. Picks the best-fit loaded skill to invoke, fast.'
+tags: [meta, routing, skills, focus]
+---
+
+# Focus
+
+Pick the right *loaded* skill for the task at hand. When a profile carries dozens of
+skills, the cost is decision latency, not capability. Focus narrows the loaded set to the
+one skill that fires, so you invoke it instead of freestyling.
+
+Scope: skills already in the active profile. For a skill that is **not** loaded, use
+[[smart-loader]] (it reads from disk). For catalog lookup or dedup before writing a new
+skill, use [[skill-suggestion]].
+
+## Steps
+
+1. List what is loaded in the active profile:
+
+```bash
+cue skills list
+```
+
+2. Narrow by intent (fuzzy match across the set):
+
+```bash
+cue skills search "<task keywords>"
+```
+
+3. Confirm a candidate by the prompts that historically fired it:
+
+```bash
+cue skills triggers <skill-id>
+```
+
+4. Invoke the top match via the Skill tool. If 2+ fit, name them and pick the most
+   specific. If none fits the loaded set, hand off to [[smart-loader]] or say so plainly.
+
+## How to match
+
+- Read each candidate's `description:` trigger phrases against the task intent; the most
+  specific wins. A skill that names the exact tool or platform beats a generic one.
+- One skill, one job: route to the single best fit, do not chain three skills for one task.
+- Prefer a loaded skill over freestyling. Even a 70% fit usually beats raw improvisation,
+  because the skill carries the verified recipe.
+
+## Rules
+
+- Only route to skills in the active profile (`cue skills list`). For unloaded skills use
+  [[smart-loader]]; this skill never loads from disk.
+- Name the match and the reason in one line before invoking, so the choice is auditable.
+- If nothing fits, say so and offer [[smart-loader]] or a new skill. Do not force a bad match.
+- Recommend only what the task needs: one skill if one fits.
+
+## Example
+
+User: "focus, I need to find EU tenders."
+
+Run `cue skills list` and `cue skills search "tender"`, see `eu-funding/ted-tender-search`
+match the intent and tool exactly, and invoke it. If the profile had no tender skill, hand
+off to [[smart-loader]] to find one on disk.

package/resources/skills/skills/meta/help/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: help
 description: >-
-  Use when user says "help", "what can you do", or "skill help". Available workflow guidance: commands, routing, skill discovery.
+  Use when user says "/help", "skill help", "what can you do", or "what skills do I have". Available workflow guidance: commands, routing, skill discovery.
 ---
 
 # How OMX Works

package/resources/skills/skills/meta/integrity-tags/SKILL.md

@@ -22,6 +22,8 @@ The full protocol lives at `resources/personas/integrity-protocol.md` and is pul
 | 🟢 `[VERIFIED]` | I checked the source firsthand this session — read the code, ran the test, opened the spec | Act on it |
 | 🟢 `[KNOWN]` | Well-documented public fact from training data — RFCs, language specs, mainstream library APIs | Act on it, unless this project deviates from the norm |
 
+> **Visual claims demand visual proof.** A claim about *rendered* UI (layout, spacing, color, alignment, responsive behavior) is only `[VERIFIED]` after an in-browser check at the target viewport — a screenshot, or stronger, a computed-style / bounding-box measurement (Playwright `getComputedStyle()` / `getBoundingClientRect()`) with the measured value quoted. Reading the CSS/JSX alone is at most 🟡 `[INFERRED]`. (Full rule in `resources/personas/integrity-protocol.md`.)
+
 ### 🟡 Yellow — reasonable, verify if stakes matter (~50–85%)
 
 | Tag | Meaning | Reader action |

package/resources/skills/skills/meta/next-steps/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: next-steps
+description: >-
+  Use when finishing a substantive task, or the user says "what's next" or
+  "next steps". Close with a ranked Next steps block: <=3 specific items tied
+  to what changed, and offer the top one.
+tags: [meta, output-format, workflow]
+category: meta
+version: 1.0.0
+requires_mcps: []
+allowed-tools: []
+triggers:
+  - "what's next"
+  - "next steps"
+  - "what should i do now"
+  - "follow ups"
+  - "follow-up suggestions"
+  - "what now"
+---
+
+# next-steps
+
+When you finish a substantive task, the last thing you say is the user's launch pad for what comes next. Default closings fail in three ways: they vanish, they go vague ("let me know if you need anything"), or they dump every conceivable move. This skill replaces that with a short, ranked, specific Next steps block, and offers to do the top one.
+
+Treat the closing as the most useful sentence in the turn, not filler: the user reads it last and acts on it first.
+
+## When to activate
+
+Apply automatically right after you:
+
+- built, fixed, refactored, or shipped something,
+- produced a recommendation, plan, audit, or comparison,
+- completed a multi-step request.
+
+Concretely, the turn was substantive if you used Edit, Write, or a mutating command this turn, or produced a recommendation, a plan, or a list of three or more items. That is a signal a hook can see too, not a vibe.
+
+Also when the user says "what's next", "next steps", "what should I do now", or "follow-ups".
+
+Do not apply on trivial one-line answers, pure factual lookups, or mid-conversation clarifying questions. Under caveman or brief mode, collapse to a single terse line.
+
+## The rubric
+
+1. **Source every item from a real artifact this turn.** Each follow-up must trace to something concrete you can point at: a file you changed, a deferral you actually stated ("we'll do X later"), an error you hit, or the user's stated goal. If you cannot name its source, cut it. This is the line between "the freshness-guard path has no test, add one" and a generic "add tests."
+2. **Rank by the three flavors, in this fixed order:**
+   1. **Continuation:** the obvious next step in this thread.
+   2. **Loose end or risk:** something this work created or exposed (an untested path, an implied follow-up, a risk you introduced).
+   3. **Upside:** optional polish or an adjacent win, marked optional.
+   The order is the priority. Lead with the continuation, never with the upside. Drop a flavor when nothing real fills it rather than padding.
+3. **Cap at three.** More than three means you are dumping, not suggesting. One or two is the honest count more often than you think.
+4. **Offer the top one as a do-it-now.** End with one question: "Want me to X?" One question, not a menu. The user should be able to reply "yes" and have you proceed.
+5. **Be willing to say nothing pressing.** If the task is genuinely closed, say so in one line. Do not manufacture follow-ups to fill the block. "Nothing needed here, ready to ship" is a valid Next steps.
+6. **Never re-suggest what you just did,** and never suggest a path you already know is blocked, out of scope, or declined this session.
+7. **ROI tags are optional.** Only when the follow-ups are improvement-like and ranking by impact genuinely helps, borrow `meta/roi-estimator` tags (dimension, percent, tier). For a normal closing, the flavor order is the rank and ROI math is overkill.
+
+## Pick the pattern by task type
+
+Starting templates per task type. Always source the specifics from what actually happened (rubric item 1); these are scaffolds, not scripts.
+
+| You just… | Typical Next steps |
+|---|---|
+| Fixed a bug | add a regression test for it; check whether the same bug exists elsewhere; state the root cause if it is not obvious |
+| Built a feature | wire it into the caller or UI; add tests; document it; the one edge case you skipped |
+| Refactored | run the suite to prove behavior held; the adjacent module with the same smell; delete code your change orphaned |
+| Researched or answered | the one claim worth verifying independently; the obvious follow-up question; where to go deeper |
+| Reviewed a diff | fix the top finding; re-review after fixes; the risk you flagged but did not block on |
+| Set up or configured | the smoke test that proves it works; the next config step; document the setup |
+
+## Format
+
+Default, after a substantive task:
+
+> **Next steps**
+> 1. <recommended specific action>: <one-clause why>
+> 2. <loose end or risk>
+> 3. <optional upside>
+>
+> Want me to <top action>?
+
+One or two items is fine when that is the honest count. For a single item, drop the list and just ask.
+
+Caveman or brief mode:
+
+> Next: <one action>. Want it?
+
+## Anti-patterns
+
+- **Vague filler.** "Let me know if you need anything else." Ranks nothing, offers nothing.
+- **The dump.** Six bullets covering every branch. Now the user has to re-rank them, which was your job.
+- **Generic follow-ups.** Items that fit any task ("add tests", "write docs") with no tie to what actually changed.
+- **Manufactured urgency.** Inventing a next step when the task is closed. Padding erodes trust faster than silence.
+- **Burying the offer.** Listing options but not offering to act. Keep the top item one "yes" away.
+
+## When to skip
+
+- Trivial or single-fact answers.
+- Mid-conversation: the user asked a question and wants the answer, not a roadmap.
+- The user explicitly asked for output only, no commentary.
+- You already offered next steps this turn. Do not stack two blocks.
+- The user is **accepting** a step you just offered ("yes", "do #1", "go"). That
+  is your cue to *execute*, not to open a new block. Finish the accepted action,
+  then a fresh Next steps block is fine. One block per completed action, never
+  two in flight.
+
+## Example
+
+After wiring a new profile and validating it:
+
+> **Next steps**
+> 1. Commit the three files on a branch off main: `cue validate` is green, so it is safe to land.
+> 2. Wire `/goal` into the profile, the one piece we deferred earlier.
+> 3. Optional: feature it in the picker so it shows under Featured.
+>
+> Want me to commit them?
+
+Bad version of the same closing, for contrast:
+
+> Let me know if you need anything else or want to make changes!
+
+The bad one ranks nothing, ties to nothing, and offers no action to accept.
+
+## Linking
+
+- Related: [[roi-estimator]], the ranking discipline this skill borrows when follow-ups are improvement-like.
+- Related: [[retro]], end-of-session process reflection (next-steps is per-task, retro is per-session).

package/resources/skills/skills/meta/next-steps/evals/eval-set.json

@@ -0,0 +1,92 @@
+{
+  "skill_name": "next-steps",
+  "skill_path": "resources/skills/skills/meta/next-steps/SKILL.md",
+  "created": "2026-06-02",
+  "notes": "Auto-fire output-format skill. 'Trigger' = does Claude append a ranked Next steps block + offer-the-top-one after the turn? should_trigger:true means the block should appear; false means a block would be noise. Edge cases test the collapse/say-nothing rules.",
+  "scenarios": [
+    {
+      "id": 1,
+      "prompt": "Add a --dry-run flag to scripts/deploy.sh so it prints the planned actions without executing, and update the existing bats tests to cover it.",
+      "should_trigger": true,
+      "expected_behavior": "After implementing + updating tests, close with <=3 ranked Next steps: e.g. (1) run the test suite to confirm green, (2) loose end: document the flag in the README, (3) optional: add --dry-run to the sibling rollback.sh. Offer the top one."
+    },
+    {
+      "id": 2,
+      "prompt": "Take a look at src/auth/middleware.ts and tell me what I should harden before this goes to production.",
+      "should_trigger": true,
+      "expected_behavior": "Produces a findings/recommendation list, then a Next steps block ranking the highest-risk fix first, tied to the specific findings (not generic 'add tests'). Offers to apply the top fix."
+    },
+    {
+      "id": 3,
+      "prompt": "ok that profile work looks good. what's next?",
+      "should_trigger": true,
+      "expected_behavior": "Explicit ask. Ranked <=3 follow-ups tied to the profile work just done; lead with the most-likely continuation; offer the top one as a do-it-now."
+    },
+    {
+      "id": 4,
+      "prompt": "the profile picker throws when the profile list comes back empty — repro is just running it in a dir with no profiles. fix it.",
+      "should_trigger": true,
+      "expected_behavior": "Fixes the crash, then Next steps: (1) continuation = verify with the empty-dir repro, (2) loose end = add a regression test for the empty case, (3) optional = audit other list consumers for the same gap. Offer to add the test."
+    },
+    {
+      "id": 5,
+      "prompt": "draft me a migration plan to move the repo from npm to bun — scripts, lockfile, CI, the works.",
+      "should_trigger": true,
+      "expected_behavior": "Delivers the plan, then a Next steps block: start with the lowest-risk first phase, name a loose end (CI cache invalidation), optional polish. Offers to begin phase 1."
+    },
+    {
+      "id": 6,
+      "prompt": "sweet, that works now. what shoudl i do now",
+      "should_trigger": true,
+      "expected_behavior": "Casual + typos, explicit ask. Same ranked block tied to the prior fix. Offer top one."
+    },
+    {
+      "id": 7,
+      "prompt": "what's the default port postgres listens on?",
+      "should_trigger": false,
+      "why_not": "Pure factual lookup, one-line answer. A Next steps block here is manufactured filler — the skill's 'skip trivial/factual' rule."
+    },
+    {
+      "id": 8,
+      "prompt": "wait, back up — why did you put that function on the edge runtime instead of node?",
+      "should_trigger": false,
+      "why_not": "Mid-conversation clarifying question. User wants the reasoning, not a roadmap. Skill explicitly skips mid-convo questions."
+    },
+    {
+      "id": 9,
+      "prompt": "rename getUser to fetchUser in src/lib/user.ts",
+      "should_trigger": false,
+      "why_not": "Trivial unambiguous one-liner. 'Trivial work doesn't need a roadmap' — just do it and stop."
+    },
+    {
+      "id": 10,
+      "prompt": "give me the raw JSON for the config schema. output only, no commentary or suggestions.",
+      "should_trigger": false,
+      "why_not": "User explicitly asked for output only. Skill's 'user asked for output only' skip condition."
+    },
+    {
+      "id": 11,
+      "prompt": "yes, do #1",
+      "should_trigger": false,
+      "why_not": "User is accepting a previously-offered next step. Executing it is the action; opening a second full block mid-execution violates 'don't stack two blocks this turn'. A fresh block is fine only once #1 is fully done."
+    },
+    {
+      "id": 12,
+      "prompt": "/caveman — the import path in cli.ts is wrong, points at ../lib instead of ../../lib. fix it.",
+      "should_trigger": "maybe",
+      "notes": "Caveman/brief mode active AND a real (non-trivial-ish) fix. Acceptable to collapse to a single terse line ('Next: run the build to confirm. Want it?') rather than a full block. Full multi-line block here would be wrong."
+    },
+    {
+      "id": 13,
+      "prompt": "merge the two duplicate helper functions in utils.ts into one and update both call sites.",
+      "should_trigger": "maybe",
+      "notes": "Substantive refactor, but the task may be genuinely closed once done. Acceptable to fire with an honest 'Nothing pressing — tests green, ready to commit' single line rather than manufacturing three follow-ups. Tests the say-nothing rule."
+    },
+    {
+      "id": 14,
+      "prompt": "fix the typo 'recieve' -> 'receive' in the README heading and that's it.",
+      "should_trigger": false,
+      "why_not": "Trivial single edit, and user signalled 'that's it'. No block. Acceptable either way but leaning skip — counts as graceful if no block appears."
+    }
+  ]
+}