Plan/Implement Pattern

What This Is

The Plan/Implement Pattern is a systematic workflow for complex work that separates thinking from doing. Inspired by The Phoenix Project’s principles of work visibility and WIP management, this pattern ensures that:

Work is planned before execution begins
Plans are reviewed by Marketing Architects before implementation
Progress is visible throughout execution
Work in progress (WIP) is managed systematically

This is not bureaucracy—it’s deliberate execution that prevents chaos and makes work manageable.

The Core Pattern

Marketing Architect: "plan: Build Q1 campaign messaging"
    ↓
Operations Manager creates PLAN.md:
  - Maps out approach
  - Identifies resources needed (skills, agents, files, tools)
  - Estimates effort
  - Outlines expected deliverables
    ↓
Marketing Architect: Reviews PLAN.md
  - Approves approach
  - OR suggests modifications
  - OR requests alternative approach
    ↓
Marketing Architect: "implement"
    ↓
Operations Manager:
  - Creates TODO.md (task tracking)
  - Executes plan step-by-step
  - Updates progress in TODO.md
  - Flags blockers early
  - Delivers results
    ↓
Work complete, visible throughout

Key insight: The approval gate between plan and implement keeps the human in control while leveraging AI execution capabilities.

PLAN.md Structure

Location: Created in the relevant execution directory (e.g., /research/{domain}/execution/2025-10-21/PLAN.md) Created by: Operations Manager (during plan meta command) Purpose: Map out the approach BEFORE execution begins

Standard PLAN.md Template

# Plan: [Project Name]

**Created:** [Date]
**Status:** [Pending Approval | Approved | In Progress | Complete]

---

## Objective

[Clear statement of what this work aims to achieve]

## Approach

[High-level strategy for accomplishing the objective]

### Steps

1. [Step 1 description]
2. [Step 2 description]
3. [Step 3 description]
...

## Resources Required

### Skills
- [Skill name 1] - [Why needed]
- [Skill name 2] - [Why needed]

### Sub-agents
- [Agent role] - [Responsible for which steps]

### Files
- [File path] - [What information it contains]

### Tools/Integrations
- [Tool name] - [What it will be used for]

## Expected Deliverables

- [Deliverable 1]
- [Deliverable 2]

## Estimated Effort

**Time estimate:** [X hours/days]
**Complexity:** [Low | Medium | High]

## Risks & Considerations

- [Risk 1] - [Mitigation]
- [Risk 2] - [Mitigation]

## Dependencies

- [Dependency 1]
- [Dependency 2]

---

**Awaiting approval from Marketing Architect**

What Makes a Good Plan

A good PLAN.md:

✅ Shows clear reasoning for the approach
✅ Identifies specific resources needed (not generic)
✅ Acknowledges risks and how to mitigate them
✅ Provides realistic estimates (not overly optimistic)
✅ References specific files that will be used
✅ Maps which agents will do which work

A bad PLAN.md:

❌ Vague approach (“do research”)
❌ Generic resources (“use research skills”)
❌ No risk assessment
❌ Unrealistic timeline
❌ Doesn’t specify which files/agents/tools

TODO.md Structure

Location: Same directory as PLAN.md (e.g., /research/{domain}/execution/2025-10-21/TODO.md) Created by: Operations Manager (during implement meta command) Purpose: Track work in progress, make status visible

Standard TODO.md Template

# TODO: [Project Name]

**Created:** [Date]
**Last Updated:** [Date + Time]
**Status:** [In Progress | Blocked | Complete]

---

## Progress Overview

**Completion:** [X%]
**Current Phase:** [Phase name]
**Blockers:** [None | Description of blocker]

---

## Tasks

### ✅ Completed

- [x] [Task 1] - [Who completed] - [When]
- [x] [Task 2] - [Who completed] - [When]

### 🚧 In Progress

- [ ] **[Current task]** - [Agent working on it] - [Started when]
  - Status: [Description of current status]
  - Next step: [What happens next]

### ⏳ Pending

- [ ] [Task 4] - [Assigned to]
- [ ] [Task 5] - [Assigned to]

---

## Notes

### [Date]
- [Note about decision made, blocker encountered, or insight gained]

### [Date]
- [Another note]

---

