From 94df71eddec1e6f8366e9e5919aed5bf9327ee6c Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Sun, 19 Jul 2026 19:56:10 -0500 Subject: docs(start-work): catch open-ended tasks at the ticket-quality gate The Justify gate's ticket-quality check now names the absence-phrased open-ended goal as the specific case where acceptance criteria aren't concrete, and routes it to the measurable-acceptance conversion in todo-format.md before work starts rather than into an implementation with no definition of done. --- .claude/commands/start-work.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.claude/commands/start-work.md b/.claude/commands/start-work.md index 85ed6b0..726cef4 100644 --- a/.claude/commands/start-work.md +++ b/.claude/commands/start-work.md @@ -171,7 +171,7 @@ Then produce a justification that covers all of these, concisely: 7. **Effort estimate.** S (under 1 hour), M (1 hour to 1 day), L (over 1 day). Rough is fine. 8. **Alternatives considered.** Is there a cheaper way? Can we defer? Can we address the root cause via a different path? 9. **Reasons not to do this.** A forced devil's-advocate verdict on whether the work should happen at all — distinct from Downsides (what the change costs) and Alternatives (cheaper paths). Surface the top three objections if real ones exist; when none rise to a genuine objection, say so in one line rather than manufacturing three (e.g. "Nothing material argues against this. No reason to defer or drop it."). Building the case against the work is cheapest at this gate, which is its purpose. -10. **Ticket quality check.** Is scope clear, are acceptance criteria concrete, are reproduction steps present for bugs? If **not clear**, stop and ask the user to choose one of: +10. **Ticket quality check.** Is scope clear, are acceptance criteria concrete, are reproduction steps present for bugs? An **open-ended goal** phrased as an absence ("find bugs until none remain," "refactor until nothing worthwhile is left," "clean it up") is the specific case where acceptance criteria aren't concrete: it has no definition of done, so there's no writable acceptance test and no clean commit at the end. Don't start it as-is. Give it measurable criteria first — bound the surface, a characterization net, dispositioned findings, an objective floor (see `todo-format.md`'s "Making an open-ended task measurable") — which is also what makes it `:solo:`-eligible. If **not clear**, stop and ask the user to choose one of: - (a) Bounce to `/brainstorm` to refine the ticket first. - (b) Ping the ticket author for clarification. - (c) Supply the missing info themselves right now, if it is easy for them to do so. -- cgit v1.2.3