tasks-generator

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.1","author":"Luong NGUYEN <[e-mail]>"}

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:

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:

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 below).
• Repo state: dirty working tree → stash before sync (see Repo Sync); no origin → stop and ask.
• Existing tasks.md: back it up before regenerating (see Pre-checks).
• README update: only if the PRD lives inside an ideas repo (see README Maintenance) — 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

Phase 5: Generate tasks.md

Create tasks.md in same directory as PRD. See references/tasks-template.md for full template.

Task Format

Each task must include:

### 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

Before finalizing:

• All PRD requirements addressed
• Each task links to PRD
• No circular dependencies
• Clear MVP vs post-MVP distinction
• Ambiguous requirements flagged
• All tasks in dependency table
• Critical path identified

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:

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.
• 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 for the full reviewable shape, dependency table, critical path, and final-message format. See references/self-test.md for the pre-success self-test checklist.