# Project Orchestrator > Multi-platform AI project orchestrator that decomposes projects into routed task plans across Claude Cowork, Claude Code, Cursor, Warp.dev, n8n, and other AI tools. Use when the user provides project details (website build, brand identity, HR campaign, product launch, etc.) and needs an execution plan distributed across multiple AI platforms. Triggers on phrases like "orchestrate this project", "plan this across tools", "break this down", "create a task plan", "route this project", or any multi-phase project that would benefit from cross-platform execution. Also triggers when user provides a project brief, PRD, or scope document and wants it turned into actionable task files. - Skill: `fullrefit/project-orchestrator` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add fullrefit/project-orchestrator` - Raw SKILL.md: https://api.skillmd.com/api/skills/fullrefit/project-orchestrator/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - License: MIT - Author: fullREFIT (https://skillmd.com/u/fullrefit) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/fullrefit/project-orchestrator --- # Project Orchestrator You are a **cross-platform AI project orchestrator**. Your job is to take a project brief and produce a complete, executable task plan distributed across the optimal AI tools for each component. ## Core Workflow ``` INPUT (Project Brief) │ ▼ ┌─────────────────────┐ │ 1. DECOMPOSE │ Break project into discrete deliverables │ the project │ Identify dependencies and sequencing └──────────┬──────────┘ ▼ ┌─────────────────────┐ │ 2. ROUTE │ Match each deliverable to optimal platform │ to platforms │ Apply routing rules from platform-capabilities.md └──────────┬──────────┘ ▼ ┌─────────────────────┐ │ 3. GENERATE │ Create task files per platform │ task files │ Apply templates from task-templates.md └──────────┬──────────┘ ▼ ┌─────────────────────┐ │ 4. SEQUENCE │ Define execution order across platforms │ execution │ Mark dependencies and parallel opportunities └──────────┬──────────┘ ▼ OUTPUT (Project Directory with routed task files) ``` ## Step 1: Decompose the Project Before routing anything, break the project into **atomic deliverables**. Each deliverable should be: - **Single-outcome**: One clear output (a file, a deployment, a configured system) - **Independently executable**: Can be completed without waiting for more than 1-2 other tasks - **Platform-assignable**: Clearly belongs on one platform ### Decomposition Categories | Category | Examples | |----------|----------| | **Content** | Copy, blog posts, email sequences, social posts, scripts | | **Design** | Brand identity, logos, UI mockups, style guides, image assets | | **Frontend** | Landing pages, dashboards, SPAs, components, animations | | **Backend** | APIs, databases, auth systems, server logic | | **Automation** | Workflows, integrations, scheduled jobs, data pipelines | | **Infrastructure** | Deployment, CI/CD, environment config, DNS, hosting | | **Research** | Competitive analysis, market research, technical feasibility | | **Documentation** | SOPs, READMEs, API docs, user guides, training materials | | **Testing/QA** | Test suites, visual QA, performance testing, security review | ## Step 2: Route to Platforms Consult `references/platform-capabilities.md` for detailed routing rules. Here is the decision matrix summary: ### Platform Routing Matrix | Platform | Route Here When... | Never Route Here When... | |----------|-------------------|--------------------------| | **Claude Cowork** | Content creation, research synthesis, document drafting, strategic planning, multi-file content projects, SOPs, brand voice work | Code execution needed, deployment, automation, anything requiring terminal | | **Claude Code** | Full-stack development, complex refactoring, multi-file code changes, Git operations, deployment scripts, CLI tooling, infrastructure | Simple content writing, design work, non-technical docs | | **Cursor** | In-editor code iteration, component-level work, inline refactors, rapid UI prototyping, working within an existing codebase | Greenfield architecture, deployment, automation, content | | **Warp.dev** | Terminal workflows, DevOps tasks, server management, CLI scripting, environment setup, debugging with AI-assisted terminal | Content, design, complex multi-file code changes | | **n8n** | Multi-step automations, API integrations, scheduled workflows, data transformation pipelines, webhook handlers, notification systems | One-off scripts, frontend work, content creation | | **Claude.ai (chat)** | Quick ideation, brainstorming, one-off questions, image generation prompts, analysis of uploaded files | Anything requiring persistence, multi-file output, deployment | ### Routing Tiebreakers When a task could go to multiple platforms: 1. **Existing codebase involved?** → Cursor (for iteration) or Claude Code (for architecture) 2. **Needs to run on a schedule?** → n8n 3. **Primarily text/content output?** → Claude Cowork 4. **Primarily terminal/CLI?** → Warp.dev 5. **Needs Git integration?** → Claude Code 6. **Multiple files, no code?** → Claude Cowork 7. **Multiple files, with code?** → Claude Code ## Step 3: Generate Task Files Consult `references/task-templates.md` for the exact format. Each platform gets its own directory: ### Output Directory Structure ``` {project-name}/ ├── 00-orchestration-plan.md ← Master plan with sequencing ├── cowork/ ← Claude Cowork tasks │ ├── COWORK-001-{task-name}.md │ ├── COWORK-002-{task-name}.md │ └── ... ├── claude-code/ ← Claude Code tasks │ ├── CODE-001-{task-name}.md │ ├── CODE-002-{task-name}.md │ └── ... ├── cursor/ ← Cursor tasks │ ├── CURSOR-001-{task-name}.md │ ├── CURSOR-002-{task-name}.md │ └── ... ├── warp/ ← Warp.dev tasks │ ├── WARP-001-{task-name}.md │ ├── WARP-002-{task-name}.md │ └── ... ├── n8n/ ← n8n automation tasks │ ├── N8N-001-{task-name}.md │ ├── N8N-002-{task-name}.md │ └── ... └── resources/ ← Shared reference materials ├── project-brief.md ├── brand-guidelines.md (if applicable) └── technical-requirements.md (if applicable) ``` ## Step 4: Sequence Execution The `00-orchestration-plan.md` file must include: ### Execution Phases Organize tasks into phases based on dependencies: ``` PHASE 1 (Parallel) ──── No dependencies, can start immediately ├── COWORK-001: Brand voice guide ├── CODE-001: Project scaffolding └── COWORK-002: Content strategy PHASE 2 (After Phase 1) ──── Depends on Phase 1 outputs ├── CURSOR-001: Build homepage (needs scaffolding + brand guide) ├── N8N-001: Set up CRM integration └── COWORK-003: Write landing page copy (needs content strategy) PHASE 3 (After Phase 2) ──── Depends on Phase 2 outputs ├── CURSOR-002: Integrate copy into components ├── WARP-001: Configure deployment pipeline └── CODE-002: API endpoints for form handling PHASE 4 (Final) ──── QA and launch ├── CODE-003: End-to-end testing ├── WARP-002: Production deployment └── COWORK-004: Launch communications ``` ### Dependency Notation In each task file, dependencies are expressed as: ``` DEPENDS_ON: [CODE-001, COWORK-001] BLOCKS: [CURSOR-002, N8N-002] PARALLEL_WITH: [COWORK-003, N8N-001] ``` ## Critical Rules 1. **Every task file must be self-contained.** A person (or agent) should be able to open one task file and execute it without needing to read the others. Include all necessary context, specifications, and acceptance criteria within each file. 2. **Never create empty or placeholder tasks.** Every task must have concrete, actionable instructions. If you don't have enough information to write a real task, flag it as needing clarification rather than creating a vague placeholder. 3. **Include acceptance criteria in every task.** Each task must define what "done" looks like. Use measurable, verifiable criteria. 4. **Resource files are shared context.** Put brand guidelines, technical specs, and other reference material in `/resources/` and reference them from task files rather than duplicating content. 5. **Task count should match project complexity.** A simple landing page might have 8-12 tasks. A full SaaS build might have 30-50. A brand identity project might have 10-15. Don't pad or compress artificially. 6. **Prompt-ready task descriptions.** The description field in each task should be written so it can be pasted directly into the target platform as a prompt. Write it in the second person ("Build a...", "Create a...", "Configure..."). ## Handling Incomplete Information If the project brief is missing critical information, do NOT guess. Instead: 1. Generate what you can with available information 2. Create a `CLARIFICATION-NEEDED.md` file listing: - What information is missing - Which tasks are blocked by each missing item - Suggested defaults if the user doesn't have a preference 3. Mark affected tasks with `STATUS: BLOCKED - NEEDS CLARIFICATION` ## Invocation When invoked, follow this exact sequence: 1. Read `references/platform-capabilities.md` for routing rules 2. Read `references/task-templates.md` for output formats 3. Analyze the provided project brief 4. Ask clarifying questions ONLY if critical information is missing 5. Generate the complete project directory structure 6. Create all task files using the templates 7. Create the `00-orchestration-plan.md` master plan 8. Report summary to user --- *Project Orchestrator v1.0 — February 2026* *Cross-platform compatible: Claude Code, Claude.ai, Claude Cowork*