tasks-generator v1.3.4A

Immutable. This exact content never changes and is served at /api/v1/blob/f4741d872ad41b2c.

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

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