to-issues: prefer native sub-issues; reference /prototype code explicitly
Two minimal edits to the to-issues skill: - The "What to build" template now points explicitly at the `/prototype` skill's code as the source of an inlined decision snippet, rather than gesturing at "a prototype". - Publishing now prefers the tracker's native sub-issues (parent → slice) and native blocking edges (Blocked by) where supported — mechanics already documented in the issue-tracker doc — keeping the `## Parent` and `## Blocked by` body sections as the fallback. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
66f92b61f5
commit
0172e61e57
2 changed files with 7 additions and 2 deletions
|
|
@ -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.
|
||||
|
||||
<issue-template>
|
||||
## 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
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue