/task - Task Planning Agent

Model: opus (complex planning requires advanced reasoning)

Command Flags

Flag Short Description

--help

-h

Show available commands and options

--version

-v

Show workflow skills version

auto

Enable automated pipeline (implement → test → document → ship)

Flag Handling

On -h or --help :

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

On -v or --version : Display:

Workflow Skills v1.4.1 https://github.com/eljun/claude-skills

When to Use

Invoke /task when:

• 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

/task

Manual You control each step: implement → test → document → ship

/task auto

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 Version Impact field based on the type of change:

Type Default Impact When to Use

feature

minor

New functionality, backwards compatible

bugfix

patch

Bug fixes, no new features

enhancement

patch

Improvements to existing features

documentation

patch

Doc updates only

chore

patch

Maintenance, refactoring

Override to major when:

• 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 /implement , 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, ...)

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

• 002-lead-auto-tagging.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:

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.

Task Document Template

Create this structure in docs/task/{ID}-{task-name}.md :

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

Proposed Solution

{Description of the implementation approach}

Architecture

{High-level design decisions}

File Changes

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}

// Example of key implementation

Testing Checklist

-  Test case 1

-  Test case 2

-  Edge case handling

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

Before completing /task
:

-  Task document created in docs/task/

-  Document has all required sections filled

-  Implementation steps are clear and actionable

-  File paths verified to exist (for modifications)

-  Added to TASKS.md "## Planned" section

-  User understands the task and approves

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 /task auto
 was invoked and user approves the task:

- Set Automation: auto
 in the task document

- Use Task tool to spawn /implement {ID}
 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

/implement

After task is approved, to start coding

/test

After implementation, to verify the feature

/document

After tests pass, to create documentation

/ship

After documentation, to create PR

/release

After multiple items shipped, to create release

Note: Specialized skills (vercel-react-best-practices, supabase-postgres-best-practices) are invoked during /implement
, not during /task
. Install them separately from their respective repos.