ce-babysit-pr
Babysits an open GitHub PR until merge-ready, first judging whether an old PR still belongs. Use when asked to watch a PR over…
Generate and evaluate grounded ideas. Use when the user wants ideas, improvements, or surprising directions before choosing one to develop. Not for refining an idea they already have (ce-brainstorm) or judging one already on the table (ce-pov).
Claude Code
$ npx -y skills add everyinc/compound-engineering-plugin --skill ce-ideate --agent claude-code
Codex
$ npx skills add everyinc/compound-engineering-plugin --skill ce-ideate -a codex -y
Cursor
$ npx skills add everyinc/compound-engineering-plugin --skill ce-ideate -a cursor -y
Gemini CLI
$ npx skills add everyinc/compound-engineering-plugin --skill ce-ideate -a gemini-cli -y
GitHub Copilot
$ npx skills add everyinc/compound-engineering-plugin --skill ce-ideate -a github-copilot -y
OpenCode
$ npx skills add everyinc/compound-engineering-plugin --skill ce-ideate -a opencode -y
Windsurf
$ npx skills add everyinc/compound-engineering-plugin --skill ce-ideate -a windsurf -y
name: ce-ideate description: "Generate and evaluate grounded ideas. Use when the user wants ideas, improvements, or surprising directions before choosing one to develop. Not for refining an idea they already have (ce-brainstorm) or judging one already on the table (ce-pov)." argument-hint: "[feature, focus area, or constraint] [output:md]"
`ce-ideate` runs before `ce-brainstorm`. This skill answers "which ideas are worth exploring?" `ce-brainstorm` then answers what one chosen idea should mean. `ce-plan` answers how it gets built.
**Done:** a ranked ideation artifact is written to `<root>/ideation/` when that root is present, else to a CE temp path. Every idea generated has been critiqued, and the survivors are explained. The user is left holding the next-steps menu. No requirements, plans, or code.
1. **Ground before ideating.** No advice detached from the repo. 2. **Generate many, critique all, explain survivors only.** Generate the full candidate list before critiquing any of it. Rejection is explicit and carries a reason; this is not optimistic ranking. 3. **Send the user to brainstorming for action.** Never skip from ideation output to planning. 4. **Never dispatch on an unidentified subject.** Ask instead, through the host's blocking question tool already in the current tool list (match by capability, not by a host-specific name). Presence in the current tool list is proof the tool exists; never call a user-facing question tool to discover whether it exists. If a matching tool is listed but unloaded, use the host's tool-discovery primitive to load that capability — do not search for another host's tool name. Where no such tool is in the list, or a real question call errors, offer numbered options on the user-visible surface. Never skip a question silently. Keep "Surprise me" a real option, alongside a Cancel that exits cleanly. Do not ask about solution direction, constraints, audience, tone, or success criteria; `ce-brainstorm` asks those. If it takes more than 3 questions, ideation is the wrong workflow. 5. **Never print the internal taxonomy label.** The labels `repo-grounded`, `elsewhere-software`, and `elsewhere-non-software` only decide which agents to dispatch. Describe the mode to the user in the topic's own words. 6. **Warn and proceed when grounding fails.** 7. **Show the user the cost line before dispatching.**
The **focus hint** is any optional context this run was invoked with, from the user or from a calling skill. The rest of this skill calls it `{focus_hint}`.
Artifacts go under `<root>/ideation/`, and learnings are read from `<root>/solutions/`. Resolve `<root>` only when you are about to compose one of those paths, and never before the mode is classified — an elsewhere or no-repo run writes to a temp directory and never needs it. Pass a subagent the resolved path, not the config.
<!-- ce-docs-root:start --> **Resolve the CE artifact root `<root>` before composing any artifact path.**
<!-- ce-docs-root:end -->
Both reads this phase names are required, even when the subject, mode, and format look clear. Those two references define the resume check, the format decision, and the scope classification. Nothing here is resolved before reading them.
**Output mode is exclusive.** A run produces HTML (`.html`) or markdown (`.md`), never both. Precedence runs from a request in this prompt, through a stated user preference and config (`ideate_output:`), down to the `html` default; a headless run resolves the format the same way, with no pipeline override.
Read `references/output-mode.md` whenever a format is resolved. The read is required. It defines each step of the decision, and the 30-day recent-work check that decides whether this run updates an existing doc instead of writing a new one.
<!-- ce-config-layers:start --> **Resolve ordinary CE yaml keys from the two repo files.**
<!-- ce-config-layers:end -->
**Non-software routing.** A topic that is not about software runs elsewhere-mode grounding rather than the repo scan. It then follows `references/universal-ideation.md` in place of Phase 2's frames and the Phase 5 menu. The deliverable is still written automatically.
**The Phase 0 checks.** `references/scope-gates.md` defines every Phase 0 check, plus what changes in surprise-me and tactical runs. Ask when the subject is not identifiable. `go deep` beats a tactical signal.
Read `references/grounding.md` before dispatching any grounding agent. The read is required. That reference defines every dispatch in this phase, including the routing test that runs *before* either dispatch block. Grounding runs in parallel, in the **foreground**.
A generic subagent is one whose whole b
AI skills that make each unit of engineering work easier than the last. Compound Engineering is a plugin of 37 skills for AI coding agents.
Babysits an open GitHub PR until merge-ready, first judging whether an old PR still belongs. Use when asked to watch a PR over…
Develop independent competing solutions to a defined brief, compare them, and synthesize a winning approach. Use when choosing…
Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm or…
Review a named diff or PR for bugs, regressions, tests, and standards. Use when asked to review code or when a shipping skill…
Commit, push, and open a PR. Use when asked to ship/open a PR, or for PR-description-only flows like writing, rewriting, or…
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.