Skill Tracer
Skills › Compound Engineering › ce-brainstorm

ce-brainstorm

skill · 69 lines · MIT · skills/ce-brainstorm/SKILL.md

The facts

Its description

Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm or scope what to build. Not for executing already-specified work. Use ce-pov for a verdict on adopting a named external technology.

The description the agent reads to decide when to use it.

From its settingsline 3

When it starts

The agent picks this skill when the user wants to brainstorm, explore, or scope an idea or feature before anything is built — vague or ambitious requests that need shaping into requirements. It is not for executing already-specified work, and a verdict on adopting a named external technology goes to ce-pov instead.

Things a person might say (the model's guesses)

  • “I want to brainstorm a per-channel mute feature for notification rules.”
  • “Help me scope out this idea before we build anything.”
  • “I've got a vague idea for a new onboarding flow — can we think it through?”

A model's summary of when it is used.

A model's reading

What it takes when started

[feature idea or problem to explore] [output:html]

What to type after its name when you start it.

From its settingsline 4

Starts other agents

3 lines mention starting other agents

Lines in the file that mention starting another agent. Found by matching words, so treat them as pointers.

Found by matching wordsline 15 line 59 line 69

Files it mentions

references/phase-0.md, references/universal-brainstorming.md, references/handoff.md, references/interaction-rules.md, references/settled-decisions.md, references/output-mode.md (first 5 of 11 lines)

Files the text names, such as ones to read or write. Found by matching words, so treat them as pointers.

Found by matching wordsline 17 line 21 line 52 line 53 line 54

Stops for a person

1 line stops to ask a person

Lines that stop and wait for a person before going on. Found by matching words, so treat them as pointers.

Found by matching wordsline 19

What it leads to

Other skills this one hands off to, calls, requires or offers instead, as a model read them.

A model's reading

What leads to it

Other skills that hand off to this one, call it, require it or offer it instead, as a model read them.

A model's reading

Licence

MIT, from LICENSE

The terms its author shares it under, which let it be shown here.

From the repositorylicence text
Other files in this skill (25) Close

The text

Open on GitHub

Most marks come from matching words in the file, so treat them as pointers.

1---
2name: ce-brainstorm
3description: "Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm or scope what to build. Not for executing already-specified work. Use ce-pov for a verdict on adopting a named external technology."
4argument-hint: "[feature idea or problem to explore] [output:html]"
5---
6
7# Brainstorm a Feature or Improvement
8
9Brainstorming answers **WHAT** to build through dialogue; `ce-plan` then enriches the same unified plan artifact with **HOW**. This skill does not implement code.
11**Outcome:** a result sized to the work that `ce-plan` can build on without inventing product behavior, scope boundaries, or success criteria: a chat paragraph for Lightweight work, or a requirements-only unified plan under `<root>/plans/` when a file is earned.
13**Done, on the brainstorm path:** that artifact is written and passes the Ready for Planning Check — or no file was written because the dialogue produced no decision that a later reader (the planner, a reviewer, or a future reader) needs recorded under a stable ID and the user asked for none — and Phase 4's handoff has been presented.
15**Lightweight work ends in chat.** Phase 0.3 classifies the tier from the request and bounded inline reads before anything is dispatched; when the tier is uncertain, take the heavier one. Lightweight work — small, well-bounded, low ambiguity — ends in a chat paragraph with no file, no grounding scout, no approach generation, and no claim verifier. A file is earned only by a decision that a later reader needs recorded under a stable ID, or by the user asking for one.
17**Stop and route instead** in three cases, decided by `references/phase-0.md`, not from memory. Each ends the run its own way, so the done condition above does not apply: non-software work, where `references/universal-brainstorming.md` replaces Phases 0.2–4; a verdict question about a named external candidate, where you offer the `ce-pov` handoff; and neither — quick help, a factual question, a single-step task — answered directly.
19The feature description is what the invocation carries, whether the user wrote it or a calling skill passed it. If none came, ask the user what they want to explore and do not proceed until you have one.
21**`mode:return-to-caller`** (a leading token a calling skill such as `lfg` sets): strip it, run the dialogue unchanged, and replace Phase 4 with the structured return `references/handoff.md` defines: no menu, no `lfg` or `ce-plan` invocation.

Brainstorm a Feature or Improvement

Brainstorming answers WHAT to build through dialogue; ce-plan then enriches the same unified plan artifact with HOW. This skill does not implement code.

Outcome: a result sized to the work that ce-plan can build on without inventing product behavior, scope boundaries, or success criteria: a chat paragraph for Lightweight work, or a requirements-only unified plan under <root>/plans/ when a file is earned.

Done, on the brainstorm path: that artifact is written and passes the Ready for Planning Check — or no file was written because the dialogue produced no decision that a later reader (the planner, a reviewer, or a future reader) needs recorded under a stable ID and the user asked for none — and Phase 4's handoff has been presented.

Lightweight work ends in chat. Phase 0.3 classifies the tier from the request and bounded inline reads before anything is dispatched; when the tier is uncertain, take the heavier one. Lightweight work — small, well-bounded, low ambiguity — ends in a chat paragraph with no file, no grounding scout, no approach generation, and no claim verifier. A file is earned only by a decision that a later reader needs recorded under a stable ID, or by the user asking for one.

Stop and route instead in three cases, decided by references/phase-0.md, not from memory. Each ends the run its own way, so the done condition above does not apply: non-software work, where references/universal-brainstorming.md replaces Phases 0.2–4; a verdict question about a named external candidate, where you offer the ce-pov handoff; and neither — quick help, a factual question, a single-step task — answered directly.

The feature description is what the invocation carries, whether the user wrote it or a calling skill passed it. If none came, ask the user what they want to explore and do not proceed until you have one.

**mode:return-to-caller** (a leading token a calling skill such as lfg sets): strip it, run the dialogue unchanged, and replace Phase 4 with the structured return references/handoff.md defines: no menu, no lfg or ce-plan invocation.

Raw lines 1 to 23
Names a skill ce-plan :9
Starts an agent dispatched :15
Reads a file references/phase-0.md :17
Names a skill ce-pov :17
Involves a person ask the user :19
Names a skill lfg :21
Reads a file references/handoff.md :21
24## Artifact Root
26Resolve `<root>` the first time you compose or read a `<root>/` path, never earlier; a scratch-only or no-repo run that touches none skips this entirely.
28<!-- ce-docs-root:start -->
29**Resolve the CE artifact root `<root>` before composing any artifact path.**
31- **Read** `docs_root` from `<repo-root>/.compound-engineering/config.yaml` only (`<repo-root>` = `git rev-parse --show-toplevel`). Do not read it from `config.local.yaml`. Unset -> `<root>` is `docs`, exactly as before.
32- **Validate** a set value: a repo-relative directory whose real, symlink-resolved path stays inside the repo and is neither the repo root nor under `.git/`. Otherwise stop with an error naming `docs_root` and the value -- never fall back to `docs`.
33- **Use** `<root>` as the sole artifact location: create it if absent, compose each path as `<root>/<subdir>` with this skill's own subdirectory, and never also read `docs`.
34<!-- ce-docs-root:end -->
36`brainstorm_output` and `brainstorm_model` resolve by this rule instead:
38<!-- ce-config-layers:start -->
39**Resolve ordinary CE yaml keys from the two repo files.**
41- **Read** `<repo-root>/.compound-engineering/config.local.yaml`, then `config.yaml` (`<repo-root>` = `git rev-parse --show-toplevel`). Missing files are skipped. Gitignore does not change resolution.
42- **Win** with the first active (non-commented) value. For scalars, empty is unset; an invalid value continues to the next layer, then the skill default. For lists and maps, a present key — including an empty list or map — replaces the whole key.
43- **Do not** use this rule for `docs_root` — that key is `config.yaml` only.
44<!-- ce-config-layers:end -->

Artifact Root

Resolve <root> the first time you compose or read a <root>/ path, never earlier; a scratch-only or no-repo run that touches none skips this entirely.

<!-- ce-docs-root:start --> **Resolve the CE artifact root <root> before composing any artifact path.**

  • Read docs_root from <repo-root>/.compound-engineering/config.yaml only (<repo-root> = git rev-parse --show-toplevel). Do not read it from config.local.yaml. Unset -> <root> is docs, exactly as before.
  • Validate a set value: a repo-relative directory whose real, symlink-resolved path stays inside the repo and is neither the repo root nor under .git/. Otherwise stop with an error naming docs_root and the value -- never fall back to docs.
  • Use <root> as the sole artifact location: create it if absent, compose each path as <root>/<subdir> with this skill's own subdirectory, and never also read docs.

<!-- ce-docs-root:end -->

brainstorm_output and brainstorm_model resolve by this rule instead:

<!-- ce-config-layers:start --> Resolve ordinary CE yaml keys from the two repo files.

  • Read <repo-root>/.compound-engineering/config.local.yaml, then config.yaml (<repo-root> = git rev-parse --show-toplevel). Missing files are skipped. Gitignore does not change resolution.
  • Win with the first active (non-commented) value. For scalars, empty is unset; an invalid value continues to the next layer, then the skill default. For lists and maps, a present key — including an empty list or map — replaces the whole key.
  • Do not use this rule for docs_root — that key is config.yaml only.

<!-- ce-config-layers:end -->

Raw lines 24 to 45
46## Execution Flow
48Phases run in this order. Each names the files it cannot run correctly without: read them when you reach it, and never do its work from this table alone.
50| Phase | Read first | What only those files carry |
51|---|---|---|
52| before the first question, and for the whole run — non-software route included | Read `references/interaction-rules.md` | the Core Principles, and the Interaction Rules: one question per turn, ask only decisions the environment cannot settle, the blocking-question-tool default and the visual-probe gate that overrides it, when a question is genuinely open-ended, and the one `ce-prototype` routing test this skill states in full there |
53| before treating a decision the conversation carries as settled | Read `references/settled-decisions.md` | the settlement test; skipping it re-asks a decided question or promotes an unexamined assertion |
54| 0.0 output mode | `references/output-mode.md` | the `OUTPUT_FORMAT` precedence; the token-parsing convention |
55| 0.1–0.4 resume, classify, route, scope | `references/phase-0.md` | resume scan; the stop-and-route classification; scope tiers; the coherent-work gate (is this one piece of work?); both tripwires (visual or spatial features; unfamiliar territory); the task list |
56| 1 understand the idea | `references/dialogue.md` | context scan and grounding scout; opt-in Slack researcher; pressure test; blindspot and visual-probe gates; the conflict gate against existing `CONCEPTS.md` and verified code; Phase 1.3 exit condition |
57| 2–2.6 approaches, synthesis, verification | `references/approaches.md`, plus `references/synthesis-summary.md` before composing the synthesis | approach generation; model elevation; the scoping synthesis; the claim verifier |
58| 3 write the plan | `references/plan-write.md`, then `references/brainstorm-sections.md` and the rendering reference for the format | whether a doc is warranted; the section contract; the Ready for Planning Check |
59| 4 handoff | `references/handoff.md` | the option set and its visibility conditions; the rendering-mode rule; per-selection dispatch, including what `ce-plan` is passed; closing summaries |
61These rules hold without any read:
63**`OUTPUT_FORMAT` is exclusive** — markdown OR HTML, never both. The format is the first that applies: a request in this prompt, a preference the user stated earlier, config, then markdown, in every run including headless ones.
65**When a file is written on the brainstorm path the artifact contract does not change**: write to `<root>/plans/YYYY-MM-DD-HHMM-<type>-<topic>-plan.<md|html>`, with `HHMM` from local wall-clock time at write; frontmatter carries `artifact_contract: ce-unified-plan/v1` and `product_contract_source: ce-brainstorm`; the body is a Goal Capsule plus the Product Contract. Do **not** emit a Goal Launch Block or Reader Index. The non-software route writes none of this.
67**When a file is written, do not declare it written or enter Phase 4 while any check fails** in the Ready for Planning Check; a chat result enters Phase 4 (the handoff) with no check to run. An improvised handoff menu is the other silent failure: it shows options that should be hidden and passes the wrong input to the next skill.
69The Phase 1.1 grounding scout, the Phase 2.6 claim verifier, and the opt-in Slack researcher are tiered by task shape, never hardcoded to a model name; read `references/model-tiers.md` before dispatching one. Model elevation is a separate mechanism (`references/reasoning-elevation.md`).

Execution Flow

Phases run in this order. Each names the files it cannot run correctly without: read them when you reach it, and never do its work from this table alone.

PhaseRead firstWhat only those files carry
before the first question, and for the whole run — non-software route includedRead references/interaction-rules.mdthe Core Principles, and the Interaction Rules: one question per turn, ask only decisions the environment cannot settle, the blocking-question-tool default and the visual-probe gate that overrides it, when a question is genuinely open-ended, and the one ce-prototype routing test this skill states in full there
before treating a decision the conversation carries as settledRead references/settled-decisions.mdthe settlement test; skipping it re-asks a decided question or promotes an unexamined assertion
0.0 output modereferences/output-mode.mdthe OUTPUT_FORMAT precedence; the token-parsing convention
0.1–0.4 resume, classify, route, scopereferences/phase-0.mdresume scan; the stop-and-route classification; scope tiers; the coherent-work gate (is this one piece of work?); both tripwires (visual or spatial features; unfamiliar territory); the task list
1 understand the ideareferences/dialogue.mdcontext scan and grounding scout; opt-in Slack researcher; pressure test; blindspot and visual-probe gates; the conflict gate against existing CONCEPTS.md and verified code; Phase 1.3 exit condition
2–2.6 approaches, synthesis, verificationreferences/approaches.md, plus references/synthesis-summary.md before composing the synthesisapproach generation; model elevation; the scoping synthesis; the claim verifier
3 write the planreferences/plan-write.md, then references/brainstorm-sections.md and the rendering reference for the formatwhether a doc is warranted; the section contract; the Ready for Planning Check
4 handoffreferences/handoff.mdthe option set and its visibility conditions; the rendering-mode rule; per-selection dispatch, including what ce-plan is passed; closing summaries

These rules hold without any read:

**OUTPUT_FORMAT is exclusive** — markdown OR HTML, never both. The format is the first that applies: a request in this prompt, a preference the user stated earlier, config, then markdown, in every run including headless ones.

When a file is written on the brainstorm path the artifact contract does not change: write to <root>/plans/YYYY-MM-DD-HHMM-<type>-<topic>-plan.<md|html>, with HHMM from local wall-clock time at write; frontmatter carries artifact_contract: ce-unified-plan/v1 and product_contract_source: ce-brainstorm; the body is a Goal Capsule plus the Product Contract. Do not emit a Goal Launch Block or Reader Index. The non-software route writes none of this.

When a file is written, do not declare it written or enter Phase 4 while any check fails in the Ready for Planning Check; a chat result enters Phase 4 (the handoff) with no check to run. An improvised handoff menu is the other silent failure: it shows options that should be hidden and passes the wrong input to the next skill.

The Phase 1.1 grounding scout, the Phase 2.6 claim verifier, and the opt-in Slack researcher are tiered by task shape, never hardcoded to a model name; read references/model-tiers.md before dispatching one. Model elevation is a separate mechanism (references/reasoning-elevation.md).

Raw lines 46 to 69
Names a skill ce-prototype :52
Reads a file references/output-mode.md :54
Reads a file references/phase-0.md :55
Reads a file references/dialogue.md :56
Reads a file references/approaches.md :57
Reads a file references/plan-write.md :58
Reads a file references/handoff.md :59
Starts an agent dispatch :59
Names a skill ce-plan :59
Reads a file references/model-tiers.md :69
Starts an agent dispatching :69

From EveryInc/compound-engineering-plugin at 3449230, 2026-10-31. Skills read by DeepSeek V4.1 Flash on 2026-11-04. Summary and techniques by Claude Opus 5.5 on 2026-11-06.