ce-brainstorm

SKILL.md

Brainstorm a Feature or Improvement

Note: The current year is 2026. Use this when dating requirements-only unified plans.

Brainstorming helps answer WHAT to build through collaborative dialogue. It precedes /ce-plan, which enriches the same unified plan artifact with HOW to build it.

The durable output of this workflow is a requirements-only unified plan. In other workflows this might be called a lightweight PRD or feature brief. In compound engineering, keep the workflow name brainstorm, but write the first version of the plan artifact under docs/plans/ with artifact_readiness: requirements-only so planning does not need to invent product behavior, scope boundaries, or success criteria.

This skill does not implement code. It explores, clarifies, and documents decisions for later planning or execution.

Core Principles

Assess scope first - Match the amount of ceremony to the size and ambiguity of the work.

Be a thinking partner - Suggest alternatives, challenge assumptions, and explore what-ifs instead of only extracting requirements.

Resolve product decisions here - User-facing behavior, scope boundaries, and success criteria belong in this workflow. Detailed implementation belongs in planning.

Keep implementation out of the Product Contract by default - Do not include libraries, schemas, endpoints, file layouts, or code-level design unless the brainstorm itself is inherently about a technical or architectural change.

Right-size the artifact - Simple work gets a compact requirements-only unified plan or brief alignment. Larger work gets a fuller Product Contract. Do not add ceremony that does not help planning.

Apply YAGNI to carrying cost, not coding effort - Prefer the simplest approach that delivers meaningful value. Avoid speculative complexity and hypothetical future-proofing, but low-cost polish or delight is worth including when its ongoing cost is small and easy to maintain.