diff --git a/user/agents/skills/create-ticket/SKILL.md b/user/agents/skills/create-ticket/SKILL.md index b378d4e..5b555af 100644 --- a/user/agents/skills/create-ticket/SKILL.md +++ b/user/agents/skills/create-ticket/SKILL.md @@ -61,7 +61,20 @@ Same conventions as the `/ticket` skill: and offer to draft a questionnaire with `/to-questionnaire` so it can go to that person in one pass. If Gib would rather ship the story without waiting, the question becomes a numbered Note naming its owner. + Where the scope of the story itself is unsettled, meaning the epic docs, the + deliverables, and the code do not already say what this ticket covers, one question + is not enough and drafting anyway is how invented scope gets in. Call the Skill tool + with "grilling" and work its frontier with Gib until the scope is agreed, then draft. + This is the exception rather than the default. Most stories have their scope already + worked out in the epic docs, and those go straight to step 4. 4. **Draft the content** in the matching format below, in markdown first. + Then call the Skill tool with "unslop" and apply its pattern detection to the + draft: puffery, superficial -ing phrases, "not just X but Y", vague attributions, + rule of three padding, alongside the punctuation rules above. Skip its "Adding soul" + section entirely. The house formats are rigid templates and an AC table does not + want voice, it wants to read as though a person wrote it plainly. Conrad reads these, + and prose that reads as machine generated costs the ticket its credibility before + anyone weighs what it actually says. 5. **Overwrite guardrail.** If the ticket already has a non-trivial description (anything beyond a placeholder), show what is there and confirm before replacing it. Empty or placeholder tickets are filled without asking. diff --git a/user/agents/skills/review-ticket/SKILL.md b/user/agents/skills/review-ticket/SKILL.md index c2e6f55..1c8c83f 100644 --- a/user/agents/skills/review-ticket/SKILL.md +++ b/user/agents/skills/review-ticket/SKILL.md @@ -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. diff --git a/user/agents/skills/ticket/SKILL.md b/user/agents/skills/ticket/SKILL.md index 12b1284..af1e7f2 100644 --- a/user/agents/skills/ticket/SKILL.md +++ b/user/agents/skills/ticket/SKILL.md @@ -481,6 +481,19 @@ place from the start. reality (codebase, Jira, staging, and prod/CI env with permission) rather than taking the ticket's description at face value — this is what makes the plan trustworthy instead of just plausible-sounding. + + Then classify the ticket before drafting anything, and say the classification out + loud so Gib can override it. Borrowing the `grilling` skill's paths: **bounded** is + a well-scoped change to a flow that already exists in this repo, and + **architectural** is a new subsystem, a schema change other stories depend on, or + anything that alters an interface neighbouring work relies on. Bounded is the common + case and goes straight to step 11. For architectural, call the Skill tool with + "grilling" and resolve its frontier with Gib BEFORE writing `plan.md` — those + questions get answered in conversation, not deferred into the plan's Open questions + section, because an architectural plan built on a wrong assumption is the expensive + one to discover in Phase 2. Bounded measures the repo, not your familiarity: if the + flow being changed isn't already there to read, it isn't bounded. In doubt, take the + heavier path. 11. Write `plan.md` in `/plan.md` (a sibling of `resources/`, not inside it). Structure: ``` @@ -524,6 +537,21 @@ place from the start. column of a ticket test case as part of the case, not as commentary: a note like "confirm the certificate matches the emailed version" is its own thing to prove. + **Where the shape is in question, borrow the vocabulary.** When the plan has to + decide how deep a module should be, where a seam belongs, or what an interface + exposes — not merely which file to edit — call the Skill tool with "codebase-design" + and use its terms in the Approach section. `review-ticket` already does this when it + writes the dev review; this is the same judgment made again, with code about to be + written for real. + + **The Test plan is a design decision, not a formality.** Beyond the cases + `ticket.md` already captured, call the Skill tool with "tdd" to decide which + additional tests are worth writing, where the seam under test goes, and whether a + mock is warranted. That judgment is what keeps this section focused instead of + padded: a test plan listing one case per changed file is slop, and three tests that + can actually fail beat twelve that can't. If the ticket carries automated-test + subtasks from its dev review, name them here as the tests Phase 2 writes first. + **Wide refactors are the exception to one-commit steps.** A wide refactor is a single mechanical change whose blast radius fans across the codebase (renaming a column, retyping a shared symbol), so one edit breaks thousands of call sites at once and no @@ -555,6 +583,16 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved naturally splits into independent units). Commit messages are short and imperative, describing what changed, following House style above. + **Write the test first for steps that carry real logic**, meaning a router + procedure, a derivation, a permission or authorization check, a migration, or a + state machine. For those, call the Skill tool with "tdd" and get a failing test + before the implementation. A step covered by an automated-test subtask from the + ticket's dev review is always one of these, and that subtask names the behavior the + test has to demonstrate. Do NOT do this for UI wiring, a grid column, a copy change, + or a styling fix — a test-first cycle there produces exactly the smoke-test padding + House style rejects. When unsure whether a step qualifies, ask whether the test could + ever fail for a reason worth knowing about. If it couldn't, skip it. + If a step fails in a way `plan.md` didn't predict, and the cause isn't obvious within a couple of minutes, call the Skill tool with "diagnosing-bugs" rather than trying fixes to see what sticks. Note anything it turns up that changes the plan. @@ -703,6 +741,14 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved tight bullet. If it will not compress to a bullet, it is Jira content, not MR content. A reviewer should be able to read the whole file in about a minute; if it has grown past roughly 120 lines including the handoff, it has drifted. + + Before saving, call the Skill tool with "unslop" and apply its pattern detection to + the Summary and Additional Notes ONLY: puffery, superficial -ing phrases, "not just + X but Y", vague attributions, rule-of-three padding. The pasted handoff is generated + output and is never edited, per the rule above. Skip unslop's "Adding soul" section + too — an MR description wants plain and factual, not voice. Henry reads every one of + these, and prose that reads as machine-generated costs the MR its credibility before + anyone looks at the diff. 9. Fill the Jira ticket fields directly, by issue type. Rich text fields are ADF: render markdown with `python3 ~/.agents/skills/review-ticket/scripts/review2adf.py render ` and PUT via `{"fields": {...}}` to `/rest/api/3/issue/`. @@ -711,6 +757,12 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved field-to-type map below is verified against the project's edit screens, don't PUT a field to a type that doesn't carry it. + **Same prose bar as `mr.md`.** Every field authored here is read by the Lead and the + PM. Run the `unslop` skill's pattern detection over the markdown before rendering it + to ADF, skipping its "Adding soul" section — Jira fields want plain, factual, and + specific. This does not apply to proof cells, which are references to artifacts and + test names rather than prose. + **Proof first.** Before filling any proof column, capture working feature proof yourself wherever possible: run the app (`run` skill) and screenshot the real feature with browser automation, or capture test output for behavior with no UI.