New Plan Skill

You are helping the user design and document a new phase for the database development roadmap.

Context to Gather First

Before writing anything, collect the context you need:

1. •Read doc/plan/README.md to understand the existing phases, current phase naming convention (A, B, C … G, G2, G4, H, I, J, K …), and the next available phase letter/number.
2. •Scan doc/plan/ (excluding completed/) to see any in-progress or planned phases that the new phase might depend on or follow.
3. •Read one or two recent phase files to internalize the expected document structure and level of detail.

User Input

Use AskUserQuestion to ask the user:

• •What feature or improvement should the new phase cover?
• •Are there any specific implementation approaches or constraints they have in mind?

Keep the question open-ended — the user may have given a description already in their prompt; if so, skip asking and use that.

Determine the Phase Identifier

Pick the next available phase identifier following the existing sequence visible in doc/plan/README.md. Use a letter (e.g. L) or a numbered suffix (e.g. G5) depending on the context of the phase.

Write the Plan File

Create doc/plan/phase-<id>-<short-slug>.md following the structure used in existing phase files:

# Phase <ID> — <Title>

One sentence describing the goal of this phase.

## Items

| # | Track | Item | Depends on |
|---|-------|------|------------|
| N | X.Y   | Description | — or phase |

---
Important: Each item should be committed separately, follow 'Git Workflow' in CLAUDE.md

---

## Overview

Why this phase exists. What problem it solves. How it fits with other phases.

---

## N. Item Title (Track X.Y)

### What Changes
### Background
### Implementation Approach
### Key Files
### Tests
### Implementation Steps (N commits)

#### Step N.1 — ...
**Commit:** ...

---

## Verification

- [ ] Tests pass: `cargo test`
- [ ] Zero warnings: `cargo fmt && cargo build 2>&1 | grep -i warning`
- [ ] Each commit is independently testable

Match the depth and detail of the existing plan files. Include concrete code examples, SQL snippets, or file paths where they clarify the approach. Be specific enough that another developer (or Claude) could implement the phase from the document alone.

Update the README

Add a row to the phase table in doc/plan/README.md:

| **<ID>** | <Title> | <item count> | [phase-<id>-<slug>.md](phase-<id>-<slug>.md) | Planned |

Insert it after the last existing row in the table.

Commit and PR

1. •Stage and show the diff for review:
   bash

   git add doc/plan/
   git diff --cached --stat
   

2. •Wait for user approval, then commit:
   bash

   git commit -m "Add Phase <ID> plan: <title>"
   

3. •Push and open a PR:
   bash

   git push -u origin <branch>
   gh pr create --title "Plan: Phase <ID> — <title>" --body "..."
   

The PR body should summarise the phase goal, list the items, and note any dependencies on other phases.

Important Notes

• •Do not implement any code — this skill is for planning only.
• •Follow the Git Workflow from CLAUDE.md (small focused commits, review before committing).
• •The plan should be detailed enough to hand off to the next-phase skill for implementation.
• •If the user already created a branch before invoking this skill, use that branch rather than creating a new one.