@codyswann/lisa 2.43.0 → 2.44.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa/skills/prd-backlink/SKILL.md +33 -14
- package/plugins/lisa/skills/prd-backlink/agents/openai.yaml +2 -2
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/src/base/skills/prd-backlink/SKILL.md +33 -14
package/package.json
CHANGED
|
@@ -82,7 +82,7 @@
|
|
|
82
82
|
"lodash": ">=4.18.1"
|
|
83
83
|
},
|
|
84
84
|
"name": "@codyswann/lisa",
|
|
85
|
-
"version": "2.
|
|
85
|
+
"version": "2.44.0",
|
|
86
86
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
87
87
|
"main": "dist/index.js",
|
|
88
88
|
"exports": {
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: prd-backlink
|
|
3
|
-
description: "Update a source PRD with
|
|
3
|
+
description: "Update a source PRD with an always-written, machine-readable `## Tickets` (alias `## Generated Work`) section linking back to every work item created from it. Each entry carries a parseable ref + URL + type + parent token so the generated child set is readable without scraping prose. Vendor-aware on the source side (Notion / Confluence / Linear / GitHub Issue / file) and tracker-agnostic on the ticket side; the documented section is written for every vendor, additive to native hierarchy linking. Idempotent — regenerates the section on each run rather than appending, so re-planning never accumulates stale links. Invoked by the *-to-tracker skills at the end of their pipeline and standalone if a PRD's Tickets section needs to be refreshed."
|
|
4
4
|
allowed-tools: ["Skill", "Bash", "Read", "Edit", "Write", "Glob", "Grep"]
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -8,6 +8,8 @@ allowed-tools: ["Skill", "Bash", "Read", "Edit", "Write", "Glob", "Grep"]
|
|
|
8
8
|
|
|
9
9
|
Write or update the `## Tickets` section of a source PRD so it links to every work item created from that PRD. The Debrief flow (and a human reading the PRD months later) uses this section as the canonical work-item set for the initiative.
|
|
10
10
|
|
|
11
|
+
This documented section is the **always-written, machine-readable record** of the generated child set. It is written for **every** `source_type` — including the vendors that also get a native hierarchy link (`github` / `linear` / `jira`) — so the generated top-level work is readable later from the PRD body alone, without parsing free-form comments or depending on a native relationship that may be unavailable on older hosts or across vendors. Native hierarchy linking (see the per-vendor sections below) is **additive** to this section, never a substitute for it. This is the documented-section leg of the `prd-lifecycle-rollup` rule (cited by slug; its taxonomy is not restated here).
|
|
12
|
+
|
|
11
13
|
## Input
|
|
12
14
|
|
|
13
15
|
Pass `$ARGUMENTS` as a single JSON-style block:
|
|
@@ -31,8 +33,8 @@ Pass `$ARGUMENTS` as a single JSON-style block:
|
|
|
31
33
|
- `linear` → Linear MCP project / issue read
|
|
32
34
|
- `github` → `gh issue view`
|
|
33
35
|
- `file` → `Read` tool on the absolute path
|
|
34
|
-
2. **Locate the existing section.** Search for `section_heading` (default `## Tickets`). If present, you will replace it. If not, you will append a new section just before any closing footer / sign-off / signature block, otherwise at the end.
|
|
35
|
-
3. **Render the section.** Use the format below. Group by Epic. Within an Epic, group by Story. Sub-tasks nest under their Story. Bugs and Spikes that are not under a Story go in a flat list at the bottom.
|
|
36
|
+
2. **Locate the existing section.** Search for `section_heading` (default `## Tickets`). The canonical heading is `## Tickets`; `## Generated Work` is an accepted alias that the reader recognizes — match either heading when locating an existing section so a PRD authored with either name is found and regenerated in place (never duplicated under the other name). If present under either name, you will replace it (keeping whichever heading was already there, or the explicit `section_heading` override). If not present, you will append a new section just before any closing footer / sign-off / signature block, otherwise at the end.
|
|
37
|
+
3. **Render the section.** Always render it — for every `source_type`, even when a native hierarchy link was also made (additive, not exclusive). Use the format below. Group by Epic. Within an Epic, group by Story. Sub-tasks nest under their Story. Bugs and Spikes that are not under a Story go in a flat list at the bottom. Each entry carries a machine-readable token (ref + URL + type + parent) so the generated child set is parseable without reading prose — see [Format](#format).
|
|
36
38
|
4. **Write the updated PRD back** using the source's native write tool:
|
|
37
39
|
- `notion` → `notion-update-page`
|
|
38
40
|
- `confluence` → `updateConfluencePage`
|
|
@@ -49,7 +51,7 @@ Pass `$ARGUMENTS` as a single JSON-style block:
|
|
|
49
51
|
|
|
50
52
|
## Format
|
|
51
53
|
|
|
52
|
-
The rendered section must be deterministic — same inputs produce identical output bytes. This is what makes idempotency reliable.
|
|
54
|
+
The rendered section must be deterministic — same inputs produce identical output bytes. This is what makes idempotency reliable. Every entry is simultaneously **human-readable** (a nested markdown link) and **machine-readable** (a trailing structured token), so the generated child set can be enumerated by parsing this section alone — the contract LPC-1.3 rollup (`github-prd-intake` / `*-prd-intake`) reads against, with no need to scrape free-form comments.
|
|
53
55
|
|
|
54
56
|
```markdown
|
|
55
57
|
## Tickets
|
|
@@ -58,28 +60,45 @@ _Generated by `lisa:prd-backlink`. Regenerated on every Plan run; do not edit by
|
|
|
58
60
|
|
|
59
61
|
### <Epic key>: <Epic title>
|
|
60
62
|
|
|
61
|
-
- [<Epic key>](<url>) — Epic
|
|
62
|
-
- [<Story key>](<url>) — Story: <title>
|
|
63
|
-
- [<Sub-task key>](<url>) — Sub-task: <title>
|
|
64
|
-
- [<Sub-task key>](<url>) — Sub-task: <title>
|
|
65
|
-
- [<Story key>](<url>) — Story: <title>
|
|
63
|
+
- [<Epic key>](<url>) — Epic <!-- lisa:gw ref=<ref> url=<url> type=Epic parent= -->
|
|
64
|
+
- [<Story key>](<url>) — Story: <title> <!-- lisa:gw ref=<ref> url=<url> type=Story parent=<Epic ref> -->
|
|
65
|
+
- [<Sub-task key>](<url>) — Sub-task: <title> <!-- lisa:gw ref=<ref> url=<url> type=Sub-task parent=<Story ref> -->
|
|
66
|
+
- [<Sub-task key>](<url>) — Sub-task: <title> <!-- lisa:gw ref=<ref> url=<url> type=Sub-task parent=<Story ref> -->
|
|
67
|
+
- [<Story key>](<url>) — Story: <title> <!-- lisa:gw ref=<ref> url=<url> type=Story parent=<Epic ref> -->
|
|
66
68
|
|
|
67
69
|
### <Epic key>: <Epic title>
|
|
68
70
|
...
|
|
69
71
|
|
|
70
72
|
### Unparented items
|
|
71
73
|
|
|
72
|
-
- [<Bug key>](<url>) — Bug: <title>
|
|
73
|
-
- [<Spike key>](<url>) — Spike: <title>
|
|
74
|
+
- [<Bug key>](<url>) — Bug: <title> <!-- lisa:gw ref=<ref> url=<url> type=Bug parent= -->
|
|
75
|
+
- [<Spike key>](<url>) — Spike: <title> <!-- lisa:gw ref=<ref> url=<url> type=Spike parent= -->
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### Machine-readable entry token
|
|
79
|
+
|
|
80
|
+
Every list entry ends with a single-line HTML comment — invisible in rendered markdown, so the section stays clean for humans, but a stable, greppable record for machines:
|
|
81
|
+
|
|
82
|
+
```text
|
|
83
|
+
<!-- lisa:gw ref=<ref> url=<url> type=<type> parent=<parent-ref or empty> -->
|
|
74
84
|
```
|
|
75
85
|
|
|
76
|
-
|
|
86
|
+
- **`lisa:gw`** — a fixed sentinel (`gw` = generated work). A reader enumerates the generated child set by matching `<!-- lisa:gw ` lines; it never has to parse the surrounding prose, headings, or indentation.
|
|
87
|
+
- **`ref`** — the child-ref identity from the `prd-lifecycle-rollup` rule: `<org>/<repo>#<n>` for GitHub, the issue/project identifier (e.g. `TEAM-123`) for Linear, the issue key (e.g. `PROJ-123`) for JIRA. This is the same dedupe key native linking uses, so the documented record and the native record agree.
|
|
88
|
+
- **`url`** — the canonical URL of the work item.
|
|
89
|
+
- **`type`** — `Epic | Story | Task | Sub-task | Bug | Spike` (verbatim from the ticket's `type`).
|
|
90
|
+
- **`parent`** — the **`ref`** of this entry's parent (its `parent_key` resolved to the parent's ref), or **empty** when the entry is top-level (`parent_key` null/empty). A reader selects the **generated top-level child set** — exactly what the PRD owns per the rule — as every `lisa:gw` line whose `parent` is empty.
|
|
91
|
+
|
|
92
|
+
The visible markdown link and the token always carry the same `ref`/`url`/`type`; the token is the authoritative machine field (the prose may wrap or be reflowed by a host editor, the comment line will not). Field order within the token is fixed (`ref`, `url`, `type`, `parent`) so output is byte-stable.
|
|
93
|
+
|
|
94
|
+
If the input contains zero items, write the section header with a single line: `_No tickets created — Plan flow may not have completed._` Do not omit the section; presence-of-section is itself a signal to Debrief, and the always-written guarantee means a reader can always distinguish "ran, produced nothing" from "never ran."
|
|
77
95
|
|
|
78
96
|
## Idempotency
|
|
79
97
|
|
|
80
98
|
Rendering rules:
|
|
81
|
-
- Sort epics by key (lexical). Sort stories within an epic by key. Sort sub-tasks within a story by key. Sort the unparented list by `(type, key)`.
|
|
99
|
+
- Sort epics by key (lexical). Sort stories within an epic by key. Sort sub-tasks within a story by key. Sort the unparented list by `(type, key)`. The same sort applies to the `lisa:gw` tokens (each token sits on its entry's line), so the machine-readable order is identical across runs.
|
|
82
100
|
- The line `_Generated by ..._` is fixed text — does not include a timestamp. A timestamp would defeat the diff-equality check Debrief relies on.
|
|
101
|
+
- Regenerate the whole section from the current ticket set on every run — **never append**. Dedupe is by **child-ref** (the token's `ref`, per the `prd-lifecycle-rollup` idempotency dedupe key): the same ticket set produces a byte-identical section with no duplicate entries, and re-running over an existing section is a no-op diff. A ticket present in a prior run but absent now simply does not reappear (stale links never accumulate).
|
|
83
102
|
|
|
84
103
|
## Native parent linking (GitHub)
|
|
85
104
|
|
|
@@ -242,4 +261,4 @@ Omit the `Native parent links` line when no native linking applies (Notion / Con
|
|
|
242
261
|
|
|
243
262
|
## Related rules
|
|
244
263
|
|
|
245
|
-
- `prd-lifecycle-rollup` — the vendor-neutral source of truth for PRD→generated-top-level-work ownership, the per-vendor terminal predicate, PRD `shipped` rollup, and the child-ref idempotency dedupe key. This skill implements the GitHub, Linear, and JIRA native-linking legs of that rule; it cites the rule by slug rather than restating its taxonomy.
|
|
264
|
+
- `prd-lifecycle-rollup` — the vendor-neutral source of truth for PRD→generated-top-level-work ownership, the per-vendor terminal predicate, PRD `shipped` rollup, and the child-ref idempotency dedupe key. This skill implements both the **documented always-written, machine-readable generated-work section** leg (the universal fallback written for every vendor) and the GitHub, Linear, and JIRA native-linking legs of that rule; it cites the rule by slug rather than restating its taxonomy.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
1
|
display_name: "PRD Backlink"
|
|
2
|
-
short_description: "Update a source PRD with
|
|
2
|
+
short_description: "Update a source PRD with an always-written, machine-readable `## Tickets` (alias `## Generated Work`) section linking back to every work…"
|
|
3
3
|
default_prompt:
|
|
4
|
-
- "Use $prd-backlink: Update a source PRD with
|
|
4
|
+
- "Use $prd-backlink: Update a source PRD with an always-written, machine-readable `## Tickets` (alias `## Generated Work`) section linking back to every work…."
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.44.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.44.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: prd-backlink
|
|
3
|
-
description: "Update a source PRD with
|
|
3
|
+
description: "Update a source PRD with an always-written, machine-readable `## Tickets` (alias `## Generated Work`) section linking back to every work item created from it. Each entry carries a parseable ref + URL + type + parent token so the generated child set is readable without scraping prose. Vendor-aware on the source side (Notion / Confluence / Linear / GitHub Issue / file) and tracker-agnostic on the ticket side; the documented section is written for every vendor, additive to native hierarchy linking. Idempotent — regenerates the section on each run rather than appending, so re-planning never accumulates stale links. Invoked by the *-to-tracker skills at the end of their pipeline and standalone if a PRD's Tickets section needs to be refreshed."
|
|
4
4
|
allowed-tools: ["Skill", "Bash", "Read", "Edit", "Write", "Glob", "Grep"]
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -8,6 +8,8 @@ allowed-tools: ["Skill", "Bash", "Read", "Edit", "Write", "Glob", "Grep"]
|
|
|
8
8
|
|
|
9
9
|
Write or update the `## Tickets` section of a source PRD so it links to every work item created from that PRD. The Debrief flow (and a human reading the PRD months later) uses this section as the canonical work-item set for the initiative.
|
|
10
10
|
|
|
11
|
+
This documented section is the **always-written, machine-readable record** of the generated child set. It is written for **every** `source_type` — including the vendors that also get a native hierarchy link (`github` / `linear` / `jira`) — so the generated top-level work is readable later from the PRD body alone, without parsing free-form comments or depending on a native relationship that may be unavailable on older hosts or across vendors. Native hierarchy linking (see the per-vendor sections below) is **additive** to this section, never a substitute for it. This is the documented-section leg of the `prd-lifecycle-rollup` rule (cited by slug; its taxonomy is not restated here).
|
|
12
|
+
|
|
11
13
|
## Input
|
|
12
14
|
|
|
13
15
|
Pass `$ARGUMENTS` as a single JSON-style block:
|
|
@@ -31,8 +33,8 @@ Pass `$ARGUMENTS` as a single JSON-style block:
|
|
|
31
33
|
- `linear` → Linear MCP project / issue read
|
|
32
34
|
- `github` → `gh issue view`
|
|
33
35
|
- `file` → `Read` tool on the absolute path
|
|
34
|
-
2. **Locate the existing section.** Search for `section_heading` (default `## Tickets`). If present, you will replace it. If not, you will append a new section just before any closing footer / sign-off / signature block, otherwise at the end.
|
|
35
|
-
3. **Render the section.** Use the format below. Group by Epic. Within an Epic, group by Story. Sub-tasks nest under their Story. Bugs and Spikes that are not under a Story go in a flat list at the bottom.
|
|
36
|
+
2. **Locate the existing section.** Search for `section_heading` (default `## Tickets`). The canonical heading is `## Tickets`; `## Generated Work` is an accepted alias that the reader recognizes — match either heading when locating an existing section so a PRD authored with either name is found and regenerated in place (never duplicated under the other name). If present under either name, you will replace it (keeping whichever heading was already there, or the explicit `section_heading` override). If not present, you will append a new section just before any closing footer / sign-off / signature block, otherwise at the end.
|
|
37
|
+
3. **Render the section.** Always render it — for every `source_type`, even when a native hierarchy link was also made (additive, not exclusive). Use the format below. Group by Epic. Within an Epic, group by Story. Sub-tasks nest under their Story. Bugs and Spikes that are not under a Story go in a flat list at the bottom. Each entry carries a machine-readable token (ref + URL + type + parent) so the generated child set is parseable without reading prose — see [Format](#format).
|
|
36
38
|
4. **Write the updated PRD back** using the source's native write tool:
|
|
37
39
|
- `notion` → `notion-update-page`
|
|
38
40
|
- `confluence` → `updateConfluencePage`
|
|
@@ -49,7 +51,7 @@ Pass `$ARGUMENTS` as a single JSON-style block:
|
|
|
49
51
|
|
|
50
52
|
## Format
|
|
51
53
|
|
|
52
|
-
The rendered section must be deterministic — same inputs produce identical output bytes. This is what makes idempotency reliable.
|
|
54
|
+
The rendered section must be deterministic — same inputs produce identical output bytes. This is what makes idempotency reliable. Every entry is simultaneously **human-readable** (a nested markdown link) and **machine-readable** (a trailing structured token), so the generated child set can be enumerated by parsing this section alone — the contract LPC-1.3 rollup (`github-prd-intake` / `*-prd-intake`) reads against, with no need to scrape free-form comments.
|
|
53
55
|
|
|
54
56
|
```markdown
|
|
55
57
|
## Tickets
|
|
@@ -58,28 +60,45 @@ _Generated by `lisa:prd-backlink`. Regenerated on every Plan run; do not edit by
|
|
|
58
60
|
|
|
59
61
|
### <Epic key>: <Epic title>
|
|
60
62
|
|
|
61
|
-
- [<Epic key>](<url>) — Epic
|
|
62
|
-
- [<Story key>](<url>) — Story: <title>
|
|
63
|
-
- [<Sub-task key>](<url>) — Sub-task: <title>
|
|
64
|
-
- [<Sub-task key>](<url>) — Sub-task: <title>
|
|
65
|
-
- [<Story key>](<url>) — Story: <title>
|
|
63
|
+
- [<Epic key>](<url>) — Epic <!-- lisa:gw ref=<ref> url=<url> type=Epic parent= -->
|
|
64
|
+
- [<Story key>](<url>) — Story: <title> <!-- lisa:gw ref=<ref> url=<url> type=Story parent=<Epic ref> -->
|
|
65
|
+
- [<Sub-task key>](<url>) — Sub-task: <title> <!-- lisa:gw ref=<ref> url=<url> type=Sub-task parent=<Story ref> -->
|
|
66
|
+
- [<Sub-task key>](<url>) — Sub-task: <title> <!-- lisa:gw ref=<ref> url=<url> type=Sub-task parent=<Story ref> -->
|
|
67
|
+
- [<Story key>](<url>) — Story: <title> <!-- lisa:gw ref=<ref> url=<url> type=Story parent=<Epic ref> -->
|
|
66
68
|
|
|
67
69
|
### <Epic key>: <Epic title>
|
|
68
70
|
...
|
|
69
71
|
|
|
70
72
|
### Unparented items
|
|
71
73
|
|
|
72
|
-
- [<Bug key>](<url>) — Bug: <title>
|
|
73
|
-
- [<Spike key>](<url>) — Spike: <title>
|
|
74
|
+
- [<Bug key>](<url>) — Bug: <title> <!-- lisa:gw ref=<ref> url=<url> type=Bug parent= -->
|
|
75
|
+
- [<Spike key>](<url>) — Spike: <title> <!-- lisa:gw ref=<ref> url=<url> type=Spike parent= -->
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### Machine-readable entry token
|
|
79
|
+
|
|
80
|
+
Every list entry ends with a single-line HTML comment — invisible in rendered markdown, so the section stays clean for humans, but a stable, greppable record for machines:
|
|
81
|
+
|
|
82
|
+
```text
|
|
83
|
+
<!-- lisa:gw ref=<ref> url=<url> type=<type> parent=<parent-ref or empty> -->
|
|
74
84
|
```
|
|
75
85
|
|
|
76
|
-
|
|
86
|
+
- **`lisa:gw`** — a fixed sentinel (`gw` = generated work). A reader enumerates the generated child set by matching `<!-- lisa:gw ` lines; it never has to parse the surrounding prose, headings, or indentation.
|
|
87
|
+
- **`ref`** — the child-ref identity from the `prd-lifecycle-rollup` rule: `<org>/<repo>#<n>` for GitHub, the issue/project identifier (e.g. `TEAM-123`) for Linear, the issue key (e.g. `PROJ-123`) for JIRA. This is the same dedupe key native linking uses, so the documented record and the native record agree.
|
|
88
|
+
- **`url`** — the canonical URL of the work item.
|
|
89
|
+
- **`type`** — `Epic | Story | Task | Sub-task | Bug | Spike` (verbatim from the ticket's `type`).
|
|
90
|
+
- **`parent`** — the **`ref`** of this entry's parent (its `parent_key` resolved to the parent's ref), or **empty** when the entry is top-level (`parent_key` null/empty). A reader selects the **generated top-level child set** — exactly what the PRD owns per the rule — as every `lisa:gw` line whose `parent` is empty.
|
|
91
|
+
|
|
92
|
+
The visible markdown link and the token always carry the same `ref`/`url`/`type`; the token is the authoritative machine field (the prose may wrap or be reflowed by a host editor, the comment line will not). Field order within the token is fixed (`ref`, `url`, `type`, `parent`) so output is byte-stable.
|
|
93
|
+
|
|
94
|
+
If the input contains zero items, write the section header with a single line: `_No tickets created — Plan flow may not have completed._` Do not omit the section; presence-of-section is itself a signal to Debrief, and the always-written guarantee means a reader can always distinguish "ran, produced nothing" from "never ran."
|
|
77
95
|
|
|
78
96
|
## Idempotency
|
|
79
97
|
|
|
80
98
|
Rendering rules:
|
|
81
|
-
- Sort epics by key (lexical). Sort stories within an epic by key. Sort sub-tasks within a story by key. Sort the unparented list by `(type, key)`.
|
|
99
|
+
- Sort epics by key (lexical). Sort stories within an epic by key. Sort sub-tasks within a story by key. Sort the unparented list by `(type, key)`. The same sort applies to the `lisa:gw` tokens (each token sits on its entry's line), so the machine-readable order is identical across runs.
|
|
82
100
|
- The line `_Generated by ..._` is fixed text — does not include a timestamp. A timestamp would defeat the diff-equality check Debrief relies on.
|
|
101
|
+
- Regenerate the whole section from the current ticket set on every run — **never append**. Dedupe is by **child-ref** (the token's `ref`, per the `prd-lifecycle-rollup` idempotency dedupe key): the same ticket set produces a byte-identical section with no duplicate entries, and re-running over an existing section is a no-op diff. A ticket present in a prior run but absent now simply does not reappear (stale links never accumulate).
|
|
83
102
|
|
|
84
103
|
## Native parent linking (GitHub)
|
|
85
104
|
|
|
@@ -242,4 +261,4 @@ Omit the `Native parent links` line when no native linking applies (Notion / Con
|
|
|
242
261
|
|
|
243
262
|
## Related rules
|
|
244
263
|
|
|
245
|
-
- `prd-lifecycle-rollup` — the vendor-neutral source of truth for PRD→generated-top-level-work ownership, the per-vendor terminal predicate, PRD `shipped` rollup, and the child-ref idempotency dedupe key. This skill implements the GitHub, Linear, and JIRA native-linking legs of that rule; it cites the rule by slug rather than restating its taxonomy.
|
|
264
|
+
- `prd-lifecycle-rollup` — the vendor-neutral source of truth for PRD→generated-top-level-work ownership, the per-vendor terminal predicate, PRD `shipped` rollup, and the child-ref idempotency dedupe key. This skill implements both the **documented always-written, machine-readable generated-work section** leg (the universal fallback written for every vendor) and the GitHub, Linear, and JIRA native-linking legs of that rule; it cites the rule by slug rather than restating its taxonomy.
|