Marketplace plan
Plan lifecycle management for Codex plans stored in $CODEX_HOME/plans (default ~/.codex/plans). Use when a user asks to create, find, read, update, delete, or manage plan documents for implementation work or overview/reference documentation.
git clone https://github.com/aiskillstore/marketplace
T=$(mktemp -d) && git clone --depth=1 https://github.com/aiskillstore/marketplace "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/benderfendor/plan" ~/.claude/skills/aiskillstore-marketplace-plan-1a0553 && rm -rf "$T"
skills/benderfendor/plan/SKILL.mdPlan
Overview
Create and manage plan documents on disk. Plans stored on disk are markdown files with YAML frontmatter and free-form content. When drafting in chat, output only the plan body without frontmatter; add frontmatter only when stashing to disk. Support both implementation plans and overview/reference plans. Only write to the plans folder; do not modify the repository codebase.
Core rules
- Resolve the plans directory as
or$CODEX_HOME/plans
when~/.codex/plans
is not set.CODEX_HOME - Create the plans directory if it does not exist.
- Never write to the repo; only read files to understand context.
- Require frontmatter with only
andname
(single-line values) for on-disk plans.description - When presenting a draft plan in chat, omit frontmatter and start at
.# Plan - Enforce naming rules: short, lower-case, hyphen-delimited; filename must equal
.<name>.md - If a plan is not found, state it clearly and offer to create one.
- Allow overview-style plans that document flows, architecture, or context without a work checklist.
Decide the task
- Find/list: discover plans by frontmatter summary; confirm if multiple matches exist.
- Read/use: validate frontmatter; present summary and full contents.
- Create: inspect repo read-only; choose plan style (implementation vs overview); draft plan; write to plans directory only.
- Update: load plan; revise content and/or description; preserve frontmatter keys; overwrite the plan file.
- Delete: confirm intent, then remove the plan file if asked.
Plan discovery
- Prefer
for quick summaries.scripts/list_plans.py - Use
to validate a specific plan.scripts/read_plan_frontmatter.py - If name mismatches filename or frontmatter is missing fields, call it out and ask whether to fix.
Plan creation workflow
- Read relevant docs and entry points (
,README.md
, key modules) to scope requirements.docs/ - Identify scope, constraints, and data model/API implications (or capture existing behavior for an overview).
- Draft either an ordered implementation plan or a structured overview plan with diagrams/notes as needed.
- Immediately output the plan body only (no frontmatter), then ask the user if they want to 1. Make changes, 2. Implement it, 3. Stash it as per plan.
- If the user wants to stash it, prepend frontmatter and save the plan under the computed plans directory using
.scripts/create_plan.py
Plan update workflow
- Re-read the plan and related code/docs before updating.
- Keep the plan name stable unless the user explicitly wants a rename.
- If renaming, update both frontmatter
and filename together.name
Scripts (low-freedom helpers)
Create a plan file (body only; frontmatter is written for you). Run from the plan skill directory:
python ./scripts/create_plan.py \ --name codex-rate-limit-overview \ --description "Scope and update plan for Codex rate limiting" \ --body-file /tmp/plan-body.md
Read frontmatter summary for a plan (run from the plan skill directory):
python ./scripts/read_plan_frontmatter.py ~/.codex/plans/codex-rate-limit-overview.md
List plan summaries (optional filter; run from the plan skill directory):
python ./scripts/list_plans.py --query "rate limit"
Plan file format
Use one of the structures below for the plan body. When drafting, output only the body (no frontmatter). When stashing, prepend this frontmatter:
--- name: <plan-name> description: <1-line summary> ---
Implementation plan body template
# Plan <1-3 sentences: intent, scope, and approach.> ## Requirements - <Requirement 1> - <Requirement 2> ## Scope - In: - Out: ## Files and entry points - <File/module/entry point 1> - <File/module/entry point 2> ## Data model / API changes - <If applicable, describe schema or contract changes> ## Action items [ ] <Step 1> [ ] <Step 2> [ ] <Step 3> [ ] <Step 4> [ ] <Step 5> [ ] <Step 6> ## Testing and validation - <Tests, commands, or validation steps> ## Risks and edge cases - <Risk 1> - <Risk 2> ## Open questions - <Question 1> - <Question 2>
Overview plan body template
# Plan <1-3 sentences: intent and scope of the overview.> ## Overview <Describe the system, flow, or architecture at a high level.> ## Diagrams <Include text or Mermaid diagrams if helpful.> ## Key file references - <File/module/entry point 1> - <File/module/entry point 2> ## Auth / routing / behavior notes - <Capture relevant differences (e.g., auth modes, routing paths).> ## Current status - <What is live today vs pending work, if known.> ## Action items - None (overview only). ## Testing and validation - None (overview only). ## Risks and edge cases - None (overview only). ## Open questions - None.
Writing guidance
- Keep action items ordered and concrete; include file/entry-point hints.
- For overview plans, keep action items minimal and set sections to "None" when not applicable.
- Always include testing/validation and risks/edge cases in implementation plans.
- Use open questions only when necessary (max 3).
- If a section is not applicable, note "None" briefly rather than removing it.