Start Task

Context

• Current branch: !git branch --show-current
• Working tree status: !git status --short
• Existing branches: !git branch --list 'feature/task-*'

Your task

Create a feature branch for a backlog task and begin implementation.

The user will provide a task ID (e.g. task-123 or 123). If no task ID is provided, check the argument $ARGUMENTS for the task reference.

Step 1 — Load the task

• Normalize the input: if the user gave just a number like 123, treat it as task-123.
• Use mcp__backlog__task_view to read the full task details: title, description, acceptance criteria, and any referenced files.
• If the task is not found, use mcp__backlog__task_search to locate it.
• Print a brief summary of the task for the user.

Step 2 — Ensure a clean working tree

• Check git status. If there are uncommitted changes, warn the user and ask whether to stash them before proceeding.
• Ensure we are on the main branch. If not, ask the user if they want to switch.

Step 3 — Create and switch to a feature branch

• Pull latest changes on main: git pull --rebase.
• Derive a branch name from the task: feature/task-{id}-{slugified-title} (lowercase, hyphens, max ~60 chars).
  • Example: task 113 "Split app.css into native CSS modules" → feature/task-113-split-css-modules
• Create and switch to the branch: git checkout -b <branch-name>.

Step 4 — Mark the task as in-progress

• Use mcp__backlog__task_edit to set the task status to In Progress.

Step 5 — Plan and implement

• Analyze the task description and acceptance criteria carefully.
• Read all files referenced in the task, plus any related code you need to understand.
• Create a plan and present it to the user for approval before writing code.
• Once approved, implement the changes following the project's patterns and conventions.
• After implementation, run the full verification suite:

  npm run lint && npm run typecheck && npm test && npm run build:app && npx playwright test

• Fix any issues found by the verification suite.

Step 6 — Report

• Summarize what was implemented and which acceptance criteria were addressed.
• Remind the user they can use /close-task-commit-push-pr when ready to ship.

Rules

• Always create the branch from an up-to-date main branch.
• Never start implementation without showing the plan to the user first.
• Follow existing code patterns and conventions in the project.
• Do not use interactive git flags (-i).
• If the working tree is dirty, never silently discard changes.