name	loom-task-start
description	Use when starting a new task, feature, bugfix, or refactor in a Loom project — "let's start", "new task", "working on", "implement", "begin". Ensures a board task exists with a clear scope and a sharp definition of done, then loads context before any code changes.

Task Start (Loom)

Make the work trackable on the board before diving in. The board is the source of truth — one task = one focused, independently-mergeable change.

Find or create the task — tasks_list (the loom-tasks MCP); if none matches, tasks_create with a clear, specific title in Conventional-Commits form (type(scope): summary — lowercase type like feat/fix/refactor, imperative summary), drawing the scope from the project's CLAUDE.md "Commit scopes".
Scope it. Put the scope and a sharp definition of done in the task body (tasks_update body). The DoD states what proves it works — a command that exits clean, a manual repro, a regression check. A task without a DoD isn't ready to work. If an open decision blocks pinning the DoD, ask the human via question_ask (the Requests inbox) rather than guessing. Keep it to one logical change; if it's really several, split it.
Move it — set the task to the active column (the in-progress ROLE) via tasks_update columnKey. First, skip any card flagged held (an owner brake) or deferred (the manager hasn't sequenced it) — don't begin work on those.
Load context before changing anything — git log --oneline -15, read CLAUDE.md, and read the relevant code/notes so your change matches what's there. Reuse existing shapes over inventing new ones.

Then implement: keep the change small and matched to the surrounding code, meet the DoD, and build/ verify before reporting it done.

name	loom-task-start
description	Use when starting a new task, feature, bugfix, or refactor in a Loom project — "let's start", "new task", "working on", "implement", "begin". Ensures a board task exists with a clear scope and a sharp definition of done, then loads context before any code changes.

Make the work trackable on the board before diving in. The board is the source of truth — one task = one focused, independently-mergeable change.

Find or create the task — tasks_list (the loom-tasks MCP); if none matches, tasks_create with a clear, specific title in Conventional-Commits form (type(scope): summary — lowercase type like feat/fix/refactor, imperative summary), drawing the scope from the project's CLAUDE.md "Commit scopes".
Scope it. Put the scope and a sharp definition of done in the task body (tasks_update body). The DoD states what proves it works — a command that exits clean, a manual repro, a regression check. A task without a DoD isn't ready to work. If an open decision blocks pinning the DoD, ask the human via question_ask (the Requests inbox) rather than guessing. Keep it to one logical change; if it's really several, split it.
Move it — set the task to the active column (the in-progress ROLE) via tasks_update columnKey. First, skip any card flagged held (an owner brake) or deferred (the manager hasn't sequenced it) — don't begin work on those.
Load context before changing anything — git log --oneline -15, read CLAUDE.md, and read the relevant code/notes so your change matches what's there. Reuse existing shapes over inventing new ones.

Then implement: keep the change small and matched to the surrounding code, meet the DoD, and build/ verify before reporting it done.

loom-task-start