diff --git a/.changeset/to-issues-sub-issues-and-prototype.md b/.changeset/to-issues-sub-issues-and-prototype.md new file mode 100644 index 0000000..273605c --- /dev/null +++ b/.changeset/to-issues-sub-issues-and-prototype.md @@ -0,0 +1,5 @@ +--- +"mattpocock-skills": minor +--- + +Sharpen how the **`to-issues`** skill records structure. The "What to build" template now adds a context pointer to where the **`/prototype`** skill's code lives, rather than inlining a snippet from it. And publishing now prefers the tracker's **native sub-issues** for parent → slice and **native blocking edges** for `Blocked by` where the tracker supports them (mechanics already live in the issue-tracker doc), keeping the `## Parent` / `## Blocked by` body sections as the fallback. diff --git a/skills/engineering/to-issues/SKILL.md b/skills/engineering/to-issues/SKILL.md index 333f1ee..4a79f28 100644 --- a/skills/engineering/to-issues/SKILL.md +++ b/skills/engineering/to-issues/SKILL.md @@ -54,7 +54,7 @@ Iterate until the user approves the breakdown. For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. These issues are considered ready for AFK agents, so publish them with the correct triage label unless instructed otherwise. -Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field. +Publish issues in dependency order (blockers first) so you can reference real issue identifiers. Where the tracker supports it, link each slice to its parent as a native **sub-issue** and wire each blocker as a native **blocking edge** (mechanics in the issue-tracker doc); the `## Parent` and `## Blocked by` body sections are the fallback otherwise. ## Parent @@ -65,7 +65,7 @@ A reference to the parent issue on the issue tracker (if the source was an exist A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation. -Avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it here and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits. +Avoid specific file paths or code snippets — they go stale fast. Exception: if the `/prototype` skill produced code that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), add a context pointer to where that prototype code lives rather than inlining it. ## Acceptance criteria