## Blockers & Issues

**Current blockers:**
- [None | Description]

**Resolved blockers:**
- [Blocker] - [How resolved] - [When]

---

**Updated by Operations Manager**

TODO.md Best Practices

Update frequency:

After every major task completion
When blockers are encountered
At phase transitions
Minimum: Every 3-4 completed tasks

One task in progress at a time:

Finish current work before starting new work
Reduces context switching
Prevents 20 half-finished projects
Clear ownership (which agent is doing what)

Make blockers visible immediately:

Don’t hide problems
Flag blockers as soon as they’re discovered
Describe what’s blocking progress
Propose mitigation or escalate to Marketing Architect

Phoenix Project Connection

Work Visibility

Phoenix Project principle: “You can’t manage what you can’t see.” How this pattern implements it:

PLAN.md shows approach before work starts
TODO.md shows progress during execution
Both files are committed to Git (permanent record)
Marketing Architect can see status at any time

Result: No “black box” AI work. Everything is transparent.

Limiting WIP (Work In Progress)

Phoenix Project principle: “Finish work before starting new work.” How this pattern implements it:

TODO.md shows what’s currently in progress
Best practice: One task marked “In Progress” at a time
Complete current step before moving to next
Prevents context switching chaos

Result: Work actually gets finished instead of accumulating partially completed tasks.

Making Problems Visible Early

Phoenix Project principle: “Problems should be flagged early, not hidden.” How this pattern implements it:

Blockers section in TODO.md
Notes capture decisions and issues
Marketing Architect can intervene early
Prevents late-stage surprises

Result: Issues are addressed when they’re small, not when they’re catastrophic.

Approval Gates

Phoenix Project principle: “Constrain WIP at the constraint point.” How this pattern implements it:

Human approval required between plan and implement
Marketing Architect is the constraint (strategic thinking)
AI handles execution (high throughput)
Work doesn’t start until plan is approved

Result: AI doesn’t execute the wrong approach at high speed.

When to Use This Pattern

✅ USE Plan/Implement When:

Complex multi-step work (research projects, campaign planning)
High stakes (brand strategy, major launches)
Unclear requirements (need to map out approach first)
Multiple agents involved (orchestration complexity)
Learning mode (want to see how system works)
Need audit trail (compliance, documentation)

❌ DON’T USE Plan/Implement When:

Simple one-off tasks (“Create a tweet about X”)
You trust the system (you know it will do the right thing)
Speed over visibility (need fast execution)
Exploratory work (just trying something out)

Alternative: /yolo Mode

What it is: Skip planning, execute directly in one shot. When to use it:

Marketing Architect: "/yolo Create 3 blog post ideas about productivity"
    ↓
Operations Manager:
  - Skips PLAN.md creation
  - Executes immediately
  - Returns results
  - No TODO.md tracking

Benefits:

⚡ Fast execution
🎯 Direct results
🧹 No overhead

Risks:

❌ No approval gate
❌ No progress visibility
❌ Can’t intervene mid-execution
❌ No audit trail

Use /yolo when:

You trust the system to do the right thing
Task is simple and low-risk
Speed matters more than visibility
You don’t need documentation

DON’T use /yolo when:

Complex, multi-step work
High stakes (strategy, major projects)
Need to review approach first
Want audit trail

Real-World Examples

Example 1: Research Project

Marketing Architect: "plan: Analyze competitor positioning in the productivity space"

Operations Manager creates PLAN.md:
---
Objective: Identify how top 5 competitors position their productivity tools

Approach:
1. Identify top 5 competitors (market research)
2. Analyze website messaging (web scraping)
3. Research social media presence (content analysis)
4. Compare positioning strategies (synthesis)

Resources:
- Skills: Conducting Competitive Research, Analyzing Qualitative Data
- Agents: Brand Analyst (steps 1-4)
- Files: /strategy/messaging/pillars.md (our positioning for comparison)
- Tools: Perplexity (research), Firecrawl (web scraping)

Expected Deliverables:
- Competitor positioning matrix
- Gap analysis report
- Recommendations for differentiation

Estimated Effort: 4-6 hours
Risks: Competitors may have paywalled content (mitigation: use free sources)
---

Marketing Architect: [Reviews, approves]

