메뉴
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.