strvcom

Task Breakdown Command. Breaks a feature into discrete, dependency-ordered implementation tasks from a PRD and tech spec. Creates a task list and individual task files with no approval prompt. When run inside the `/start-job` pipeline, return control to that orchestrator so it can invoke the implementation phase. When invoked standalone, stop after generating tasks and prompting for the next step. Use when the user says "break this down into tasks", "create tasks", "task breakdown", or after the tech spec is complete and the user wants to plan implementation.

Create a Flutter feature Product Requirements Document through a structured clarify-plan-draft workflow. Outputs a PRD using the repository template under `.claude/tasks/<feature-name>/prd.md`. Use when the user says "create a PRD", "write requirements", "define the feature", "start a feature spec", or wants to specify a feature before techspec/tasks/start-job.

Technical Specification Command. Translates a PRD into an implementation-ready technical spec through deep project analysis and clarification. Use when the user says "create a tech spec", "write the technical design", "spec this out", or after a PRD is complete and the user wants to move to technical planning.

Top-level orchestrator for Flutter feature specification. Runs the full uninterrupted pipeline: prd → techspec → tasks in one shot. Use when the user says "spec a feature", "write a spec for", "start feature spec", "plan a feature", or wants to go from idea to implementation-ready tasks without typing three separate commands.

Build/test/lint verification pass for this Flutter app — runs codegen, analyze, test, then iOS + Android native builds in parallel, then `dart format`. Does NOT commit anything; leaves the working tree dirty so the user can review and commit on demand. Used at the end of the prd → techspec → tasks → implement-tasks-sequence flow before `pr-review`, and can also be invoked manually when the user says "verify build", "run full verification", or "check everything".

Create or update a GitHub PR for this Flutter repository using gh CLI. Verifies the work with build-verify and pr-review, generates an inline PR description, commits pending changes when approved, pushes, and opens or updates the PR. Supports stacked PRs by asking for the base branch when detection is ambiguous. Use when the user says "create PR", "open PR", "push PR", or wants to submit their work for review.

Build a full feature in this Flutter repository that includes backend or storage data flow: read API schema, create DTOs, map DTOs to entities, add Riverpod use cases, connect feature state, and render UI data. Use when a task goes beyond a screen and needs real data integration.

Create a new Flutter screen in this repository using the existing feature structure, AutoRoute setup, Riverpod state pattern, and code generation workflow. Use when adding a new page, route, stateful screen, or feature folder in this template.

Survey a codebase's animation and motion code as a senior motion advisor, then produce a prioritized audit and self-contained implementation plans for other agents (or cheaper models) to execute. Read-only on source code — it plans improvements, it does not apply them. Use when the user asks to "improve the animations", "audit the motion", "make this app feel better", or wants a roadmap of animation fixes rather than a review of a single diff.

Survey any codebase as a senior advisor and produce prioritized, self-contained implementation plans for OTHER models/agents to execute. Strictly read-only on source code — never implements, fixes, or refactors anything itself. Use when asked to audit a codebase, find improvement opportunities (bugs, security, performance, test coverage, tech debt, migrations, DX), suggest features or where to take the project next (roadmap, product direction), or generate handoff plans for another agent to implement.

Oversight-first daily PR maintenance for the current repo. Use when the user wants to triage and maintain their pull requests — "do my PR rounds", "pr daily", "review my PRs", "check my open PRs", "rebase and fix my PRs", daily PR cleanup. Resolves the right GitHub account first, fans out read-only parallel code reviews on PRs awaiting the user's review (never auto-submitted), and single-threads verification-gated fixes (rebase, review comments, failing CI) on the user's own PRs. Works on any repo and any stack — discovers conventions and checks from the repo itself. Do NOT use for a one-off review of a single specific PR, or to merge PRs.

Audit JS supply-chain hygiene (Safe Chain on dev machine, .npmrc/equivalent in repo, GitHub Actions CI gates, CONTRIBUTING.md mention) and offer interactive fixes. INVOKE ONLY when the user explicitly types `/supply-chain-check` — do NOT auto-invoke based on project type, lockfile presence, security mentions, or any related context.

Compact the current conversation into a handoff document for another agent to pick up.

Split working-tree changes into multiple logical commits using Conventional Commits format. Use when the user says "split commits", "logical commits", "break this into commits", "commit my changes", "commit strategy", or has accumulated multi-concern changes on a branch. Auto-detects the repo's commit conventions from recent history and asks for type/scope/approval through interactive selections (AskUserQuestion) instead of free typing. Never bypasses git hooks. Do NOT use for amending existing commits, rewriting history, interactive rebase, or pushing as the primary goal — only for creating new local commits from current changes.

Use when challenging ideas, plans, decisions, or proposals. Invoke to play devil's advocate, run a pre-mortem, red team, stress test assumptions, audit evidence quality, or find blind spots before committing. Do NOT use for building plans, making decisions, or generating solutions — this skill only challenges and critiques.

Distill anything to its absolute essence — the fewest words that carry the full meaning. Use when user wants a TLDR, asks to summarize, name, or condense something, or mentions "nutshell".

Use when the user's message contains a JSON block with "source": "pinpoint" (pasted from the pinpoint browser overlay after clicking Send). Acks the bridge so the browser clears, then applies each annotation's comment to its component.

Use when creating, updating, moving, or reviewing tasks on the project's Backlog.md board (the backlog/ folder) — adding a work stream, changing a task's status, linking a plan/spec, or checking what is open / in progress / done.