Marketing Architect: "implement"

Operations Manager creates TODO.md and executes:
- ✅ Identified top 5 competitors - Brand Analyst - 2:45pm
- ✅ Scraped competitor websites - Brand Analyst - 3:20pm
- 🚧 Analyzing social media content - Brand Analyst - Started 3:30pm
- ⏳ Create positioning matrix
- ⏳ Write gap analysis report

[Work continues with visible progress...]

Example 2: Simple Task (No Plan Needed)

Marketing Architect: "Create a Twitter thread about context architecture"

Operations Manager:
- Assesses: Simple, well-defined task
- Delegates to Content Writer
- Content Writer uses relevant skills
- Returns thread
- No PLAN.md or TODO.md needed

[Done in one shot]

Example 3: /yolo Mode

Marketing Architect: "/yolo Give me 5 LinkedIn post ideas for this week"

Operations Manager:
- Reads /strategy/messaging/pillars.md
- Generates 5 ideas immediately
- Returns results
- No planning, no tracking

[Fast execution, no overhead]

Meta Command Details

The `plan` Meta Command

Invocation:

Marketing Architect: "plan: [description of work]"

What it does:

Operations Manager analyzes the request
Determines approach (which skills, agents, files, tools)
Creates PLAN.md with detailed plan
Waits for Marketing Architect approval

What it outputs:

PLAN.md file in appropriate directory
Explanation of approach
Request for approval

The `implement` Meta Command

Invocation:

Marketing Architect: "implement"

Prerequisites:

PLAN.md exists and is approved
Marketing Architect has reviewed approach

What it does:

Operations Manager loads approved PLAN.md
Creates TODO.md for tracking
Executes plan step-by-step
Updates TODO.md after major milestones
Flags blockers if encountered
Delivers results

What it outputs:

TODO.md (progress tracking)
Deliverables specified in PLAN.md
Final summary

File Location Patterns

For Research Projects

/research/{domain}/execution/{YYYY-MM-DD}/
├── PLAN.md              ← Created during 'plan'
├── TODO.md              ← Created during 'implement'
├── notes.md             ← Working notes
├── findings.md          ← Research outputs
└── [other deliverables]

For Campaign Projects

/projects/{campaign-name}/
├── PLAN.md
├── TODO.md
├── /deliverables/
└── /strategy/

For Ad-Hoc Work

No specific location required
Use /tmp/ or scratch space
PLAN.md and TODO.md co-located with outputs

Anti-Patterns to Avoid

❌ Creating Plans That Are Too Vague

Bad:

Approach: Do competitor research
Resources: Research skills

Good:

Approach:
1. Identify top 5 competitors via Perplexity search
2. Scrape websites using Firecrawl
3. Analyze messaging using "Analyzing Qualitative Data" skill

Resources:
- Skills: Conducting Competitive Research (competitive-analysis.md)
- Agents: Brand Analyst (all steps)
- Tools: Perplexity (step 1), Firecrawl (step 2)

❌ Not Updating TODO.md

Bad:

[TODO.md created at start, never updated, status unclear]

Good:

TODO.md updated after:
- Every completed task
- Blockers encountered
- Phase transitions
- Clear status at all times

❌ Using Plan/Implement for Simple Tasks

Bad:

Marketing Architect: "plan: Create one tweet"
[Unnecessary overhead for simple task]

Good:

Marketing Architect: "Create a tweet about X"
[Direct execution, no planning needed]

❌ Implementing Without Approval

Bad:

Marketing Architect: "plan: Build campaign"
Operations Manager: [Creates PLAN.md AND starts implementing without approval]

Good:

Marketing Architect: "plan: Build campaign"
Operations Manager: [Creates PLAN.md, waits for approval]
Marketing Architect: [Reviews, approves]
Marketing Architect: "implement"
Operations Manager: [NOW executes]

Integration with Other Workflows

Works With: Research Workflow

The Plan/Implement pattern is embedded in the research workflow:

Research Domain Setup
    ↓
"plan: Run customer insight research"
    ↓
PLAN.md created in /research/customer-insight/execution/2025-10-21/
    ↓
Approve
    ↓
"implement"
    ↓
TODO.md tracks research execution
    ↓
Results exported

Works With: Content Generation

