tasks-generator · diff
v1.3.4 to v1.4.0
3 added, 3 removed. Audit A to A.
---
name: tasks-generator
description: "Generate sprint-based development tasks from a PRD. Use when asked to create tasks or break down requirements. Don't use for PRD/TAD authoring or task execution."
license: MIT
effort: max
metadata:
- version: 1.3.4
+ version: 1.4.0
author: "Luong NGUYEN <luongnv89@gmail.com>"
---
# Tasks Generator
Transform PRD documents into structured, sprint-based development tasks with dependency analysis.
## Environment Check
Before running this skill, verify:
- [ ] The project has a PRD file (prd.md or similar)
- [ ] You have write access to the project directory
- [ ] The project is a git repository with a remote
- [ ] You can run bash commands in the project directory
If any check fails, the skill will stop and ask for clarification.
## Subagent Architecture
This skill uses a **Staged Pipeline (E) + Parallel Workers (B)** architecture:
```
Phase 1: Requirements Extraction
↓ (requirements-extractor agent)
↓
Phase 2-3: Sprint Planning
↓ (sprint-planner agent)
↓
Phase 4-5: Parallel Sprint Task Generation
├→ (sprint-worker agents, spawned in parallel — one per sprint)
├→ sprint 1 tasks
├→ sprint 2 tasks
├→ sprint 3 tasks
└→ ...
↓
Phase 6: Cross-Sprint Dependency Resolution
↓ (dependency-resolver agent)
↓
Final Output: tasks.md with all tasks and dependencies
```
**Agents**:
1. `agents/requirements-extractor.md` — Reads PRD + supporting docs, produces structured feature list
2. `agents/sprint-planner.md` — Defines sprint scope (POC, MVP, full features), produces sprint plan
3. `agents/sprint-worker.md` — Generates tasks for ONE sprint (runs in parallel, one per sprint)
4. `agents/dependency-resolver.md` — Wires cross-sprint dependencies, produces final tasks.md
**Key Insight**: Per-sprint task generation is parallelizable. Large PRDs produce 30-80 tasks across 4+ sprints. Sprint tasks are not fully independent — Sprint 2 depends on Sprint 1 output — so the dependency-resolver does a final pass to wire cross-sprint relationships.
## Repo Sync Before Edits (mandatory)
Before creating/updating/deleting files in an existing repository, sync the current branch with remote:
```bash
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"
```
If the working tree is not clean, stash first, sync, then restore:
```bash
git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop
```
If `origin` is missing, pull is unavailable, or rebase/stash conflicts occur, stop and ask the user before continuing.
## Modes (check before running)
- **Input resolution**: `$ARGUMENTS` present → use it directly; empty → auto-pick (see [Input](#input) below).
- **Repo state**: dirty working tree → stash before sync (see [Repo Sync](#repo-sync-before-edits-mandatory)); no `origin` → stop and ask.
- **Existing `tasks.md`**: back it up before regenerating (see [Pre-checks](#pre-checks)).
- **README update**: only if the PRD lives inside an `ideas` repo (see [README Maintenance](#readme-maintenance-ideas-repo-only)) — skip otherwise.
## Input
Preferred: PRD file path provided in `$ARGUMENTS`.
Auto-pick mode (if `$ARGUMENTS` is empty):
1. Reuse the most recent project folder/path from this chat/session.
2. If unavailable, use env var `IDEAS_ROOT` when present.
3. Else check shared marker file `~/.config/ideas-root.txt`.
4. Backward compatibility fallback: `~/.openclaw/ideas-root.txt`.
5. If still unavailable, ask the user to provide the path or set `IDEAS_ROOT`.
6. Use `<project>/prd.md`.
7. If multiple candidates are plausible, ask user to choose.
## Pre-checks
1. Resolve `PRD_PATH` (from `$ARGUMENTS` or auto-pick mode) and verify it exists
2. Check for existing `tasks.md` in the same directory - create backup if exists: `tasks_backup_YYYY_MM_DD_HHMMSS.md`
3. Look for supporting docs in same directory: `tad.md`, `ux_design.md`, `brand_kit.md`
## Workflow
### Phase 1: Extract Requirements
From PRD, extract:
- Core features and value proposition
- User stories and personas
- Functional requirements
- Non-functional requirements (performance, security)
- Technical constraints and dependencies
### Phase 2: Define Development Phases
**POC (Proof of Concept):**
- Single most important feature proving core value
- Minimal implementation, 1-2 sprints
**MVP (Minimum Viable Product):**
- Essential features for first release
- Core user workflows
**Full Features:**
- Remaining enhancements
- Nice-to-haves and polish
### Phase 3: Create Sprint Plan
| Sprint | Focus | Scope |
|--------|-------|-------|
| Sprint 1 | POC | Core differentiating feature |
| Sprint 2 | MVP Foundation | Auth, data models, primary workflows |
| Sprint 3 | MVP Completion | UI/UX, integration, validation |
| Sprint 4+ | Full Features | Enhancements, optimization, polish |
### Phase 4: Analyze Dependencies
1. **Map Dependencies**: For each task, identify "Depends On" and "Blocks"
2. **Group Parallel Tasks**: Assign tasks to execution waves
- 3. **Calculate Critical Path** — the longest dependency chain; it sets the minimum duration. Referred to as "critical path" everywhere below.
- 4. **Validate**: reject **circular dependencies** (the dependency graph must be a DAG — no cycles) and broken references
+ 3. **Validate and calculate deterministically**: pass the combined `{"tasks": [...]}` graph to `scripts/analyze_dependencies.py`; it validates the canonical IDs, edge direction, effort units, cycles, critical path, and direct bottlenecks. Read [references/dependency-analysis.md](references/dependency-analysis.md) for the exact schema and CLI. Do not re-compute these numeric results in prose.
+ 4. **Explain and render**: keep feature coverage, mitigation, parallel-opportunity judgments, and the final `tasks.md` narrative in the resolver; reject the helper's errors and never override its result.
### Phase 5: Generate tasks.md
Create `tasks.md` in same directory as PRD. See [references/tasks-template.md](references/tasks-template.md) for full template.
## Task Format
Each task must include:
```markdown
### Task X.Y: [Action-oriented Title]
**Description**: What and why, referencing PRD
**Acceptance Criteria**:
- [ ] Specific, testable condition 1
- [ ] Specific, testable condition 2
**Dependencies**: None / Task X.X
**PRD Reference**: [Section]
```
## Task Guidelines
- **Title**: Action-oriented (e.g., "Implement user authentication API")
- **Size**: 1-3 days of work; break larger features
- **Criteria**: Cover happy path and edge cases
- **Dependencies**: List prerequisites and external dependencies
## Quality Checks
The pre-finalize bars are defined once, in [Acceptance Criteria](#acceptance-criteria) — check every item there before reporting `tasks.md` complete. [references/self-test.md](references/self-test.md) holds the mechanical greps behind them.
## README Maintenance (ideas repo only)
After writing `tasks.md`, if the PRD lives inside an `ideas` repo, update the repo README ideas table:
- Preferred: `cd` to the repo root and run `python3 scripts/update_readme_ideas_index.py` (if it exists)
- Fallback: update `README.md` manually (ensure Tasks status becomes ✅ for that idea)
## Commit and push
- Commit immediately after updates.
- Confirm before pushing — this is a visible action:
```bash
git push origin <branch>
```
- If push is rejected: `git fetch origin && git rebase origin/main && git push`.
## Reporting with GitHub links (mandatory)
When reporting completion, include:
- GitHub link to `tasks.md`
- GitHub link to `README.md` when it was updated
- Commit hash
Link format (derive `<owner>/<repo>` from `git remote get-url origin`):
- `https://github.com/<owner>/<repo>/blob/main/<relative-path>`
## Step Completion Reports
After completing each major step, output a status report in this format:
```
◆ [Step Name] ([step N of M] — [context])
··································································
[Check 1]: √ pass
[Check 2]: √ pass (note if relevant)
[Check 3]: × fail — [reason]
[Check 4]: √ pass
[Criteria]: √ N/M met
____________________________
Result: PASS | FAIL | PARTIAL
```
Adapt the check names to match what the step actually validates. Use `√` for pass, `×` for fail, and `—` to add brief context. The "Criteria" line summarizes how many acceptance criteria were met. The "Result" line gives the overall verdict.
**Requirements phase checks:** `PRD parsed`, `Features extracted`, `Constraints identified`
**Sprint Planning phase checks:** `Phases defined`, `Stories created`, `Dependencies mapped`
**Generation phase checks:** `tasks.md written`, `Sprint breakdown complete`, `Estimates assigned`
**Output phase checks:** `README updated`, `Committed`, `Links reported`
## Output Summary
After generating, provide:
1. File location
2. Sprint overview (count, tasks per sprint)
3. MVP scope summary
4. Dependency analysis (waves, critical path, bottlenecks)
5. Flagged ambiguous requirements
6. Next steps: Review Sprint 1 and Wave 1 tasks first
## Acceptance Criteria
The skill run is considered successful only if ALL of the following hold:
- [ ] `tasks.md` exists in the same directory as the input PRD.
- [ ] `tasks.md` contains at least 3 sprints (POC, MVP Foundation, MVP Completion at minimum).
- [ ] Each sprint contains at least 3 tasks; total task count is between 15 and 80.
- [ ] Every task includes ALL of: `Description`, `Acceptance Criteria` (>=2 testable items), `Dependencies` (explicit `None` or task IDs), `PRD Reference`, and an effort estimate (e.g., `Effort: 1-3 days` or `S/M/L`).
- [ ] Every task ID follows the `Task <sprint>.<index>` pattern (e.g., `Task 1.1`, `Task 2.3`).
- [ ] A dependency table is present and references only tasks that exist in the file (no broken IDs).
- [ ] No circular dependencies (see Phase 4).
- [ ] At least one task per PRD requirement; ambiguous PRD items are flagged in a dedicated section.
- [ ] Critical path is identified and stated explicitly.
- [ ] The MVP vs post-MVP split is explicit — every sprint is labelled POC, MVP, or Full Features.
- [ ] If a prior `tasks.md` existed, a `tasks_backup_YYYY_MM_DD_HHMMSS.md` file is created.
- [ ] Final report includes GitHub links to `tasks.md` (and `README.md` if updated) plus the commit hash.
If any criterion fails, the skill must report it as a `FAIL` row in the Step Completion Report and not claim success.
## Expected Output
The skill produces `tasks.md` next to the PRD, plus a final agent message with GitHub links and commit hash. See [references/tasks-template.md](references/tasks-template.md) for the full reviewable shape, dependency table, critical path, and final-message format. See [references/self-test.md](references/self-test.md) for the pre-success self-test checklist.