delivery

Designs and runs a multi-agent run across the delivery stages (pre-flight and orientation, test design, implement, verify live, review, describe) or any multi-step job the user describes, cheaply and honestly. It first decides whether one agent is enough, then runs the stages as a workflow script, as subagents, or as agents the session spawns directly, depending on what the platform supports, with capped fix loops, a separate skeptical verifier, and an honest blocked exit. Use when asked to build, design, or run a workflow, orchestrate subagents, run the delivery pipeline end to end, implement a plan with agents, or make a multi-agent run cheaper or more reliable.

Designs the tests for a feature from its spec and its real implementation, and produces a test-design document (scenarios per acceptance criterion, an API test table, a coverage matrix, and spec-versus-code divergences) for an implementer to turn into test code. Use when asked to design tests, write a test plan, decide what to verify, or before tests are written for a change. It designs only; it doesn't write or run test code.

Draws technical diagrams (flowcharts, sequence and state diagrams, architecture and data-flow pictures) that read as one system, choosing Mermaid for pages that render it and hand-drawn ASCII for terminals, chat replies, and markdown read in an editor. Project-specific destinations, renderer limits, and size or width limits come from an optional settings file. Parses Mermaid before shipping when the environment has a parser or validator. Use when about to draw any diagram, flowchart, sequence diagram, or state diagram, or when another skill asks for one. For charts of data (bar, line, pie), use a charting skill instead.

Verifies a change in the running app instead of trusting tests alone. It boots the app and confirms it responds, mints a local test session, drives the changed flow over HTTP or in a real browser, checks the stored effect before and after, and reports each check as passed, failed, or not run, with the evidence it saw. Covers browser extensions too. Use when asked to verify a change live, check it actually works in the running app, smoke-test it in the browser, or prove it before merge. Not for writing or running unit or end-to-end test suites, or for just starting the app.

Writes a pull request title and description from the branch's diff and history, shows the full draft for approval, then creates or updates the pull request on the project's code host and links any extended context. Use when a branch is ready to open or update a pull request or merge request, or when asked to write, draft, or publish a PR description.

Reviews a branch or pull request against a catalog of review concerns (a built-in starter set plus the project's own, mined from its past reviews) in two agent stages, map-and-review per slice of the diff and a separate validation, and reports only validated bugs, issues, and nits, each quoting its added line, with an advisory ship verdict. Also builds or refreshes the project's concern catalog from past review comments. Unlike a general code review, it checks the project's own recurring concerns and prints how much of the catalog it covered. Use when asked to review, audit, or check a branch or pull request for correctness or readiness to merge, or to build a review catalog.

Makes a Prisma schema change end to end on the development database, using the Prisma CLI to generate every migration (never hand-written SQL), reviewing the SQL before it's applied, regenerating the client, updating application types, and confirming no migration is left pending. Use when changing a Prisma schema, adding or altering a model, field, enum, or relation, creating or fixing a migration, or checking a hand-written migration.

Routes work through the delivery pipeline (explain, plan, test design, implement, verify live, review, describe, demo). It checks where the current branch stands with cheap read-only checks, names the current stage and the one next stage with the skill or command that runs it, and asks before starting it; it can also jump to a named stage or hand the remaining stages to a multi-agent run. Use when the user says "ship this", "what's next in the pipeline", "where am I in the pipeline", "what's left before I open a PR", "take this to PR", or asks which delivery step or skill comes next. Not for "what's next" about code, a function, or a plan step; answer those directly.

Audits SKILL.md files and writes a scored report with concrete fixes. Use when asked to review, audit, critique, grade, lint, or score a skill or a folder of skills, or before publishing or porting a skill into a plugin. For creating or rewriting a skill, or for skill usage and context cost, use the platform's skill-authoring and usage tools instead.

Writes explanations and reader-facing documents point-first, with a lead line that answers, an optional ASCII diagram, a body shaped to the content (steps, prose, or table), and one next action. Use when asked to explain something, walk through it, or say how it works or why it broke, when giving a multi-step plan, or when writing a plan, handoff, spec, or report for someone to read and act on. For one-line answers and status replies, answer directly instead.