菜单
Execute implementation plans by dispatching subagents per task with pre-flight question phases. Load when tasks are independent and you want to delegate.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | task-dispatch |
| description | Execute implementation plans by dispatching subagents per task with pre-flight question phases. Load when tasks are independent and you want to delegate. |
Dispatch fresh subagent per task with two-phase execution: question collection, then implementation.
Subagents running with pi --no-session cannot ask questions mid-execution. They run to completion. So we structure the dispatch in two steps:
Phase 1: Collect questions
Controller → Dispatch implementer (questions-only mode)
Subagent → Outputs questions and STOPs
Phase 2: Execute with answers
Controller → Parse questions, relay to user, get answers
Controller → Re-dispatch implementer with answers
Subagent → Works autonomously to completion
After implementation: same two-stage review as before.
Never skip review loops or proceed with open issues.
Dispatch implementer with this prompt:
You are planning implementation for: [task name]
## Task
[FULL TEXT from plan - paste here, do not read file]
## Context
[Where this fits, dependencies, architectural notes]
## Your Job
Before writing any code, identify everything you need to know to implement this task correctly.
Output your questions in this format, then STOP:
QUESTIONS:
If you have no questions, output:
QUESTIONS:
None
and then STOP.
Do NOT start implementation. Only identify questions.
## Phase 2: Execution Prompt
After user provides answers, re-dispatch:
You are implementing: [task name]
[FULL TEXT from plan]
[Same as before]
[The user answered:] Q1: [answer] Q2: [answer] ...
If you encounter something unexpected that wasn't covered by the answers, report BLOCKED with specifics.
Ask nothing. Proceed with implementation.
## Spec Reviewer Prompt
Review whether implementation matches spec.
[FULL TEXT]
[From implementer's report]
Read actual code. Do NOT trust the report.
Check:
Report: ✅ Spec compliant | ❌ Issues: [with file:line refs]
## Code Quality Reviewer Prompt
Review code quality: clean, tested, maintainable.
Only run after spec compliance passes.
Check:
Report: Strengths, Issues (Critical/Important/Minor), Assessment
## Status Handling
| Status | Action |
|--------|--------|
| DONE | Proceed to spec review |
| DONE_WITH_CONCERNS | Read concerns first, proceed to review |
| BLOCKED | Assess blocker: more context / stronger model / break task / escalate to human |
## Model Selection
| Task | Model |
|------|-------|
| Mechanical, 1-2 files, clear spec | cheap |
| Integration, multi-file | standard |
| Architecture, design, broad understanding | most capable |
## Red Flags
**Never:**
- Start on main/master branch without explicit consent
- Skip spec OR quality review
- Proceed with unfixed issues
- Parallel dispatch implementers (conflicts)
- Make subagent read plan (give full text instead)
- Start quality review before spec compliance ✅
- Move to next task with open review issues
- Skip Phase 1 and assume no questions needed (unless task is trivial)
## Integration
| Skill | Use |
|-------|-----|
| `subagent` | Spawn implementer and reviewer subagents |
| `git-workflow` | Commit after each approved task |
| `plan-mode` | Create plan before starting |
| `parallel` | Parallel commands (not subagent dispatch) |
Use when opening a PR and driving it to green CI — push the branch, write a high-level PR description, watch checks, fix failures, and keep looping until green; also use when an already-open PR gets new commits.
Use when the user starts, resumes, switches, saves, or recalls a named task or ongoing work across sessions (e.g. "remember this", "continue X", "what was I doing on Y", "track this task").
Git commit workflow. Load when finishing any code-change task (after verification) to commit and push, or when explicitly staging/committing.
Use when modifying or adding a transform, loss, model, method, package, task-model, config, docs page, or example in a Lightly AG repo (lightly-ssl or lightly-train) and you need repo-specific conventions.
Spawn a subagent to run a task. Use when you want to delegate work to a separate pi instance.
Use when configuring or replicating LT-DETR v2 (ltdetrv2-s/m/l/x) COCO benchmarks via the lightly-train wrapper — model alias map, global vs per-rank batch size, recipe invariants, ECDet config mapping, cluster pins, and common gotchas.