OpenClaw v2

Project Management: How the Core Four Runs Projects

The Core Four agents coordinate work across three distinct task systems. Each system serves a different scope and lifetime. Understanding when to use which system is the single most important operational skill for any agent in the OpenClaw org.

The Three Systems (Know the Difference)

System 1: file-todos (Persistent Project Tasks)

  • Where: todos/ directory in the project repo
  • Format: Markdown files named like 001-pending-p1-fix-login.md
  • Status lifecycle: pending (needs human approval) → ready (approved, can work) → complete
  • YAML frontmatter fields: status, priority, tags, dependencies, issue_id

Use when: Tracking development work across sessions. Technical debt items. Features that need planning or human sign-off before execution.

Who reviews: toli approves pending items to make them ready. Agents only work items with ready status. This is the human-in-the-loop gate — nothing moves to execution without toli's explicit approval.

Example filename: 001-pending-p1-fix-login.md means item #001, pending approval, priority 1, short description "fix-login."

Example frontmatter:

hljs yaml[object Object],
,[object Object], ,[object Object],
,[object Object], ,[object Object],
,[object Object], [,[object Object],, ,[object Object],]
,[object Object], []
,[object Object], ,[object Object],
,[object Object]

System 2: TaskCreate/TaskList/TaskUpdate (Real-Time Swarm Coordination)

  • Where: ~/.claude/tasks/{team-name}/
  • Key operations:
    • TaskCreate — Add a unit of work with subject, description, and activeForm
    • TaskList — See all available tasks, their status, and who owns them
    • TaskUpdate — Claim a task, mark it complete, set dependencies with addBlockedBy

Use when: Swarm mode. Parallel agents working the same problem. Pipeline coordination where task B depends on task A finishing first.

Self-organizing worker pattern:

  1. TaskList — find unclaimed, unblocked work
  2. Claim it (set owner via TaskUpdate)
  3. Do the work
  4. Mark complete (TaskUpdate with status completed)
  5. Repeat

Dependencies: addBlockedBy creates a dependency chain. When the blocking task completes, the blocked task automatically becomes available. This is how you build pipelines — research must finish before writing starts, writing must finish before review starts.

System 3: TodoWrite (Single-Session Tracking)

  • Ephemeral — disappears when the session ends
  • Use when: Claude needs to track its own multi-step work within a single conversation
  • Not for: Anything that needs to survive across sessions or be visible to other agents

This is personal scratch paper. No one else sees it. It does not persist.

How Core Four Agents Use This in Practice

Architect (Lacie) — Strategic Project Tracking

Uses file-todos for cross-session strategic initiatives:

  • 001-pending-p1-q1-pricing-strategy.md — toli approves → status becomes ready → Architect researches pricing models, competitive landscape, and delivers a recommendation
  • Strategic initiatives often span days or weeks, making file-todos the right persistence layer

Uses TaskCreate swarm for research sprints:

  • Spawns parallel research specialists (market-researcher, competitor-analyst, data-analyst)
  • Each specialist gets a TaskCreate item with clear deliverable
  • Specialists self-organize via TaskList, claim work, deliver findings
  • Architect synthesizes all results into a single strategic brief

Builder (Gary) — Engineering Projects

Uses file-todos for the development backlog:

  • 001-ready-p1-auth-redesign.md — Gary claims → spawns Perry (code review) and Harry (implementation) in worktrees
  • Each file-todo maps to a meaningful unit of shippable work

Uses TaskCreate/TaskUpdate to coordinate multi-agent builds with dependency tracking:

  • Each feature = one top-level task
  • Sub-tasks use addBlockedBy to express dependencies (e.g., database migration must complete before API endpoint work begins)
  • Gary monitors the task board, unblocks stuck items, and merges results

Revenue Operator (Cherry) — Revenue Pipeline

Uses file-todos for outreach campaigns:

  • 001-ready-p2-giphy-outreach-batch.md — Cherry claims → executes 50 personalized outreach emails using prospect research and template system
  • Campaign file-todos include target lists, messaging angles, and success metrics in the markdown body

Uses TaskCreate for research swarms before major campaigns:

  • Before a big push, Cherry spawns prospect-researchers and market-analysts
  • Research tasks feed into the campaign file-todo with enriched prospect data
  • Campaign execution only begins after research tasks complete

Operator (Jerry) — Operations and Community

Uses file-todos for ongoing operational tasks:

  • 001-pending-p1-barry-content-calendar.md — toli approves → Jerry produces the weekly content calendar for Barry
  • Barry's Tier B queue (content ideas, community responses, scheduled posts) becomes file-todos that Jerry reviews daily and either executes or escalates

Uses TaskCreate for operational sprints:

  • Community health checks, documentation updates, and process improvements get broken into parallel tasks
  • Jerry coordinates but specialists do the execution

The Daily Work Loop

Morning:

  1. Architect reads the morning brief (auto-generated overnight by the compound loop)
  2. Architect checks pending file-todos → flags any needing toli approval
  3. All Core Four agents check their QUEUE.md and claim ready file-todos

During the day: 4. Heartbeats check for new work every 30 minutes 5. Compound loops advance in-progress file-todos (research deepens, code progresses, outreach sends) 6. Completed file-todos trigger the next step in the pipeline (e.g., Builder finishes feature → Operator updates docs → Revenue Operator announces)

When a task is big: 7. The Core Four agent creates a team (TeamCreate) 8. Breaks work into TaskCreate items with dependencies (addBlockedBy) 9. Spawns specialists who self-organize via TaskList 10. Synthesizes results — delivers to toli or hands off to the next agent in the chain 11. Cleans up the team (TeamDelete)

The QUEUE.md + Task System Bridge

Each agent's QUEUE.md is their personal view of active work — what they are doing right now, what is next, and what is blocked.

  • When work spans multiple agents, it becomes a file-todo in the shared project todos/ directory
  • When work requires a swarm, the Core Four agent creates a TaskCreate/TaskList team
  • When work is session-local, the agent uses TodoWrite

Hierarchy of task systems, from most persistent to least:

file-todos (project backlog — survives across all sessions)
  → QUEUE.md (agent's active work — personal view of what matters now)
    → TaskCreate (swarm coordination — lives for the duration of a team)
      → TodoWrite (session tracking — dies when conversation ends)

Each level feeds into the one above it. A TodoWrite item might surface something that becomes a TaskCreate item in a swarm, which produces results that update a file-todo in the project backlog.

Project Structure for souls.zip

souls.zip/
├── todos/
│   ├── 001-ready-p1-auth-redesign.md
│   ├── 002-pending-p1-pricing-page-rewrite.md
│   ├── 003-ready-p2-dashboard-analytics.md
│   └── PROJECT.md (project context block)

PROJECT.md contains the business context block that gets injected into every specialist spawn for this project. It answers: What is this project? Who is the customer? What are the constraints? What has already been decided?

Every specialist that touches this project receives the PROJECT.md context so they never start from zero. This is how 36 specialists can work on the same codebase without stepping on each other or losing strategic alignment.