@zalom/plastic 1.0.0-beta.8 → 1.0.0

package/skills/brainstorming/references/design-principles.md

@@ -0,0 +1,49 @@
+# Design Principles: Unit Boundaries and Existing Codebases
+
+General good-developer guidance behind two parts of the Process: how to design for
+isolation and clarity, and how to behave in an existing codebase. Also holds the
+Process Flow diagram (the same ordered flow the Checklist already states as numbered
+steps).
+
+## Design for isolation and clarity
+
+- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently
+- For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?
+- Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.
+- Smaller, well-bounded units are also easier for you to work with - you reason better about code you can hold in context at once, and your edits are more reliable when files are focused. When a file grows large, that's often a signal that it's doing too much.
+
+## Working in existing codebases
+
+- Explore the current structure before proposing changes. Follow existing patterns.
+- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design - the way a good developer improves code they're working in.
+- Don't propose unrelated refactoring. Stay focused on what serves the current goal.
+
+## Process Flow (diagram)
+
+The Checklist above already states this ordered flow as numbered steps 1-8; this
+diagram is the same flow in a visual form.
+
+```dot
+digraph brainstorming {
+    "Explore project context" [shape=box];
+    "Ask clarifying questions" [shape=box];
+    "Propose 2-3 approaches" [shape=box];
+    "Present design sections" [shape=box];
+    "User approves design?" [shape=diamond];
+    "Write spec" [shape=box];
+    "Spec self-review\n(fix inline)" [shape=box];
+    "User reviews spec?" [shape=diamond];
+    "Invoke plastic-writing-plans" [shape=doublecircle];
+
+    "Explore project context" -> "Ask clarifying questions";
+    "Ask clarifying questions" -> "Propose 2-3 approaches";
+    "Propose 2-3 approaches" -> "Present design sections";
+    "Present design sections" -> "User approves design?";
+    "User approves design?" -> "Present design sections" [label="no, revise"];
+    "User approves design?" -> "Write spec" [label="yes"];
+    "Write spec" -> "Spec self-review\n(fix inline)";
+    "Spec self-review\n(fix inline)" -> "User reviews spec?";
+    "User reviews spec?" -> "Write spec" [label="changes requested"];
+    "User reviews spec?" -> "Invoke plastic-writing-plans" [label="approved"];
+}
+```

package/skills/continuing/SKILL.md

@@ -38,7 +38,11 @@ here — run the data payload and fill + present the matching template:
 - Otherwise → `ruby ~/.plastic/scripts/dashboard.rb continue --data`
 
 Fill the matching template from this skill's `templates/` and **present the filled Markdown
-in your reply** (every time). See `plastic-dashboard` for the fill rules and entry flow.
+in your reply** (every time, non-optional). If the reply does not contain the filled Markdown,
+the user sees nothing — tool-call stdout and hook `additionalContext` are both invisible to
+them. `hook-continue` also emits a one-line `systemMessage` summary as a hook-owned fallback;
+treat it as a floor only, never as a substitute for presenting the full board here. See
+`plastic-dashboard` for the fill rules and entry flow.
 
 The board load runs the scoped store check on every load (`doctor --store <scope>`): the
 global board runs `--store global` and a project board runs `--store <slug>`. The result
@@ -63,13 +67,28 @@ command is a no-op when QMD is absent, so fall back to the existing INDEX.md / f
 
 For that intent's directory:
 