For complex content projects:

"plan: Create 3-month content calendar"
    ↓
PLAN.md maps out content themes, production schedule
    ↓
"implement"
    ↓
Content generated systematically with TODO.md tracking

For simple content:

"Create blog post about X"
    ↓
Direct execution (no plan needed)

Works With: Campaign Planning

"plan: Q1 product launch campaign"
    ↓
PLAN.md outlines campaign strategy, timelines, deliverables
    ↓
Approve
    ↓
"implement"
    ↓
TODO.md tracks campaign asset creation

Success Criteria

You’re using this pattern correctly when: ✅ Complex work has a PLAN.md before execution starts ✅ Marketing Architect reviews plans before implementation ✅ TODO.md shows clear status at any point in time ✅ Blockers are flagged immediately (not hidden) ✅ Simple tasks skip planning (no unnecessary overhead) ✅ /yolo is used appropriately (for trusted, simple work) ✅ Work is visible throughout (Phoenix Project principle) ✅ WIP is limited (one task in progress at a time) You’re doing it wrong when: ❌ Implementing without approval ❌ Plans are vague or generic ❌ TODO.md is never updated ❌ Using plan/implement for one-line tasks ❌ Using /yolo for complex, high-stakes work ❌ Multiple tasks “in progress” simultaneously ❌ Blockers hidden until end

Summary

The Plan/Implement Pattern is systematic execution inspired by The Phoenix Project. It:

Separates thinking from doing (plan first, execute second)
Keeps humans in control (approval gate)
Makes work visible (PLAN.md and TODO.md)
Manages WIP (one task in progress at a time)
Flags problems early (blockers section)

Use it for complex work. Skip it for simple tasks. Use /yolo when you trust the system. This is how you work ON the marketing system, not IN it—deliberate execution that compounds over time.

Getting Started

The Five Layers

System Architecture

Workflows

Reference

​Plan/Implement Pattern

​What This Is

​The Core Pattern

​PLAN.md Structure

​Standard PLAN.md Template

​What Makes a Good Plan

​TODO.md Structure

​Standard TODO.md Template

​TODO.md Best Practices

​Phoenix Project Connection

​Work Visibility

​Limiting WIP (Work In Progress)

​Making Problems Visible Early

​Approval Gates

​When to Use This Pattern

​✅ USE Plan/Implement When:

​❌ DON’T USE Plan/Implement When:

​Alternative: /yolo Mode

​Real-World Examples

​Example 1: Research Project

​Example 2: Simple Task (No Plan Needed)

​Example 3: /yolo Mode

​Meta Command Details

​The plan Meta Command

​The implement Meta Command

​File Location Patterns

​For Research Projects

​For Campaign Projects

​For Ad-Hoc Work

​Anti-Patterns to Avoid

​❌ Creating Plans That Are Too Vague

​❌ Not Updating TODO.md

​❌ Using Plan/Implement for Simple Tasks

​❌ Implementing Without Approval

​Integration with Other Workflows

​Works With: Research Workflow

​Works With: Content Generation

​Works With: Campaign Planning

​Success Criteria

​Summary

Plan/Implement Pattern

What This Is

The Core Pattern

PLAN.md Structure

Standard PLAN.md Template

What Makes a Good Plan

TODO.md Structure

Standard TODO.md Template

TODO.md Best Practices

Phoenix Project Connection

Work Visibility

Limiting WIP (Work In Progress)

Making Problems Visible Early

Approval Gates

When to Use This Pattern

✅ USE Plan/Implement When:

❌ DON’T USE Plan/Implement When:

Alternative: /yolo Mode

Real-World Examples

Example 1: Research Project

Example 2: Simple Task (No Plan Needed)

Example 3: /yolo Mode

Meta Command Details

The `plan` Meta Command

The `implement` Meta Command

File Location Patterns

For Research Projects

For Campaign Projects

For Ad-Hoc Work

Anti-Patterns to Avoid

❌ Creating Plans That Are Too Vague

❌ Not Updating TODO.md

❌ Using Plan/Implement for Simple Tasks

❌ Implementing Without Approval

Integration with Other Workflows

Works With: Research Workflow

Works With: Content Generation

Works With: Campaign Planning

Success Criteria

Summary