Projects

---

name: Projects description: Build a personal project management system that scales from simple lists to structured planning. metadata: {"clawdbot":{"emoji":"📁","os":["linux","darwin","win32"]}}

Core Behavior

• User mentions a project → help define scope, create folder
• User adds tasks → capture in project context
• Regular review prompts → surface stalled projects
• Create ~/projects/ as workspace

First Question

• "What does done look like?" — define success before starting
• Scope creep is the project killer — clear boundaries from day one
• If they can't define done, the project isn't ready to start

Project Types to Recognize

• One-time goal: clear end state, then archive (move apartments, plan trip)
• Ongoing area: never truly done, maintain indefinitely (health, career)
• Client work: external deadline, deliverables, often paid
• Learning: skill acquisition, may spawn other projects
• Creative: writing, art, building — process matters as much as output

Minimal Project Structure

• Folder with project name: ~/projects/kitchen-renovation/
• README.md: what, why, done criteria, deadline if any
• tasks.md: simple checklist, add as discovered
• notes.md: decisions made, research, reference material

When User Starts a Project

• Ask: "What's the one sentence description?"
• Ask: "When does this need to be done?" (or "no deadline")
• Ask: "What's the very next physical action?"
• Create folder with README containing answers

Task Capture

• Quick capture: "Add to kitchen project: call contractor"
• Tasks are concrete actions, not vague goals
• "Research options" is a task, "figure out renovation" is not
• Estimate size if useful: small/medium/large or hours

When Projects Grow

• More than 15 tasks → consider grouping into phases
• Multiple workstreams → split into areas within project
• Dependencies emerging → note which tasks block others
• Collaborators involved → note who owns what

Phase/Milestone Structure

For larger projects:

~/projects/kitchen-renovation/
├── README.md
├── phase-1-planning/
│   ├── tasks.md
│   └── notes.md
├── phase-2-demo/
├── phase-3-install/
└── archive/

Active Project Limits

• Suggest maximum 3-5 active projects — more means nothing progresses
• Distinguish active (working this week) from someday (parked intentionally)
• Parked projects go in ~/projects/_someday/
• Review someday quarterly — activate, archive, or delete

Weekly Project Review

• What progressed this week?
• What's the next action for each active project?
• Any projects stalled more than 2 weeks?
• Any someday projects ready to activate?

Stalled Project Detection

• No task completions in 2+ weeks → surface in review
• Ask: "Is this still a priority? Block or drop?"
• Options: push forward, park to someday, kill it
• Killing projects is healthy — better than zombie projects

Project Completion

• Define done checklist in README from start
• When complete: review what went well, what didn't
• Archive to ~/projects/_archive/year/
• Celebrate completion — don't just move to next thing

Client/Work Projects

• Add: deadline, contact info, rate if applicable
• Track time if billing: simple log in project folder
• Deliverables list with status
• Communication log: key decisions and approvals

What NOT To Suggest

• Complex project management app until files fail
• Rigid methodology (Agile, GTD, etc.) — adapt to user
• Gantt charts for personal projects — overkill
• Time tracking for non-billable work — adds friction

Project Templates

Offer to create templates for recurring project types:

• "You start client projects often — want a template?"
• Template: folder structure, README prompts, standard tasks
• Keep templates minimal — adapt per project

Integration Points

• Calendar: deadlines, milestones
• Contacts: collaborators, stakeholders
• Invoices: if client project with billing
• Goals: projects often serve larger goals

Someday/Maybe List

• Ideas not ready for commitment
• Review monthly — promote, delete, or keep parking
• No guilt about long lists — it's a holding pen
• "This would be cool but not now" is valid

Project Metrics (When Asked)

• How long did similar projects take?
• Completion rate: started vs finished
• Average project duration
• Don't track obsessively — only if user finds it useful