菜单
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.
用 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).
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).
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 | prd-to-tasks |
| description | 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. |
Break down a PRD into a tasks.json that drives implementation.
implement-tasksgrill-with-docs first)implement directly)grill-with-docs or manually)task-pipeline CLI available at $HOME/.pi/agent/scripts/task-pipeline/{
"$schema": "tasks/v1",
"metadata": {
"project": "Feature name",
"prd": "PRD-feature.md",
"created": "YYYY-MM-DD",
},
"phases": {
"1-foundation": {
"label": "Phase 1: Foundation",
"description": "Setup and shared utilities",
"tasks": ["T001", "T002"],
},
"2-core": {
"label": "Phase 2: Core",
"description": "Must-have features (P0)",
"tasks": ["T003", "T004"],
},
"3-polish": {
"label": "Phase 3: Polish",
"description": "Edge cases, tests, hardening",
"tasks": ["T005"],
},
},
"tasks": [
{
"id": "T001",
"title": "Set up project structure",
"description": "Create directories and config files",
"phase": "1-foundation",
"priority": "critical",
"estimatedHours": 2,
"dependencies": [],
"acceptanceCriteria": [
"Directory structure created",
"Config files in place",
],
},
],
}
| Field | Required | Description |
|---|---|---|
id | Yes | Unique ID (T001, T002...) |
title | Yes | Verb phrase ("Implement X") |
description | Yes | What and approach |
phase | Yes | Must match a phase key |
priority | Yes | critical, high, medium, low |
estimatedHours | Yes | Conservative estimate |
dependencies | Yes | IDs of prerequisite tasks |
acceptanceCriteria | Yes | Verifiable pass/fail conditions |
bun "$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, and shows the topological execution order.
If validation fails, the CLI prints a specific error. Fix the issue before proceeding.
Write tasks.json to the project root.