Create a feature branch for a backlog task, switch to it, and start implementation. Use when the user says "start task-123", "work on task-123", "implement task-123", or invokes /start-task with a task ID.
Scanned 9/5/2026
Install to Claude Code
npx -y skills add devoxx/DevoxxGenieIDEAPlugin --skill start-task --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Start Task?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/devoxx-start-task)More formats (shields.io, HTML) on the badges page.
---
name: start-task
description: Create a feature branch for a backlog task, switch to it, and start implementation. Use when the user says "start task-123", "work on task-123", "implement task-123", or invokes /start-task with a task ID.
allowed-tools: Bash(git checkout:*), Bash(git branch:*), Bash(git status:*), Bash(git pull:*), Bash(git stash:*), Bash(npm run lint:*), Bash(npm run typecheck:*), Bash(npm test:*), Bash(npm run build*), Bash(npx playwright test:*), mcp__backlog__task_view, mcp__backlog__task_edit, mcp__backlog__task_search, mcp__backlog__task_list
---
# 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:
```bash
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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!