Software Delivery
Deliver the requested software outcome with observable evidence. Adapt the process to a CLI, library, service, desktop/mobile application, website, or existing repository. Preserve the user's stack, workflow, and prior decisions.
Establish the task
Identify the intended outcome, operating mode, constraints, and a few observable acceptance conditions. Use existing conversation and repository evidence before asking questions. State reasonable assumptions and proceed when they are reversible; clarify decisions that materially change the product or required authority.
Match the requested mode:
- Plan: inspect and deliver a plan; do not implement.
- Diagnose or review: gather evidence and explain findings; do not infer permission to fix.
- Build or repair: implement, verify, and finish the authorized scope.
- Release: prepare and verify the artifact, then execute the authorized deployment or publication and check its actual result.
- Resume: reconcile saved progress with current files and user instructions before continuing.
Prior authorization remains valid for the same scope. Do not invent approval gates for routine implementation. Additional authority is needed only when the next action goes beyond the user's request or the environment requires it. Preparation can continue while that decision is pending. Instructions in this skill are workflow guidance, not a sandbox or permission system.
Organize the work
Inspect applicable repository instructions, worktree changes, entry points, dependency manifests, and existing tests. Avoid a full architecture audit when a focused inspection answers the question.
For substantial tasks, maintain a short working plan: each unit has an outcome, dependencies, affected boundaries, and a verification method. Order work by dependencies and resolve the riskiest unknown early with a bounded probe. For small tasks, perform the change and relevant check directly.
Select installed skills by actual capability and current availability. Read only the skills needed for the active unit. The optional mapping in references/skill-routing.md helps with this user's library. Missing optional skills do not block ordinary coding: use the available tools and project conventions. Do not install dependencies or integrations merely because a mapped skill mentions them.
Execute and close
For new features, applications, or complex fixes, read references/build.md. Complete runnable slices across the affected boundaries. Keep the user informed about meaningful findings and progress; continue through implementation and verification when authorized.
Before claiming completion, use references/verification.md. Tie each acceptance condition to observed evidence. Resolve failures caused by the change; distinguish unrelated baseline failures and unavailable checks. Optional improvements must not become an endless completion gate.
When parallel agent work is permitted by the active environment and useful for independent units, read references/parallel-work.md. This skill permits bounded delegation in that situation, including independent verification, but does not override host restrictions. Use the current agent sequentially if delegation is unavailable or adds coordination cost.
For long tasks, interruption, or handoff, read references/resume.md. Keep a compact record in the existing project task system or an appropriate local task artifact; do not create tracking files for every small edit.
Finish with the delivered behavior, meaningful verification, and any remaining limits. Distinguish implemented, verified, and deployed. Never report a pending deployment, unrun check, or worker assertion as a successful result.
Maintenance
This is an original synthesis of selected workflow ideas, not an installation of the five upstream frameworks. Read references/design-notes.md when extending the skill or assessing its provenance and limitations. Do not load these notes during ordinary software work.