• Sequentially: From a validated specification
• Standalone (Contract entry): From any specification meeting format requirements

• Specification content (required) - The validated decisions and requirements to plan from
• Topic name (optional) - Will derive from specification if not provided
• Output format preference (optional) - Will ask if not specified
• Recommended output format (optional) - A format suggestion for consistency with existing plans
• Work type (optional) —

  greenfield

  ,

  feature

  , or

  bugfix

  . Determines which context-specific guidance is loaded during phase and task design. Defaults to

  greenfield

  when not provided.
• Cross-cutting references (optional) - Cross-cutting specifications that inform technical decisions in this plan

Output the next fenced block as a code block:

I need the specification content to plan from. Could you point me to the
specification file (e.g., .workflows/specification/{topic}/specification.md),
or provide the content directly?

Output the next fenced block as a code block:

The specification at {path} appears to be {concern — e.g., 'still in-progress'
or 'missing sections that are referenced elsewhere'}. Should I proceed with
this, or is there a more complete version?

1. Re-read this skill file completely. Do not rely on your summary of it. The full process, steps, and rules must be reloaded.
2. Read all tracking and state files for the current topic — plan index files, review tracking files, implementation tracking files, or any working documents this skill creates. These are your source of truth for progress. Check for scratch files at

   .workflows/.cache/planning/{topic}/

   . If a scratch file exists, you are mid-authoring for that phase — resume the approval loop in author-tasks.md.
3. Check git state. Run

   git status

   and

   git log --oneline -10

   to see recent commits. Commit messages follow a conventional pattern that reveals what was completed.
4. Announce your position to the user before continuing: what step you believe you're at, what's been completed, and what comes next. Wait for confirmation.
5. Check

   task_list_gate_mode

   ,

   author_gate_mode

   , and

   finding_gate_mode

   in the Plan Index File frontmatter — if

   auto

   , the user previously opted in during this session. Preserve these values.

• Plan Index File —

  .workflows/planning/{topic}/plan.md

  . Contains frontmatter (topic, format, status, progress), phases with acceptance criteria, and task tables tracking status. This is the single source of truth for planning progress.
• Authored Tasks — Detailed task files written to the chosen Output Format (selected during planning). The output format determines where and how task detail is stored.

status: concluded

status: planning

planning:

Output the next fenced block as markdown (not a code block):

· · · · · · · · · · · ·
- **`c`/`continue`** — Walk through the plan from the start. You can review, amend, or navigate at any point — including straight to the leading edge.
- **`r`/`restart`** — Erase all planning work for this topic and start fresh. This deletes the Plan Index File and any Authored Tasks. Other topics are unaffected.
· · · · · · · · · · · ·

1. Read output-formats.md, find the entry matching the

   format:

   field in the Plan Index File, and load the format's authoring.md
2. Follow the authoring file's cleanup instructions to remove Authored Tasks for this topic
3. Delete the scratch directory if it exists:

   rm -rf .workflows/.cache/planning/{topic}/

4. Delete the Plan Index File
5. Commit:

   planning({topic}): restart planning

Output the next fenced block as markdown (not a code block):

· · · · · · · · · · · ·
- **`y`/`yes`** — Use {format}
- **`n`/`no`** — See all available formats
· · · · · · · · · · · ·

1. Read output-formats.md, find the chosen format entry, and load the format's about.md and authoring.md
2. Capture the current git commit hash:

   git rev-parse HEAD

3. Create the Plan Index File at

   .workflows/planning/{topic}/plan.md

   using the Frontmatter and Title templates from plan-index-schema.md. Set

   status: planning

   ,

   spec_commit

   to the captured git hash, today's actual date for

   created

   and

   updated

   , and

   work_type

   to the value provided by the caller (or

   greenfield

   if not provided).
4. Commit:

   planning({topic}): initialize plan

CHECKPOINT: Do not conclude if any tasks in the Plan Index File show

status: pending

. All tasks must be

authored

before concluding.

Output the next fenced block as markdown (not a code block):

· · · · · · · · · · · ·
- **`y`/`yes`** — Conclude plan and mark as concluded
- **Comment** — Add context before concluding
· · · · · · · · · · · ·

1. Update plan status — Set

   status: concluded

   in the Plan Index File frontmatter
2. Final commit — Commit the concluded plan:

   planning({topic}): conclude plan

3. Present completion summary:

Output the next fenced block as markdown (not a code block):

Planning is complete for **{topic}**.

The plan contains **{N} phases** with **{M} tasks** total, reviewed for traceability against the specification and structural integrity.

Status has been marked as `concluded`. The plan is ready for implementation.