delivery

Diagnose and fix failing pull request checks — read the failing job logs, reproduce locally, classify the failure, apply a fix, and push until the checks go green. Use when: PR checks are red, CI is failing, a required status check is blocking merge, or a build/test/lint job fails on a PR.

Run any change to .ai/ — the record of how the team develops with AI: which practice, agent, skill, hook, model, or guardrail is used at which stage of the development flow, the concepts underneath, and how far adoption has got. Use for recording a usage, promoting or retiring an adoption status, adding a stage, or adding a concept. Routes authoring to the `docs` role under the repository's own ai instruction files. DO NOT USE FOR: registering a tool with its vendor and version (flow-tech), or AI shipped inside the product (flow-arc42, flow-domain, flow-tech).

Run any change to .arc42/ — an architecture chapter, section, or diagram; a new or updated architecture decision record; a technical debt record; or an architecture proposal, comparison, or target-architecture draft, which lands as a record in proposed status. Use for every architecture documentation task, from a one-line chapter correction to recording a cross-cutting decision. Routes drafting to the `architecture` role under the repository's own arc42 instruction files. DO NOT USE FOR: the domain model (flow-domain), the technology graph (flow-tech), or implementing what a decision says (flow-feature, flow-create-service).

Run .NET Aspire upgrades with a plan-first workflow. Creates and refines an upgrade plan, performs staged updates, enables new Aspire features, and validates runtime behavior with recorded results.

Run bug resolution end to end — from an ad-hoc "this is broken" report or a triaged issue through reproduction, root cause analysis, TDD fix implementation (test first), verification, and local runtime validation. Missing reproduction steps, severity, or root cause context is derived in Stage 0 rather than being a reason to skip the flow.

Create a new module in an existing project — from an ad-hoc "we need a module for X" request or an approved module specification through planning, implementation, testing, local run, and monitoring. Use for new modules and for carving an existing area into a module; missing specification, boundaries, or architecture context is derived in Stage 0 rather than being a reason to skip the flow.

Run Minimum Viable Product (MVP) creation — from an ad-hoc product idea or an approved MVP specification through planning, implementation, testing, local run, and monitoring with agent handoffs. Use for a first runnable product increment of any size; missing scope, feature priorities, or architecture context is derived in Stage 0 rather than being a reason to skip the flow.

Create a new service in an existing project — from an ad-hoc "we need a service for X" request or an approved service specification through service design, implementation, project wiring, testing, local run, and monitoring. Use for new services and for extracting an existing area into its own service; missing specification, responsibilities, or architecture context is derived in Stage 0 rather than being a reason to skip the flow.

Run any change to .design/ — UX principles, color tokens, typography and layout, interaction guidelines, accessibility, and component libraries. Use for refreshing tokens from the design source, adding an interaction or accessibility rule, or evaluating a component library, including small rule additions. Routes authoring to the `ux` role under the repository's own design instruction files. DO NOT USE FOR: wireframes, user flows, prototypes, and UI reviews (the `ux` role directly), UI implementation (flow-feature, flow-bug), or UI dependency changes (flow-update-packages).

Run any change to .domain/ — the context map, or a bounded context's domain model, features, model and flow diagrams, dependencies, and naming. Use for a new aggregate or domain service, a changed invariant, a feature breakdown, a cross-context dependency, a term or alias, or scaffolding a new bounded context. Routes modeling to the `domain` role under the repository's own domain instruction files. DO NOT USE FOR: a field, entity, or method inside an existing aggregate that leaves the documented model unchanged (flow-feature), or the architecture decision behind a context boundary (flow-arc42).

Generic flow entrypoint, for task categories with no dedicated flow-* skill — or when the skill that does match targets fundamentally different work. Routes the task to the closest specialist agent, runs a minimal plan-execute-review workflow, and closes through the shared phase tier matching the change kind.

Run feature work end to end — from an ad-hoc request or an approved specification through implementation, validation, review, and personal approval. Use for new features, incremental changes to existing features, and small UI tweaks; missing scope, acceptance criteria, or architecture context is derived in Stage 0 rather than being a reason to skip the flow.