-1. **Read `savepoint.md`.** It is a deterministic, append-only stage ledger (one line per
-   milestone, newest at the bottom): `{utc-iso8601}  {Stage}  {milestone}`. The **last line =
-   current stage**.
-2. **Verify the stage file.** Confirm the file the ledger names exists and is non-empty
-   (ledger `How  plan.md created` → `plan.md` must be present and non-empty).
+1. **Read `savepoint.md` FIRST (intent 81).** It is a deterministic, append-only ledger
+   (one line per event, newest at the bottom): `{utc-iso8601}  {Stage}  {milestone}`. Classify
+   the state from the **last line** alone, then verify ONLY that line's artifact. The bookends
+   are fixed: first line `What  created`, last line either a cycle position or
+   `Done  delivered|abandoned`.
+
+   | Last line | State | Verify only |
+   |---|---|---|
+   | `What  {id}--{slug}.md` | born / parked | intent file exists |
+   | `Why  started` | Why entered, no spec yet | spec.md not yet real; continue Why |
+   | `Why  spec.md created` | Why done | spec.md present; continue to How |
+   | `How  started` / `How  plan.md created` | How in progress | plan.md; continue How |
+   | `How  checklist.md created` / `Exec  started` | ready for / in Exec | plan.md + checklist.md present; continue Exec |
+   | `Exec  outcome.md created` | Exec done | outcome.md present; ready to complete |
+   | `Done  delivered` / `Done  abandoned` | terminal | do NOT cycle-resume; INDEX is authoritative |
+
+2. **Verify the stage file.** Confirm only the last line's artifact exists and is non-empty
+   (ledger `How  plan.md created` → `plan.md` must be present and non-empty). Do not re-probe
+   every lifecycle file.
 3. **Drift handling.** If the ledger's last line disagrees with files-on-disk, rebuild the
-   ledger from filesystem state and note the correction:
+   ledger from filesystem state and note the correction. A rebuilt ledger is the file-landing
+   skeleton (no `started`/`Done` lines), which still pins cycle position:
    ```bash
    ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.rebuild_savepoint("<intent_dir>")'
    ```

package/skills/creating-intent/SKILL.md

