Baonguyen/sprint refinement - #21
Conversation
4bf910e to
62900a6
Compare
|
@jeffhorn-nava looking for your feedback with regards to having a sprint refinement skill. Here is the original issue: Issue 15 Refined issued: Issue 22 A couple of thoughts on my end. I thought that the Sprint refinement skill brought up some pretty good points, and I liked it overall. It just needs some refinements. I was, however, looking at Joe's Rebar project. Specifically, I looked at a presentation that he did and the changes that he made for Rebar over DSO. One thought that came up is that he had skills with these processes in DSO, and it did not work out in the way that he liked. With Rebar, he used Python to help make the skill more deterministic. Originally, I suggested that maybe, with these skills, they aren't complicated enough to require a more deterministic workflow. However, with thinking about Joe's changes in the way that he has built projects, I am thinking that maybe any time that you acquire a process that has a multi-agent skill, it may be advisable to make it more deterministic in order to maintain the quality gates that we are looking for. That said, I would be totally okay with keeping this as a skill only and moving it to a more deterministic process if we find it lacking after many uses. Note: it's a lot easier to compare both issues if you open them in a split view within Chrome. |
62900a6 to
7689f2a
Compare
jeffhorn-nava
left a comment
jeffhorn-nava
left a comment
There was a problem hiding this comment.
I like this quite a lot! One suggested change, because I ought to have caught it myself when I committed it: there's no need to keep a count of the rules.
I think it's ready to go. Based on #22 you can make further refinements here or do them on new PRs, either way. My comments over there are mostly about the refinement comment trail. Maybe comments should be reviewed like commit message drafts, PR drafts, and issue drafts by the review-draft skill?
| ## Architecture and CI | ||
|
|
||
| Deep reference lives in two rule files under `rules/` at the repo root. Claude Code auto-loads each | ||
| Deep reference lives in three rule files under `rules/` at the repo root. Claude Code auto-loads each |
There was a problem hiding this comment.
| Deep reference lives in three rule files under `rules/` at the repo root. Claude Code auto-loads each | |
| Deep reference lives in rule files under `rules/` at the repo root. Claude Code auto-loads each |
I'm ok with keeping it a skill for now. It might be good for us to lightly retread some of Joe's ground. |
| wording it for its audience, reviewing it, labeling it, and filing it. Every template opens with | ||
| an "Issue readiness state" checklist that tracks the issue's lifecycle: reviewed by a human | ||
| engineer, refinement complete, all open questions answered, post-refinement changes reviewed by | ||
| a human, and ready for work. Tick the boxes as the issue advances; the `refine-issue` skill |
There was a problem hiding this comment.
Nice to see refine-issue wired into the lifecycle here. One gap: it's named in CONTRIBUTING.md but not in AGENTS.md, where create-issue, create-pr, and review-draft each get a mention (the Issue templates and Workflow sections). Worth adding a one-line pointer there too so the skill is discoverable from the agent guide, per the doc-maintenance table's "CONTRIBUTING.md and Workflow above."
| In practice: `review-draft` keeps its parallel reviewers on a cheap tier and its adjudication on | ||
| Opus; `refine-issue` runs its debate, review, and adjudication roles on Opus and its planner on |
There was a problem hiding this comment.
This pins review-draft's adjudication to "Opus," but review-draft/SKILL.md deliberately says "a more capable model" and never names a specific one. Full disclosure: I kept review-draft's wording generic on purpose, but I never talked that through with you, so it isn't a settled convention. A decision either way is genuinely useful: make this rule generic to match review-draft ("adjudication on a more capable tier"), or update review-draft to name Opus so the two agree. As written, they drift. No strong preference from me, let's just pick one.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Route the Reviewer's human-comment conflicts through the Adjudicator and the approval gate so none are collected then dropped, per the never-silently-drop invariant. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
e2a34cb to
5645758
Compare
2 participants
What
Adds the
refine-issueskill: pressure-tests an existing GitHub issue for sprint readinessvia an adjudicated product-owner-vs-senior-engineer debate, reconciling human comments before
any change is written back.
Relates to #15, #29
How
See
skills/refine-issue/SKILL.mdfor the full flow: debate → reconcile comments → adjudicateevery proposed change → update the issue via
ghonly after human approval. Also includessupporting updates to issue templates,
AGENTS.md,CONTRIBUTING.md, and a newrules/subagent-model-tiers.md.Test plan
refine-issueagainst issue Spike: feasibility of a Spring Boot Java SDK mirroring the Strata SDK #15 ("Spike: feasibility of a Spring Boot Java SDKmirroring the Strata SDK"). The refined output was filed as issue Spike: feasibility of a Spring Boot Java SDK mirroring the Strata SDK #29 (same title) rather
than overwritten in place, so the two issues can be compared directly.
process slice with explicit form-builder tie-in), added acceleration-delta and go/no-go
criteria, pinned reproducibility requirements, and resolved/re-scoped open questions.
Notes for reviewers
Compare #15 and #29 directly to see what the skill changed and why; that diff is the intended
review artifact for this PR, in addition to the skill code itself.