hotsheet

<!-- hotsheet-skill-version: 22 -->

Read .hotsheet/worklist.md and work through the tickets in priority order.

For each ticket:

1. Read the ticket details carefully
2. Implement the work described
3. When complete, mark it done via the Hot Sheet UI

Work through them in order of priority, where reasonable.

If the worklist says "Auto-Prioritize", follow those instructions to choose and mark tickets as Up Next before working on them.

If API calls fail (connection refused or 403), re-read .hotsheet/settings.json for the current port and secret values — you may be connecting to the wrong Hot Sheet instance.

MCP tools (hotsheet_*) are preferred over curl when the channel is connected — see the worklist for per-operation guidance. The 14-tool surface covers ticket lifecycle (hotsheet_update_ticket, hotsheet_create_ticket, hotsheet_get_ticket, hotsheet_delete_ticket, hotsheet_restore_ticket, hotsheet_toggle_up_next, hotsheet_duplicate_tickets), bulk operations (hotsheet_batch), notes (hotsheet_edit_note, hotsheet_delete_note), attachments (hotsheet_add_attachment), channel signaling (hotsheet_signal_done), feedback sugar (hotsheet_request_feedback), and query (hotsheet_query_tickets). Curl stays supported as the universal fallback for non-Claude AI agents and human terminal callers.

Parallelizing work across the worker pool: hotsheet_get_worker_pool / hotsheet_set_worker_target / hotsheet_dispatch_tickets / hotsheet_drain_workers. When the project has "always preview agent plans" on (the worklist says so), call hotsheet_propose_partition with your whole proposed assignment INSTEAD of hotsheet_dispatch_tickets — it surfaces the plan in the owner's partition editor for review, and the UI dispatches on accept (you do not claim the tickets yourself).

Git: keep the target current + integrate worker branches

You run on the target branch (usually main) in the main worktree, so you are the single integrator for parallel worktree workers (docs/89). Distributed workers (/hotsheet-worker) commit their work on their own branches and rebase onto the target to stay current, but they never write the target — that's your job:

• Stay current — before integrating, bring the target up to date: git fetch then git pull --rebase (or rebase onto the upstream) when the repo has a remote, so you build on the latest. Commit or stash your own in-progress changes first so a merge doesn't tangle with them.
• Integrate ready worker branches — periodically (e.g. when a batch of workers has finished, or the pool drains). Use the integration helpers (HS-9048) rather than hand-rolling the git: GET /api/workers/integratable returns the detected target branch + the ready worker branches (hotsheet/* ahead of the target, with ahead/behind counts); then for each, in ticket-priority order, POST /api/workers/integrate with { "branch": "<name>" } does a guarded merge into the target. It returns a status: merged (success), conflict (it captured the conflicted files + aborted cleanly — resolve them by hand or, if non-trivial, ask the maintainer), dirty-tree (commit/stash your own changes first), not-on-target / nothing-to-integrate. The helper never pushes — pushing still needs explicit permission.
• A ready branch may carry a BATCH of several tickets. Workers batch small/related tickets onto one branch and refresh + gate once at the batch boundary (docs/98), so the "branch ready" signal fires once per batch, not per ticket — one integrateBranch call + one gate run covers the whole batch. When you integrate it, clear pending_integration for every ticket whose work it carried (next bullet), not just one.
• Gates after a merge (and the optional in-helper gate, HS-9091). After a merged result with no gate field, run the project's gates yourself (type-check, lint, the relevant tests). If the project configured the opt-in integrationGate shared setting, the helper ran that command inside the merge and you'll get either: merged with result.gate.ran: true (the gate already passed — you do not need to re-run those gates for this branch); gate-failed (the gate command failed and the merge was already rolled back to the pre-merge target — do NOT re-merge blindly; read result.gate.output to decide whether to quickly fix-and-retry or, if non-trivial, ask the maintainer); or gate-timeout (same rolled-back state, but the gate exceeded its time limit). On gate-failed/gate-timeout the branch is unmerged — leave its ticket's pending_integration marker set (don't clear it).
• For each ticket whose work you just integrated, clear its "merge pending" marker: hotsheet_update_ticket with { "id": <id>, "pending_integration": false } (the tickets marked pending_integration are the ones awaiting integration).
• Sensible conflict resolution, ask on the hard ones — auto-resolve trivial/mechanical conflicts; if a conflict is non-trivial or ambiguous, or the gates fail in a way you can't quickly and safely fix, stop and ask the maintainer rather than force it (leave the branch unmerged). Integrate only from committed branch state — never disturb a worker mid-ticket.
• NEVER git push without the maintainer's explicit permission — local integration only.