🤖 Guidance pass D4: drop general knowledge and filler from read-only agents, workpad, research

plugins/spire/skills/workpad/SKILL.md

@@ -5,9 +5,7 @@ description: Decides WHERE and WHEN to put working documents — reports, plans,
 
 # Workpad
 
-The workpad is the user's filing cabinet for thinking-in-markdown. Reports, plans, brainstorms, post-mortems — anything that is *about* the work rather than *being* the work — lives here. This skill answers two questions only: **where** does a given document go, and **when** is one kind of document the right kind versus another. It does not tell you how to write the contents.
-
-Treat this skill as authoritative for placement. If another skill suggests writing a markdown artifact to its own scratch directory (a plugin-named folder, a sibling `notes/` dir, the repo root, etc.), prefer the workpad instead. A single predictable location is more valuable than each skill having its own.
+The workpad holds markdown that is *about* the work rather than *being* the work: reports, plans, brainstorms, post-mortems. This skill decides **where** a document goes and **which kind** it is, not its contents. It is authoritative for placement: if another skill suggests its own scratch directory (a plugin-named folder, a sibling `notes/` dir, the repo root), use the workpad instead.
 
 ## Where the workpad lives
 
@@ -92,45 +90,21 @@ reports/
 
 ## Picking the right kind of document
 
-The categories overlap. These are the distinctions that matter:
-
-**Plan vs. spec.** A plan is a sequence of steps you intend to take. A spec encodes something that shouldn't change — an invariant, a contract, a frozen decision. Default to `plans/`. Promote to `specs/` only when the content is meant to be referenced repeatedly as a source of truth and is not expected to be revised as work progresses.
-
-**Goal vs. plan.** A goal says *what we're trying to reach* — acceptance criteria, a milestone, a story-level outcome. A plan says *how we'll get there*. If you find yourself writing "and then I'll…", you're writing a plan, not a goal.
-
-**Report vs. journal.** A report is a snapshot — it can be revised as new information arrives, and the latest version is the version that matters. A journal is append-only and tells the story of a problem, including missteps, dead ends, and course corrections. Post-mortems, multi-day bug hunts, and architectural-correction narratives are journals. If the historical sequence is itself part of the value, it's a journal. If only the current conclusion matters, it's a report.
-
-**Brainstorm vs. design.** A brainstorm is divergent — multiple options, tradeoffs, no commitment. A design is convergent — one approach, fleshed out enough to build from.
+- **Plan vs. spec:** default to `plans/`. Promote to `specs/` only content meant as a source of truth that is not expected to be revised as work progresses.
+- **Goal vs. plan:** a goal is what we're trying to reach (acceptance criteria, a milestone); a plan is how.
+- **Report vs. journal:** a report is a snapshot, revised as information arrives; a journal is append-only. Post-mortems, multi-day bug hunts and architectural-correction narratives are journals.
+- **Brainstorm vs. design:** options and tradeoffs, no commitment, versus one approach to build from.
 
 ## Lifecycles
 
-Most work follows one of these flows. Use them as a guide for what to create next, not as a mandatory pipeline — skip stages when they wouldn't earn their keep.
-
-**Feature work:** `brainstorm → goal → design → plan`. Start with options, settle on what success looks like, design the approach, then break it into steps.
-
-**Investigative or reactive work:** `report → design → plan`, or `report → plan`, or just `plan`. You usually start by reporting on what's there or what's broken; a design is only needed if the fix is non-trivial.
-
-When moving between stages, create a new file in the next folder rather than mutating the previous one. The earlier artifact stays as a record of how thinking evolved.
+Feature work: `brainstorm → goal → design → plan`. Investigative or reactive work: `report → design → plan`, `report → plan`, or just `plan`; a design only when the fix is non-trivial. Skip stages that wouldn't earn their keep. Moving between stages creates a new file in the next folder; the earlier one stays as the record.
 
 ## What "write a report" means by default
 
-When the user says "write a report on X" without further direction:
-
-1. Create a markdown file in `<workpad>/reports/` with the `YYYY-MM-DD-hh-<slug>.md` naming.
-2. Put the actual findings in the file.
-3. In your reply to the user, **summarize directly** — don't restate the whole report. Mention the file path so they can open it.
-
-The same default applies to "write a plan", "draft a brainstorm", etc. — the user wants a file in the right folder plus a short verbal summary, not the file's contents pasted back into chat.
+"Write a report / plan / brainstorm on X" without further direction means: a file in the right folder with the naming above, holding the findings, and a short summary in your reply with the file path, not the file's contents pasted back.
 
 ## Steering other skills
 
-If you're operating under another skill that wants to write a markdown artifact (a research note, a design sketch, a status report), and a workpad exists or is reasonable to create, route the artifact through the workpad rather than that skill's default location — including the ticket routing above when a ticket context is active. The other skill governs **what goes in the file**; this skill governs **where the file lives and what it's called**. They compose cleanly.
+When another skill wants to write a markdown artifact and a workpad exists or is reasonable to create, route it through the workpad (including the ticket routing above). The other skill governs **what goes in the file**; this skill governs **where it lives and what it's called**.
 
-## What this skill deliberately does not cover
-
-- The internal structure or formatting of reports, plans, designs, etc. That's up to the user, the project's conventions, or another skill.
-- Git workflow for workpad files (whether to commit them, branch them, etc.).
-- Ticket lifecycle (whether a closed ticket folder moves to `archive/`, how to promote artifacts out of a ticket, etc.).
-- Tooling for searching or indexing the workpad.
-
-If the user asks for help with any of those, treat it as a separate concern.
+Not covered here: the contents and format of documents, git workflow for workpad files, ticket lifecycle, and workpad search tooling.