Outcome-First Workflows
Run substantial work against a visible finish line. Define what must become true,
which constraints matter, and what evidence will prove completion; leave routine
implementation choices open.
Route Nearby Work
- Use
plan-changes when the requested deliverable is an implementation plan.
- Use
systematic-debugging when the cause of broken behavior is unknown.
- Use
adversarial-review when the user explicitly wants independent,
high-scrutiny review.
- Handle small, directly verifiable tasks without adding workflow ceremony.
Establish the Contract
Before substantive work, derive a compact contract from the request and local
context:
Outcome: <observable end state>
Constraints: <scope, safety, compatibility, authority>
Non-goals: <adjacent work intentionally excluded>
Done when:
- <claim> -> <evidence that can prove it>
Stop or ask when: <human decision or authority boundary>
Do not turn this into a screenplay. Include decisions that control the result,
not a command-by-command itinerary.
Ask the user only about choices that cannot be discovered and would materially
change the result. Resolve codebase facts, tool availability, and current state
directly when safe.
Match Evidence to the Claim
Choose the witness before implementing when verification affects the design.
| Completion claim |
Appropriate witness |
| A user flow works |
Exercise the real UI or equivalent user surface. |
| Hidden state changed |
Read it back through the owning API, CLI, log, or datastore. |
| A code contract holds |
Run the narrow test, type check, lint, or contract probe that exercises it. |
| Performance improved |
Compare repeated baseline and treatment runs under the same load. |
| A deployment shipped |
Verify the deployment job and the served artifact or live behavior. |
| An external artifact changed |
Re-open the external artifact; a local diff cannot prove it. |
One witness may support several claims, but a convenient witness must not stand
in for the relevant one. A build does not prove a user interaction, and a UI
check does not prove a database invariant.
Execute Within the Contract
- Inspect the current state before editing when the implementation boundary or
cause is uncertain.
- Keep one integration owner for the outcome. If the runtime supports parallel
workers, delegate only independent sources or review lanes.
- Give each lane a bounded question, allowed scope, expected evidence, and
stopping condition. Do not split work that shares unresolved design state.
- Reconcile findings before editing overlapping files or adopting review
feedback.
- Update the contract only when new evidence changes the real outcome,
constraint, or finish line. Report material scope changes.
- Stop once the finish-line evidence is collected. More activity is not more
completion.
Handle New Information
- If evidence disproves the assumed cause, switch to
systematic-debugging.
- If a new user choice would materially change the product or architecture,
pause at that decision boundary.
- If a safe alternative stays inside the contract, take it and record the
trade-off.
- If adjacent cleanup is useful but unnecessary, leave it outside the finish
line rather than silently expanding scope.
Complete Honestly
Before declaring completion, check:
- The observable outcome exists.
- Every material claim has the right witness.
- Constraints and non-goals were respected.
- Review feedback was validated before adoption.
- Remaining work is either outside scope or explicitly blocked.
Report the achieved outcome first, then the strongest evidence, then any
material limitation. Do not make the user reconstruct completion from a list of
commands.
1---2name: outcome-first-workflows3description: Use when leading a larger implementation, investigation, audit, migration, or review that needs an observable end state, explicit scope, a stopping condition, bounded parallel work, or evidence matched to completion claims. Do not use for a small task with one obvious check.4---56# Outcome-First Workflows78Run substantial work against a visible finish line. Define what must become true,9which constraints matter, and what evidence will prove completion; leave routine10implementation choices open.1112## Route Nearby Work1314- Use `plan-changes` when the requested deliverable is an implementation plan.15- Use `systematic-debugging` when the cause of broken behavior is unknown.16- Use `adversarial-review` when the user explicitly wants independent,17 high-scrutiny review.18- Handle small, directly verifiable tasks without adding workflow ceremony.1920## Establish the Contract2122Before substantive work, derive a compact contract from the request and local23context:2425```markdown26Outcome: <observable end state>27Constraints: <scope, safety, compatibility, authority>28Non-goals: <adjacent work intentionally excluded>29Done when:30- <claim> -> <evidence that can prove it>31Stop or ask when: <human decision or authority boundary>32```3334Do not turn this into a screenplay. Include decisions that control the result,35not a command-by-command itinerary.3637Ask the user only about choices that cannot be discovered and would materially38change the result. Resolve codebase facts, tool availability, and current state39directly when safe.4041## Match Evidence to the Claim4243Choose the witness before implementing when verification affects the design.4445| Completion claim | Appropriate witness |46| --- | --- |47| A user flow works | Exercise the real UI or equivalent user surface. |48| Hidden state changed | Read it back through the owning API, CLI, log, or datastore. |49| A code contract holds | Run the narrow test, type check, lint, or contract probe that exercises it. |50| Performance improved | Compare repeated baseline and treatment runs under the same load. |51| A deployment shipped | Verify the deployment job and the served artifact or live behavior. |52| An external artifact changed | Re-open the external artifact; a local diff cannot prove it. |5354One witness may support several claims, but a convenient witness must not stand55in for the relevant one. A build does not prove a user interaction, and a UI56check does not prove a database invariant.5758## Execute Within the Contract59601. Inspect the current state before editing when the implementation boundary or61 cause is uncertain.622. Keep one integration owner for the outcome. If the runtime supports parallel63 workers, delegate only independent sources or review lanes.643. Give each lane a bounded question, allowed scope, expected evidence, and65 stopping condition. Do not split work that shares unresolved design state.664. Reconcile findings before editing overlapping files or adopting review67 feedback.685. Update the contract only when new evidence changes the real outcome,69 constraint, or finish line. Report material scope changes.706. Stop once the finish-line evidence is collected. More activity is not more71 completion.7273## Handle New Information7475- If evidence disproves the assumed cause, switch to `systematic-debugging`.76- If a new user choice would materially change the product or architecture,77 pause at that decision boundary.78- If a safe alternative stays inside the contract, take it and record the79 trade-off.80- If adjacent cleanup is useful but unnecessary, leave it outside the finish81 line rather than silently expanding scope.8283## Complete Honestly8485Before declaring completion, check:8687- The observable outcome exists.88- Every material claim has the right witness.89- Constraints and non-goals were respected.90- Review feedback was validated before adoption.91- Remaining work is either outside scope or explicitly blocked.9293Report the achieved outcome first, then the strongest evidence, then any94material limitation. Do not make the user reconstruct completion from a list of95commands.
EzraApple