From compound-engineering
[BETA] Transform feature descriptions or requirements into structured implementation plans grounded in repo patterns and research. Use when the user says 'plan this', 'create a plan', 'write a tech plan', 'plan the implementation', 'how should we build', 'what's the approach for', 'break this down', or when a brainstorm/requirements document is ready for technical planning. Best when requirements are at least roughly defined; for exploratory or ambiguous requests, prefer ce:brainstorm first.
npx claudepluginhub apollostreetcompany/codex-compound --plugin compound-engineeringThis skill uses the workspace's default tool permissions.
**Note: The current year is 2026.** Use this when dating plans and searching for recent documentation.
Generates structured implementation plans from feature descriptions or requirements, grounded in repo patterns and research. Deepens existing plans via interactive sub-agent review.
Creates structured plans for multi-step tasks including software features, implementations, research, or projects. Deepens plans via interactive sub-agent reviews.
Creates structured plans for multi-step tasks like software features, research workflows, events, or study plans. Deepens existing plans with interactive sub-agent reviews.
Share bugs, ideas, or general feedback.
Note: The current year is 2026. Use this when dating plans and searching for recent documentation.
ce:brainstorm defines WHAT to build. ce:plan defines HOW to build it. ce:work executes the plan.
This workflow produces a durable implementation plan. It does not implement code, run tests, or learn from execution-time results. If the answer depends on changing code and seeing what happens, that belongs in ce:work, not here.
Use the platform's question tool when available. When asking the user a question, prefer the platform's blocking question tool if one exists (AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.
Ask one question at a time. Prefer a concise single-select choice when natural options exist.
<feature_description> #$ARGUMENTS </feature_description>
If the feature description above is empty, ask the user: "What would you like to plan? Please describe the feature, bug fix, or improvement you have in mind."
Do not proceed until you have a clear planning input.
ce:brainstorm produced a requirements document, planning should build from it rather than re-inventing behavior.Every plan should contain:
A plan is ready when an implementer can start confidently without needing the plan to write the code for them.
If the user references an existing plan file or there is an obvious recent matching plan in docs/plans/:
Before asking planning questions, search docs/brainstorms/ for files matching *-requirements.md.
Relevance criteria: A requirements document is relevant if:
If multiple source documents match, ask which one to use using the platform's blocking question tool when available (see Interaction Method). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.
If a relevant requirements document exists:
(see origin: <source-path>)If no relevant requirements document exists, planning may proceed from the user's request directly.
If no relevant requirements document exists:
ce:brainstorm firstThe planning bootstrap should establish:
Keep this bootstrap brief. It exists to preserve direct-entry convenience, not to replace a full brainstorm.
If the bootstrap uncovers major unresolved product questions:
ce:brainstorm againIf the origin document contains Resolve Before Planning or similar blocking questions:
If true product blockers remain:
ce:brainstorm to resolve themClassify the work into one of these plan depths:
If depth is unclear, ask one targeted question and then continue.
Prepare a concise planning context summary (a paragraph or two) to pass as input to the research agents:
Run these agents in parallel:
Collect:
docs/solutions/Decide whether the plan should carry a lightweight execution posture signal.
Look for signals such as:
Execution target: external-delegate to implementation units that are pure code writingWhen the signal is clear, carry it forward silently in the relevant implementation units.
Ask the user only if the posture would materially change sequencing or risk and cannot be responsibly inferred.
Based on the origin document, user signals, and local findings, decide whether external research adds value.
Read between the lines. Pay attention to signals from the conversation so far:
Leverage repo-research-analyst's technology context:
The repo-research-analyst output includes a structured Technology & Infrastructure summary. Use it to make sharper external research decisions:
Always lean toward external research when:
Skip external research when:
Announce the decision briefly before continuing. Examples:
If Step 1.2 indicates external research is useful, run these agents in parallel:
Summarize:
For Standard or Deep plans, or when user flow completeness is still unclear, run:
Use the output to:
Build a planning question list from:
For each question, decide whether it should be:
Ask the user only when the answer materially affects architecture, scope, sequencing, or risk and cannot be responsibly inferred. Use the platform's blocking question tool when available (see Interaction Method).
Do not run tests, build the app, or probe runtime behavior in this phase. The goal is a strong plan, not partial execution.
feat: Add user authentication or fix: Prevent checkout double-submitfeat, fix, or refactordocs/plans/YYYY-MM-DD-NNN-<type>-<descriptive-name>-beta-plan.md
docs/plans/ if it does not exist-beta before -plan to distinguish from stable-generated plans2026-01-15-001-feat-user-authentication-flow-beta-plan.md, 2026-02-03-002-fix-checkout-race-condition-beta-plan.mdFor Standard or Deep plans, briefly consider who is affected by this change — end users, developers, operations, other teams — and how that should shape the plan. For cross-cutting work, note affected parties in the System-Wide Impact section.
Break the work into logical implementation units. Each unit should represent one meaningful change that an implementer could typically land as an atomic commit.
Good units are:
Avoid:
Before detailing implementation units, decide whether an overview would help a reviewer validate the intended approach. This section communicates the shape of the solution — how pieces fit together — without dictating implementation.
When to include it:
| Work involves... | Best overview form |
|---|---|
| DSL or API surface design | Pseudo-code grammar or contract sketch |
| Multi-component integration | Mermaid sequence or component diagram |
| Data pipeline or transformation | Data flow sketch |
| State-heavy lifecycle | State diagram |
| Complex branching logic | Flowchart |
| Single-component with non-obvious shape | Pseudo-code sketch |
When to skip it:
Choose the medium that fits the work. Do not default to pseudo-code when a diagram communicates better, and vice versa.
Frame every sketch with: "This illustrates the intended approach and is directional guidance for review, not implementation specification. The implementing agent should treat it as context, not code to reproduce."
Keep sketches concise — enough to validate direction, not enough to copy-paste into production.
For each unit, include:
Every feature-bearing unit should include the test file path in **Files:**.
Use Execution note sparingly. Good uses include:
Execution note: Start with a failing integration test for the request/response contract.Execution note: Add characterization coverage before modifying this legacy parser.Execution note: Implement new domain behavior test-first.Execution note: Execution target: external-delegateDo not expand units into literal RED/GREEN/REFACTOR substeps.
If something is important but not knowable yet, record it explicitly under deferred implementation notes rather than pretending to resolve it in the plan.
Examples:
Use one planning philosophy across all depths. Change the amount of detail, not the boundary between planning and execution.
Lightweight
Standard
Deep
For sufficiently large, risky, or cross-cutting work, add the sections that genuinely help:
Do not add these as boilerplate. Include them only when they improve execution quality or stakeholder alignment.
Omit clearly inapplicable optional sections, especially for Lightweight plans.
---
title: [Plan Title]
type: [feat|fix|refactor]
status: active
date: YYYY-MM-DD
origin: docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md # include when planning from a requirements doc
deepened: YYYY-MM-DD # optional, set later by deepen-plan-beta when the plan is substantively strengthened
---
# [Plan Title]
## Overview
[What is changing and why]
## Problem Frame
[Summarize the user/business problem and context. Reference the origin doc when present.]
## Requirements Trace
- R1. [Requirement or success criterion this plan must satisfy]
- R2. [Requirement or success criterion this plan must satisfy]
## Scope Boundaries
- [Explicit non-goal or exclusion]
## Context & Research
### Relevant Code and Patterns
- [Existing file, class, component, or pattern to follow]
### Institutional Learnings
- [Relevant `docs/solutions/` insight]
### External References
- [Relevant external docs or best-practice source, if used]
## Key Technical Decisions
- [Decision]: [Rationale]
## Open Questions
### Resolved During Planning
- [Question]: [Resolution]
### Deferred to Implementation
- [Question or unknown]: [Why it is intentionally deferred]
<!-- Optional: Include this section only when the work involves DSL design, multi-component
integration, complex data flow, state-heavy lifecycle, or other cases where prose alone
would leave the approach shape ambiguous. Omit it entirely for well-patterned or
straightforward work. -->
## High-Level Technical Design
> *This illustrates the intended approach and is directional guidance for review, not implementation specification. The implementing agent should treat it as context, not code to reproduce.*
[Pseudo-code grammar, mermaid diagram, data flow sketch, or state diagram — choose the medium that best communicates the solution shape for this work.]
## Implementation Units
- [ ] **Unit 1: [Name]**
**Goal:** [What this unit accomplishes]
**Requirements:** [R1, R2]
**Dependencies:** [None / Unit 1 / external prerequisite]
**Files:**
- Create: `path/to/new_file`
- Modify: `path/to/existing_file`
- Test: `path/to/test_file`
**Approach:**
- [Key design or sequencing decision]
**Execution note:** [Optional test-first, characterization-first, external-delegate, or other execution posture signal]
**Technical design:** *(optional -- pseudo-code or diagram when the unit's approach is non-obvious. Directional guidance, not implementation specification.)*
**Patterns to follow:**
- [Existing file, class, or pattern]
**Test scenarios:**
- [Specific scenario with expected behavior]
- [Edge case or failure path]
**Verification:**
- [Outcome that should hold when this unit is complete]
## System-Wide Impact
- **Interaction graph:** [What callbacks, middleware, observers, or entry points may be affected]
- **Error propagation:** [How failures should travel across layers]
- **State lifecycle risks:** [Partial-write, cache, duplicate, or cleanup concerns]
- **API surface parity:** [Other interfaces that may require the same change]
- **Integration coverage:** [Cross-layer scenarios unit tests alone will not prove]
## Risks & Dependencies
- [Meaningful risk, dependency, or sequencing concern]
## Documentation / Operational Notes
- [Docs, rollout, monitoring, or support impacts when relevant]
## Sources & References
- **Origin document:** [docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md](path)
- Related code: [path or symbol]
- Related PRs/issues: #[number]
- External docs: [url]
For larger Deep plans, extend the core template only when useful with sections such as:
## Alternative Approaches Considered
- [Approach]: [Why rejected or not chosen]
## Success Metrics
- [How we will know this solved the intended problem]
## Dependencies / Prerequisites
- [Technical, organizational, or rollout dependency]
## Risk Analysis & Mitigation
- [Risk]: [Mitigation]
## Phased Delivery
### Phase 1
- [What lands first and why]
### Phase 2
- [What follows and why]
## Documentation Plan
- [Docs or runbooks to update]
## Operational / Rollout Notes
- [Monitoring, migration, feature flag, or rollout considerations]
- [ ] syntax for progress trackingRED/GREEN/REFACTOR instructionsBefore finalizing, check:
ce:brainstormExecution noteIf the plan originated from a requirements document, re-read that document and verify:
ce:brainstormREQUIRED: Write the plan file to disk before presenting any options.
Use the Write tool to save the complete plan to:
docs/plans/YYYY-MM-DD-NNN-<type>-<descriptive-name>-beta-plan.md
Confirm:
Plan written to docs/plans/[filename]
Pipeline mode: If invoked from an automated workflow such as LFG, SLFG, or any disable-model-invocation context, skip interactive questions. Make the needed choices automatically and proceed to writing the plan.
After writing the plan file, present the options using the platform's blocking question tool when available (see Interaction Method). Otherwise present numbered options in chat and wait for the user's reply before proceeding.
Question: "Plan ready at docs/plans/YYYY-MM-DD-NNN-<type>-<name>-beta-plan.md. What would you like to do next?"
Options:
/deepen-plan-beta - Stress-test weak sections with targeted research when the plan needs more confidencedocument-review skill - Improve the plan through structured document review/ce:work - Begin implementing this plan in the current environment/ce:work in another session - Begin implementing in a separate agent session when the current platform supports itBased on selection:
docs/plans/<plan_filename>.md using the current platform's file-open or editor mechanism (e.g., open on macOS, xdg-open on Linux, or the IDE's file-open API)/deepen-plan-beta → Call /deepen-plan-beta with the plan pathdocument-review skill → Load the document-review skill with the plan pathCONTENT=$(cat docs/plans/<plan_filename>.md)
TITLE="Plan: <plan title from frontmatter>"
RESPONSE=$(curl -s -X POST https://www.proofeditor.ai/share/markdown \
-H "Content-Type: application/json" \
-d "$(jq -n --arg title "$TITLE" --arg markdown "$CONTENT" --arg by "ai:compound" '{title: $title, markdown: $markdown, by: $by}')")
PROOF_URL=$(echo "$RESPONSE" | jq -r '.tokenUrl')
Display View & collaborate in Proof: <PROOF_URL> if successful, then return to the options/ce:work → Call /ce:work with the plan path/ce:work in another session → If the current platform supports launching a separate agent session, start /ce:work with the plan path there. Otherwise, explain the limitation briefly and offer to run /ce:work in the current session instead.If running with ultrathink enabled, or the platform's reasoning/effort level is set to max or extra-high, automatically run /deepen-plan-beta only when the plan is Standard or Deep, high-risk, or still shows meaningful confidence gaps in decisions, sequencing, system-wide impact, risks, or verification.
When the user selects "Create Issue", detect their project tracker from AGENTS.md or, if needed for compatibility, CLAUDE.md:
Look for project_tracker: github or project_tracker: linear
If GitHub:
gh issue create --title "<type>: <title>" --body-file <plan_path>
If Linear:
linear issue create --title "<title>" --description "$(cat <plan_path>)"
If no tracker is configured:
AGENTS.md for future runsAfter issue creation:
/ce:workNEVER CODE! Research, decide, and write the plan.