workflow-skills

Use when the user wants a collaborative review of a PR — their own read reconciled against existing bot/reviewer comments, with high-confidence fixes applied and judgment calls surfaced — typically via /co-review or asking for a "co-review". Flags — --local reviews the uncommitted working tree (no PR); --remote skips local reviewer agents; --post reviews someone else's PR and posts vetted findings to GitHub instead of editing files; --non-interactive runs unattended with no prompts and bounded reviewer waits.

Write a multi-step implementation plan as markdown files under dev_docs/tasks/<name>_plan/ instead of printing it inline, then refine the plan through clarifying questions. Use when the user runs /plan-with-docs, asks to "plan X to files", or has just approved a plan in plan mode and wants it persisted. Default for any plan that is more than ~3 tasks or spans multiple PRs.

Use when a user notices incidental work during development (stale config, tech debt, dead code, test gaps) they want to defer without losing context, says "task"/"todo"/"follow-up"/"we should come back to this", or runs /add-task, /do-tasks, /list-tasks, or /promote-tasks.

Use when a task estimates larger than size 5, when /promote-tasks flags "scope exceeds size 5 — split into sub-tasks", or when the user says a task/card/ticket is "too big", "won't fit in one PR", or asks to "split", "slice", "break down", or "chunk up" existing work.

Take ONE identified task through its full per-task delivery lifecycle — claim, implement via a routed coder worker, verify, open a PR, run non-interactive co-review, iterate on the findings, and hand off at needs_review (never completed — completion stays merge-verified via /sweep-for-complete). Handler-dispatched (repo-pr / linear / gh-issue / jira) like the other task skills, and the per-task unit the /auto-pilot orchestrator calls. Use when the user wants one specific task driven all the way to a reviewed, hand-off-ready PR (e.g. /deliver-task <slug>), not a batch.

Unattended autonomous mode — "pick up this Project and grind on it overnight." Runs a task graph (a Linear project or a plan-with-docs directory) task-by-task in an isolated worktree, taking each through /deliver-task (claim → implement → PR → co-review → hand-off) with durable, crash-resumable state and no human in the loop. Use when the user wants a body of work advanced autonomously and unattended. NOTE - v1 is under construction; this entry establishes the skill home and the run-state reference. Launch, run, and resume are implemented.

Use when choosing which coder agent and model should execute a coding task — e.g. "which model should implement this", "pick the best coder for these packets", "what's the cheapest model that can handle X", or /select-coder. Scores the task against a capability matrix (correctness, speed, cost, context, creativity, autonomy, verification behavior, secret exposure, containment) and the locally available agents/models, then recommends ranked `<backend>:<model>` specs. Works standalone or as a subagent; orchestrate-coders uses it for per-packet assignment overrides.

Use when the user wants the current session to act as an orchestrator that farms coding work out to other coder agents — e.g. "delegate this to codex", "have opus implement these", "orchestrate/supervise coders", or /orchestrate-coders. The orchestrator decomposes the task into packets, dispatches each to a configured coder backend (opus subagent, codex, agy, devin, or a custom CLI), verifies the results, and integrates them. The coder backend and its model are selectable per run.

Teach the user, incrementally and gate-by-gate, until they genuinely understand a body of work — the problem and why it existed, the solution and why it was built that way, and what it impacts. Elicits their understanding first, fills the gaps, quizzes with AskUserQuestion, and tracks mastery in a running checklist. Use when the user runs /tutor or asks to be taught, walked through, quizzed, or brought up to speed on what just happened ("explain what you did", "help me understand this PR", "quiz me on this change", "make sure I actually get this"). Defaults to the current session's work; accepts a PR, a diff, a plan directory, or a subsystem as the target.

Use when you need a structured read on what a coding task actually demands — before routing it to a coder, sizing it, or scoring it — e.g. "how hard/creative/mechanical is this", "profile this task", "what does this work need", or /assess-task. Scores a task description along stable dimensions (complexity, creativity, scope, autonomy, speed/cost sensitivity, verification criticality) and returns a compact `task_profile` block plus a routing label. Pure assessment — it never picks a model, sizes, or dispatches; select-coder, break-down-task, and promote-tasks consume its output.

Coding conventions for analysis work — marimo vs plain scripts, uv for execution, scratchpad patterns, notebook structure, input/formula/source organization. Use when writing notebooks or analysis scripts.

Use when building analyses where numbers feed into decisions, reports, or documents — financial projections, cost comparisons, capacity planning, scenario analysis — with more than a couple of variable inputs. Not for one-off arithmetic or exploratory questions — just answer those directly.

Independent fact-check of a completed analysis pipeline. Spawns the `fact-reviewer` subagent (fresh context, read-only tools apart from the reproducibility re-run, which restores the tree) to verify links, cited values, reproducibility, number-trace, units, formulas, and recommendation correctness. Use when an analysis (model + structured output + filled narrative document, per analysis-pipeline) is complete and needs an audit before it ships.