2684 Implementation Roadmap 7b9c7a43

Implementation Roadmap

Overview

This document details the concrete implementation steps for Project Creator. Each phase builds on the previous one.

Dependency order:

1. Foundation Files → everything references these
2. Tracking Infrastructure → commands need somewhere to write state
3. Core Command (/project) → other commands depend on current project context
4. Seeding Commands → the main workflows
5. First Test → validate the system works

Estimated effort: 7-11 hours (from ticket)

Phase 1: Foundation Files (COMPLETED)

Core configuration that defines how Project Creator works.

1.1 CLAUDE.md

• Create CLAUDE.md with:
  • Role definition (collaborator, reverse prompting heavy, critical and creative)
  • Parent-child pattern description (ignore child CLAUDE.md at parent level)
  • Three phases overview (seeding, cultivation, shaping) with seeding focus
  • Reference to methodology.md for deep patterns
  • Guidance on how to use commands

1.2 README.md

• Create README.md with:
  • Quick start guide (how to begin a session)
  • Command reference with examples
  • Directory structure explanation
  • When to use /intake vs /onboard
  • Session workflow examples

1.3 Methodology Reference

• Copy llm-workflow-methodology.md to methodology.md
• Add Project Creator-specific header noting this is the reference doc

1.4 Git Configuration

• Create .gitignore with projects/ entry
• Initialize git repo (if not already)
• Create templates/ directory (empty, for future use)

Phase 2: Tracking Infrastructure (COMPLETED)

Files that maintain state across sessions.

2.1 Tracking Directory

• Create tracking/ directory
• Create tracking/current-project.md with initial content explaining format
• Create tracking/projects-log.md with header and empty table
• Create tracking/patterns-discovered.md with header explaining purpose

Phase 3: Core Command — /project (COMPLETED)

The foundation command that all other commands depend on.

3.1 Command File

• Create .claude/commands/project.md
• Implement three modes:
  • No args: Show current project + list all clients/projects
  • [client/project]: Set current project (must exist)
  • new [client/project]: Create directory structure and set as current

3.2 Project Creation Logic

• Create client directory if needed (projects/[client]/)
• Create project directory (projects/[client]/[project]/)
• Initialize git repo in project directory
• Create minimal scaffold (context/ directory for requirements)
• Update tracking/current-project.md
• Add entry to tracking/projects-log.md

3.3 Project Listing Logic

• Scan projects/ directory for clients
• Scan each client for projects
• Display hierarchically with current marked

Phase 4: Seeding Commands (COMPLETED)

The main workflows for capturing project requirements.

4.1 /intake — New Project Reverse Prompting

• Create .claude/commands/intake.md
• Read current project context (or accept override)
• Implement reverse prompting flow:
  • Ask questions one at a time
  • Cover: purpose, users, constraints, success criteria, technical context
  • Push for specificity (like Writing Companion's sensory details)
  • Extract the "quality" — what makes this project distinct
• Create/update project context files:
  • [project]/context/requirements.md — captured requirements
  • [project]/context/constraints.md — technical and business constraints
  • [project]/context/decisions.md — decisions made during intake
• Update tracking/projects-log.md with session summary

4.2 /onboard — Existing Project Analysis

• Create .claude/commands/onboard.md
• Verify project exists and has content to analyze
• Analyze existing files against methodology checklist:
  • CLAUDE.md present and complete?
  • README.md present and useful?
  • Commands defined?
  • Skills defined?
  • Documentation present?
• Produce structured report: FOUND / MISSING / RECOMMENDATIONS
• Ask before starting gap-filling reverse prompting
• Target gaps specifically (don't re-capture what exists)

4.3 /process — External Input Processing

• Create .claude/commands/process.md
• Accept input types:
  • Pasted text (transcripts, notes)
  • File path (documents, existing specs)
• Extract structured information:
  • Requirements mentioned
  • Constraints identified
  • Decisions implied
  • Questions raised
• Update project context files with extracted content
• Flag items needing clarification for /intake follow-up

4.4 /gaps — Assessment

• Create .claude/commands/gaps.md
• Read all project context files
• Compare against methodology checklist:
  • Purpose clearly defined?
  • Users identified?
  • Success criteria specified?
  • Technical constraints captured?
  • Key decisions documented?
• Produce gap report with priorities
• Suggest which gaps to fill next (and how)

4.5 /checkpoint — Session Capture

• Create .claude/commands/checkpoint.md
• Summarize what was captured this session
• Update tracking files:
  • tracking/projects-log.md — session entry
  • tracking/patterns-discovered.md — any new patterns noticed
• Identify concrete next steps
• Prepare handoff notes (for potential context loss)
• Optionally commit changes to project git repo

Phase 5: First Test

Validate the system works end-to-end.

5.1 Test Scenario

• Run: /project new acme-corp/sample-project
• Run: /intake and go through reverse prompting
• Run: /process with sample transcript (if available)
• Run: /gaps to see assessment
• Run: /checkpoint to capture session

5.2 Validation

• Verify project directory created correctly
• Verify context files populated
• Verify tracking files updated
• Verify gap assessment is meaningful
• Verify checkpoint captures useful state

5.3 Refinement

• Note any friction points
• Update commands based on learnings
• Document patterns in tracking/patterns-discovered.md

Success Criteria Checklist

• CLAUDE.md clearly describes the pattern and role
• README.md is usable by a human starting a session
• /project correctly handles client/project hierarchy
• /intake draws out requirements through reverse prompting
• /onboard analyzes existing projects and fills gaps
• /process handles transcripts and extracts structured content
• /gaps identifies meaningful gaps
• /checkpoint captures session state usefully
• All commands respect current project context
• First test produces a seeded sub-project

Notes for Multi-Session Implementation

If this takes multiple sessions:

1. Phase 1-2 can be done in one session (foundation + tracking)
2. Phase 3 (/project command) should be its own session — it's the critical dependency
3. Phase 4 commands can be done 1-2 per session, in order:
   • /intake first (core workflow)
   • /checkpoint second (enables clean session ends)
   • /gaps third (enables assessment)
   • /process fourth (extends intake)
   • /onboard fifth (variant of intake)
4. Phase 5 (first test) validates everything

Each session should end with:

• Committing completed work
• Noting which checkboxes are done
• Identifying the next phase to tackle