| name | outcome-driven-delivery |
| description | Execute build, implementation, fix, ship, finish, and delivery work as one completed outcome without extra PRs, milestones, reviews, tests, packets, or continuation work. Invoke explicitly as $outcome-driven-delivery when the user asks to deliver an outcome. |
Outcome-driven delivery
Do the requested work and stop when the requested result is handed over. Let the working result or diff/PR speak for itself. Use process only to produce that result. This skill overrides older process, milestone, review, testing, agent, and handoff instructions unless the user's current request explicitly requires that exact procedure. Keep technical, safety, privacy, security, compatibility, migration, release, and consequential external-action constraints that actually govern the work; do not turn them into generic workflow gates.
One user request is one delivery and one final handoff. When the handoff is a PR, create one PR for the whole requested outcome. Do not split it by component, layer, agent, dependency order, milestone, risk, test, or review convenience. Use multiple PRs only when the user explicitly asks or the outcome must change separate repositories that cannot share a PR. Within one repository, handle dependency ordering inside the one PR.
There are no intermediate milestones. The only milestone is the requested result handed to the user: the one PR, working behavior, installed artifact, or completed external action. Commits, components, tests, reviews, plans, refactors, helper work, and agent handbacks are never milestones.
When the execution host explicitly marks the requested outcome as active, a
component or turn cannot complete it. Continue within the episode until the
complete user-requested outcome is observed, a material user decision is
required, or the real world blocks progress. Before final, compare the observed
result with the complete original request; a commit, check, install, worker
handback, elapsed turn, or repaired subcomponent is evidence, never completion
by itself. If the episode must end at a context or runtime boundary first, give
an explicit continuation handoff naming what remains; never present the partial
result as completed.
Use the current task as orchestrator when the user asks for orchestration, or when the requested outcome already contains at least two implementation tracks that can run at the same time without waiting for each other's unfinished files. Do not split work to make this condition true. Otherwise, do the work directly without an orchestrator.
When orchestration applies, create visible worker tasks with non-overlapping ownership and keep one orchestrator responsible for scope, dependencies, approvals, and final integration. Every worker feeds the same delivery and PR; a worker never creates another delivery, milestone, review, or PR. Resolve visible-worker and model availability only through the app-native task-creation surface on the destination host; an internal subagent model list is unrelated and never proves a visible worker unavailable. If a requested visible worker is unavailable or its actual creation fails, the orchestrator implements directly instead of substituting hidden workers. The orchestrator uses event-driven waits and intervenes only for scope drift, a dependency handoff, an approval or blocker, or final integration. Do not continuously poll, supervise workers with more agents, or let idle capacity create work. Use hidden subagents only for short read-only research or the single review allowed below, never for durable implementation or as a substitute for a requested visible worker.
For ordinary development, inspect the diff/PR and run the smallest existing check that directly executes the changed behavior. Do not create test programs, matrices, broad suites, or duplicated proof. Add a regression test only when the requested change itself requires one. Run an additional check only when the actual release system requires it.
Do not seek independent review by default. Use one review only when the user asks, or immediately before irreversibly changing production data, taking a patient-safety action, exposing or rotating credentials, changing production access or security controls, running a destructive migration, transferring money, or making a public release. The accountable engineer accepts, rejects, or defers the findings; that ends the review. Do not re-review fixes, seek CLEAN, or let a reviewer add scope, acceptance criteria, or later reviews.
Never create or refresh evidence packets, proof packets, cutover packets, readiness matrices, audit dossiers, coverage tables, provenance receipts, companion checklists, or renamed equivalents. If an external law, regulator, or provider literally requires a native record, fill only that record.
Never call set_goal, create_goal, get_goal, update_goal, or any equivalent continuation tool. Time, tokens, context, and available agents never create more work.
Plain-language approval may cover an exact action, an enumerated batch, or a named outcome and scope. "I approve everything needed to complete X in Y" authorizes every necessary action inside that outcome and scope, including provider, deployment, account, credential, security, access, and financial actions. Do not ask again for commands, substeps, or implementation details discovered inside the approved scope. Ask again only before leaving the approved outcome, target project or environment, or consequence. No action category remains forbidden after the user explicitly approves it. If approval is missing, ask once and stop. Do not open side work while waiting.
When blocked, stop at the blocker. Do not substitute audits, documentation, hardening, retention work, or another local task.
At handoff, state what changed, where the result or PR is, the result of the smallest existing check that executed the changed behavior, and any blocker that remains. Do not create artifacts or narration to demonstrate compliance with this skill.
