Plan to Implementation Workflow
How plans become implemented features.
Related:
- PLANS.md - Plan structure, templates, and best practices
- CI-CD.md - What to check before merging to main
The Flow
Note: Claude always asks for confirmation before running git commands (add, commit, push, branch, merge).
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ 1. USER: "I want to add feature X" or "Fix problem Y" │
│ │
│ 2. CLAUDE: │
│ - Creates PLAN-*.md or INVESTIGATE-*.md in backlog/ │
│ - Asks user to review the plan │
│ │
│ 3. USER: Reviews and edits the plan, then confirms │
│ │
│ 4. CLAUDE: │
│ - Moves plan to active/ │
│ - Implements phase by phase │
│ - Runs validation after each phase │
│ - Commits after each phase │
│ - Updates plan with progress │
│ │
│ 5. USER: Reviews result │
│ │
│ 6. CLAUDE: │
│ - Moves plan to completed/ │
│ - Final commit │
│ │
└─────────────────────────────────────────────────────────────────────┘
Step 1: Describe What You Want
Tell Claude what you want to do:
"I want to add Draw.io extension support"
"Fix the Docker CLI path issue in the devcontainer"
"Add SCRIPT_VER to all install scripts"
Step 2: Claude Creates a Plan
Claude will:
- Create plan file in
website/docs/ai-development/ai-developer/plans/backlog/:PLAN-*.mdif the solution is clearINVESTIGATE-*.mdif research is needed first
- Ask you to review the plan
See PLANS.md for plan structure, templates, and what goes in each section.
Step 3: Review the Plan
Open the plan file and review it:
- Are the phases in the right order?
- Are the tasks specific enough?
- Is anything missing?
- Are the validation steps correct?
Edit the file if needed.
When satisfied, tell Claude:
"Plan approved, start implementation"
Step 4: Claude Implements
Claude will:
-
Move plan to active/:
mv website/docs/ai-development/ai-developer/plans/backlog/PLAN-xyz.md website/docs/ai-development/ai-developer/plans/active/ -
Ask about feature branch (recommended):
Claude will ask:
"Do you want to work on a feature branch? (recommended)
This keeps your changes separate from the main code until you're ready. When done, you'll create a Pull Request to merge your changes."
If yes: Claude creates a branch like
feature/update-scriptsIf no: Claude works directly on the current branchSee "What is a Feature Branch?" below if you're new to this.
-
Work phase by phase:
- Complete tasks in order
- Ask user to confirm each phase: "Phase 1 complete. Does this look good?"
- Update the plan file (mark tasks complete)
- Commit after user confirms
- Stop if user has concerns
-
Ask for help if blocked or unclear
Step 5: Review Result
Check the changes:
- Does the script work?
- Does install/uninstall work correctly?
- Any shellcheck warnings?
If changes needed, tell Claude what to fix.
If good, tell Claude:
"Looks good, complete it"
Step 6: Claude Completes
Claude will:
- Move plan to completed/
- Update plan status:
## Status: Completed - Push changes
If working on a feature branch, Claude will also:
- Create a Pull Request using
gh pr create - Explain next steps:
"I've created a Pull Request. You can:
- Review it on GitHub
- Ask someone to review it
- Merge it when ready"
Before merging the PR, Claude will ask:
-
Check version bump:
"Should we bump the version before merging?
- Current version: 1.0.3
- If yes, what should the new version be?"
-
Documentation: CI auto-updates docs after merge - no manual step needed.
See CI-CD.md for details on what happens after merge.
Version Management (MANDATORY)
CRITICAL: Before pushing to GitHub or creating a PR, Claude MUST:
- Ask the user: "Should we bump the version for this change?"
- If yes: Update
version.txtwith the new version number - Version types:
- PATCH (1.0.x → 1.0.y): Bug fixes, small improvements
- MINOR (1.x.0 → 1.y.0): New features, documentation improvements
- MAJOR (x.0.0 → y.0.0): Breaking changes
Why this matters: Users running dev-update will only see updates if the version number changes. Without a version bump, changes will never reach users.
See RELEASING.md for full release process.
Quick Reference
Commands to give Claude:
| You say | Claude does |
|---|---|
| "I want to add X" / "Fix Y" | Creates plan, asks for review |
| "Plan approved" | Asks about feature branch, moves to active/, starts implementing |
| "Yes, use a feature branch" | Creates branch, works there |
| "No, work on current branch" | Works on current branch |
| "Looks good, complete it" | Moves to completed/, creates PR if on feature branch |
| "Stop" | Pauses and waits for instructions |
Example Session
YOU: I want to add SCRIPT_VER to all install scripts
CLAUDE: I'll create a plan for that.
Created website/docs/ai-development/ai-developer/plans/backlog/PLAN-script-version-variable.md
Please review the plan and let me know if it looks good
or needs changes.
YOU: [reviews file, makes edits]
Plan approved, start implementation
CLAUDE: Do you want to work on a feature branch? (recommended)
This keeps your changes separate from the main code until you're ready.
When done, you'll create a Pull Request to merge your changes.
YOU: Yes
CLAUDE: Created branch: feature/script-version-variable
Moving plan to active/...
Starting Phase 1...
[works through phases, committing after each]
Phase 2 complete. Validation passed.
Continuing to Phase 3...
All phases complete. Please review the changes.
YOU: Looks good, complete it
CLAUDE: Done! I've:
- Moved plan to completed/
- Pushed the feature branch
- Created Pull Request #12
Next steps:
- Review the PR on GitHub
- Merge it when you're ready
- Or ask a teammate to review it first
What is a Feature Branch?
If you're new to git branches, this section explains the concept.
The Problem
Imagine you're writing a book with others. If everyone edits the same copy at the same time, it gets messy. Someone might overwrite your changes, or you might break something while experimenting.
The Solution: Branches
A branch is like making a personal copy of the book to work on. You can:
- Make changes without affecting the original
- Experiment freely
- Share your copy when it's ready
main (the original)
│
└── feature/add-chapter-5 (your copy)
│
└── [you work here safely]
The Workflow
- Create branch - Make your personal copy
- Work on it - Make changes, commit as you go
- Create Pull Request (PR) - Ask to merge your changes back
- Review - Others can look at your changes before merging
- Merge - Your changes become part of the original
Why It's Recommended
- Safe: Your experiments don't break the main code
- Reviewable: Others can check your work before it's merged
- Reversible: Easy to undo if something goes wrong
- Collaborative: Multiple people can work on different features
Commands Claude Uses
# Create and switch to a new branch
git checkout -b feature/my-feature
# Push the branch to GitHub
git push -u origin feature/my-feature
# Create a Pull Request
gh pr create --title "Add my feature" --body "Description..."
You don't need to memorize these - Claude handles it for you.
Optional: Working with GitHub Issues
If you're using GitHub issues to track work, tell Claude:
"Work on issue #42"
Claude will:
- Read the issue with
gh issue view 42 - Create a plan based on the issue
- Create a branch:
issue-42-short-name - Close the issue when complete