Skip to content
cccskills
FreePublished on GitHub

ce-plan

Turn requirements for software or other multi-step work into a structured plan with an approach, constraints, and verification steps. It also helps develop existing plans, researching decisions before handing the work over for execution.

OriginalShow the original description

Create structured plans for multi-step work, including software and non-software tasks. Use when asked to plan, break down implementation, plan from requirements, or deepen an existing plan; prefer ce-brainstorm for exploratory framing.

See how to install

Good for

  • Planning implementation from requirements
  • Breaking complex work into manageable steps
  • Adding detail to an existing plan
  • Defining how completed work will be checked

Files included (36)

  • SKILL.md7.6 KB
  • references/agents/agent-native-planning-strategist.md4.6 KB
  • references/agents/architecture-strategist.md3.2 KB
  • references/agents/best-practices-researcher.md7.6 KB
  • references/agents/data-integrity-guardian.md3.2 KB
  • references/agents/framework-docs-researcher.md6.1 KB
  • references/agents/git-history-analyzer.md2.8 KB
  • references/agents/learnings-researcher.md19.7 KB
  • references/agents/pattern-recognition-specialist.md3.6 KB
  • references/agents/performance-oracle.md4.5 KB
  • references/agents/repo-research-analyst.md15.2 KB
  • references/agents/security-sentinel.md4.0 KB
  • references/agents/slack-researcher.md10.8 KB
  • references/agents/spec-flow-analyzer.md5.2 KB
  • references/agents/web-researcher.md9.5 KB
  • references/approach-altitude.md7.4 KB
  • references/bakeoff.md2.4 KB
  • references/deepening-workflow.md19.9 KB
  • references/final-review.md18.8 KB
  • references/html-rendering.md33.8 KB
  • references/intake.md19.7 KB
  • references/markdown-rendering.md10.6 KB
  • references/output-contracts.md2.8 KB
  • references/output-mode.md7.3 KB
  • references/plan-handoff.md21.3 KB
  • references/plan-sections.md29.1 KB
  • references/reasoning-elevation.md17.5 KB
  • references/research.md24.5 KB
  • references/resume.md9.6 KB
  • references/settled-decisions.md5.1 KB
  • references/structure.md20.8 KB
  • references/synthesis-summary.md27.9 KB
  • references/universal-planning.md15.3 KB
  • scripts/elevation-dispatch.sh13.2 KB
  • scripts/packs-resolve.py30.8 KB
  • scripts/peer-job-runner.py101.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Create Technical Plan

The current year is 2026.

Outcome: a plan for carrying out and checking the agreed work while preserving its outcome and constraints. Resolve technical choices from evidence; leave adequate instructions unchanged. ce-brainstorm defines WHAT, ce-plan plans HOW, and ce-work executes. A prior brainstorm is optional.

An explicit invocation always produces a plan. Never classify a direct invocation as "not a planning task" and route out. It may select any output contract below, and the smallest valid plan is a few sentences in chat.

Research, decide, and write the plan — never implement. Do not write production code, run tests, or learn from execution-time results. Directional pseudo-code and grammar sketches may communicate design; changing code to see what happens belongs in ce-work.

Mandatory Completion Contract

A run is complete when its output contract's done condition is met. Every normal interactive branch that produces a plan artifact or checkpoint is incomplete until the user has been asked what to do next. A request that already authorizes the next action is that answer. For a Durable software implementation-plan run that continues past the resume check, that means the Phase 5.4 menu has been presented and the selected action has actually fired. For Direct, the change stated and the handoff offered; for a Chat brief, the brief and its one-line save-or-ce-work offer in chat. Neither presents the Phase 5.4 menu. Non-software plans and approach-level plans end with the handoff their reference workflow defines. A run that only answers a question may end after the answer unless its reference requires a save or share step.

Writing the file, checking confidence, and running or explicitly skipping ce-doc-review are intermediate milestones. In pipeline mode, the run is complete only when the plan, the confidence check, and the non-interactive document-review state have been returned to the caller, which decides what happens next.

Interaction Method

Ask one question at a time through the host's blocking question tool already in the current tool list. Match by capability; never probe a user-facing tool to discover it. If none is listed or a real question call errors, render numbered choices in chat; never silently skip a required question. If no feature description was supplied, ask what to plan and wait.

Output Contract

Decide which output contract applies at the start of scoping (Phase 0.6), before choosing depth and before the scoping synthesis. It applies only when no resume route (Phase 0.1) fired and the source check (Phase 0.2) found no upstream artifact. Ground it with bounded inline reads of what the request names, without dispatching a subagent. Select one:

  • Direct — the work can be stated, done, and verified in one pass with no decision the user would weigh. State the change in a few sentences and offer the handoff to ce-work or the user; execution starts only with implementation authority, as references/output-contracts.md defines.
  • Chat brief — bounded work with at most one decision the user would weigh and no risk surface. Deliver it in chat and stop.
  • Durable — everything else. Continue the workflow below.

