project-coordinator（项目协调员）

Installation

Option 1: ClawhHub CLI (recommended)

openclaw skills install project-coordinator
# or
clawhub install project-coordinator

Option 2: From GitHub

# Clone the repo
git clone https://github.com/KaigeGao1110/Project-Coordinator.git ~/.openclaw/skills/project-coordinator

# Or download directly
curl -L https://github.com/KaigeGao1110/Project-Coordinator/archive/refs/heads/main.zip -o /tmp/project-coordinator.zip
unzip /tmp/project-coordinator.zip -d ~/.openclaw/skills/
mv ~/.openclaw/skills/Project-Coordinator-main ~/.openclaw/skills/project-coordinator

Project Coordinator Skill

A skill for structuring multi-agent project execution with isolated session architecture.

Manifest

name: project-coordinator
version: 1.0.11
description: |
  Spawns an isolated Project Coordinator session that owns a project's context,
  breaks work into tasks, and spawns subagents for parallel execution.
  The Coordinator reports back to the main session when done.
permissions:
  - spawn: subagent sessions (via sessions_spawn)
  - read: workspace files
  - exec: shell commands via subagents
dataPolicy:
  archivedData: internal workspace only
  neverExternal: true

Architecture

Main Session (never runs code directly)
  └── Project Coordinator (spawned per project, mode="run")
        └── Subagents (spawned by Coordinator, run tasks in parallel)

Token efficiency: Each project Coordinator is isolated. Old project sessions accumulate zero main-session tokens after completion.

Least-privilege design: The Coordinator does NOT read session transcript files directly. All transcript reading, sanitization, and archiving is delegated to a dedicated archive-subagent using the archive-project skill.

Trigger Conditions

Activated when:

• User says "start a new project" or "let's work on [project]"
• A task is complex and needs multiple subagents
• A task will take more than a few minutes
• When user says "archive this" after a project is done → spawn archive-subagent

Do NOT activate for: quick questions, simple lookups, one-liner tasks.

Trigger 3: Slash command

Type //start followed by your project description to activate the Project Coordinator. Example: "//start build a Chrome extension"

Project Coordinator Pattern

Step 1: Define the Project

Collect from the user:

• Project name (e.g., "cureforge-hr-assessment")
• Project description (1-2 sentences)
• Key deliverables
• Any known constraints

Step 2: Spawn Project Coordinator

sessions_spawn(
  task=f"""You are the Project Coordinator for {project_name}.

Project: {project_description}

Your job:
1. Understand the full scope of this project
2. Break it into independent tasks
3. Spawn subagents to execute tasks in parallel
4. Monitor subagent progress
5. Compile results and report back to main session

When done, write a summary and await further instructions.
""",
  label=f"coordinator-{project_name}",
  runtime="subagent",
  model="minimax-m2.7-highspeed",
  mode="run"
)

Step 3: Monitor Progress

• Use subagents(action="list") to track subagent status
• Receive completion announcements via inter-session messages
• If a subagent fails, decide whether to retry or adapt

Step 4: Compile and Report

When all subagents complete:

1. Review all outputs
2. Write a final summary
3. Save any deliverables before the Coordinator session ends

Step 5: Archiving (Delegated)

When a project is complete and archiving is requested:

1. The Coordinator spawns an archive-subagent
2. The archive-subagent uses the archive-project skill to handle:

- Locating the correct session transcripts - Sanitizing credentials - Writing ARCHIVE.md - Committing to workspace

1. The Coordinator monitors the archive-subagent and reports completion

The Coordinator itself does NOT read session transcript files directly.

Coordinator's Tool Usage

Note: The Coordinator should NOT directly read, copy, move, or delete session transcript files. All such operations must be performed by a dedicated archive-subagent using the archive-project skill.

Subagent sandboxing: When spawning subagents, each subagent runs in an isolated sandbox with workspace-only filesystem access. Subagents cannot access credentials, environment variables, or session transcripts outside their scope. Network access is restricted per platform policy.

The Coordinator SHOULD directly call tools:

• exec — run commands, check files
• write — create output files
• read — examine code or documents
• sessions_spawn — spawn subagents for parallel work
• subagents — monitor subagent status

Subagent Naming Convention

Format: {project}-{role}

Examples:

• cureforge-gke-migration
• cureforge-rabbitmq-queue
• cureforge-review

Session Management Rules

• One Coordinator per project (isolated token accounting)
• Do NOT run multiple unrelated projects in one Coordinator
• When a project is complete, the Coordinator stops — no lingering sessions
• For long-running projects: Coordinator can spawn child Coordinators for sub-phases

After Project Completion

1. Report completion to Main session (brief summary)
2. Notify the user
3. User decides: archive / continue / hold