Fetch the current shared plan from .hub/ in this repo: all tasks (status/owner/declared interface), and recent teammate activity. Pulls the latest from git first. For picking up someone else's work, prefer get_handoff_brief instead - it also includes the requirements/design docs, structured completion reports, and anchor-verified file history in one deterministic call.

Propose a task: title, scope (file paths / module / route names it'll touch), and optionally the interface it'll expose and assumptions being made. Leaves the task UNCLAIMED (owner is not set to you automatically) - call claim_task right after if you intend to build it yourself, so teammates can otherwise pick it up. Commits and pushes to .hub/tasks/. Returns conflicts (other declared tasks touching the same scope) AND recentActivityNearby (real git commits touching this scope in the last 10 minutes, from anyone else - catches a teammate mid-edit right now even if they never declared a task for it). Check both before proceeding.

Claim an existing task (e.g. one from get_context) so teammates know you're working on it. Returns recentActivityNearby - real commits touching this task's scope in the last 10 minutes from anyone else. A non-empty list doesn't block the claim, but check it before diving in.

Update a task's status. When marking a task 'done', ALWAYS include completion with this fixed shape (not a free-text summary) - a structured report is what stays consistent when a different model reads it later, unlike prose that gets reinterpreted differently by every reader: whatWasBuilt (1-3 sentences), decisions (each with decision/why/alternativesConsidered), filesChanged (each with path/purpose), knownLimitations, nextSteps. This becomes the permanent, queryable design record in .hub/tasks/ for teammates, and feeds get_handoff_brief. IMPORTANT: if the response includes uncommittedFileWarnings, the files you listed in filesChanged are NOT actually committed/pushed yet - commit and push them for real before telling the user this is done, or teammates will never see the code. If you're changing direction WITHOUT finishing (switching approach, or dropping it), set status 'abandoned' with abandonReason instead of just going quiet - an abandoned task is reclaimable by teammates and shows up honestly in get_handoff_brief; a task silently left 'in_progress' forever looks like someone's still on it.

Broadcast what you're currently doing, so teammates' get_context/get_handoff_brief calls show it in recent activity. Use kind 'pivoted' specifically when you change approach mid-task without abandoning it outright - detail should say what you were doing, what you're doing instead, and why - so teammates see the change of direction immediately instead of working from your original (now stale) plan.

Attach a short rationale note to a file you finished touching (what you did, why). Pinned to the current commit as an anchor - anyone continuing this file later gets told via get_file_history whether the file has changed since (so they know if the note is still trustworthy).

Get the rationale trail for a specific file - what teammates did to it and why, before you continue it. Each note carries an anchorStatus: 'verified' (file unchanged since the note), 'changed' (modified since - re-read the file before trusting the note), 'gone' (deleted), 'unknown'.

See every status transition a task went through (todo -> claimed -> in_progress -> done/abandoned) with who made each change and when - useful when a task's current state alone doesn't explain how it got there, e.g. it was abandoned then reclaimed then abandoned again.

Fast, single-file freshness check - call this immediately before editing any file that's part of a shared interface or that you haven't touched yet this session, ESPECIALLY in a long-running session. Returns anchor-verified notes on the file plus real commits from anyone else touching it in the last 15 minutes. This is cheaper than get_handoff_brief and catches drift a session-start snapshot misses (a teammate can commit to this exact file while you're mid-session).

Read the two living plan documents: requirements (the why/what) and design (the architecture/how). Read this alongside get_context/get_handoff_brief to understand intent, not just the task list.

Replace the full content of one plan document (requirements.md or design.md) with new markdown. Read get_plan first and edit the whole doc, don't append blindly - this is the shared source of truth for project intent that every teammate's agent reads.

THE tool to call when picking up work someone else started, or at the start of any session on a shared repo - call this INSTEAD OF assembling context yourself from several calls. Deterministically bundles: requirements + design (why/how), active/unclaimed tasks (what's left), recently completed tasks with their structured completion reports (what was just built, key decisions, why), recently ABANDONED tasks with why they were dropped (so you don't redo a dead end or wonder why something looks half-finished), recent activity, and anchor-verified file history for every file those completions touched. Optionally filter by scope (e.g. ["frontend"]) to focus on one area.