Run project scaffolding and development environment setup for an existing repository. Use this skill after flow-repo to initialize the .github folder, coding guidelines, Aspire AppHost, project structure, and local validation. Assumes the repository already exists and is configured.

Run GitHub repository creation and configuration for a new project. Use this skill to create the repository, expand the README, write repository instructions, set up MCP servers, configure branch protection, add issue and PR templates, and establish repository governance. Run flow-project after this skill to scaffold the development project.

Run existing repository structure and layout refactors. Use for folder moves, project or solution layout corrections, test/harness placement, and reference updates. Do not use for initial scaffolding (use flow-repo or flow-project), new modules/services (use flow-create-module or flow-create-service), or architecture documentation only (use flow-arc42).

Run any change to .tech/ — the technology graph of platforms, runtimes, frameworks, libraries, packages, services, and tools. Use for adding a technology, pinning a version, promoting or retiring a status, adding a layer, or refreshing the graph diagram. Routes the reasoning to the `architecture` role under the repository's own tech instruction files. DO NOT USE FOR: changing the dependency itself in a project file (flow-update-packages), or the decision that picks a technology (flow-arc42, which .tech then records the outcome of).

Run dependency and package update workflows. Coordinates safe updates of NuGet packages, npm modules, SDKs, and tools across projects with security scanning, compatibility testing, and local runtime monitoring.

Write this engine's two seeded procedures into a repository — start, how its application comes up, and capture, how evidence of the feature being built is taken — each as one editable copy with a pointer wrapper per host, and record them under components.delivery in .devbook/config.json. Idempotent: first install, plugin upgrade, and a seed change are one run. Use when: adopting the delivery engine in a repository, upgrading it, or the start or capture skill is missing. Triggers on: "delivery install", "install delivery", "seed the start skill", "seed the capture skill", "delivery-install".

Shared Build & Test phase for code-modifying flow-* flows. Builds all projects and runs the unit and end-to-end suites first, failing fast on any red result. Invoked in order by the flow-runner agent.

Shared Personal Validation review handoff for every flow-* flow. Brings the application up, publishes the review links as clickable URLs, and says what to check by hand. Runs again on every revise round. It presents and never decides — the mandatory approval gate stays with the flow-runner. Invoked by the flow-runner agent.

Shared QA Validation phase for code-modifying flow-* flows. Runs after Build & Test; depth is driven by change kind (new functionality = Playwright QA with capture, bug/existing-flow change = targeted verification, dependency update = startup-only, otherwise skipped). Invoked by the flow-runner agent.

Take one pull request to merge-ready: score it against the merge-ready checklist and clear its blockers using update-pr-branch, fix-pr-checks, and pr-remarks-review. One PR per pass, worked in this session. Built to run repeatedly under /loop as a PR babysitter, picking the next PR each pass. Use when: getting your pull request ready for merge, watching CI on it, or running a scheduled pull request sweep.

Push the current branch to its remote and stop there — no pull request. Use when: pushing a branch, publishing local commits, setting the upstream for a new branch, or getting commits onto the remote so CI runs.

Create work items from active Azure Monitor SRE alerts, in whatever tracker the repository binds — GitHub issues, Jira tickets, or Markdown chapters. Use when: triaging Azure alerts, translating SRE incidents to tracked work, syncing Azure Monitor findings to the backlog, bulk item creation from an alert feed.

Start this session's work from a single tracker work item — a GitHub issue, a Jira ticket, or a Markdown chapter: fetch the items matching a filter, select one, claim it, route it to the flow-* skill that matches its type, and run that flow here. One item per run, no extra sessions. Use when: picking up an issue for implementation, pulling the next item off the backlog, or running a scheduled backlog pickup.

Bring a pull request branch up to date with its base branch and resolve merge conflicts, then re-validate and push. Use when: a PR is behind or out of date, GitHub reports conflicts, 'this branch has conflicts that must be resolved', or a required 'branch up to date' status is blocking merge.