/task - Task Planning Agent
Model: opus (complex planning requires advanced reasoning)
Command Flags
| Flag | Short | Description |
|---|
| | Show available commands and options |
| | Show workflow skills version |
| | Enable automated pipeline (implement → test → document → ship) |
Flag Handling
/task - Task Planning Agent
Usage:
/task Create a new task (manual mode)
/task auto Create task with auto-pipeline enabled
/task -h, --help Show this help message
/task -v, --version Show version
Options:
auto After task approval, automatically chain through:
implement → test → document → ship
Examples:
/task # Interactive task creation
/task auto # Task with full automation
Next: /implement {ID}
Workflow Skills v1.4.1
https://github.com/eljun/claude-skills
When to Use
- Starting a new feature or enhancement
- Planning a bug fix that requires multiple changes
- User says "I want to add...", "Let's implement...", "Can we build..."
- Discussing requirements before coding
- Creating implementation specs for future work
Invocation Options
| Command | Mode | Behavior |
|---|
| Manual | You control each step: implement → test → document → ship |
| Automated | After task approval, all steps run autonomously |
Auto Mode Workflow
/task auto → User approves task
↓
/implement
↓
/test (Playwright E2E)
│
PASS → /document
FAIL → /implement (with test report)
│
▼
/ship → PR + notify
Auto mode notes:
- Full automation: Runs through implement → test → document → ship
- Test failures: Auto-retries by sending test report back to implement agent
- Unexpected errors: Stops and notifies you
Workflow
User Request
↓
1. Discuss & clarify requirements
2. Research codebase for context
3. Generate Task ID (next available number)
4. Create docs/task/{ID}-{task-name}.md
5. Add to TASKS.md under "## Planned" with ID
6. User can /clear and start fresh
↓
Ready for /implement {ID}
What This Skill Does
1. Requirements Gathering
Ask clarifying questions:
- What is the expected behavior?
- Any UI/UX preferences?
- Priority level?
Version Impact Guidelines
Set the
field based on the type of change:
| Type | Default Impact | When to Use |
|---|
| | New functionality, backwards compatible |
| | Bug fixes, no new features |
| | Improvements to existing features |
| | Doc updates only |
| | Maintenance, refactoring |
- Breaking API changes
- Database schema changes requiring migration
- Removing deprecated features
- Changes that require user action
2. Codebase Research
Before creating the task document:
- Check existing similar implementations
- Identify files to modify
- Find reusable components/hooks
- Note potential pitfalls
Note: Specialized skills (vercel-react-best-practices, supabase-postgres-best-practices) are invoked during
, not during task planning. This keeps planning focused on requirements and architecture.
3. Generate Task ID
Before creating the task document, generate the next available Task ID:
- Read TASKS.md to find all existing task IDs
- Find the highest ID number across all sections (Planned, In Progress, Testing, etc.)
- Assign next ID = highest + 1
- If no tasks exist, start with ID = 1
ID Format: Simple integers (1, 2, 3, ...)
bash
# Example: If TASKS.md has tasks with IDs 1, 2, 5
# Next ID = 6 (highest + 1)
4. Create Task Document
Location: docs/task/{ID}-{task-name}.md
Naming: Zero-padded ID prefix + kebab-case descriptive name:
001-user-dashboard-redesign.md
003-booking-calendar-view.md
ID Padding: Use 3 digits (001, 002, ... 999) for consistent sorting.
5. Update TASKS.md
Add the task to the "## Planned" section with ID and link to task document.
If TASKS.md doesn't exist, create it first with this structure:
markdown
# Tasks
Task tracking for the development workflow.
---
## Planned
Tasks ready for `/implement {ID}`.
|----|------|----------|----------|---------|
---
## In Progress
|----|------|---------|----------|--------|
---
## Testing
Tasks being tested via `/test`.
|----|------|----------|-------------|--------|
---
## Approved
Tested and approved. Ready for `/document` then `/ship`.
|----|------|----------|-------------|-------------|----------|
---
## Ready to Ship
PRs created via `/ship`. **Items stay here until `/release` is run** (even after merge).
|----|------|--------|----|--------|----------|
---
## Shipped
Released items. Only `/release` moves items here with version number.
| ID | Task | PR | Release | Shipped |
|----|------|-----|---------|---------|
Task Document Template
Create this structure in
docs/task/{ID}-{task-name}.md
:
markdown
# {Task Title}
> **ID:** {number}
> **Status:** PLANNED
> **Priority:** HIGH | MEDIUM | LOW
> **Type:** feature | bugfix | enhancement | documentation | chore
> **Version Impact:** minor | patch | major
> **Created:** {Date}
> **Platform:** Web
> **Automation:** manual | auto
## Overview
{2-3 sentence description of what we're building and why}
## Requirements
### Must Have
- [ ] Requirement 1
- [ ] Requirement 2
### Nice to Have
- [ ] Optional requirement
## Current State
{Description of how things work now, if applicable}
**Current Files:**
|------|---------|
| `path/to/file.tsx` | Description |
## Proposed Solution
{Description of the implementation approach}
### Architecture
{High-level design decisions}
### File Changes
|--------|------|-------------|
| CREATE | `path/to/new.tsx` | New component for X |
| MODIFY | `path/to/existing.tsx` | Add Y functionality |
| DELETE | `path/to/old.tsx` | No longer needed |
## Implementation Steps
### Step 1: {Title}
{Detailed instructions with code snippets if needed}
### Step 2: {Title}
{Detailed instructions}
## Code Examples
{Include specific code changes when helpful}
```typescript
// Example of key implementation
Testing Checklist
Dependencies
- Required packages: {list any new deps}
- Required APIs: {list endpoints needed}
- Blocked by: {any dependencies on other tasks}
Notes for Implementation Agent
{Any important context the /implement agent needs to know}
Related
- Similar feature: [link to docs]
- Design reference: [link if applicable]
---
## TASKS.md Integration
After creating the task document, add an entry with the ID:
```markdown
## Planned
| ID | Task | Priority | Task Doc | Created |
|----|------|----------|----------|---------|
| 1 | Dashboard Redesign | HIGH | [001-dashboard-redesign.md](docs/task/001-dashboard-redesign.md) | Jan 25 |
| 2 | Fix Login Bug | MEDIUM | [002-fix-login-bug.md](docs/task/002-fix-login-bug.md) | Jan 26 |
Output Checklist
Handoff to /implement
When planning is complete, inform the user:
Manual Mode
Task created: #{ID} - {Task Title}
Document: docs/task/{ID}-{task-name}.md
Added to TASKS.md under "Planned"
Next Steps:
/implement {ID} # e.g., /implement 1
/implement {ID}-{task-name} # e.g., /implement 001-auth-jwt
(Optional: /clear first to start fresh session)
Auto Mode
When
was invoked and user approves the task:
- Set in the task document
- Use Task tool to spawn with model: opus
- The implement skill will chain to subsequent skills automatically
Task approved! Starting automated pipeline...
Task: #{ID} - {Task Title}
Spawning /implement {ID} with opus model...
IMPORTANT: In auto mode, after user approves the task:
- Do NOT wait for user to invoke /implement
- Use Task tool to spawn implement agent with model: opus
- Example:
Task({ subagent_type: "general-purpose", model: "opus", prompt: "/implement {ID}" })
- The automation flag in the task doc controls subsequent chaining
Related Skills
| Skill | When to Use |
|---|
| After task is approved, to start coding |
| After implementation, to verify the feature |
| After tests pass, to create documentation |
| After documentation, to create PR |
| After multiple items shipped, to create release |
Note: Specialized skills (vercel-react-best-practices, supabase-postgres-best-practices) are invoked during
, not during
. Install them separately from their respective repos.