task-start

Start a task (existing work item)

Run the task-start recipe as ONE deterministic call, then sync the local working tree. The engine enforces the provider-side order (load → branch → in_progress → assign to you → comment); your job is the inputs, the local git, the ownership check, and the briefing.

Steps

1. Resolve the issue id from the user's words (123, AB#123, or a work-item URL → extract the integer). Ask only if genuinely absent.

2. Preflight local git (local git is YOUR job, not Baron's): run git status --porcelain — if dirty, stop and ask the user to commit/stash first. Never start work on a dirty tree.

3. Run the recipe — call baron_recipe_run with the only input it declares:

   { "name": "task-start", "inputs": { "issueId": "<id>" } }
   

   The engine loads the item, creates the canonical branch (<prefix>/<id>-<slug>, derived by Baron's core so every agent picks the same name), moves it to in_progress, assigns it to you (issue.assign @me), and comments the branch on the item. Starting a task makes it yours.

4. If it stops on the ownership guard, ask — never take over silently. The recipe refuses only when the item is assigned to someone else, with RECIPE_REQUIRE: "AB#N is assigned to <them>, not you (<you>). Assign it to yourself first…". On that error:

   • Ask the user (AskUserQuestion: "AB#N is assigned to <them>. Take it over and start?" → Take over / Cancel).
   • On Take over → baron_issue_write { op: "assign", id: "<id>", assignee: "@me" }, then re-run the recipe from step 3 (the guard now passes because the item is yours).
   • On Cancel → stop. Do not start, do not reassign.

   An unassigned item, or one already yours, never hits this — it just starts. So re-running task-start on your own work is silent and idempotent.

5. Sync the local checkout to the branch Baron created on the provider:

   git fetch origin && git switch <branch-name-from-the-result>
   

6. Pull into the active sprint if needed (sprint providers only): compare the item's iteration with the active sprint. If it's in a past iteration or has none while a sprint is active (baron_issue_read op=iterations → the one with current: true), ask whether to pull it in, and on yes call baron_issue_write { op: "set_iteration", id, iteration: "@current" }. If no sprint is current, skip silently. (This is the "scope creep" checkpoint — the user opts in by pulling mid-sprint.)

7. Understand the work before coding — read the whole item, not just the title. Baron's read already gives you the body (a Bug's repro steps, otherwise the description), type, labels, and parent. Gather the rest so you start informed, using the provider's read/explore tools:

   • Comments / discussion on the item — decisions, gotchas, prior attempts, review feedback.
   • Attachments (specs, screenshots, logs, stack traces) — open the ones that look relevant.
   • Extra native fields the body doesn't carry — a Bug's System Info, Acceptance Criteria, and any custom fields.