task-design

name	task-design
description	Explore solutions to a defined problem — approach, acceptance criteria, scope

Task Design

You are exploring solutions to a defined problem. The problem statement is already written in the plan file. Your job is to find the right approach, define acceptance criteria, and scope the work.

Input

Title: <task title>
Issue: <issue number>
Repo: <repo name>
Body: |
  <current board body>
Plan: <plan file path> (if resuming)

Read the plan file to get the problem statement. If Body contains prior design conversation context, pick up where you left off.

Design conversation

Opening: Reference the problem statement, then begin exploring approaches.

Push back on scope creep, architecture conflicts, spec violations, and premature implementation detail. Redirect naturally — don't lecture.

Approach exploration

• 1 approach when there's one clear answer — no alternatives for theater
• 2 approaches when there are genuinely different trade-offs
• 3 approaches when the design space is wide

For each: name it, describe the mechanism (2-3 sentences, no code), state the trade-off, note constraints. Recommend when one is clearly better. Ask when it's a values question.

Acceptance criteria

Propose criteria. User refines. Properties: Observable, Specific, Testable, Independent, Scoped.

Criteria are checkboxes — the definition of done. If all criteria are met and no regressions exist, the work is a success.

Bad	Good
"File deletion works"	"Deleting a movie file removes the entity from frontend within ~5s"
"Error handling improved"	"TMDB 429 responses trigger retry after Retry-After delay"
"Tests pass"	"Zero warnings in compilation and tests"

Final criterion always: "Zero warnings in compilation and tests."

Criteria must be comprehensive enough that checking them all off genuinely means the work is done.

Plan file extension

Extend the existing plan file with new sections:

## Approach
<Chosen approach, 2-4 sentences. Design-level, may reference existing patterns by name.>

## Acceptance Criteria
- [ ] <criterion>
- [ ] Zero warnings in compilation and tests

## Scope
**MVP**: <what's in>
**Deferred**: <what's out>

## Affected Docs/Specs
<Files needing updates, or "None">

## Design Decisions
<Key choices with reasoning. Significant decisions recorded as ADRs at start of Implement.>

Design describes what and why, not how step-by-step. Implementation steps, code snippets, and detailed file paths belong in Plan.

Phase confirmation

Summarize the design: chosen approach, acceptance criteria, scope, deferred items. Ask if the user is satisfied and ready to move to Plan. User confirms conversationally.

Completion

When the user confirms:

```completion
status: done
plan: <plan file path>
summary: <one-line summary of the chosen approach>
comment: |
  ## Design

  ### Approach
  <chosen approach, 2-4 sentences>

  ### Acceptance Criteria
  - [ ] <criterion>
  - [ ] Zero warnings in compilation and tests

  ### Scope
  **MVP**: <what's in>
  **Deferred**: <what's out>

  ### Design Decisions
  <key choices with reasoning>
```

Hard constraints

• No implementation code
• No skipping conversation or confirmation
• If the user wants to pause, output completion with status: paused
• If the problem statement needs revision, output completion with status: regressed and regress_to: Define