task-orchestrator skill

Use this skill when the user needs reliable agent coordination with tm.

Activation cues

Activate this skill when requests involve:

• delegating to multiple agents
• sequencing dependent tasks
• sharing context between assignees
• tracking progress or blocked work
• orchestrating a delivery pipeline

Prerequisites

1. tm exists in the current project root.
2. The project has been initialized with ./tm init.
3. TM_AGENT_ID is set for the current agent session.

Startup protocol (always)

./tm list
./tm list --format json

Do not treat ORCHESTRATOR.md as live runtime state. It is a static discovery contract.

Standard workflow

1. Set identity:

   export TM_AGENT_ID="orchestrator_agent"
   

2. Create tasks with Commander's Intent:

   ./tm add "Implement auth API" --assignee backend_agent \
     -d "WHY: secure user access, WHAT: login/token/session endpoints, DONE: users can authenticate successfully"
   

3. Add dependencies:

   ./tm add "Create login UI" --assignee frontend_agent --depends-on <backend_task_id>
   

4. Share handoff context:

   ./tm share <task_id> "API contract: POST /auth/login, POST /auth/refresh"
   

5. Track progress:

   ./tm progress <task_id> "Implemented token issuance and refresh validation"
   

6. Complete to trigger unblocking:

   ./tm complete <task_id>
   

Coordination rules

• Query state with ./tm list before creating or updating tasks.
• Include WHY, WHAT, and DONE in all substantive delegated tasks.
• Use ./tm share for cross-agent information, not private notes.
• Use ./tm note only for private reasoning.
• Keep commands non-interactive and deterministic.

Safety and quality

• Avoid destructive operations unless explicitly requested.
• If task state conflicts with assumptions, re-query ./tm list --format json.
• For release-related orchestration, run from release source branch policy (main unless overridden by process).

Available resources

• Runtime checks: scripts/verify-tm.sh
• Extended reference: references/REFERENCE.md