clean-delivery-workflowlisted

The order of work for a change, and how much of that order a given change actually warrants: understanding before editing, clarifying what is ambiguous, deciding the test approach, implementing in reversible steps, separating refactoring from behaviour where independently valid, running the gates the risk deserves, and verifying before declaring done. Also the entry point that routes a situation to the skill that owns it. Use when starting a change and the order is not obvious, when a change has sprawled and needs re-sequencing, when refactoring and behaviour changes have been mixed in one commit, when work is being declared done without verification, when the same ceremony is being applied to a one-line fix and a migration, or when you know the problem but not which skill covers it. Does not itself cover any step in depth — it routes to requirements-and-acceptance, java-testing-strategy, tdd, java-refactoring, code-review and quality-gates, each of which owns its own.
robsonkades/agent-skills · ★ 2 · Code & Development · score 75

Install: claude install-skill robsonkades/agent-skills

# Clean Delivery Workflow ## Purpose Two failures this exists to prevent, and they look nothing alike. The first is the change that starts in the editor: code written before anyone established what was being asked, discovering in review that it solves the wrong problem. The second is ceremony applied uniformly — a one-line configuration fix carrying a design discussion, an acceptance-criteria table and the full pipeline, until the process becomes something people route around. The workflow establishes prerequisites, not a one-way pass. New evidence can send work back to clarification, risk assessment or test design; how much each step deserves depends on the change. ## Workflow 1. **Understand.** Read the code that exists before proposing a change to it. Find relevant callers, tests, ownership and history. Inspect commits when intent is unclear; “the last three” is not a meaningful boundary when the change history has a different shape. Read applicable repository instructions and build/CI configuration. Inspect staged, unstaged and untracked changes before editing; preserve work outside your ownership. For Java, use the project's compiler/toolchain, runtime and dependency evidence; this workflow sets no Java baseline and does not authorize upgrades or preview features. 2. **Clarify.** Resolve ambiguity from available evidence first. Ask only for missing decisions that materially change correctness or scope; record safe assumptions and continue ind