references/output-contracts.md defines Direct and Chat brief; read it when either is selected. When the tier is still uncertain after those reads, take the heavier one. If a read surfaces a decision the user would weigh, a risk surface, or multi-pass verification, move to the heavier tier before emitting anything. Durable regardless of size: a run with no synchronous user to act on chat this turn (pipeline, headless, goal- or scheduler-driven), a request whose wording asks for a plan, a plan file, or an output format, a request that continues an existing plan's item, and a risk surface — authentication, payments, migrations, external contracts.

Workflow

Phases run in order unless a reference routes out or short-circuits. Read a phase's required reference in full when you enter that phase; a read made before that phase does not satisfy it, and a reference named for the final steps is read again at its step even when already in context. If a required reference cannot be read, stop before the action it governs and report the blocker and recovery path; never reconstruct the missing rules from memory. In pipeline mode, every required-reference failure returns status: blocked, phase, blocker, and recovery_path; include artifact_path and preserve the artifact when one exists. Report blocked even when an artifact exists.

Phase 0: Output, Resume, and Scope

  1. Output first. Read references/output-mode.md before interpreting any phase. It defines token parsing, output and confirmation precedence, renderer selection, artifact location, and when a repository may be resolved.
  2. Resume, deepen, approach, and domain. Read references/resume.md before acting. It defines resuming an existing plan, enriching a requirements-only plan, deepening, approach-level planning, and the software/non-software split. Follow any terminal route it selects; otherwise continue.
  3. Source and scope. Read references/intake.md before Phase 0.2 and follow it through Phase 0.7. It defines finding and preserving the upstream artifact, routing out to bootstrap work, blocking questions, depth, named resources, and the scoping synthesis; the Output Contract decision above happens inside it. Do not pass a decision point that has not resolved.

Phases 1-4: Research and Compose

  1. Read references/research.md before gathering context.
  2. Read references/structure.md before resolving questions or structuring the plan.
  3. Compose from references/plan-sections.md plus the format-rendering reference selected by output-mode.md.

Phase 5: Review, Write, Deepen, and Hand Off

  1. Read references/final-review.md before the pre-write review; it defines Phase 5.1 through 5.3.2. On an interactive run from a brainstorm, the user sees the Phase 5.1.5 scoping synthesis in chat before the write: a confirmation to wait on, or its one-line auto-proceed announcement.
  2. Model elevation. Immediately before authoring, read references/reasoning-elevation.md, resolve the choice at this boundary, and follow it. Do not author until activation resolution has completed and any selected dispatch or transparent fallback has settled.
  3. In pipeline mode, evidence that invalidates a decision settled earlier in the session stops the write. Return the exact token settled-decision-invalidated, the decision, and the reason; do not resolve it silently.
  4. Write the plan before presenting options, then complete the confidence path final-review.md defines.

STOP. Read references/plan-handoff.md immediately before Phase 5.3.8 and 5.4 (document review and the handoff menu). Document review is mandatory for a Durable plan and the default is non-interactive (mode:non-interactive). In interactive software runs, ask exactly: "Plan ready at <absolute path to plan>. What would you like to do next?" Present its menu and wait. If the selection arrives after a user turn, reload references/plan-handoff.md before acting. Rendering the menu, receiving a selection, or announcing a route is not completion; execute the selected action.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

ce-babysit-pr

FreeSummary

Monitor an open GitHub pull request over time, respond to review feedback, and address automated check failures. Apply and push fixes, then report whether it appears ready to merge or what still blocks progress.

  • Monitoring a pull request until it appears ready to merge
  • Addressing review feedback as it arrives
  • Handling automated check failures during review
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

ce-bakeoff

FreeSummary

Develop independent solutions to a defined problem, compare them against shared requirements, and combine useful contributions into a coherent recommendation. An independent assessment and evidence checks support the selection, while unresolved tradeoffs and verification needs remain explicit.

  • Comparing concrete solutions to a defined problem
  • Developing rough options before choosing an approach
  • Comparing architectural or product proposals
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

ce-brainstorm

FreeSummary

Turn a vague feature idea into clear requirements through dialogue. Define what to build, its scope, and success criteria, then capture the result in a short chat summary or a requirements document ready for implementation planning.

  • Clarifying a vague feature idea
  • Narrowing the scope of an ambitious improvement
  • Documenting requirements before implementation planning
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

ce-code-review

FreeSummary

Review code changes or a pull request for bugs, effects on existing behavior, test gaps, and project standards. Receive findings supported by the code and a clear account of review coverage, with local fixes available when explicitly requested.

  • Reviewing a pull request before release
  • Checking changes for bugs and test gaps
  • Applying review findings locally
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

ce-commit

FreeSummary

Save working changes as local Git commits with messages that explain the outcome. Follow the project's commit style, select files explicitly, and split clearly separate changes into a few logical commits when appropriate.

  • Saving completed work as a local commit
  • Writing messages that explain the outcome
  • Separating unrelated changes into commits
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

Commit and push code changes, then open a pull request with a clear title and description. You can also draft or update PR descriptions and hand published requests to the follow-up monitoring workflow.

  • Committing changes and opening a pull request
  • Drafting only a PR title and description
  • Updating an existing PR description
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

See all skills by EveryInc

Report a problem with this skill