exec-plans
Execution Plans (ExecPlans):
This document describes the requirements for an execution plan ("ExecPlan"), a design document that a coding agent can follow to deliver a working feature or system change. Treat the reader as a complete beginner to this repository: they have only the current working tree and the single ExecPlan file you provide. There is no memory of prior plans and no external context.
Integration with Plan Mode (Conflict Resolution)
If you are currently operating in "Plan Mode", you must reconcile the rules of Plan Mode with this ExecPlans specification. When generating the final plan, the rules here OVERRIDE Plan Mode's default constraints:
- Verbosity over Conciseness: Ignore Plan Mode's instructions to be "concise by default", use "3-5 short sections", or "avoid naming more than 3 paths". You MUST follow the comprehensive, verbose "Skeleton of a Good ExecPlan" defined below.
- Document Structure: ExecPlans are living documents. You must include the
Progresscheckboxes,Decision Log, and all other mandatory ExecPlan sections, ignoring Plan Mode's instruction to omit a Scope section. - Envelope/Formatting: To satisfy Plan Mode's tooling, you MUST wrap the final ExecPlan inside the
<proposed_plan>and</proposed_plan>XML tags. The content inside these tags should be the standard ExecPlan Markdown. - Process: Continue to rigorously follow Plan Mode's conversational phases (Phase 1, 2, 3) to explore, ask questions, and reach a decision-complete state BEFORE you output this ExecPlan.
How to use ExecPlans
When authoring an executable specification (ExecPlan), follow these guidelines to the letter. Be thorough in reading (and re-reading) source material to produce an accurate specification. When creating a spec, start from the skeleton and flesh it out as you do your research.
When implementing an executable specification (ExecPlan), do not prompt the user for "next steps"; simply proceed to the next milestone. Keep all sections up to date, add or split entries in the list at every stopping point to affirmatively state the progress made and next steps. Resolve ambiguities autonomously, and commit frequently.
More from noahacgn/codex-config
planning-and-task-breakdown
Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
7idea-refine
Refines ideas iteratively. Refine ideas through structured divergent and convergent thinking. Use "idea-refine" or "ideate" to trigger.
6api-and-interface-design
Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
6ci-cd-and-automation
Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.
6performance-optimization
Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing.
6using-agent-skills
Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
6