Make the Jira skills call unslop, grilling, and tdd where they pay

All three already delegated in places — ticket calls diagnosing-bugs and run, review-ticket calls codebase-design — so this extends a habit rather than starting one. unslop is the load-bearing part, at four points: create-ticket before the Jira write, review-ticket's check list where a bare punctuation sweep stood, and ticket on both mr.md and the Jira fields. Every one is scoped to pattern detection and skips the "Adding soul" section, which is blog voice and would fight the rigid house formats. The mr.md hook exempts the pasted pre-MR handoff, generated output the skill already forbids editing, and the field hook exempts proof cells. Conrad and Henry read all of this, and prose that reads as machine generated costs the work its credibility before anyone weighs what it says. grilling comes in as a classification gate rather than blanket ceremony. ticket now names the work bounded or architectural before drafting plan.md and escalates only on architectural, where a wrong assumption is expensive to find in Phase 2; bounded stories go straight through as before. create-ticket escalates only when the epic docs have not settled scope, which is where invented scope gets in. tdd is gated the same way: test-first for procedures, derivations, permission checks, migrations and state machines, and explicitly not for UI wiring or copy changes, where it would produce the smoke-test padding House style rejects. That closes a loop already half built, since review-ticket proposes automated-test subtasks — those subtasks now name the behavior to demonstrate, and ticket writes them first. codebase-design gets the same call in ticket's planning step that review-ticket already makes. No steps were renumbered, so ticket's Phase 2 cross-references still resolve. Claude-Session: https://claude.ai/code/session_01DFgQVLdzLwu56gU8m4gvCS
2026-08-24 11:58:01 -04:00
parent b58371bb35
commit ffce48964e
3 changed files with 67 additions and 1 deletions
@@ -56,10 +56,11 @@ step 5.
 7. Choose the Story Risk Level by uncertainty, not size: LOW is pattern following work any dev can do, MEDIUM has some novel modeling or ambiguity, HIGH is a complex subsystem for a lead, CRITICAL is rare and means top devs collaborating. State the level and one sentence of why in the draft.
 8. List dependencies for the apply phase, derived from the Relationships section: the story's own Requires notes cross checked against the epic's story map, expressed as intended Blocks links (blocker first). Note which links already exist in Jira.
 9. Draft the testing rows: Risk Mitigation rows (Risk Summary, Risk Description, Priority, Likelihood, Mitigation Strategy, empty Mitigation Proof) and Test Cases rows (Summary, Steps, Expected Results, empty Working Feature Proof, Notes). Where a mitigation strategy is an automated test, mark it as a proposed subtask with its type, coverage, and estimate. Keep rows to the ones that matter, three to six of each, not padding.
+   A proposed subtask is a promise about what gets tested, so name the behavior the test must demonstrate rather than the file it will live in. The `ticket` skill treats these subtasks as its test first cases in Phase 2, so a vague subtask becomes a vague test.
 10. Assess the LaunchDarkly flag situation for the epic and note it in the draft's handoff section: which flag the epic needs or has, and that creation and the Releases field connection are manual steps.
 11. Run the checks:
    - Path check: extract every repo path mentioned in `review.md` and verify each exists on disk, or is marked (new). Fix or mark every miss.
-    - Punctuation sweep.
+    - Prose sweep: call the Skill tool with "unslop" and apply its pattern detection to `review.md`, meaning puffery, superficial -ing phrases, "not just X but Y", vague attributions, and rule of three padding, alongside the punctuation rules above. Skip its "Adding soul" section, the voice here is the Lead writing to the implementing developer, not a blog. Henry reads every one of these, and a review that reads as machine generated loses its credibility before its content is weighed.
    - Anatomy check against the section list below.
    - Confirm no Jira write has happened.
 12. Stop. Hand the user the draft with the estimate, risk level, dependency list, and any split recommendation surfaced in the summary, and wait for their review. Do not apply in the same run unless the user has already told you to.