# Task

> Create well-defined task specifications from plans or user prompts. Use when user wants to define a task, create a work item, break down a plan into actionable work, or write a spec for implementation. Triggers on "create task", "define task", "write spec", "break this down", "make this actionable", or when moving from planning to execution.

- Skill: `majiayu000/task-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/task-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/task-2/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/task-2

---


# Task Creation

Create well-defined task specifications that provide clear goals while leaving implementation open to interpretation. Output to `.work/tasks/backlog/<name>.md`.

## Task Creation Workflow

### 1. Understand the Scope

Determine task type and relevant sections:
- **Full-stack feature**: All sections applicable
- **Backend only**: Skip UX Guidelines, focus on System Behaviors and Data
- **Frontend only**: Skip Data & Contracts internals, focus on UX
- **Documentation**: Summary, Acceptance Criteria only
- **Bug fix**: Summary, Edge Cases, Acceptance Criteria
- **Refactor**: Summary, System Behaviors, Acceptance Criteria

### 2. Gather Context

If working from a plan:
- Read the plan from `.work/plans/`
- Extract relevant decisions and constraints
- Link back to the plan

If working from user prompt:
- Ask clarifying questions about scope
- Identify affected files and systems
- Understand success criteria

### 3. Write the Task Spec

Create `.work/tasks/backlog/<descriptive-name>.md` using the template below.

**Omit sections not relevant to the task type.** A backend API task doesn't need UX Guidelines. A docs update doesn't need System Behaviors.

## Task Template

See [references/spec-template.md](references/spec-template.md) for the full template.

Core sections:
- **Summary**: One paragraph describing the task and why it exists
- **User Journey**: Entry point, happy path, exit criteria
- **UX Guidelines**: What user sees, copy tone, accessibility
- **System Behaviors**: Invariants, state transitions, policies
- **Data & Contracts**: Storage needs, API/events (high-level)
- **Usage/Cost Accounting**: What usage to track and how
- **Edge Cases**: Failure modes and user-visible outcomes
- **Acceptance Criteria**: Testable outcomes as bullet list

## Writing Guidelines

### Be Specific About What, Open About How

**Good**: "User can filter todos by status (all, active, completed)"
**Bad**: "Implement filtering using React state with useMemo optimization"

Define the outcome, not the implementation.

### Reference Concrete Touchpoints

Include:
- Files that will likely need changes
- API routes or contracts involved
- Database tables affected
- UI components to modify

### Keep It Scannable

- Use bullet points over paragraphs
- Bold key terms
- Keep acceptance criteria atomic and testable

## Task Lifecycle

After creating the task:
1. Task starts in `.work/tasks/backlog/`
2. When work begins, move to `.work/tasks/in-progress/`
3. When complete, move to `.work/tasks/completed/`

Update task status in the file header as work progresses.


