Compound Engineering Brainstorm
Turn vague or ambitious ideas into right-sized requirements-only unified plans through collaborative dialogue.
The skill requires running a setup script before executing the workflow, instructing the agent to follow its output but explicitly stating the skill's own rules win. It reads config files (config.local.yaml, config.yaml) to decide artifact root and validates that root to prevent path escape. It notes that actions like publishing to Proof, opening browser, and creating PRs are taken after user confirmation. No sensitive data handling or covert exfiltration found. However, publisher identity is unverified, and the skill involves executing arbitrary shell commands (setup script). Trust deducted for lack of independent permission audit (no full least-privilege application shown as the skill may run arbitrary commands without sandboxing) and unknown publisher identity. Overall, no egregious overreach apparent in static review.
The skill is highly structured with explicit instructions for config parsing (YAML comments handling), output format parsing (`output:` token), and config root resolution. It provides fallbacks for failure cases (e.g., continue if Node unavailable, fallback if root fails). However, static review cannot verify the scripts actually run, and there are complex interaction rules that may introduce inconsistency. No test suite provided covering skill's key paths. Reliability deducted for lack of execution evidence and potential contradictions in complex instructions.
The skill clearly defines audience and scenarios (for brainstorming, scoping, blindspot pass) and provides explicit non-fit boundaries (not for executing already-specified work, not for verdict on technology adoption). Trigger conditions are precisely defined in the description. Environment fit: the skill appears not to depend on unreachable overseas services; it uses local tools and a configurable Slack MCP (requires user auth). No apparent limitation for Chinese users. However, as a static read, actual fit in target environment not verified.
The skill provides highly structured documentation with progressive disclosure (main file plus reference files loaded on demand). It includes detailed setup instructions, parameter specifications (e.g., `output:` token), naming stability guidance (metadata field names), and known limitations (e.g., ce-doc-review is markdown-only). It mentions license (MIT) but not explicitly in skill file. Versioning and changelog info not visible in provided files. Maintenance responsibility not clearly assigned. Deducted for lack of clear changelog/versioning and missing maintainer identity.
The skill claims to produce a requirements-only unified plan with detailed structure and output guidance. It sets clear deliverables (unified plan artifact under `<root>/plans/`) and clear value proposition. However, actual quality or direct usability of generated documents cannot be verified in static review. Cost/benefit seems reasonable as skill aims to avoid over-engineering. Effectiveness deducted for lack of corroboration of actual artifact generation.
The skill's main claims (it can produce reliable unified plans) are not supported by any tests or third-party execution evidence. Some auditable details provided (like config parsing, artifact structure) but unverified. Publisher is unknown identity with no independent verification. Verifiability deducted for lack of reproducible tests or independent validation.
- Publisher identity not verified by FollowSkills enterprise registry: treat authority claims with caution.
- The skill requires running an arbitrary shell script at session start: inspect the script content before execution, especially in untrusted environments.
- The skill reads local YAML config files (.compound-engineering/config.*.yaml): ensure configuration is from a trusted source to avoid path traversal or misconfiguration.
- The skill may depend on external services (Slack MCP, Proof publishing): these require additional authentication and network reachability, which may be restricted in mainland China.
- The accuracy and completeness of generated unified plan artifacts are unverified independently.
What does this skill do, and when should you use it?
ce-brainstorm is a skill in the Compound Engineering plugin that helps users explore and scope features or problems through guided Q&A. It prioritizes answering 'what to build' by resolving product decisions (user-facing behavior, scope boundaries, success criteria) into a requirements-only unified plan, ready for downstream planning with ce-plan. The skill follows core principles like assessing scope first, being a thinking partner, keeping implementation details out of the product contract, and using one-question-at-a-time interaction with the platform's blocking question tool. It supports Markdown or HTML output and can resolve configuration for the artifact root. The skill works for software and non-software domains, though non-software brainstorms route to a dedicated universal flow.
The skill scans the repo for grounding (checking for existing similar artifacts, related documents), performs a product pressure test, then runs a collaborative dialogue with the user through scoping questions (one per turn) using the platform's native blocking question tool (e.g., Claude Code's AskUserQuestion or Codex's request_user_input). It resolves product decisions and drafts a requirements-only unified plan saved under <root>/plans/, or produces a more compact alignment document as appropriate. The skill runs a Node script to load skill context when available, and may dispatch subagents for background grounding and fact-checking when necessary. It can produce Markdown or HTML output based on input arguments.
- A product manager wants to scope a vague feature idea and align with engineers on what to build before planning starts.
- A developer working in an unfamiliar domain needs help mapping the decision surface and uncovering blind spots before attempting to build.
- A team wants to quickly assess the size of a rough improvement idea and determine whether it's large or small, requiring a concise requirements-only document to guide planning.
- A short requirements document or feature brief is needed as a handoff artifact to ce-plan for implementation planning.
- A stakeholder wants to validate whether a feature idea aligns with the existing product shape and success criteria before investing in development.
What are this skill's strengths and limitations?
- Avoids fixation on AI-generated framings by asking one question at a time and using the platform's native blocking question tool.
- Emphasizes scope assessment, tailoring the ceremony to the ambiguity and size of the work, avoiding unnecessary overhead.
- Separates product decisions (what to build) from implementation planning (how to build), enabling clearer handoffs.
- Supports both Markdown and HTML output, offering flexibility to fit into existing documentation workflows.
- Can resume prior work and build on existing artifacts rather than creating duplicates.
- Highly dependent on the underlying platform's mechanisms (e.g., Claude Code's AskUserQuestion or Codex's request_user_input), which may limit functionality on platforms without similar interactive primitives.
- Relies on a Node.js runtime to load skill context; if missing, the skill still runs but with reduced context.
- Requires parsing configuration to determine the artifact root (`docs_root`) and output format; misconfiguration may interrupt the flow.
- Intentionally excludes implementation details from the plan, requiring trust in the downstream planning phase to fill in technical solutions.
- As part of a larger plugin package, installing only this single skill may require manual selection, and installation commands vary significantly across tools.
How do you install this skill?
To install ce-brainstorm from the GitHub repository, follow the installation instructions in the README. For example, in Claude Code, run:
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineeringIn Cursor, run:
/add-plugin compound-engineeringFor Codex CLI, first register the marketplace:
codex plugin marketplace add EveryInc/compound-engineering-plugin
codex plugin add compound-engineering@compound-engineering-pluginFor other tools (like Kimi Code CLI, Cline, Grok Build CLI, Devin CLI, GitHub Copilot, Factory Droid, Qwen Code, OpenCode, Pi, Antigravity CLI), refer to the 'More Install Options' section in the README. After installation, no additional configuration is needed; the skill is available via /ce-brainstorm.
How do you use this skill?
Once installed, invoke /ce-brainstorm in your supported tool with the feature idea or problem as an argument. For example:
/ce-brainstorm make background job retries saferThe skill will guide you through a Q&A dialogue (one question at a time). It first scans the repository for grounding, then asks scoping questions, explores approaches, and confirms scope before writing the requirements plan. The final output is a requirements-only unified plan saved under <root>/plans/ (by default docs/plans/). You can request HTML output via an argument like output:html. The skill handles unfamiliar domains (blindspot pass), visual-related features (visual probes), and verdict-shaped questions (routing to ce-pov). As a fast path, if requirements are already clear, it skips unnecessary exploration.
How does this skill compare with similar options?
This skill is often used with ce-plan from the same plugin, which builds on the requirements-only plan to add implementation details. No direct comparison to other standalone tools is highlighted in the documentation.