Triage labels and long running feature branches

[dmeehan1968]

I've recently been working on a long running feature branch, with github as my tracker.

As I've been /implementing specs/tickets these commits either get pushed directly to the feature branch, or into their own PR (for Q/A) and then merged into the feature branch later.

The skills seem to leave the ready-for-agent/ready-for-human labels on the ticket and so when I triage or search for new implementable work, they show up yet have already been completed. There doesn't seem to be a triage state that reflects 'done, waiting for merge'. Most of the commits have Closes #N so will finally close when the feature branch merges to main, but as it stands, there's a load of work on the tracker that is technically done but cluttering the board.

As a workaround, I have a landed-on-branch label that I added to the triage-labels.md, so when I consider a feature 'done' I switch out the RFA/RFH label for landed-on-branch. This also means that I can potentially automate that RFA loop without it picking up tasks that are already 'done'.

What's the correct approach here?

TIA

[dgesteves]

There's no built-in state for this. The skills stop at the commit, and a repo-local label like your landed-on-branch is the workaround the triage docs themselves describe. What I'd change is when the ticket closes.

What the skills actually do (v1.3.2):

• /implement ends with "Commit your work to the current branch" (SKILL.md). It never removes ready-for-agent or closes anything, and its docs say to close the ticket yourself (implement docs).
• /triage has five states and no done state. Its docs list "a terminal state for 'implemented, awaiting verification'" as a known gap with nothing shipped, and mention the extra-label workaround, which the skill itself doesn't know about (triage docs).
• What's startable is decided by open/closed, not labels: to-tickets works the tickets "whose blockers are all done" (to-tickets), and the GitHub tracker doc counts open blockers only (tracker doc).
• GitHub ignores Closes #N until the commit reaches the default branch, and a PR into your feature branch doesn't link or close anything (GitHub docs).

So your label keeps the RFA loop clean, but a ticket blocked by a landed one still reads as blocked until the branch hits main. #936 is the same problem inside /implement-spec, still open.

On a long-running branch I'd close each ticket when it lands and let the parent carry "not on main yet":

gh issue close 42 --comment "Landed on feature/foo in abc1234, ships with feature/foo"

Then keep a draft PR from the feature branch to main with Closes #<spec> in its body, the same shape /implement-spec uses (step 3). Open tickets are real work, closed sub-issues under an open spec are done but not shipped, and your Closes #N commits are no-ops when the branch merges.

One more source of clutter: /to-spec puts ready-for-agent on the spec issue too, and its docs suggest removing it once /to-tickets has run (to-spec docs).