Menu
Create, update, revise, reopen, or rescope a plan or ExecPlan using `PLANS.md`. Use when an agent needs to create a plan, plan a change, update the plan with new requirements, or rewrite an active ExecPlan.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Author CLI surfaces as agent-facing documentation, especially `--help` and actionable error messages. Use with any language or parser design when adding or changing a CLI interface, improving help text or validation errors, moving command reference out of AGENTS.md / CLAUDE.md / a README / a skill and into CLI surfaces, or making errors suggest the corrected command line or tool call.
Create or revise repository `AGENTS.md` files using a progressive-disclosure, dispatcher-style structure. Use when an agent needs to author or edit a top-level or directory-local `AGENTS.md`, convert a long instruction file into task-oriented "Start Here for ..." sections, add a concise "Must Follow" section with Always/Never rules, improve skill-discovery cues, or decide whether guidance belongs in root `AGENTS.md`, deeper docs, local `AGENTS.md`, or a repository-local skill.
Create or revise repository `ARCHITECTURE.md` files as short, stable architecture codemaps. Use when an agent needs to author or edit `ARCHITECTURE.md`, restructure an architecture document around a bird's-eye view and code map, clarify system boundaries, add architectural invariants or cross-cutting concerns, or decide which implementation detail should stay out of `ARCHITECTURE.md` and live in deeper design documents instead.
Create or revise Markdown `description` frontmatter so `docgarden match` routes agents to the right repository documents. Use when adding a new routed Markdown document, updating existing frontmatter, fixing noisy or missing match results, tuning skills or docs discovery, or making descriptions more query-aligned without loading document bodies.
Review the current branch, PR, or worktree against the plan or ExecPlan and record findings. Use when an agent needs a code review with findings for changes associated with an active plan.
Implement from an active plan or ExecPlan while keeping it up to date. Use when an agent needs to implement the active plan, continue plan-driven work, resume the current plan, or carry out an existing ExecPlan.
| name | planner-execplan |
| description | Create, update, revise, reopen, or rescope a plan or ExecPlan using `PLANS.md`. Use when an agent needs to create a plan, plan a change, update the plan with new requirements, or rewrite an active ExecPlan. |
| metadata | {"internal":true} |
Use this skill when the task is to shape the plan itself rather than to implement from it.
MUST READ before drafting or substantially revising any ExecPlan:
docs/PLANS.mddocs/CODESTYLE.mddocs/TESTING.mdPLANS.md defines the required ExecPlan structure, lifecycle, and maintenance rules.
Use the principles in CODESTYLE.md and TESTING.md to shape the plan's scope, acceptance criteria, sequencing, and validation. Do not write a plan that narrows away work required by those documents.
Then read the current ExecPlan, if one already exists, plus the nearby design docs and code context needed to make the plan self-contained.
The planner's final deliverable is a repository-local ExecPlan Markdown file, not only a chat summary.
When creating a new ExecPlan, write it to the repo's active ExecPlan location before ending the planner phase. If the repo follows the standard layout, use docs/exec-plans/active/<descriptive-name>.md.
Do not hand off to generator-execplan until the ExecPlan file exists in the working tree, contains the decision-complete plan, and you have checked off the Planner items in the Definition of Done section.
In your planner response, explicitly name the ExecPlan path you created or updated so the next phase can pick up the right artifact.
As planner, you own:
Once implementation has started, only the planner may substantially rewrite those parts of the ExecPlan.
You do not own:
Use the planner when the task is to create, rewrite, reopen, or rescope the plan itself.
Do not use the planner to continue implementation from an existing plan; use generator-execplan for that. Do not use the planner to perform completion review or validation; use evaluator-execplan for that.
When requirements or success criteria change in a way that affects what "done" means, hand the plan back to the planner and revise the ExecPlan file before more implementation continues.
The planner's job is to make the plan decision-complete, persist it as the active ExecPlan artifact, and leave it ready for implementation and later evaluation, following PLANS.md.