菜单
Read a tasks.json file, resolve dependencies, and implement each task in the correct order using the task-pipeline CLI. Use when a tasks.json exists and needs execution. Do NOT use when there is no tasks.json (use implement instead).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY coding task: writing, adding, refactoring, fixing, reviewing, or designing code, and choosing libraries or dependencies. Also use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT use for non-coding requests (general knowledge, prose, translation, summaries, recipes).
Convert a Product Requirements Document (PRD) into a structured tasks.json file with tasks, dependencies, priorities, and estimated effort. Use when a PRD exists and the user wants to break it down into implementable tasks. Do NOT use when there is no PRD or when the user wants to skip planning.
Structured brainstorming session using proven ideation techniques. Generate creative ideas, explore alternatives, and document your brainstorming session. Use when exploring new features, solving problems creatively, or needing multiple solution approaches before deciding.
When requirements are ambiguous, incomplete, or the agent is not 100% sure about what to implement — stop and ask clarifying questions before writing code or making changes.
A relentless one-question-at-a-time interview that stress-tests a plan or design while writing the shared vocabulary and hard decisions down as it goes. Produces a PRD.md at the end. Use when starting a new feature or project and you need deep requirements understanding before implementation.
Directly implement a feature or fix without tasks.json orchestration. Use when: the task is simple (single file, config change, straightforward feature), or when there is no tasks.json and the user wants to start coding immediately. Do NOT use when: there is a tasks.json (use implement-tasks instead), or when requirements are unclear (use grill-with-docs first).
| name | implement-tasks |
| description | Read a tasks.json file, resolve dependencies, and implement each task in the correct order using the task-pipeline CLI. Use when a tasks.json exists and needs execution. Do NOT use when there is no tasks.json (use implement instead). |
Execute a tasks.json plan one task at a time, respecting dependencies.
tasks.json existstasks.json → Use prd-to-tasks firstimplement directlytask-pipeline CLI available at $HOME/.pi/agent/scripts/task-pipeline/tmux installedpi CLI available on PATHbun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" validate tasks.json --summary
This checks: valid JSON, missing dependencies, circular dependencies, phase
keys, unique IDs. With --summary it also prints phase breakdown and critical path.
If validation fails, stop and report the issues. Do NOT proceed until fixed.
Use topological sort to group tasks into parallel waves:
bun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" validate tasks.json --waves
| Wave | Tasks | Deps |
|---|---|---|
| 1 | T001, T002 | (none) |
| 2 | T003, T004 | T001 |
| 3 | T005 | T002, T003 |
bun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" prompts tasks.json
This generates tasks/TASK-XXXX-prompt files — self-contained prompts that
each subagent receives as input.
This skill is a pure orchestrator — it never writes code itself. Every
task is delegated to an isolated tmux session running pi:
# Spawn next ready wave (auto-detects pending tasks)
bun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" spawn
# Spawn specific tasks
bun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" spawn T001 T003
# Preview what would spawn
bun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" spawn --dry-run
# 1. Spawn first wave (returns immediately)
bun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" spawn
# 2. Check status — poll until wave completes
bun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" status --compact
# 3. When current wave is done, spawn the next wave
bun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" spawn
# 4. Repeat steps 2-3 until all tasks are done
bun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" status # full table
bun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" status --compact # one-liner
bun "$HOME/.pi/agent/scripts/task-pipeline/src/cli.ts" status --pending # pending only
# Peek at a specific task's live output
tmux capture-pane -t task-T005 -p | tail -20
After each task, verify against acceptance criteria:
✅ T001: Set up project structure
- ✓ Directory structure matches conventions
- ✓ Type definitions compile
If a task cannot be completed:
grill-with-docs to ask the userPhase 1: ✅ T001 setup, T002 config
Phase 2: 🔄 T003 in progress...
When all tasks complete:
All [N] tasks complete. Acceptance criteria verified.