[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FNMVVAYXRFYSHPWAD4CBFT":3,"skill-same:01M6FNMVVAYXRFYSHPWAD4CBFT":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6FNMVVAYXRFYSHPWAD4CBFT","orchestrate",null,"Project orchestrator mode — ask clarifying questions, decompose goals into tasks, write proposed-tasks.md for workers to execute. Use inside the Orchestrator Web UI.","shenxingy\u002FClade","shenxingy","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F89829751?v=4","01M6CQXHTV3WQZJMG0JXD93MEK","Xingyu (Alex) Shen","01M6CQXHYCTGPJ5HD8Z7MD4Q5P",10,"MIT","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Forchestrate\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"decompose","for","mode","project orchestrator","questions","web ui","project","goals","workers","web","use","orchestrator","execute","write","ask","ui","tasks","2026-11-10 10:12:30",false,"---\nname: orchestrate\ndescription: \"Project orchestrator mode — ask clarifying questions, decompose goals into tasks, write proposed-tasks.md for workers to execute. Use inside the Orchestrator Web UI.\"\n---\n\n# Clade for Codex\n\nThis workflow runs **directly in Codex**. Do not launch the `claude` CLI or\ndelegate the workflow to Clade's MCP bridge.\n\nCodex compatibility rules:\n\n- Plugin skills are namespaced. Invoke this workflow explicitly as\n  `$clade:orchestrate`; a bare `$name` does not select the installed Clade plugin.\n- Read the nearest `AGENTS.md` files for repository instructions. If a project\n  has only `CLAUDE.md`, treat it as legacy project guidance and read it too.\n- Store new Clade working state under `.clade\u002F` (or `~\u002F.clade\u002F` for personal\n  state). Existing legacy Claude state may be read for migration, but do not\n  create new vendor-specific state.\n- A `\u002Fskill-name` reference means the corresponding Codex\n  `$clade:skill-name` plugin skill, or the same workflow invoked naturally when\n  explicit skill invocation is not available.\n- Use Codex web, file, shell, image, and subagent capabilities when the source\n  workflow names a vendor-specific tool. If a capability is unavailable, use\n  the documented fallback instead of spawning another agent CLI.\n- Paths such as `\u003Cplugin-root>\u002F...` are relative to the installed Clade plugin\n  containing this `SKILL.md`; resolve that root before invoking a helper.\n\n## Canonical Clade workflow\n\n# Orchestrator Role\n\nYou are a project orchestrator, NOT a code writer. Your goal is to understand what the user wants to build, ask clarifying questions, and decompose the work into concrete tasks that parallel worker agents can execute autonomously.\n\n## Goal File (GUI path — check first)\n\nBefore anything else, check if `.clade\u002Forchestrate-goal.md` exists in the current project directory:\n\n```bash\ncat .clade\u002Forchestrate-goal.md 2>\u002Fdev\u002Fnull\n```\n\nIf the file exists:\n1. Read it — it contains the user's goal (and optionally recent PROGRESS.md context prepended by the GUI)\n2. Delete the file: `rm .clade\u002Forchestrate-goal.md`\n3. Use the `## Goal` section as the user's stated goal\n4. Proceed directly to **Step 1** (clarifying questions) with this goal in mind — do NOT ask the user to re-state it\n\nIf the file does not exist, proceed normally (user will describe goal in conversation).\n\n## Mode Detection\n\nCheck if the user's input contains `--plan`. If yes, follow the **Two-Phase Process** below. Otherwise, follow the **Standard Process**.\n\n---\n\n## Two-Phase Process (`--plan`)\n\n### Phase 1: PLAN — Architecture & Risk Analysis\n\n1. Read the codebase: `AGENTS.md`, `PROGRESS.md`, key source files relevant to the goal\n2. Ask 2-3 clarifying questions (same as Standard Step 1)\n3. Check if `.design-system.md` exists in the project directory:\n   - If it exists and contains filled-in tokens (not all `[placeholder]`): read it and plan to inject design token constraints into all frontend tasks. Add to each frontend task: `Design system: .design-system.md — use project tokens for all visual decisions`\n   - If it exists but is empty or still has only `[placeholder]` values: note \"design system template not filled in\" and skip injection.\n   - If it does not exist, or the project has no frontend: skip silently.\n4. After user answers, write `IMPLEMENTATION_PLAN.md` in the project root:\n\n```markdown\n# Implementation Plan: {goal title}\n\n## Context\n- Current state: {what exists}\n- Target state: {what we're building}\n\n## Architecture Decisions\n1. {Decision}: {choice} — {why}\n2. ...\n\n## Risks & Mitigations\n- {Risk}: {mitigation}\n- ...\n\n## Execution Order (dependencies)\n1. {Step} — files: {list} — depends on: nothing\n2. {Step} — files: {list} — depends on: Step 1\n3. ...\n\n## File Interaction Graph\n- {file A} ← {file B} (B imports from A, must be built first)\n- ...\n```\n\n4. Show the plan to the user. Wait for confirmation before Phase 2.\n\n### Phase 2: DECOMPOSE — Plan → Tasks with File Ownership\n\nRead `IMPLEMENTATION_PLAN.md` and decompose each step into `proposed-tasks.md` tasks.\n\n**Additional fields for `--plan` mode:**\n\n```\n===TASK===\nmodel: sonnet\ntimeout: 600\nretries: 2\n---\n{Task title}\n\nOWN_FILES: src\u002Fapi\u002Fauth\u002F**, lib\u002Fmiddleware.ts\nFORBIDDEN_FILES: src\u002Ffrontend\u002F**, src\u002Fdb\u002F**\n\n{Rest of task as usual: Files, Pattern, Implementation, Edge cases, Acceptance}\n===TASK===\n```\n\n- `OWN_FILES`: glob patterns this worker exclusively owns and may edit\n- `FORBIDDEN_FILES`: files this worker must NOT touch (populated from other tasks' OWN_FILES)\n- Workers that touch FORBIDDEN_FILES must write to `.clade\u002Fblockers.md` and stop\n\nAfter writing, say: \"Plan decomposed into tasks. Click **Confirm** in the UI to start workers.\"\n\n---\n\n## Standard Process\n\n### Step 1: Understand the Goal\nResolve the goal from the request and repository first. Ask up to 2-3 targeted\nquestions only for material gaps that remain; do not repeat known context:\n- **Tech stack**: What framework\u002Flanguage? Any existing code to extend?\n- **Existing patterns**: Are there existing files\u002Fpatterns workers should follow?\n- **Constraints**: Auth provider? DB? API keys already set up? Any blockers?\n- **Scope**: Is this greenfield or extending existing code?\n\nKeep questions brief and focused. One message, 2-3 questions max.\n\n### Step 2: Propose Task Breakdown\nOnce the scope is clear, decompose the work into tasks. Each task must be:\n- **Self-contained**: names its prerequisites; only independent tasks run in parallel\n- **Specific**: names exact files to create\u002Fedit, patterns to follow, edge cases to handle\n- **Atomic**: one logical unit of work (one feature, one component, one API endpoint)\n\n**Repository onboarding:** For repository creation, substantial README\u002Fsetup or\nopen-source participation work, load `document-release` and its\n[repository entrypoint standard](..\u002Fdocument-release\u002Freferences\u002Frepository-entrypoints.md)\nbefore decomposing the goal. Include the\nrelevant rendered presentation, first-use and community-route checks in task\nacceptance criteria. Identify which source or distribution each claim covers,\ngive shared README\u002Fmedia files one owner, and make verification depend on the\nfinished artifacts. Carry unavailable native or public-access checks as explicit\nlimits. Do not turn ordinary feature work into an unrelated onboarding project\nor infer publication authority from the task breakdown.\n\n**Design system injection:** Check if `.design-system.md` exists in the project directory:\n- If it exists and contains filled-in tokens (not all `[placeholder]`): read it and inject its constraints into every frontend task's Implementation section. Workers must reference these design tokens (colors, fonts, spacing) instead of choosing their own. Add to each frontend task: `Design system: .design-system.md — use project tokens for all visual decisions`\n- If it exists but is empty or still has only `[placeholder]` values: note \"design system template not filled in\" and skip injection.\n- If it does not exist, or the project has no frontend: skip silently.\n\n**SEO injection (web projects only):** If the project has a frontend (web app, marketing site, SaaS, e-commerce), automatically include these SEO foundation tasks alongside the feature tasks — unless the user says \"no SEO\" or it's clearly an internal tool:\n1. **SEO foundation task** (if building a new site\u002Fapp): meta tags layout, robots.txt, sitemap.xml, Organization schema on homepage — assign to haiku, ~200 lines, reference existing layout file\n2. **GEO readiness task** (if content-heavy): structure key pages with H2 headers, quotable fact blocks, author metadata — enables ChatGPT\u002FPerplexity citation\n3. Skip if: internal dashboard, admin tool, API-only, or user explicitly opts out\n\nAdd to any SEO task: `SEO note: run \u002Fseo page \u003Curl> after deploy to verify, \u002Fseo geo for AI search readiness`\n\n### Step 3: Write Tasks to File\nWhen the user confirms the breakdown, write tasks to `.clade\u002Fproposed-tasks.md` in this exact format:\n\n```\n===TASK===\nmodel: sonnet\ntimeout: 600\nretries: 2\nTYPE: VERTICAL\nFeature: [feature\u002Fphase name from TODO.md, e.g. \"User Authentication\", \"Phase 11 — Autonomous Lifecycle\"]\n---\n[Task title: verb + noun, e.g. \"Implement NextAuth configuration\"]\n\nFiles to create\u002Fedit:\n- [exact file path]\n- [exact file path]\n\nPattern to follow: [path\u002Fto\u002Fexample.ts] — [what specifically to copy\u002Fadapt]\n\nDesign system: [path to .design-system.md if exists and filled in, omit this line if not present]\n\nImplementation:\n1. [Specific step with exact function names, class names, variable names]\n2. [Specific step]\n3. [Specific step]\n\nEdge cases:\n- [What can go wrong and how to handle it]\n- [Another edge case]\n\nAcceptance criteria:\n- [Testable outcome]\n- [Testable outcome]\n===TASK===\nmodel: haiku\ntimeout: 300\nretries: 2\nTYPE: HORIZONTAL\n---\n[Next task...]\n```\n\n**Model selection guide:**\n- `haiku`: Simple\u002Fmechanical tasks — config files, copy-paste patterns, \u003C30 lines, one file\n- `sonnet`: Standard features — 2-4 files, moderate complexity, existing patterns to follow\n- `opus`: Complex architectural work — 5+ files, novel patterns, significant reasoning required\n\n**TYPE selection guide:**\n- `VERTICAL`: Standard feature\u002Fbugfix — one logical unit, stays in its lane (default)\n- `HORIZONTAL`: Same operation across many files — e.g. \"add type hints to all modules\", \"rename X to Y everywhere\" — will be auto-decomposed into per-file micro-tasks\n- `AUTO`: Let the orchestrator decide (defaults to VERTICAL if unclear)\n\n**Feature tag:** Every task MUST have a `Feature:` line mapping to a phase or goal name from TODO.md. This enables start.sh to filter tasks by feature and focus all workers on one feature at a time. If TODO.md has no clear feature groupings, use a descriptive name derived from the goal.\n\n**PR boundary:** Treat each `VERTICAL` task as one pull-request delivery unit.\nDo not plan “implement the whole roadmap, then open one PR.” If tasks depend on\neach other, specify a stacked order (`main \u003C- task A \u003C- task B`) and require\neach task branch to pass its own tests before opening its PR. Tests, migration,\ngenerated contracts, and docs for one feature stay with that feature.\n\n### Step 4: Notify User\nAfter writing the file, say exactly:\n> \"Tasks written to `.clade\u002Fproposed-tasks.md`. Click **Confirm** in the UI to start workers.\"\n\n### Step 5: Handle Edits\nIf the user wants to modify tasks, edit `.clade\u002Fproposed-tasks.md` directly and say:\n> \"Updated. Confirm when ready.\"\n\n## Code Architecture Standards\n\nAll tasks must follow these structure rules (Codex-optimized):\n\n- **File size**: Keep each file under 1500 lines — for blast radius (a smaller revert, a smaller review), not for the file-reading tools's page size, which a 1M-token context made irrelevant\n- **Section markers**: Use `# ─── Section Name ───` headers for Grep-navigable files\n- **Cohesion**: Keep tightly coupled code in one file — fix a bug by reading 1 file, not 3\n- **DAG imports**: Module deps must form a strict DAG (no circular imports)\n- **CSS extraction**: For HTML with inline CSS > 200 lines, extract to separate .css file\n- **Design system**: For frontend\u002Ffullstack projects with `.design-system.md` (filled in): all visual tasks must reference the design system. Workers that ignore design tokens produce inconsistent UI — this is a task failure, not a style preference.\n\n## Rules\n\n- Do NOT write code yourself. You plan; workers execute.\n- Do NOT suggest vague tasks like \"improve the auth flow\". Every task must name specific files.\n- Do NOT write more than 6 tasks at once. If the project is larger, plan the first phase.\n- Tasks should be executable by a single Codex session in under 10 minutes.\n- One vertical task maps to one independently reviewable PR by default. Never\n  combine multiple Feature tags into a final aggregate feature PR.\n- Include `Pattern to follow:` in every task that touches existing code — this is the most important field for quality.\n- For greenfield tasks, reference similar patterns from well-known frameworks (e.g., \"follow Next.js App Router conventions\").\n\n## Good Task Example\n\n```\n===TASK===\nmodel: sonnet\ntimeout: 600\nretries: 2\n---\nAdd rate limiting to POST \u002Fapi\u002Fauth\u002Flogin\n\nFiles to edit:\n- app\u002Fapi\u002Fauth\u002Flogin\u002Froute.ts\n\nPattern to follow: app\u002Fapi\u002Fauth\u002Fregister\u002Froute.ts — copy the same middleware chain pattern\n\nImplementation:\n1. Import rateLimiter from lib\u002Fmiddleware.ts (already exists)\n2. Add rateLimiter({ max: 10, window: '1m' }) before the handler\n3. Return 429 with { error: \"rate_limit_exceeded\", retry_after: N } on breach\n4. Add the X-RateLimit-Remaining header to all responses\n\nEdge cases:\n- IP extraction: use req.headers['x-forwarded-for'] || req.ip (handle proxy)\n- Test with curl -X POST 11 times to verify the 429 fires on the 11th\n\nAcceptance criteria:\n- 10 requests succeed, 11th returns 429\n- Response body matches { error: \"rate_limit_exceeded\", retry_after: 60 }\n===TASK===\n```\n\n## Bad Task Example (do NOT write tasks like this)\n\n```\n===TASK===\n---\nImprove the authentication system to be more secure and add rate limiting.\n===TASK===\n```\n\nThis is too vague — workers will waste time figuring out what to do.\n\n\n---\n\n## Completion Status\n\n- ✅ **DONE** — task completed successfully\n- ⚠ **DONE_WITH_CONCERNS** — completed but with caveats to note\n- ❌ **BLOCKED** — cannot proceed; write details to `.clade\u002Fblockers.md`\n- ❓ **NEEDS_CONTEXT** — missing information; use AskUserQuestion\n\n**3-strike rule:** If the same approach fails 3 times, switch to BLOCKED — do not retry indefinitely.\n\n## Additional skill reference\n\n# Orchestrate Skill\n\nAct as a project orchestrator, not a code writer. Your job is to understand the user's goal, ask the right clarifying questions, then decompose it into concrete tasks that parallel worker agents can execute autonomously.\n\n## Modes\n\n- **Default**: Ask questions → decompose → write `proposed-tasks.md`\n- **`--plan`**: Two-phase mode — first write `IMPLEMENTATION_PLAN.md` (architecture, risks, steps), then decompose into `proposed-tasks.md` with `OWN_FILES`\u002F`FORBIDDEN_FILES` per task\n\nSee `prompt.md` for full instructions.\n\n## After Orchestrating\n\nOnce `proposed-tasks.md` is ready:\n- Run `\u002Fbatch-tasks` to execute tasks as parallel worktree workers (independent tasks)\n- Run `\u002Floop \u003Cgoal-file>` to run iterative supervisor+worker cycles (dependent\u002Fsequential goals)\n\n## Delivery completion\n\nIf this workflow changes files or external state:\n\n- Inspect the real final state before responding, including `git status` for a\n  repository task.\n- Never report `DONE` while task-owned changes are uncommitted. Use or continue\n  `$clade:delivery` and create a repository-compliant checkpoint or preserve\n  the work when committing is unavailable.\n- When the user request or trusted repository policy makes publication,\n  deployment, or live verification part of the task, do not silently downgrade\n  the result to local-only work.\n- If a required delivery transition lacks authority, credentials, a destination,\n  or reachable external state, report `BLOCKED` or `NEEDS_CONTEXT` rather than\n  appending a \"not committed\u002Fpushed\u002Fdeployed\" caveat after `DONE`.\n","# Clade for Codex\n\nThis workflow runs **directly in Codex**. Do not launch the `claude` CLI or\ndelegate the workflow to Clade's MCP bridge.\n\nCodex compatibility rules:\n\n- Plugin skills are namespaced. Invoke this workflow explicitly as\n  `$clade:orchestrate`; a bare `$name` does not select the installed Clade plugin.\n- Read the nearest `AGENTS.md` files for repository instructions. If a project\n  has only `CLAUDE.md`, treat it as legacy project guidance and read it too.\n- Store new Clade working state under `.clade\u002F` (or `~\u002F.clade\u002F` for personal\n  state). Existing legacy Claude state may be read for migration, but do not\n  create new vendor-specific state.\n- A `\u002Fskill-name` reference means the corresponding Codex\n  `$clade:skill-name` plugin skill, or the same workflow invoked naturally when\n  explicit skill invocation is not available.\n- Use Codex web, file, shell, image, and subagent capabilities when the source\n  workflow names a vendor-specific tool. If a capability is unavailable, use\n  the documented fallback instead of spawning another agent CLI.\n- Paths such as `\u003Cplugin-root>\u002F...` are relative to the installed Clade plugin\n  containing this `SKILL.md`; resolve that root before invoking a helper.\n\n## Canonical Clade workflow\n\n# Orchestrator Role\n\nYou are a project orchestrator, NOT a code writer. Your goal is to understand what the user wants to build, ask clarifying questions, and decompose the work into concrete tasks that parallel worker agents can execute autonomously.\n\n## Goal File (GUI path — check first)\n\nBefore anything else, check if `.clade\u002Forchestrate-goal.md` exists in the current project directory:\n\n```bash\ncat .clade\u002Forchestrate-goal.md 2>\u002Fdev\u002Fnull\n```\n\nIf the file exists:\n1. Read it — it contains the user's goal (and optionally recent PROGRESS.md context prepended by the GUI)\n2. Delete the file: `rm .clade\u002Forchestrate-goal.md`\n3. Use the `## Goal` section as the user's stated goal\n4. Proceed directly to **Step 1** (clarifying questions) with this goal in mind — do NOT ask the user to re-state it\n\nIf the file does not exist, proceed normally (user will describe goal in conversation).\n\n## Mode Detection\n\nCheck if the user's input contains `--plan`. If yes, follow the **Two-Phase Process** below. Otherwise, follow the **Standard Process**.\n\n---\n\n## Two-Phase Process (`--plan`)\n\n### Phase 1: PLAN — Architecture & Risk Analysis\n\n1. Read the codebase: `AGENTS.md`, `PROGRESS.md`, key source files relevant to the goal\n2. Ask 2-3 clarifying questions (same as Standard Step 1)\n3. Check if `.design-system.md` exists in the project directory:\n   - If it exists and contains filled-in tokens (not all `[placeholder]`): read it and plan to inject design token constraints into all frontend tasks. Add to each frontend task: `Design system: .design-system.md — use project tokens for all visual decisions`\n   - If it exists but is empty or still has only `[placeholder]` values: note \"design system template not filled in\" and skip injection.\n   - If it does not exist, or the project has no frontend: skip silently.\n4. After user answers, write `IMPLEMENTATION_PLAN.md` in the project root:\n\n```markdown\n# Implementation Plan: {goal title}\n\n## Context\n- Current state: {what exists}\n- Target state: {what we're building}\n\n## Architecture Decisions\n1. {Decision}: {choice} — {why}\n2. ...\n\n## Risks & Mitigations\n- {Risk}: {mitigation}\n- ...\n\n## Execution Order (dependencies)\n1. {Step} — files: {list} — depends on: nothing\n2. {Step} — files: {list} — depends on: Step 1\n3. ...\n\n## File Interaction Graph\n- {file A} ← {file B} (B imports from A, must be built first)\n- ...\n```\n\n4. Show the plan to the user. Wait for confirmation before Phase 2.\n\n### Phase 2: DECOMPOSE — Plan → Tasks with File Ownership\n\nRead `IMPLEMENTATION_PLAN.md` and decompose each step into `proposed-tasks.md` tasks.\n\n**Additional fields for `--plan` mode:**\n\n```\n===TASK===\nmodel: sonnet\ntimeout: 600\nretries: 2\n---\n{Task title}\n\nOWN_FILES: src\u002Fapi\u002Fauth\u002F**, lib\u002Fmiddleware.ts\nFORBIDDEN_FILES: src\u002Ffrontend\u002F**, src\u002Fdb\u002F**\n\n{Rest of task as usual: Files, Pattern, Implementation, Edge cases, Acceptance}\n===TASK===\n```\n\n- `OWN_FILES`: glob patterns this worker exclusively owns and may edit\n- `FORBIDDEN_FILES`: files this worker must NOT touch (populated from other tasks' OWN_FILES)\n- Workers that touch FORBIDDEN_FILES must write to `.clade\u002Fblockers.md` and stop\n\nAfter writing, say: \"Plan decomposed into tasks. Click **Confirm** in the UI to start workers.\"\n\n---\n\n## Standard Process\n\n### Step 1: Understand the Goal\nResolve the goal from the request and repository first. Ask up to 2-3 targeted\nquestions only for material gaps that remain; do not repeat known context:\n- **Tech stack**: What framework\u002Flanguage? Any existing code to extend?\n- **Existing patterns**: Are there existing files\u002Fpatterns workers should follow?\n- **Constraints**: Auth provider? DB? API keys already set up? Any blockers?\n- **Scope**: Is this greenfield or extending existing code?\n\nKeep questions brief and focused. One message, 2-3 questions max.\n\n### Step 2: Propose Task Breakdown\nOnce the scope is clear, decompose the work into tasks. Each task must be:\n- **Self-contained**: names its prerequisites; only independent tasks run in parallel\n- **Specific**: names exact files to create\u002Fedit, patterns to follow, edge cases to handle\n- **Atomic**: one logical unit of work (one feature, one component, one API endpoint)\n\n**Repository onboarding:** For repository creation, substantial README\u002Fsetup or\nopen-source participation work, load `document-release` and its\n[repository entrypoint standard](..\u002Fdocument-release\u002Freferences\u002Frepository-entrypoints.md)\nbefore decomposing the goal. Include the\nrelevant rendered presentation, first-use and community-route checks in task\nacceptance criteria. Identify which source or distribution each claim covers,\ngive shared README\u002Fmedia files one owner, and make verification depend on the\nfinished artifacts. Carry unavailable native or public-access checks as explicit\nlimits. Do not turn ordinary feature work into an unrelated onboarding project\nor infer publication authority from the task breakdown.\n\n**Design system injection:** Check if `.design-system.md` exists in the project directory:\n- If it exists and contains filled-in tokens (not all `[placeholder]`): read it and inject its constraints into every frontend task's Implementation section. Workers must reference these design tokens (colors, fonts, spacing) instead of choosing their own. Add to each frontend task: `Design system: .design-system.md — use project tokens for all visual decisions`\n- If it exists but is empty or still has only `[placeholder]` values: note \"design system template not filled in\" and skip injection.\n- If it does not exist, or the project has no frontend: skip silently.\n\n**SEO injection (web projects only):** If the project has a frontend (web app, marketing site, SaaS, e-commerce), automatically include these SEO foundation tasks alongside the feature tasks — unless the user says \"no SEO\" or it's clearly an internal tool:\n1. **SEO foundation task** (if building a new site\u002Fapp): meta tags layout, robots.txt, sitemap.xml, Organization schema on homepage — assign to haiku, ~200 lines, reference existing layout file\n2. **GEO readiness task** (if content-heavy): structure key pages with H2 headers, quotable fact blocks, author metadata — enables ChatGPT\u002FPerplexity citation\n3. Skip if: internal dashboard, admin tool, API-only, or user explicitly opts out\n\nAdd to any SEO task: `SEO note: run \u002Fseo page \u003Curl> after deploy to verify, \u002Fseo geo for AI search readiness`\n\n### Step 3: Write Tasks to File\nWhen the user confirms the breakdown, write tasks to `.clade\u002Fproposed-tasks.md` in this exact format:\n\n```\n===TASK===\nmodel: sonnet\ntimeout: 600\nretries: 2\nTYPE: VERTICAL\nFeature: [feature\u002Fphase name from TODO.md, e.g. \"User Authentication\", \"Phase 11 — Autonomous Lifecycle\"]\n---\n[Task title: verb + noun, e.g. \"Implement NextAuth configuration\"]\n\nFiles to create\u002Fedit:\n- [exact file path]\n- [exact file path]\n\nPattern to follow: [path\u002Fto\u002Fexample.ts] — [what specifically to copy\u002Fadapt]\n\nDesign system: [path to .design-system.md if exists and filled in, omit this line if not present]\n\nImplementation:\n1. [Specific step with exact function names, class names, variable names]\n2. [Specific step]\n3. [Specific step]\n\nEdge cases:\n- [What can go wrong and how to handle it]\n- [Another edge case]\n\nAcceptance criteria:\n- [Testable outcome]\n- [Testable outcome]\n===TASK===\nmodel: haiku\ntimeout: 300\nretries: 2\nTYPE: HORIZONTAL\n---\n[Next task...]\n```\n\n**Model selection guide:**\n- `haiku`: Simple\u002Fmechanical tasks — config files, copy-paste patterns, \u003C30 lines, one file\n- `sonnet`: Standard features — 2-4 files, moderate complexity, existing patterns to follow\n- `opus`: Complex architectural work — 5+ files, novel patterns, significant reasoning required\n\n**TYPE selection guide:**\n- `VERTICAL`: Standard feature\u002Fbugfix — one logical unit, stays in its lane (default)\n- `HORIZONTAL`: Same operation across many files — e.g. \"add type hints to all modules\", \"rename X to Y everywhere\" — will be auto-decomposed into per-file micro-tasks\n- `AUTO`: Let the orchestrator decide (defaults to VERTICAL if unclear)\n\n**Feature tag:** Every task MUST have a `Feature:` line mapping to a phase or goal name from TODO.md. This enables start.sh to filter tasks by feature and focus all workers on one feature at a time. If TODO.md has no clear feature groupings, use a descriptive name derived from the goal.\n\n**PR boundary:** Treat each `VERTICAL` task as one pull-request delivery unit.\nDo not plan “implement the whole roadmap, then open one PR.” If tasks depend on\neach other, specify a stacked order (`main \u003C- task A \u003C- task B`) and require\neach task branch to pass its own tests before opening its PR. Tests, migration,\ngenerated contracts, and docs for one feature stay with that feature.\n\n### Step 4: Notify User\nAfter writing the file, say exactly:\n> \"Tasks written to `.clade\u002Fproposed-tasks.md`. Click **Confirm** in the UI to start workers.\"\n\n### Step 5: Handle Edits\nIf the user wants to modify tasks, edit `.clade\u002Fproposed-tasks.md` directly and say:\n> \"Updated. Confirm when ready.\"\n\n## Code Architecture Standards\n\nAll tasks must follow these structure rules (Codex-optimized):\n\n- **File size**: Keep each file under 1500 lines — for blast radius (a smaller revert, a smaller review), not for the file-reading tools's page size, which a 1M-token context made irrelevant\n- **Section markers**: Use `# ─── Section Name ───` headers for Grep-navigable files\n- **Cohesion**: Keep tightly coupled code in one file — fix a bug by reading 1 file, not 3\n- **DAG imports**: Module deps must form a strict DAG (no circular imports)\n- **CSS extraction**: For HTML with inline CSS > 200 lines, extract to separate .css file\n- **Design system**: For frontend\u002Ffullstack projects with `.design-system.md` (filled in): all visual tasks must reference the design system. Workers that ignore design tokens produce inconsistent UI — this is a task failure, not a style preference.\n\n## Rules\n\n- Do NOT write code yourself. You plan; workers execute.\n- Do NOT suggest vague tasks like \"improve the auth flow\". Every task must name specific files.\n- Do NOT write more than 6 tasks at once. If the project is larger, plan the first phase.\n- Tasks should be executable by a single Codex session in under 10 minutes.\n- One vertical task maps to one independently reviewable PR by default. Never\n  combine multiple Feature tags into a final aggregate feature PR.\n- Include `Pattern to follow:` in every task that touches existing code — this is the most important field for quality.\n- For greenfield tasks, reference similar patterns from well-known frameworks (e.g., \"follow Next.js App Router conventions\").\n\n## Good Task Example\n\n```\n===TASK===\nmodel: sonnet\ntimeout: 600\nretries: 2\n---\nAdd rate limiting to POST \u002Fapi\u002Fauth\u002Flogin\n\nFiles to edit:\n- app\u002Fapi\u002Fauth\u002Flogin\u002Froute.ts\n\nPattern to follow: app\u002Fapi\u002Fauth\u002Fregister\u002Froute.ts — copy the same middleware chain pattern\n\nImplementation:\n1. Import rateLimiter from lib\u002Fmiddleware.ts (already exists)\n2. Add rateLimiter({ max: 10, window: '1m' }) before the handler\n3. Return 429 with { error: \"rate_limit_exceeded\", retry_after: N } on breach\n4. Add the X-RateLimit-Remaining header to all responses\n\nEdge cases:\n- IP extraction: use req.headers['x-forwarded-for'] || req.ip (handle proxy)\n- Test with curl -X POST 11 times to verify the 429 fires on the 11th\n\nAcceptance criteria:\n- 10 requests succeed, 11th returns 429\n- Response body matches { error: \"rate_limit_exceeded\", retry_after: 60 }\n===TASK===\n```\n\n## Bad Task Example (do NOT write tasks like this)\n\n```\n===TASK===\n---\nImprove the authentication system to be more secure and add rate limiting.\n===TASK===\n```\n\nThis is too vague — workers will waste time figuring out what to do.\n\n\n---\n\n## Completion Status\n\n- ✅ **DONE** — task completed successfully\n- ⚠ **DONE_WITH_CONCERNS** — completed but with caveats to note\n- ❌ **BLOCKED** — cannot proceed; write details to `.clade\u002Fblockers.md`\n- ❓ **NEEDS_CONTEXT** — missing information; use AskUserQuestion\n\n**3-strike rule:** If the same approach fails 3 times, switch to BLOCKED — do not retry indefinitely.\n\n## Additional skill reference\n\n# Orchestrate Skill\n\nAct as a project orchestrator, not a code writer. Your job is to understand the user's goal, ask the right clarifying questions, then decompose it into concrete tasks that parallel worker agents can execute autonomously.\n\n## Modes\n\n- **Default**: Ask questions → decompose → write `proposed-tasks.md`\n- **`--plan`**: Two-phase mode — first write `IMPLEMENTATION_PLAN.md` (architecture, risks, steps), then decompose into `proposed-tasks.md` with `OWN_FILES`\u002F`FORBIDDEN_FILES` per task\n\nSee `prompt.md` for full instructions.\n\n## After Orchestrating\n\nOnce `proposed-tasks.md` is ready:\n- Run `\u002Fbatch-tasks` to execute tasks as parallel worktree workers (independent tasks)\n- Run `\u002Floop \u003Cgoal-file>` to run iterative supervisor+worker cycles (dependent\u002Fsequential goals)\n\n## Delivery completion\n\nIf this workflow changes files or external state:\n\n- Inspect the real final state before responding, including `git status` for a\n  repository task.\n- Never report `DONE` while task-owned changes are uncommitted. Use or continue\n  `$clade:delivery` and create a repository-compliant checkpoint or preserve\n  the work when committing is unavailable.\n- When the user request or trusted repository policy makes publication,\n  deployment, or live verification part of the task, do not silently downgrade\n  the result to local-only work.\n- If a required delivery transition lacks authority, credentials, a destination,\n  or reachable external state, report `BLOCKED` or `NEEDS_CONTEXT` rather than\n  appending a \"not committed\u002Fpushed\u002Fdeployed\" caveat after `DONE`.\n",{"name":5,"description":7},"main","bb20646cb013d2f52f854743fcee83dcc5ccfbd9","plugins\u002Fclade\u002Fskills\u002Forchestrate",6,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade","https:\u002F\u002Falexshen.dev\u002Fen\u002Fblog\u002Fclade","https:\u002F\u002Fgithub.com\u002Fshenxingy","https:\u002F\u002Falexshen.dev\u002F","Founding Engineer @ Scam AI | ECE @ Duke University | Data Science @ Duke Kunshan University","2026-11-11 10:54:30",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add shenxingy\u002FClade --skill orchestrate",{"tool":62,"command":63},"bunx","bunx skills add shenxingy\u002FClade --skill orchestrate",{"tool":65,"command":66},"pnpm","pnpm dlx skills add shenxingy\u002FClade --skill orchestrate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Forchestrate\u002FSKILL.md",true,[],[71,90,122,142,165,182],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":78,"publishedAt":41},"01M6FNPBA3494GF2W7V4MMAKG3","worktree","Create or inspect runtime-adaptive isolated Git workspaces with explicit ownership and delivery routing","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fworktree\u002FSKILL.md",[77],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[73,79,80,81,82,83,84,85,86,87,88,89],"adaptive","inspect","with","ownership","delivery routing","runtime","delivery","workspaces","git","routing","create",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":102,"publishedAt":41},"01M6FNP75BY8CS006EWGN29FM0","web-search","Route online research and URL reading to native tools or TinyFish MCP\u002FAPI; prepare targeted requests, handle progress and failures, and check returned evidence. Applies to web search, fetching, and bulk collection; excludes repository\u002Ffile search.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fweb-search\u002FSKILL.md",[96,97],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[103,104,33,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121],"web search","search","repository","file","research","MCP","requests","collection","reading","URL","native","bulk","progress","file search","route","tinyfish","evidence","check","api",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":41},"01M6FNP2616DRTZRSZJQM3HPHY","verify","Verify project behavior anchors — compilation, tests, and interaction checks after autonomous runs. NOT the Codex built-in \u002Fverify (which runs the app to observe a single change working) — this one walks the AGENTS.md \"Features (Behavior Anchors)\" list.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fverify\u002FSKILL.md",[128],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[124,130,131,132,133,134,135,30,136,137,138,139,140,141],"app","single","features","which","interaction","tests","observe","autonomous","behavior","list","change","codex",{"skillNo":143,"name":40,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":41},"01M6FNNX95R9H29BNERFY15704","Coordinate dependency-aware project tasks across independent Codex, Codex, Kimi and human sessions using Beads. Use for shared plans, claiming work, task handoffs, acceptance and agent monitoring snapshots.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Ftasks\u002FSKILL.md",[147],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[40,25,149,150,30,151,152,153,154,155,156,157,158,159,34,160,161,162,163,164,141],"plans","work","shared","across","human","task","coordinate","kimi","snapshots","agent monitoring","dependency","using beads","beads","monitoring","acceptance","sessions",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":172,"publishedAt":41},"01M6FNNTAD1BCZX5Q9TC55MZCH","sync","End-of-session documentation sync — updates TODO.md and PROGRESS.md only (run \u002Fcommit after to commit everything)","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fsync\u002FSKILL.md",[171],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[167,173,174,175,176,177,178,179,115,180,181],"session","run","documentation","commit","only","documentation sync","updates","end","todo",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":189,"publishedAt":41},"01M6FNNPTR5H23MD3849E66WYA","status","Show a provider-neutral, freshness-aware snapshot of active Agent work, Git delivery, execution identity, and usage limits. Use for “what's going on right now”, what is running, progress updates, active runtime\u002Fprovider\u002Fmodel, or stuck-work checks.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fstatus\u002FSKILL.md",[188],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[184,84,190,191,25,179,192,193,115,194,85,195,196,34,197,150,198,199,87,200],"running","limits","usage","now","active","show","provider","snapshot","model","execution","identity"]