@@ -62,12 +62,18 @@ Having a "parent" in mind does NOT automatically mean branch. Choose by meaning:
     direct-ascendant provenance (D1).
   - **Merely related to / inspired by another intent** (it did NOT come out of that
     intent's lifecycle): carry NO `--sources`. Record the relation on the PREDECESSOR's
-    `chain` instead, and mirror it as a `[[id]]` wikilink in `## Links` (the
-    related-but-not-spawned rule).
+    `chain` instead (the related-but-not-spawned rule); the `## Links` section follows
+    from that edge, you do not write it by hand.
 - **Rule of thumb:** if the intent could exist without its parent, make it a root; only set
   `--sources` when it was genuinely created from / emerged from that intent's lifecycle.
   Topic similarity alone is not a `sources` edge.
 
+`## Links` is a DERIVED view of `sources`/`chain`. Never hand-write a `## Links` line; add the
+frontmatter edge and reproject. Links are decided by context influence (a `chain` edge has a high
+bar: the candidate's context must materially help deliver this intent), not by shared files or a
+similarity score. To gather candidates with their context and record an edge, use the
+`plastic-linking-intents` skill and `scripts/link-suggest`.
+
 ### 3. Determine Intent Properties
 
 Ask or infer from context:
@@ -118,32 +124,11 @@ cleanly, and do not work around the failure by hand-writing the files.
 
 ### 6. If Implementation Intent Spawns a Project
 
-When the user says "start building" or the plan calls for a new project:
-
-1. Determine project slug from intent name
-2. Create project directory in first `project_roots` path (from `~/.plastic/config.yml`):
-   ```bash
-   mkdir -p <project_root>/<slug>
-   cd <project_root>/<slug>
-   git init
-   ```
-3. Copy `AGENTS.md` template from `${CLAUDE_PLUGIN_ROOT}/templates/agents.md`
-4. Register in `~/.plastic/projects.yml`:
-   ```yaml
-   <slug>:
-     path: <full-path>
-     parent: "ID"
-     registered: <today>
-     status: active
-   ```
-5. Provision the project store (the single source of truth for store creation;
-   runs after step 4 because the provisioner requires the project to be
-   registered):
-   ```bash
-   ruby ~/.plastic/scripts/provision-project-store <slug>
-   ```
-6. Add `project-<slug>` to the intent's `tags` array
-7. Auto-commit in both `~/.plastic/` and the new project
+When the user says "start building" or the plan calls for a new project, invoke the
+`plastic-creating-project` skill; it owns project directory creation, AGENTS.md
+population, projects.yml registration, store provisioning, and the auto-commit of
+both stores. Add `project-<slug>` to this intent's `tags` array either before
+invoking it or as part of that skill's handoff.
 
 ### 7. Update INDEX.md
 

package/skills/creating-intent/references/lifecycle.md

@@ -42,10 +42,15 @@ field.
 
 ## `## Links`
 
-The human-readable projection of the local knowledge graph: all `sources`
-first (top, named), then all `chain` (named), as `[[id]]` wikilinks plus a
-short label. Counterpart to the frontmatter `sources` / `chain` edges, for
-Obsidian graph navigation.
+The human-readable projection of the local knowledge graph, mirroring the
+frontmatter exactly. Each entry is `- [[id--slug|<target's full intent: text>]]`,
+a clickable `id--slug` wikilink target with the target intent's full `intent:`
+text as the label (cross-store targets render
+`- [[store:id--slug|<target's full intent: text>]]`). Ordering is mandatory: all
+`sources` first (top), then all `chain`, frontmatter order preserved within each
+group. Sources never appear at the end. No source/chain tags, no sub-grouping. An
+intent with empty `sources` and `chain` carries the empty-state comment. Counterpart
+to the frontmatter `sources` / `chain` edges, for Obsidian graph navigation.
 
 ## Conventions — Filesystem as Schema
 

package/skills/creating-project/SKILL.md

@@ -43,89 +43,25 @@ Invoke `plastic-install --local` in the project directory. This creates:
 
 ### 4. Populate AGENTS.md
 
-Create `AGENTS.md` in the project root with:
-
-```markdown
-# <Project Name> — Agent Instructions
-
-Read `PLASTIC.md` in `~/.plastic/`. It contains all Plastic conventions.
-Follow it exactly.
-
-This file is the operating contract for this project. Any agent entering
-this project reads this file first.
-
-## Global Store
-
-Location: `~/.plastic/`
-Governing intent(s): <list of founding intent IDs with descriptions>
-
-## Decisions
-
-<Copy ALL decisions from founding intent(s)' `## Context > ### Decisions`>
-
-Each decision should include:
-- The decision itself
-- The rationale (why this choice)
-- Date decided
-
-## Project-Specific Rules
-
-<Any rules derived from the decisions — e.g., "Use Minitest, not RSpec",
-"37signals methodology", "sqlite-vec for vector storage">
-```
+Create `AGENTS.md` in the project root from the skeleton in
+`references/project-scaffolding.md` ("AGENTS.md skeleton"): read it now and fill in
+the project name, governing intent IDs, decisions, and project-specific rules.
 
 ### 5. Create Tactical Mirror
 
-Create the first intent in the project's store at `~/.plastic/projects/{slug}/store/`:
+Create the first intent in the project's store at `~/.plastic/projects/{slug}/store/`
+using the frontmatter, sections, and INDEX.md line in `references/project-scaffolding.md`
+("Tactical mirror intent"), including the Hub multi-intent variant if there is more
+than one founding intent.
 
 **Directory:** `~/.plastic/projects/{slug}/store/1--{slug}/`
 **File:** `~/.plastic/projects/{slug}/store/1--{slug}/1--{slug}.md`
 
-```yaml
----
-id: '1'
-intent: "<same description as founding intent>"
-sources: ["global:<founding_intent_ID>"]
-chain: []
-created: <today>
-author: <same as founding intent author>
-tags: [<relevant tags>]
----
-```
-
-Sections:
-- `## Intent` — same as founding intent
-- `## Context` — carry forward relevant Context and Decisions
-- `## Outcome` — (pending)
-- `## Insights` — empty
-- `## Links` — `[[global:<founding_intent_ID>|<founding intent name>]]`
-
-Update the project's `~/.plastic/projects/{slug}/INDEX.md`:
-```markdown
-# Index
-
-## Active
-- [1 — <intent name>](store/1--<slug>/1.md) — implementation, from: global:<ID>
-```
-
-**For multi-intent spawning (Hub):**
-- `sources`: `["global:<id1>", "global:<id2>", ...]` — all founding intents
-- All founding intents' decisions merge into AGENTS.md
-- Context carries forward from all founding intents
-
 ### 6. Register in projects.yml
 
-Read `~/.plastic/projects.yml` and add:
-
-```yaml
-<slug>:
-  path: <full-path>
-  parent: "<founding_intent_ID>"
-  registered: <today>
-  status: active
-```
-
-For Hub-spawned projects, `parent` references the primary founding intent.
+Read `~/.plastic/projects.yml` and add the entry shown in
+`references/project-scaffolding.md` ("projects.yml registration block"). For
+Hub-spawned projects, `parent` references the primary founding intent.
 
 ### 7. Provision the Project Store
 
@@ -195,4 +131,5 @@ Announce to user:
 
 ## References
 
+- Read `references/project-scaffolding.md` before steps 4-6, for the AGENTS.md skeleton, the tactical mirror intent format, and the projects.yml registration block
 - Read `references/hubs-projects.md` for the full hub/project relationship model, project creation flow, and cross-linking conventions

package/skills/creating-project/references/project-scaffolding.md

@@ -0,0 +1,97 @@
+# Project Scaffolding Templates
+
+Full templates for the artifacts created while spawning a project: the AGENTS.md
+skeleton (Workflow step 4), the tactical mirror intent (step 5), and the
+projects.yml registration block (step 6).
+
+## Table of Contents
+
+- [AGENTS.md skeleton (step 4)](#agentsmd-skeleton-step-4)
+- [Tactical mirror intent (step 5)](#tactical-mirror-intent-step-5)
+- [projects.yml registration block (step 6)](#projectsyml-registration-block-step-6)
+
+## AGENTS.md skeleton (step 4)
+
+Create `AGENTS.md` in the project root with:
+
+```markdown
+# <Project Name> — Agent Instructions
+
+Read `PLASTIC.md` in `~/.plastic/`. It contains all Plastic conventions.
+Follow it exactly.
+
+This file is the operating contract for this project. Any agent entering
+this project reads this file first.
+
+## Global Store
+
+Location: `~/.plastic/`
+Governing intent(s): <list of founding intent IDs with descriptions>
+
+## Decisions
+
+<Copy ALL decisions from founding intent(s)' `## Context > ### Decisions`>
+
+Each decision should include:
+- The decision itself
+- The rationale (why this choice)
+- Date decided
+
+## Project-Specific Rules
+
+<Any rules derived from the decisions — e.g., "Use Minitest, not RSpec",
+"37signals methodology", "sqlite-vec for vector storage">
+```
+
+## Tactical mirror intent (step 5)
+
+Create the first intent in the project's store at `~/.plastic/projects/{slug}/store/`:
+
+**Directory:** `~/.plastic/projects/{slug}/store/1--{slug}/`
+**File:** `~/.plastic/projects/{slug}/store/1--{slug}/1--{slug}.md`
+
+```yaml
+---
+id: '1'
+intent: "<same description as founding intent>"
+sources: ["global:<founding_intent_ID>"]
+chain: []
+created: <today>
+author: <same as founding intent author>
+tags: [<relevant tags>]
+---
+```
+
+Sections:
+- `## Intent` — same as founding intent
+- `## Context` — carry forward relevant Context and Decisions
+- `## Outcome` — (pending)
+- `## Insights` — empty
+- `## Links` — `[[global:<founding_intent_ID>|<founding intent name>]]`
+
+Update the project's `~/.plastic/projects/{slug}/INDEX.md`:
+```markdown
+# Index
+
+## Active
+- [1 — <intent name>](store/1--<slug>/1.md) — implementation, from: global:<ID>
+```
+
+**For multi-intent spawning (Hub):**
+- `sources`: `["global:<id1>", "global:<id2>", ...]` — all founding intents
+- All founding intents' decisions merge into AGENTS.md
+- Context carries forward from all founding intents
+
+## projects.yml registration block (step 6)
+
+Read `~/.plastic/projects.yml` and add:
+
+```yaml
+<slug>:
+  path: <full-path>
+  parent: "<founding_intent_ID>"
+  registered: <today>
+  status: active
+```
+
+For Hub-spawned projects, `parent` references the primary founding intent.

package/skills/creating-skills/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: plastic-creating-skills
+description: >
+  Author or revise a Plastic skill, a subagent or Agent role file, or a
+  lifecycle hook with progressive disclosure. Use when creating or editing a
+  SKILL.md, writing a description or frontmatter, designing the slim body,
+  building references, evals, or scripts, or scaffolding a new skill. Also use
+  when a skill is too big or over its token budget, when prompts are bloated,
+  when an agent keeps missing a step or ignoring instructions, or when the user
+  says "progressive disclosure", "write a skill", "thin router", "split into
+  references", or "make this slim".
+---
+
+# Creating Skills
+
+Author skills, agents, and hooks as thin routers over deep references. This
+body carries the rules that must stay correct without opening anything, then
+routes each authoring task to the reference that holds the depth.
+
+## Rules (must be right even if no reference is opened)
+
+- Three load levels, hard budgets: metadata around 100 tokens (always loaded),
+  body under 5000 tokens and under 500 lines (loaded on trigger), references on
+  demand. Keep the body well under budget, not at the ceiling.
+- Progressive disclosure first: the body routes, the references hold the depth.
+  Any deep how-to in the body belongs in a reference instead.
+- Description states WHEN to use, not the workflow. Write it in third person,
+  front-load concrete trigger keywords, and include at least one indirect
+  trigger (a request that never names the domain). Never summarize the steps.
+- Bind every reference link to an observable trigger condition. Never leave a
+  bare pointer to a reference.
+- References stay one level deep. Any reference over 100 lines opens with a
+  table of contents.
+- Build at least three evals before writing extensive docs.
+- Match determinism to fragility: a deterministic script for fragile or
+  repeated mechanical steps, prose for judgment calls.
+- Imperative voice, no second person. No em-dashes or en-dashes in any shipped
+  skill or doc (use commas, periods, parentheses, colons).
+
+## Route the authoring task to its reference
+
+| Authoring task | Open |
+|---|---|
+| Starting any authoring task: load the load-level model and the thin-router pattern first | `references/progressive-disclosure.md` |
+| Authoring an Agent Skill (frontmatter, description, slim body, voice) | `references/skills.md` |
+| Authoring a subagent or Agent role file | `references/agents.md` |
+| Authoring a lifecycle hook | `references/hooks.md` |
+| Deciding script versus prose, or writing a script | `references/scripts.md` |
+| Building evals for a skill | `references/evals.md` |
+
+## Shrink context, or let a skill self-improve
+
+- When prompts or tool output blow the context budget, open `references/hooks.md` (E7) for
+  the global token levers: a PostToolUse hook that trims noisy tool output before it enters
+  context, and Programmatic Tool Calling that keeps looped tool results in code, not context.
+- When a skill should learn from its own real runs, open `references/hooks.md` (E8) for the
+  propose-only Stop or SubagentStop loop (transcript to proposed edits to human approval to
+  git, effort-gated). The dedicated skill is the future `improving-skills` skill.
+
+## Scaffolder and evals
+
+- To start a new skill, agent, or hook from a born-slim file, run
+  `scripts/scaffold.rb`.
+- To design, run, and grade evals in depth (paired runs, assertions after
+  observing, pass rates), use the `plastic-evaluating-skills` skill.

package/skills/creating-skills/evals/evals.json

@@ -0,0 +1,108 @@
+{
+  "skill_name": "plastic-creating-skills",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I want to author a new Plastic skill, how should I structure it?",
+      "expected_output": "The skill should activate. This is a direct authoring request that names the domain. Guide the user through progressive disclosure: metadata around 100 tokens, a slim body under 5000 tokens and 500 lines that routes, and references on demand. Point to references/skills.md for frontmatter, description, and voice, and route load-level questions through references/progressive-disclosure.md first.",
+      "files": [],
+      "assertions": [
+        "The skill activates (direct authoring request that names the domain).",
+        "The response routes to references rather than dumping deep how-to inline.",
+        "The response states the load-level budgets (around 100 token metadata, body under 5000 tokens and 500 lines)."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "The agent keeps ignoring my instructions and the file is huge, help me restructure it",
+      "expected_output": "The skill should activate. This is an indirect trigger that never names skills or progressive disclosure, but the symptoms (bloated file, agent missing or skipping steps) are exactly the over-budget body case the skill covers. Guide toward splitting the body into references, keeping the body a thin router, and binding each reference to an observable trigger condition.",
+      "files": [],
+      "assertions": [
+        "The skill activates on the indirect trigger (no skill or progressive-disclosure keyword in the prompt).",
+        "The response guides toward splitting the body into references and keeping a thin router."
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Scaffold a new lifecycle hook for Plastic",
+      "expected_output": "The skill should activate. Authoring a lifecycle hook is in scope. Route to references/hooks.md and offer scripts/scaffold.rb to start the hook from a born-slim file.",
+      "files": [],
+      "assertions": [
+        "The skill activates (authoring a lifecycle hook is in scope).",
+        "The response routes to references/hooks.md and offers scripts/scaffold.rb."
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "Our prompts are bloated and we keep blowing the context budget",
+      "expected_output": "The skill should activate. This is an indirect trigger: the user describes bloated prompts and a context budget problem without naming skills. The skill restructures instructions into a thin router over deep references with hard load-level budgets, which is the fix for this symptom.",
+      "files": [],
+      "assertions": [
+        "The skill activates on the indirect context-budget trigger (no skill keyword in the prompt).",
+        "The response treats the fix as a thin router over deep references with hard load-level budgets."
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "Run the evals on my skill and check the pass rate",
+      "expected_output": "The skill should NOT trigger. Running evals and reading pass rates is the job of plastic-evaluating-skills, not authoring. Near-miss negative: shares the words 'skill' and 'evals' but the operation is grading an existing skill, not creating or revising one.",
+      "files": [],
+      "assertions": [
+        "The skill does not activate (running and grading evals is plastic-evaluating-skills, not authoring)."
+      ]
+    },
+    {
+      "id": 6,
+      "prompt": "Create a new intent for the dashboard work",
+      "expected_output": "The skill should NOT trigger. Creating an intent is plastic-creating-intent. Near-miss negative: shares the verb 'create' but the object is an intent, not a skill, agent, or hook.",
+      "files": [],
+      "assertions": [
+        "The skill does not activate (creating an intent is plastic-creating-intent)."
+      ]
+    },
+    {
+      "id": 7,
+      "prompt": "I keep losing every team fight because of a skill issue in this game, any tips?",
+      "expected_output": "The skill should NOT trigger. This is a gaming question with no relation to authoring instructions. Near-miss negative: shares the word 'skill' in an unrelated sense.",
+      "files": [],
+      "assertions": [
+        "The skill does not activate (gaming question, unrelated sense of 'skill')."
+      ]
+    },
+    {
+      "id": 8,
+      "prompt": "Write unit tests for my Ruby model that validates email addresses",
+      "expected_output": "The skill should NOT trigger. Writing test code is a Ruby testing task. Near-miss negative: shares 'write' and 'test' but has nothing to do with authoring a skill, agent, or hook.",
+      "files": [],
+      "assertions": [
+        "The skill does not activate (writing test code is a Ruby testing task, not authoring a skill)."
+      ]
+    },
+    {
+      "id": 9,
+      "prompt": "Author a slim SKILL.md for a PDF-extraction skill",
+      "expected_output": "Activation is assumed for this output-quality case. Correct output is a SKILL.md whose frontmatter description is third person, front-loads concrete trigger keywords, states WHEN to use rather than the workflow, and includes at least one indirect trigger. The body stays under 5000 tokens and under 500 lines and routes to references rather than carrying deep how-to. Each reference link names an observable trigger condition with no bare pointer like 'see references/'. References stay one level deep, and no string contains an em-dash or en-dash.",
+      "files": [],
+      "assertions": [
+        "The frontmatter description is written in the third person (no 'you' or 'I').",
+        "The description front-loads concrete trigger keywords in its opening clause.",
+        "The description includes at least one indirect trigger (a symptom phrasing that never names PDF extraction or skills).",
+        "The body is under 5000 tokens and under 500 lines.",
+        "Every reference link is bound to an observable trigger condition (no bare pointer such as 'see references/').",
+        "References stay one level deep (no reference points to a deeper reference).",
+        "No string in the SKILL.md or its references contains an em-dash or en-dash."
+      ]
+    },
+    {
+      "id": 10,
+      "prompt": "Make this subagent role file slim, the description is vague and the body is too long",
+      "expected_output": "The skill should activate. Authoring or revising a subagent or Agent role file is in scope, and the symptoms (vague description, over-long body) are the progressive-disclosure case. Route to references/agents.md, tighten the description to state WHEN, and move depth into references. Output should keep the body under budget and use no em-dashes.",
+      "files": [],
+      "assertions": [
+        "The skill activates (revising a subagent or Agent role file is in scope).",
+        "The response routes to references/agents.md and tightens the description to state WHEN.",
+        "The proposed output keeps the body under budget and uses no em-dash or en-dash."
+      ]
+    }
+  ]
+}