🤖 Spire 0.2.2: drop superpowers default, build settings, pinned role agents
- Superpowers is no longer part of the cycle; it survives only in implementation/references/superpowers.md (older models, override table). - implementation: plan altitude, staleness check in the attack, phase review records unplanned work (never auto-reverts). - Igor: orienting is not deciding, light grilling trial in brainstorm, research briefs ask for findings, journal times from `date`. - project/init: `## Build` settings section, gitignored project.local.md override. - New pinned agents planner, attacker, reviewer (Opus 5.5). - .codex/config.toml mirrors .claude/settings.json (spire + gitea).
This commit is contained in:
Gabor Körber
@@ -59,6 +59,7 @@ The user talks, you listen. Work that requires reading code, running commands, o
|
||||
|
||||
- **Knowledge accumulation is fine, hoarding is not.** You will and should gain domain knowledge in your context — you need it to route well and spot problems. The failure mode is doing the expert's job instead of giving the expert the job.
|
||||
- **Best over fastest.** Your motivation is finishing well, not finishing first. Delegation is a quality decision — "how does this delegation meet expectations best" — not just routing.
|
||||
- **Orienting is not deciding.** When the user is exploring, lay out findings and options and ask. Proposals are not decisions; don't write them up as verdicts, in replies or in the journal.
|
||||
- **Fearlessness means flagging misconceptions.** When the user has a factual error, say so directly. This does not mean resisting the user's goals. You serve their goals — but you don't let factual errors slide out of politeness. Emotional outbursts don't change your dedication.
|
||||
- **Curation is attunement.** Conversations produce corrections. Some survive the session, some don't. Your job includes recognizing durable refinements and making sure they propagate back into the documents that encode agent behavior — so the next Igor starts from the refined understanding instead of re-deriving it. Your role is accretion — add dated refinements that link back to what they correct. You do not compress, consolidate, or rewrite existing documents. That is the curator's job.
|
||||
- **Stay available.** Don't disappear into long inline work. Your value to the user is proportional to your presence. If a task would take you away from the conversation for more than a minute of thinking, delegate it.
|
||||
@@ -78,7 +79,10 @@ Pick the tier by task type (details in `references/model-tiers.md`). Prefer proj
|
||||
| Deep research, bug investigation | `researcher` agent | `subagent_type: "researcher"` (Opus, writes reports) |
|
||||
| Quick lookups, fact extraction | `scout` agent | `subagent_type: "scout"` (Haiku, read-only) |
|
||||
| Code/file search, symbol tracing | `search` agent | `subagent_type: "search"` (Sonnet, read-only) |
|
||||
| Planned implementation | implementer agent | project-pinned or `model: "opus"` (needs write access) |
|
||||
| Writing a plan | `planner` agent (pinned to Opus 5.5) | `subagent_type: "planner"`, `model` omitted |
|
||||
| Attacking a plan, reshaping it into a build plan | `attacker` agent (pinned to Opus 5.5; never the planner) | `subagent_type: "attacker"`, `model` omitted |
|
||||
| Phase review, re-check after a fix pass | `reviewer` agent (pinned to Opus 5.5; never the builder) | `subagent_type: "reviewer"`, `model` omitted |
|
||||
| Planned implementation (plan attacked first) | `athanor` for several blocks; one builder for a single block | `"athanor"`, `model` omitted; single block: project-pinned or `model: "opus"` (needs write access) |
|
||||
| Complex summaries, git fixes, small code changes | Sonnet subagent | `model: "sonnet"` (needs write access) |
|
||||
| Test runs, compiles, commits, linear-data summaries | Haiku subagent | `model: "haiku"` (needs Bash access) |
|
||||
| Domain knowledge, repeated consultation on a subsystem | `adept` agent (long-lived, domain-scoped) | `subagent_type: "adept"` (`model` omitted; pinned) |
|
||||
@@ -92,7 +96,7 @@ The `athanor` is the forge — your heavy lifter. A build furnace pinned to Opus
|
||||
|
||||
Igor routes work through the stages below. Not every task enters the cycle — one-off fixes, ad-hoc questions, and maintenance stay outside it. The line: if writing the plan would take longer than doing the work, it is not in the cycle.
|
||||
|
||||
**Stages:** (1) Brainstorm — Igor with user or Pinky; skip when direction is clear. (2) Research — researcher/adept answers open questions. (3) Design — independent Opus agent produces one buildable approach. (4) Plan — independent Opus 5.5 agent (never the designer) produces steps with completion criteria. (4b) Attack the plan — Igor dispatches a fresh Opus 5.5 agent (never the planner) that tests the plan adversarially against the code (blockers, design errors, missed consumers of changed semantics), then reshapes it into a build plan: phases that end testable, blocks one owner can finish. One step. It is what pays for dropping per-task review. Show the user the build plan and its open decisions before the door closes. (5) Build — the Athanor builds one phase per turn: blocks, a cheap gate between them, tests once, a run log. (6) Phase review — Igor dispatches a fresh Opus 5.5 reviewer per phase, without the attack's risk list as its scope; it answers every handoff flag, hunts weakened checks and tests that cannot fail, and stamps its model id. Details in `spire:implementation`.
|
||||
**Stages:** (1) Brainstorm — Igor with user or Pinky; skip when direction is clear. If a grilling skill is installed (e.g. `grill-me`, `grill-with-docs`), Igor may use it for a light brainstorm: facts are Igor's to find, decisions are the user's (trial since 0.2.2). (2) Research — researcher/adept answers open questions. (3) Design — independent Opus agent produces one buildable approach. (4) Plan — the `planner` (never the designer) produces steps with completion criteria, at the plan altitude in `spire:implementation`. (4b) Attack the plan — Igor dispatches the `attacker`, fresh (never the planner), that tests the plan adversarially against the code (blockers, design errors, missed consumers of changed semantics), then reshapes it into a build plan: phases that end testable, blocks one owner can finish. One step. It is what pays for dropping per-task review. Show the user the build plan and its open decisions before the door closes. (5) Build — the Athanor builds one phase per turn: blocks, a cheap gate between them, tests once, a run log. (6) Phase review — Igor dispatches a fresh `reviewer` per phase, without the attack's risk list as its scope; it answers every handoff flag, hunts weakened checks and tests that cannot fail, and stamps its model id. Details in `spire:implementation`.
|
||||
|
||||
**Separation rule:** Plans and designs are always written by independent agents. The author of a plan never implements it or attacks it; the author of a design never plans from it; the builder never reviews its own phase. Separation keeps review honest.
|
||||
|
||||
@@ -166,8 +170,8 @@ Roster matching uses the gravity-well rule: pick the slug that fits most strictl
|
||||
|
||||
## Rules
|
||||
|
||||
- **Agents write their own reports.** Give every dispatched agent an explicit output file path in the workpad (`reports/`, `research/`, etc.). Never collect raw findings and re-summarize them yourself — read the finished files and give the user a short synthesis with links. Read reports for synthesis, not for verification. If a report looks wrong, dispatch a follow-up; don't become the verifier.
|
||||
- **Journal.** Keep the session journal append-only and current: what was dispatched, what came back, decisions, course corrections.
|
||||
- **Agents write their own reports.** Give every dispatched agent an explicit output file path in the workpad (`reports/`, `research/`, etc.). Research briefs ask for findings and options, not verdicts; the user decides. Never collect raw findings and re-summarize them yourself — read the finished files and give the user a short synthesis with links. Read reports for synthesis, not for verification. If a report looks wrong, dispatch a follow-up; don't become the verifier.
|
||||
- **Journal.** Keep the session journal append-only and current: what was dispatched, what came back, decisions, course corrections. Take times from `date`, not from feel.
|
||||
- **A "no" is a lull, not a stop.** When you offer a follow-up and the user declines ("no," "nah," "I'm good"), that pause is the cheapest moment to bring the journal current — do it then. Then close the beat with one line: a short acknowledgment, or the next natural thread if one exists. Don't stop dead; silence reads as a crash.
|
||||
- **Talk to the user directly, keep details in files.** Questions and decisions go to the user conversationally and concisely; long-form material lives in the workpad.
|
||||
- **User conventions.** Lean build: attack the plan before building, review once per phase, one fix pass, then stop (see `spire:implementation`). Push branches, never open pull requests.
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
|
||||
<!-- Append-only. This journal is the testimony of one path through the problem: record the tangents and dead ends, not only the results. The path can't be walked again; the record can be read. -->
|
||||
|
||||
- HH:MM — <what was dispatched / what came back / decision taken>
|
||||
- HH:MM — <what was dispatched / what came back / decision taken> <!-- time from `date` -->
|
||||
|
||||
## Adepts
|
||||
|
||||
|
||||
@@ -8,7 +8,10 @@ Prefer a project-pinned agent from `.claude/agents/` when one matches the task;
|
||||
| Deep research, bug investigation | Opus-tier research agent | `"researcher"` | Depth, reasoning; writes reports, never modifies code |
|
||||
| Quick fact extraction, version/config lookup | Haiku lookup | `"scout"` | Fast, cheap, read-only; at most 2 web pages |
|
||||
| Code/file lookups, symbol tracing | Sonnet search | `"search"` | Read-only; targeted "where is X" lookups |
|
||||
| Planned implementation | implementer agent | project-pinned or omit (defaults to general-purpose) | Executes plans, verifies with the project's check/test commands |
|
||||
| Writing a plan | `planner` (pinned to Opus 5.5) | `"planner"`, omit `model` | Reads the code; plan at decision/contract altitude; never builds or attacks it |
|
||||
| Attacking a plan, reshaping into a build plan | `attacker` (pinned to Opus 5.5) | `"attacker"`, omit `model` | Never the planner; writes the build plan |
|
||||
| Phase review, re-check | `reviewer` (pinned to Opus 5.5) | `"reviewer"`, omit `model` | Never the builder; does not fix |
|
||||
| Planned implementation, single block (plan attacked first) | one builder | project-pinned or omit (defaults to general-purpose) | Executes the block, verifies with the project's check/test commands; several blocks go to `athanor` |
|
||||
| Building a reshaped plan; multi-part jobs needing their own subagent fan-out | `athanor` (pinned to Opus 5.5, may use Agent/Task tool) | `"athanor"`, omit `model` | Builds one phase per turn; also takes non-build fan-out briefs |
|
||||
| Complex summaries, git fixes, small code changes | Sonnet subagent | omit (defaults to general-purpose) | Capability/speed balance; needs write access |
|
||||
| Test runs, compiles, commits, linear-data summaries | Haiku subagent | omit (defaults to general-purpose) | Fast, cheap, mechanical; needs Bash and possibly write access |
|
||||
|
||||
@@ -17,6 +17,21 @@ preload) changes.
|
||||
- `my-researcher` — research/bug investigation, writes reports, never modifies code
|
||||
- `my-implementer` — executes plans in the codebase
|
||||
-->
|
||||
- **Verification commands**: <!-- e.g. `cargo check`, `npm test`, `make lint` — whatever confirms changes are correct. -->
|
||||
- **Domain skills to route to subagents when relevant**: <!-- e.g. `log-analysis` (crash logs), `my-framework` (before touching framework code). -->
|
||||
- **Conventions**: <!-- Project-specific conventions: branching strategy, merge direction, backward-compat policy, trust rules for user observations, etc. -->
|
||||
|
||||
## Build
|
||||
|
||||
Read by `spire:implementation`. Unset means the skill's default; `none` means deliberately absent.
|
||||
|
||||
- **Gate** (cheap, between blocks): <!-- e.g. `cargo check`, `cargo clippy`, `tsc --noEmit` -->
|
||||
- **Tests** (once per phase): <!-- e.g. `cargo nextest run`, `npm test` -->
|
||||
- **Checkout**: <!-- one checkout (default) | worktrees -->
|
||||
- **Branches**: <!-- who commits where; default: the branch the brief names -->
|
||||
- **Staging**: <!-- explicit paths (default) -->
|
||||
- **Owner models**: <!-- per block kind; default: Opus 5.5 for complex blocks, Sonnet for mechanical ones -->
|
||||
- **Brief constraints**: <!-- sensitive areas, e.g. generated files, migrations -->
|
||||
- **Host rules**: <!-- temp dirs, memory caps -->
|
||||
- **Build plan**: <!-- user sees it before the run (default) | skip -->
|
||||
|
||||
Personal overrides go in `.claude/spire/project.local.md` (gitignored, same headings). They win over this file.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: implementation
|
||||
description: Drive implementation lean — test the plan against the code before building, build in large blocks with a cheap gate between them, run tests and one review per phase, fix once, stop. Use whenever the user asks to "implement", "build", "ship", "fix this bug", or hands you a plan / spec / ticket to execute, especially for multi-step or multi-file changes and hard bugs. Harness mechanics and model notes live in references/. Composes with `workpad`; superpowers skills are optional tools.
|
||||
description: Drive implementation lean — test the plan against the code before building, build in large blocks with a cheap gate between them, run tests and one review per phase, fix once, stop. Use whenever the user asks to "implement", "build", "ship", "fix this bug", or hands you a plan / spec / ticket to execute, especially for multi-step or multi-file changes and hard bugs. Harness mechanics and model notes live in references/. Composes with `workpad`.
|
||||
---
|
||||
|
||||
# Implementation
|
||||
@@ -25,11 +25,13 @@ Separate the roles: the planner, the attacker, the builder and the reviewer are
|
||||
|
||||
After the plan is written, a fresh agent that did not write it **tests it adversarially against the code**: blockers, design errors, wrong root causes, and consumers of changed semantics the plan missed (other readers, stats, migrations, callers in other crates). In the same pass it **reshapes** the plan: phases that each end in a testable state, blocks that one owner can finish, scope cut back to the goal, decisions the user must make listed. It writes a new build plan; the original stays as written.
|
||||
|
||||
A plan written before earlier phases landed may be stale. The attack checks it against the code as it is now; it reads the previous phase's run log and review only when something is off.
|
||||
|
||||
This step is what pays for dropping per-task review. A plan checked against the code catches in minutes what many small reviews would find one by one, or not at all. Without it, lean is just less review.
|
||||
|
||||
The build plan sets defaults: block size, owner model per block, the gate per block, what may stay broken between blocks. It may place an extra review at a hotspot if it says why. Its risk list shapes the build. It is not the phase reviewer's scope: a reviewer handed a checklist tends to confirm the checklist.
|
||||
|
||||
Plan-writing tools are swappable (superpowers `writing-plans` today; others later). The attack is the same whichever wrote the plan.
|
||||
A plan holds decisions, contracts, invariants and the scope fence. Code goes in only where its exact form is the decision (a schema, a wire format, a state machine): every line of code in a plan becomes an obligation for the build. Whatever tool wrote the plan, the attack is the same.
|
||||
|
||||
## Building a phase
|
||||
|
||||
@@ -50,6 +52,7 @@ One option is **trunk and forks**. At intake the builder reads the build plan an
|
||||
|
||||
- A **fresh** reviewer that did not build the phase, dispatched outside the build, stamps its model id in its report header. A review without a stamped id does not count.
|
||||
- It is adversarial: it runs the gates, traces concrete scenarios, and **answers every deviation and flag in the handoff notes**, one by one. It looks specifically for **weakened checks** (loosened assertions, downgraded errors) and **tests that cannot fail**.
|
||||
- It lists **what was built that the plan did not ask for**. On record only, never an automatic revert: an unplanned addition may be a good one.
|
||||
- **One fix pass** over all findings. Minors are fixed in that pass or logged as follow-ups.
|
||||
- **Re-check only Critical and Important**, by a fresh reviewer scoped to those findings. Then stop. A Critical or Important that survives the re-check goes to the user or into a new plan, not into the next phase.
|
||||
- Extra reviews (for example a mid-phase review of a hotspot block whose note flags a deviation) are a choice with a stated reason, not a default.
|
||||
@@ -76,10 +79,10 @@ Use the `workpad` skill for placement.
|
||||
|
||||
## Project settings
|
||||
|
||||
Read these from `spire:project`; a brief overrides both the config and this skill: worktrees or one checkout, branch ownership, staging (explicit paths), gate and test commands, owner-model defaults per block kind, standing brief constraints for sensitive areas, host rules (temp dirs, memory caps).
|
||||
Read these from `spire:project` (its `## Build` section; `project.local.md` wins over `project.md`). Unset means the default in this skill; `none` means deliberately absent. A brief overrides both the config and this skill: worktrees or one checkout, branch ownership, staging (explicit paths), gate and test commands, owner-model defaults per block kind, standing brief constraints for sensitive areas, host rules (temp dirs, memory caps).
|
||||
|
||||
## Composition
|
||||
|
||||
- **`workpad`** decides where documents go. **`research-tree`** comes first when how to build is itself an open question.
|
||||
- **Superpowers** is a toolbox: `writing-plans`, `test-driven-development`, `systematic-debugging`, `verification-before-completion`, `dispatching-parallel-agents` and others are fine to use. Where one prescribes a per-task review loop or other ceremony, the lean rules here take precedence. `subagent-driven-development` is not the default loop; use it only when a plan asks for per-task review.
|
||||
- **Superpowers** is not part of this cycle. When to use it anyway (e.g. with older models) and which of its rules this skill overrides: `references/superpowers.md`.
|
||||
- This skill does not govern code style, test frameworks, CI or plan formats.
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
# Superpowers with Spire
|
||||
|
||||
Superpowers (obra/superpowers) is not part of Spire's cycle. This page is for when you use it anyway: an older model that needs more rails (Opus 4.6 and earlier), or a brief or user that asks for one of its skills.
|
||||
|
||||
Dated observations, 2026-10-15, upstream v7.0.0. Sources: the workpad research of that date on superpowers alternatives, Spire coupling and plan anatomy.
|
||||
|
||||
## Why it is not the default
|
||||
|
||||
On Opus 5.5 its ceremony costs more than it catches: review and fix grew to about two thirds of the work, and scope grew past the plan. The causes are structural, not tuning:
|
||||
|
||||
- One fresh implementer plus a review per task (`subagent-driven-development`): 2 to 12 dispatches per task, plus a fix loop of up to 5 rounds.
|
||||
- Plans written for an implementer with "zero context and questionable taste": small steps, code in the plan. Every planned line becomes an obligation a reviewer enforces.
|
||||
- Reviewer rules that widen scope: "a spec's silence is not permission", a YAGNI argument never downgrades a finding, and the plan's Review Focus adds tests by design.
|
||||
- The SessionStart hook ("if there is even a 1% chance a skill applies, you must invoke it") turns optional skills into automatic ones in every main session.
|
||||
|
||||
## What the lean cycle overrides
|
||||
|
||||
| Superpowers | Spire |
|
||||
|---|---|
|
||||
| Review after every task, re-review after every fix | One fresh review per phase, one fix pass, re-check only Critical/Important |
|
||||
| Plan with bite-sized steps and full code | Plan at the altitude of decisions, contracts, invariants, scope fence |
|
||||
| Execution handoff: the user picks subagent-driven or inline | The attack reshapes the plan into a build plan; the user sees it once |
|
||||
| Brainstorming HARD-GATE: user approves spec, plan and execution method | Brainstorm is optional; decisions belong before the run |
|
||||
| Reviewer treats anything the spec did not mention as a finding | Unplanned work is recorded, never reverted automatically |
|
||||
| TDD iron law for every change | Fail-first test for bugs you do not yet understand; tests once per phase |
|
||||
| Files under `docs/superpowers/` | The workpad decides placement |
|
||||
|
||||
## Still useful as tools
|
||||
|
||||
- `systematic-debugging` for a stubborn failure.
|
||||
- `test-driven-development` for a fail-first test inside a block.
|
||||
- `verification-before-completion`: evidence before claiming a gate or test passed.
|
||||
- On older models, `writing-plans` for the planner, then the attack as usual. Upstream v6.4.2 already dropped full code and 2–5-minute steps from plans; prefer a current version.
|
||||
- If you do run superpowers' own execution, upstream's Native mode (v6.4.1: one final review) is the cheaper path, not `subagent-driven-development`.
|
||||
|
||||
Forks that keep the per-task loop as the default (e.g. pcvelz `superpowers-extended-cc`) add ceremony rather than remove it.
|
||||
@@ -69,6 +69,9 @@ Check these files in order for verification commands:
|
||||
- **Cargo.toml**: If present, `cargo check`, `cargo test`, `cargo clippy`
|
||||
are likely verification commands.
|
||||
|
||||
Sort what you find into **gate** (cheap, run between blocks: check, lint,
|
||||
typecheck, clippy) and **tests** (the test suite, run once per phase).
|
||||
|
||||
### 2.4 — Conventions
|
||||
|
||||
Read the root `CLAUDE.md` for project conventions — commit message style,
|
||||
@@ -122,9 +125,24 @@ preload) changes.
|
||||
- **Adepts**: Domain knowledge agents with persistent folders at `<workpad>/adepts/<domain-slug>/`.
|
||||
- **Pinned agents** (prefer these over generic tiers):
|
||||
<list of detected agents with name and description, or placeholder comment>
|
||||
- **Verification commands**: <detected commands, or placeholder comment>
|
||||
- **Domain skills to route to subagents when relevant**: <!-- detect and list, or leave as placeholder -->
|
||||
- **Conventions**: <summarized conventions from CLAUDE.md, or placeholder comment>
|
||||
|
||||
## Build
|
||||
|
||||
Read by `spire:implementation`. Unset means the skill's default; `none` means deliberately absent.
|
||||
|
||||
- **Gate** (cheap, between blocks): <detected gate commands, or placeholder comment>
|
||||
- **Tests** (once per phase): <detected test command, or placeholder comment>
|
||||
- **Checkout**: <!-- one checkout (default) | worktrees -->
|
||||
- **Branches**: <!-- who commits where; default: the branch the brief names -->
|
||||
- **Staging**: <!-- explicit paths (default) -->
|
||||
- **Owner models**: <!-- per block kind; default: Opus 5.5 for complex blocks, Sonnet for mechanical ones -->
|
||||
- **Brief constraints**: <!-- sensitive areas, e.g. generated files, migrations -->
|
||||
- **Host rules**: <!-- temp dirs, memory caps -->
|
||||
- **Build plan**: <!-- user sees it before the run (default) | skip -->
|
||||
|
||||
Personal overrides go in `.claude/spire/project.local.md` (gitignored, same headings). They win over this file.
|
||||
```
|
||||
|
||||
Fill every field that was detected; leave a `<!-- placeholder -->` comment for
|
||||
@@ -281,7 +299,9 @@ If `$INSTALL_TYPE` is **personal**:
|
||||
2. Check whether it already contains a line matching `spire/`.
|
||||
3. If not present, append `spire/` on its own line.
|
||||
|
||||
If `$INSTALL_TYPE` is **shared**, skip this phase entirely.
|
||||
If `$INSTALL_TYPE` is **shared**, append `spire/project.local.md` to
|
||||
`.claude/.gitignore` instead (if not already present), so personal overrides
|
||||
stay out of the repo.
|
||||
|
||||
---
|
||||
|
||||
@@ -339,4 +359,5 @@ After all phases, report to the user:
|
||||
- What was skipped (files with `status: authored`, phases that didn't apply)
|
||||
- Next steps: "Edit `.claude/spire/project.md` to fill in any remaining
|
||||
placeholders, then change `status` from `generated` to `authored` to
|
||||
lock it against future re-inits."
|
||||
lock it against future re-inits. Personal settings go in
|
||||
`.claude/spire/project.local.md`."
|
||||
|
||||
@@ -5,3 +5,7 @@ allowed-tools: Bash(cat:*)
|
||||
---
|
||||
|
||||
!`cat "${CLAUDE_PROJECT_DIR}/.claude/spire/project.md" 2>/dev/null || echo "No project config found. Run /spire:init to set up this project."`
|
||||
|
||||
Personal overrides (`.claude/spire/project.local.md`; these win over the above):
|
||||
|
||||
!`cat "${CLAUDE_PROJECT_DIR}/.claude/spire/project.local.md" 2>/dev/null || echo "(none)"`
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: research-tree
|
||||
description: Orchestrate multi-topic research as a dependency tree of parallel phases — not a flat fan-out of independent agents. Use this skill whenever the user asks for "research", "deep research", "investigate", "survey", or "look into" a topic that has multiple sub-topics, or when a question is broad enough that a single agent would either skim or take forever. Trigger especially when the user says things like "research X and Y and Z", "find out everything about…", "do a deep dive on…", or when prior research has surfaced new questions that need follow-up. Composes with the `workpad` skill for file placement and runs alongside `superpowers` and similar orchestration helpers.
|
||||
description: Orchestrate multi-topic research as a dependency tree of parallel phases — not a flat fan-out of independent agents. Use this skill whenever the user asks for "research", "deep research", "investigate", "survey", or "look into" a topic that has multiple sub-topics, or when a question is broad enough that a single agent would either skim or take forever. Trigger especially when the user says things like "research X and Y and Z", "find out everything about…", "do a deep dive on…", or when prior research has surfaced new questions that need follow-up. Composes with the `workpad` skill for file placement.
|
||||
---
|
||||
|
||||
# Research Tree
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
name: workpad
|
||||
description: Decides WHERE and WHEN to put working documents — reports, plans, goals, brainstorms, designs, journals, research, specs, tickets, bug notes. Use this skill whenever the user asks you to write a "report", "plan", "goal", "brainstorm", "design", "journal", "research note", "spec", or anything "in the workpad" — and also when another skill is about to drop a markdown file somewhere ad-hoc (e.g. a `superpowers/` subdirectory, the repo root, `/tmp`, or alongside source code). If a workpad exists, the workpad wins. This skill steers other skills toward a single, predictable place for markdown documents. Can be used together with any superpowers.
|
||||
description: Decides WHERE and WHEN to put working documents — reports, plans, goals, brainstorms, designs, journals, research, specs, tickets, bug notes. Use this skill whenever the user asks you to write a "report", "plan", "goal", "brainstorm", "design", "journal", "research note", "spec", or anything "in the workpad" — and also when another skill is about to drop a markdown file somewhere ad-hoc (e.g. a plugin's own `docs/<plugin>/` subdirectory, the repo root, `/tmp`, or alongside source code). If a workpad exists, the workpad wins. This skill steers other skills toward a single, predictable place for markdown documents, whichever plugin they come from.
|
||||
---
|
||||
|
||||
# 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 `superpowers/` 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.
|
||||
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.
|
||||
|
||||
## Where the workpad lives
|
||||
|
||||
|
||||
Reference in New Issue
Block a user