solve-task

Solve Task

Gather the right context for a task, distill it into a brief, then enter the normal development workflow. This skill does NOT plan or implement — it disciplines context-gathering and hands the brief to superpowers:brainstorming (which leads to writing-plans → subagent-driven-development, or the execution strategy chosen in the startup survey (inline / subagent / lite)).

Inputs

$ARGUMENTS is either:

• a task key (e.g. PRI-4, matching the board's key_pattern), or
• a free-text description (e.g. "add a logout endpoint").

Pipeline

1. Startup: survey + Preflight (index freshness + task-corpus warm-up). Run this BEFORE anything else. First resolve, once, the repo path (git rev-parse --show-toplevel) and the working branch (git branch --show-current; if it is in REVIEW_BRANCHES use it, else the primary branch) — step 3 reuses the same branch for search_codebase.

   Resolve task_board exactly once before any board call. Read the repo .review.yml block: its task_board mapping has priority; an absent block falls back to get_board_config(); an explicit empty task_board: disables board work for this run. Keep the resolved {type, project, key_pattern, create_target, done_target, options} value and reuse this resolved value in Step 1 and every board operation. Never call the deploy fallback when the repo explicitly disables the board.

   Call prepare_task_context(repo, key, branch, warm_board=True) once here — pass the resolved key when $ARGUMENTS matches key_pattern, else board-less: pass the user's formulation verbatim as key (the tool's key parameter is required and accepts free text when no board key matches). It folds the manual round trips below into one deterministic call and returns a single payload: preflight (branch, indexed_sha, drift, summaries, chunks, graph_nodes — feeds Step 0.1/0.4 below), task_board/task (feeds Step 2), related/subsystems/code/test_exemplars (feeds Step 3), gaps (a list of {section, reason, cause, cause_detail, remedy} — branch on cause, the machine-readable class, not the prose reason; cause_detail refines it INSIDE the class (auth_failed | missing_database | null) and decides the wording of Step 0a; copy every entry into Constraints / open questions in the Step 4 brief verbatim) and warnings (surface to the user). No source failure raises — a failed section just adds a gaps entry, so the steps below stay fail-open.