Repository navigation
Should to-tickets attach subissues to the parent? #1204
Description
Skill
to-tickets
Harness and version
Cursor. The installed skill text matches skills/engineering/to-tickets/SKILL.md.
Model and effort
Grok 4.7. The context was long: a grilling session, then /to-spec, then /to-tickets.
What happened
/to-tickets published ten child issues for an existing parent. The publish step says to use the platform's native sub-issue relationship, and then says "Do NOT close or modify any parent issue."
The model put Parent: #154 in each child body and set blocking edges between siblings. It did not attach the children as subissues. It read the subissue link as a modification of the parent. I had to ask for it.
What you expected
The children should have been GitHub subissues of the parent on the first publish. "Do not modify the parent" should mean do not edit or close the parent, not skip the subissue relationship the same step asks for.
Is that a wording problem in the skill, or did the model over read a clear instruction?
Activity
nokiy commentedon Oct 7, 2026
Another data point, from Claude Code.
I publish specs as GitHub issues and run
to-ticketson each. Across my recent specs the result was inconsistent. Most got their tickets attached as native sub-issues. The two most recent got none (0 sub-issues), even though every child had a## Parentsection pointing at the spec. GitHub only showed those as "mentioned this issue" in the timeline. Same skill text, same tracker, different outcome. To me that points at the instruction being read two ways, not at a missing capability.#1188 gives the command, which fixes the "how". But on current main,
Do NOT close or modify any parent issue.still sits a few lines below "make each ticket its sub-issue". So the conflict in this issue is still there: attaching a sub-issue does change the parent (it gets a sub-issues list).What I run now against the latest
to-tickets:Stating it positively names the one allowed change, so the model doesn't have to decide whether a sub-issue link counts as a "modification". I backfilled the two specs with
gh issue edit <parent> --add-sub-issue .... No new issues were created, and nothing else on the parent changed.mattpocock commentedon Oct 7, 2026
Agent brief:
skills/engineering/to-tickets/SKILL.mdtells the agent to make each ticket a sub-issue of the source issue, then says "Do NOT close or modify any parent issue." (line 67), and models read the sub-issue link as a forbidden modification. Replace that line with a positive rule: leave the parent's body, labels and state alone; attaching each ticket as its sub-issue is the one expected change. Patch changeset.