Orchestrate

Orchestrate: Full Task Pipeline

Run the complete agent pipeline for a task: branch setup, implement, test, CI validate, review, push, and create PR.

Usage

/orchestrate <asana-task-id-or-url>

Accepts either:

• Asana task ID: 1213560067347874
• Asana URL: https://app.asana.com/0/1234567890/1213560067347874

Pipeline

Phase 0: Setup

1. Parse the Asana task ID from the argument:

   • If it's a URL, extract the last numeric segment as the task ID
   • If it's already a numeric ID, use it directly

2. Read the Asana task to get:

   • Task title
   • Task description and acceptance criteria
   • Any tags or custom fields (e.g., package name, ticket number)

3. Create a feature branch from main:

   • Pull latest main: git checkout main && git pull origin main
   • Generate branch name from task: feat/<ticket>-<slug>
     • Extract ticket number from task name or custom field (e.g., QVAC-123)
     • Slugify the task title (lowercase, hyphens, max 50 chars)
     • Example: feat/QVAC-123-add-rag-support-for-lancedb
   • If no ticket number found: feat/<task-title-slug>
   • Create and switch to branch: git checkout -b <branch-name>

4. Inform the user of the setup:

   Task: <task-title>
   Branch: <branch-name>

Phase 0.5: Plan

Before any implementation, create a plan for the user to approve:

1. Read the relevant source files mentioned in the task description or likely affected by the changes
2. Draft an implementation plan that includes:
   • Summary of what will be changed and why
   • Files to create or modify (with brief description of changes per file)
   • Approach and key design decisions
   • Dependencies or packages to add (if any)
   • How it will be verified (build commands, test commands)
3. Present the plan to the user and wait for approval
   • If the user requests changes, update the plan and ask again
   • Do NOT proceed until the user explicitly approves
4. Comment on the Asana task with the approved plan

Phase 1: Implement

Launch the implementer agent with the Asana task ID and the approved plan.

Implement Asana task <task-id>. Follow this approved plan:

<paste the approved plan here>

Write code within scope of the plan, verify build/tests pass, and commit working changes.

Wait for completion. If the implementer reports failure (e.g., ambiguous requirements, build failures after 3 retries), stop the pipeline and report to the user.

Phase 1.5: Determine test and CI requirements

After implementation, analyze the changed files and the Asana task to decide what's needed next.

Run git diff --name-only main...HEAD and apply these rules:

1. Native addon packages — if changed files match a package in the CI Package Mapping table in .agent/knowledge/ci-validation.md, CI is needed. Use the short name from that table. If multiple addon packages changed, run CI for each.

2. SDK / TS packages (packages/sdk/**, packages/rag/**, packages/cli/**) — SDK CI runs automatically via pr-checks-sdk-pod on PR creation. No manual trigger needed.

3. Everything else (simple libraries, docs, workflows, config, markdown) — no CI needed.

If CI is needed, inform the user which packages will be validated and why.

Determine if new tests are needed by checking:

Read the Asana task acceptance criteria. If they describe specific behaviors or scenarios, those should become tests.

Phase 1.75: Write Tests

If Phase 1.5 determined tests are needed, launch the test-writer agent:

Write automated tests for the changes on the current branch. Task ID: <task-id>. Focus on new public APIs, new behavior, and edge cases. Match existing test patterns.

Wait for completion. If the test-writer discovers code bugs, launch the implementer again with the bug details before proceeding.

If tests are not needed, skip to Phase 2.