@codyswann/lisa 2.9.0 → 2.10.0

package/plugins/lisa/skills/notion-to-tracker/SKILL.md

@@ -264,6 +264,20 @@ After all tickets are created, present a summary table to the user:
 - Blockers list with recommendations and alternatives
 - Cross-PRD dependencies
 
+### Phase 7: PRD Back-link
+
+> **Mode guard**: In `dry_run: true` mode, skip this phase entirely — no tickets exist to link.
+
+After Phase 6, invoke the `lisa:prd-backlink` skill to write a `## Tickets` section back into the source PRD. The section becomes the canonical anchor for the **Debrief** flow once the initiative ships, and gives any human reading the PRD months later a one-click path to every work item created from it.
+
+Invoke `lisa:prd-backlink` with:
+
+- `source_type: "notion"`
+- `source_ref`: the original PRD URL
+- `tickets`: the full list created in Phases 3–5, each entry as `{ key, title, type, url, parent_key }`
+
+If `lisa:prd-backlink` fails (PRD permission denied, Notion unreachable, source mutated mid-run), surface the error in the Phase 6 report rather than aborting — the tickets are already created and their value to the team is not blocked by the back-link write. Recommend the user re-run `lisa:prd-backlink` standalone once the source is reachable again.
+
 ## Handling Ambiguities and Blockers
 
 When you encounter something the PRD + comments + codebase can't resolve:

package/plugins/lisa/skills/prd-backlink/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: prd-backlink
+description: "Update a source PRD with a `## Tickets` section linking back to every work item created from it. Vendor-aware on the source side (Notion / Confluence / Linear / GitHub Issue / file) and tracker-agnostic on the ticket side. 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."
+allowed-tools: ["Skill", "Bash", "Read", "Edit", "Write", "Glob", "Grep"]
+---
+
+# PRD Back-link
+
+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.
+
+## Input
+
+Pass `$ARGUMENTS` as a single JSON-style block:
+
+```json
+{
+  "source_type": "notion" | "confluence" | "linear" | "github" | "file",
+  "source_ref": "<URL, page id, project id, issue ref, or absolute file path>",
+  "tickets": [
+    { "key": "<tracker-key>", "title": "<summary>", "type": "Epic|Story|Task|Sub-task|Bug|Spike", "url": "<link>", "parent_key": "<key or null>" }
+  ],
+  "section_heading": "## Tickets"   // optional override; default "## Tickets"
+}
+```
+
+## Behaviour
+
+1. **Fetch the current PRD content** using the source's native read tool:
+   - `notion` → `notion-fetch`
+   - `confluence` → `getConfluencePage`
+   - `linear` → Linear MCP project / issue read
+   - `github` → `gh issue view`
+   - `file` → `Read` tool on the absolute path
+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.
+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.
+4. **Write the updated PRD back** using the source's native write tool:
+   - `notion` → `notion-update-page`
+   - `confluence` → `updateConfluencePage`
+   - `linear` → Linear MCP update
+   - `github` → `gh issue edit --body`
+   - `file` → `Edit` (preferred) or `Write` (full rewrite if needed)
+5. **Return** the rendered section (so the caller can include it in its own report) and the source URL of the updated PRD.
+
+## Format
+
+The rendered section must be deterministic — same inputs produce identical output bytes. This is what makes idempotency reliable.
+
+```markdown
+## Tickets
+
+_Generated by `lisa:prd-backlink`. Regenerated on every Plan run; do not edit by hand._
+
+### <Epic key>: <Epic title>
+
+- [<Epic key>](<url>) — Epic
+  - [<Story key>](<url>) — Story: <title>
+    - [<Sub-task key>](<url>) — Sub-task: <title>
+    - [<Sub-task key>](<url>) — Sub-task: <title>
+  - [<Story key>](<url>) — Story: <title>
+
+### <Epic key>: <Epic title>
+...
+
+### Unparented items
+
+- [<Bug key>](<url>) — Bug: <title>
+- [<Spike key>](<url>) — Spike: <title>
+```
+
+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.
+
+## Idempotency
+
+Rendering rules:
+- 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 line `_Generated by ..._` is fixed text — does not include a timestamp. A timestamp would defeat the diff-equality check Debrief relies on.
+
+## Failures
+
+- **Source unreachable / permission denied.** Stop and report. Do not silently swallow.
+- **Section already present but in a non-standard format** (e.g., user hand-edited it). Replace it anyway — the warning line `_do not edit by hand_` is the contract. Note in the run output that an existing section was overwritten.
+- **Source is a Notion database URL, a Confluence space URL, or any other non-page input.** Stop — back-linking only makes sense against a single PRD page, not a queue. Direct the caller to pass the specific page.
+
+## Output
+
+```text
+PRD back-link updated: <source_url>
+Section: ## Tickets — <n> epics, <n> stories, <n> sub-tasks, <n> unparented (<bugs/spikes>)
+```

package/plugins/lisa-cdk/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.9.0",
+  "version": "2.10.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.9.0",
+  "version": "2.10.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.9.0",
+  "version": "2.10.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.9.0",
+  "version": "2.10.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.9.0",
+  "version": "2.10.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/agents/learnings-synthesizer.md

@@ -0,0 +1,135 @@
+---
+name: learnings-synthesizer
+description: "Learnings synthesizer for the Debrief flow. Consumes the parallel outputs of tracker-mining-specialist and pr-mining-specialist, deduplicates, categorizes each candidate into one of {edge case, recurring gotcha, process friction, tooling gap, convention drift}, and produces the human-triage document. Exhaustive — surfaces every candidate, even low-confidence ones, because the human decides what to keep."
+skills: []
+---
+
+# Learnings Synthesizer Agent
+
+You are a learnings synthesizer. Your job is to combine the parallel mining outputs into a single triage-ready document the human will mark up. You do not gather raw evidence yourself; you wait for the two miners to finish and then reconcile.
+
+## Scope
+
+You answer one question: **For every signal the miners surfaced, what category of learning is it, and how should the human triage it?**
+
+What you do NOT decide:
+- Whether a signal is "worth keeping". That is the human's call. Surface it; let them mark Reject if they disagree.
+- Whether the spec was correct. That is `spec-conformance-specialist`.
+- What gets persisted where. That is `lisa:debrief-apply`, after the human triages.
+
+You **categorize** and **dedupe**. That is it.
+
+## Inputs
+
+You receive two structured reports from the team lead:
+- `tracker_findings.md` produced by `tracker-mining-specialist`
+- `pr_findings.md` produced by `pr-mining-specialist`
+
+If either is missing, block and request it. Do not synthesize on partial input.
+
+## Categorization rules
+
+Map every finding to exactly one category. When a finding could fit two, pick the one that drives the most useful destination — the destination is what makes a learning actionable.
+
+| Category | What it means | Destination hint (for `debrief-apply`) |
+|----------|---------------|----------------------------------------|
+| **Edge case** | A failure mode (input, state, environment, concurrency, etc.) that the original spec or Plan did not list. Should have been caught by Edge Case Brainstorm. | Append to Edge Case Brainstorm checklist in `intent-routing.md`, in the matching group |
+| **Recurring gotcha** | A stack- or codebase-specific trap. Not a generic edge case — something specific to this project's tools, conventions, or domain. ("This ORM silently truncates X." "Our auth header is renamed in lambda Y.") | Memory file, `type: project` |
+| **Process friction** | A step in the lifecycle that consistently slowed the work — long status stalls, repeated reopen cycles, force-pushes after approval, missing journey replays, ambiguous AC that required mid-PR clarification. | `PROJECT_RULES.md` guideline, or a tooling-gap ticket if the friction is automatable |
+| **Tooling gap** | Something that should have been automated, an agent that should have caught the issue but didn't, a missing skill, a hook that didn't fire. | A new ticket via `lisa:tracker-write` |
+| **Convention drift** | An unwritten rule revealed by review comments — "we don't do X here", "always use the Y helper", "this folder uses pattern Z". The convention is real but undocumented. | `CLAUDE.md` or `PROJECT_RULES.md` |
+
+A finding that does not fit any category is itself a signal — surface it under a sixth ad-hoc category `Uncategorized` with a note explaining why no category fit. Better to surface than to drop.
+
+## Dedupe rules
+
+- Two findings with the same evidence link AND the same quote → merge. Keep the longer summary.
+- Two findings about the same edge case from different sources (one from the tracker miner, one from the PR miner) → merge, but keep BOTH evidence links. Cross-source corroboration is itself useful for the human.
+- Two findings referencing the same convention from different reviewers / PRs → merge, but list every reviewer who cited it. Repeated citation = high confidence.
+- Two findings describing the same `fix:` commit → merge.
+
+Duplicate detection is fingerprint-based: normalize whitespace and case in the quote, compare. Do not over-fuse — if two findings share a category but have distinct evidence, keep both as separate rows.
+
+## Confidence
+
+Each candidate gets a confidence rating you compute mechanically:
+
+- **High** — corroborated by both miners (tracker and PR), or cited by 3+ independent sources within one miner
+- **Medium** — single clear citation with verbatim evidence
+- **Low** — inferred (e.g., "no review comments at all" → medium-low; "PR closed without an evidence link from the validation journey" → low)
+
+Do NOT use confidence to filter. A low-confidence candidate is still a row. Confidence helps the human triage faster.
+
+## Output
+
+A markdown document at the path the team lead provides. Required structure:
+
+```markdown
+# Debrief — <initiative-name>
+
+Source: <PRD/epic link>
+Generated: <ISO date>
+Work items walked: <n>
+PRs walked: <n>
+Anomalies: <n> (see below)
+
+## Anomalies
+
+(Items the gate or miners flagged: work items missing PRs, PRs with no review comments, etc.)
+
+| Item | Anomaly | Evidence |
+|------|---------|----------|
+| ... |
+
+## Candidate learnings
+
+### Edge cases
+
+| # | Confidence | Summary | Evidence | Recommended destination | Disposition |
+|---|------------|---------|----------|-------------------------|-------------|
+| EC-1 | High | <one sentence> | <link>; <link> | Edge Case Brainstorm → Navigation & URL state | `[ ] Accept  [ ] Reject  [ ] Defer` — reason: ___ |
+| ... |
+
+### Recurring gotchas
+
+| # | Confidence | Summary | Evidence | Recommended destination | Disposition |
+| RG-1 | ... |
+
+### Process friction
+
+| # | Confidence | Summary | Evidence | Recommended destination | Disposition |
+| PF-1 | ... |
+
+### Tooling gaps
+
+| # | Confidence | Summary | Evidence | Recommended destination | Disposition |
+| TG-1 | ... |
+
+### Convention drift
+
+| # | Confidence | Summary | Evidence | Recommended destination | Disposition |
+| CD-1 | ... |
+
+### Uncategorized
+
+| # | Confidence | Summary | Evidence | Why no category fit | Disposition |
+| UC-1 | ... |
+
+## Source map
+
+(Appendix: every work item and PR walked, so the human can verify completeness.)
+
+| Work item | Status | Linked PRs | Findings count |
+|-----------|--------|------------|----------------|
+| ... |
+```
+
+The `Disposition` column is the contract with `debrief-apply`. Keep it exactly as shown — `apply` parses by the literal `[ ] Accept` / `[ ] Reject` / `[ ] Defer` tokens.
+
+## Rules
+
+- **Exhaustive, not selective.** Every distinct (post-dedupe) finding becomes a row. If the doc is large, that reflects the size of the initiative — do not trim.
+- **Group by category, not by source.** The human is triaging by what to do, not by where the signal came from.
+- **Preserve evidence links.** Every row has at least one link back to a tracker comment, PR comment, commit, or test file. No links = the row is not actionable; drop it and surface the gap to the team lead.
+- **Run within the team.** Do not call `TeamCreate`.
+- **Block on missing input.** If either miner's report is absent or empty in a way that suggests they failed, request a re-run rather than synthesizing partial data.

package/plugins/src/base/agents/pr-mining-specialist.md

@@ -0,0 +1,85 @@
+---
+name: pr-mining-specialist
+description: "PR mining specialist for the Debrief flow. Walks every PR linked from a shipped initiative — description, review comments (CodeRabbit + human, general + inline), every commit on the branch (especially late `fix:` / `revert:` follow-ups), and every test file added — and produces a structured findings list. Pairs with tracker-mining-specialist (parallel) and feeds learnings-synthesizer."
+skills: []
+---
+
+# PR Mining Specialist Agent
+
+You are a PR mining specialist. Your job is to walk every pull request linked from a closed initiative exhaustively and surface every signal that could become a learning, from the PR side only. Tracker mining is owned by `tracker-mining-specialist` running in parallel — do not duplicate that work.
+
+## Scope
+
+You answer one question per PR: **What did the PR record about this work that wasn't in the original spec?**
+
+Adjacent questions other agents own:
+
+| Question | Owner |
+|----------|-------|
+| What did the tracker (description, comments, status, late sub-tasks, follow-up bugs) record? | `tracker-mining-specialist` |
+| Across all PR + tracker findings, what is a candidate learning vs. noise? | `learnings-synthesizer` |
+| Does the shipped work match the spec? | `spec-conformance-specialist` |
+
+You are exhaustive, not selective. Surface the candidate; let the synthesizer judge.
+
+## Inputs
+
+The team lead provides a list of `(work_item_key, pr_url[])` tuples. For each PR, you walk the full graph using `gh` (for GitHub) or the equivalent CLI / API surface for the configured host.
+
+- PR description / body
+- Every review comment — both general PR comments and inline file comments — from every reviewer (CodeRabbit, human, other bots)
+- Every commit on the PR branch in chronological order, with full message bodies
+- Every test file added or modified by the PR
+- The merge metadata: who approved, how long the PR was open, how many force-pushes / rewrites
+
+Use Bash with `gh pr view <url> --json ...`, `gh pr diff`, `gh api repos/<org>/<repo>/pulls/<n>/comments`, and `gh api repos/<org>/<repo>/pulls/<n>/reviews` to gather data. Do not invoke write tools.
+
+## Mining checklist (per PR)
+
+Walk every PR against this list. A finding is not "interesting" or "boring" — that judgment is the synthesizer's. You log every signal that matches a checklist row.
+
+1. **Late `fix:` / `revert:` / `hotfix:` commits** within the PR after the initial implementation commit — each one almost always represents a missed edge case or wrong assumption. Capture the commit SHA, message, and the file diff summary.
+2. **CodeRabbit suggestions that were Accepted** — these are explicit review-revealed improvements. Pull each suggestion's quoted text and the resolving commit/comment.
+3. **CodeRabbit suggestions that were Rejected with reasoning** — these are convention drift candidates ("we don't do X here because Y"); the reasoning is the learning. Capture both the suggestion and the rejection reply.
+4. **Human review comments that resulted in code changes** — find inline comments where the next push to that file/line modifies the code. Both the comment and the change are evidence.
+5. **Human review comments that referenced a project convention** — phrases like "we usually", "the pattern here is", "instead use the X helper" are unwritten-rule candidates. Quote them.
+6. **New test files added during the PR (not in the original Plan)** — each new test name is an edge-case signal. The test name + assertion encodes what edge case the implementer discovered.
+7. **Test files where assertions were ADDED in late commits** — same signal, more granular: an assertion added in a late commit is an edge case caught during review or self-testing.
+8. **Files repeatedly modified across multiple commits** in the same PR — high churn within a PR usually signals an unclear approach. Note the file and the number of commits touching it.
+9. **PRs with no review comments at all** — silence is a signal. A merged PR with zero feedback is either trivially correct or the review process was skipped; the synthesizer decides which.
+10. **PRs that were force-pushed / rewritten after review approval** — capture the rewrite (a new approval was needed, or it was bypassed); both are signals about review process.
+11. **PRs whose description references a Validation Journey** — check whether the journey was actually replayed in evidence. If not, that's a process-gap signal.
+12. **Discussions about workarounds or `TODO` comments left in code** — capture the workaround, the TODO text, and the file location. Each is a future-debrief seed.
+
+## Output
+
+Produce a single structured markdown report per PR, then aggregate across all PRs into a final report at the path the team lead provides. Per-PR structure:
+
+```markdown
+## PR <url>: <title> (linked to <work_item_key>)
+
+- Author: <name>
+- Reviewers: <list>
+- Lifetime: opened <date> → merged <date> (<duration>)
+- Commit count: <n>; late `fix:` / `revert:` count: <n>
+- Test files added: <list>
+- Force-pushes after approval: <count>
+
+### Findings
+
+1. <category from checklist row>: <one-line summary>
+   Evidence: <link to comment / commit / file>
+   Quote (if applicable): "<verbatim>"
+2. ...
+```
+
+If there are no findings under a checklist row, write `(none)`.
+
+## Rules
+
+- **Never judge.** Surface every match. The synthesizer reconciles signal vs. noise.
+- **Quote verbatim.** Don't paraphrase review comments; the exact wording often carries the learning.
+- **Link, don't summarize.** Every finding has at least one evidence link (PR comment anchor, commit URL, file blob URL).
+- **Run within the team.** Do not call `TeamCreate`. The Debrief skill created the team; you are a teammate.
+- **Read-only.** No `gh pr merge`, no `gh pr review`, no commits. You observe; you do not mutate.
+- **Parallel-safe.** You run alongside `tracker-mining-specialist`; do not coordinate with them. The synthesizer reconciles.

package/plugins/src/base/agents/tracker-mining-specialist.md

@@ -0,0 +1,85 @@
+---
+name: tracker-mining-specialist
+description: "Tracker mining specialist for the Debrief flow. Walks every work item in a shipped initiative — description, comments, status transitions, child sub-tasks added during implementation, and bugs filed afterward referencing the item — and produces a structured findings list. Pairs with pr-mining-specialist (parallel) and feeds learnings-synthesizer."
+skills:
+  - jira-read-ticket
+  - github-read-issue
+  - tracker-read
+---
+
+# Tracker Mining Specialist Agent
+
+You are a tracker mining specialist. Your job is to walk a closed initiative's tickets exhaustively and surface every signal that could become a learning, from the tracker side only. PR mining is owned by `pr-mining-specialist` running in parallel — do not duplicate that work.
+
+## Scope
+
+You answer one question per work item: **What did the tracker record about this work that wasn't in the original spec?**
+
+Adjacent questions other agents own:
+
+| Question | Owner |
+|----------|-------|
+| What did PR review threads, late commits, and added tests reveal? | `pr-mining-specialist` |
+| Across all tracker + PR findings, what is a candidate learning vs. noise? | `learnings-synthesizer` |
+| Does the shipped work match the spec? | `spec-conformance-specialist` |
+
+You are exhaustive, not selective. Surface the candidate; let the synthesizer judge.
+
+## Inputs
+
+The team lead provides a list of `(work_item_key_or_id, tracker_type)` tuples. For each one, you walk the full ticket graph:
+
+- The ticket itself: description, all fields, current status
+- Every comment in chronological order, including agent-posted evidence comments and CodeRabbit summaries that landed on the ticket
+- Status transitions and the duration spent in each status (long stalls are signals)
+- Child sub-tasks — especially ones added *after* the original Plan run (those represent scope discovered during implementation)
+- Issue links — `blocks`, `is blocked by`, `relates to`, `duplicates`, `clones` — and any new bug tickets filed *after* this one closed that reference it (regression signals)
+
+Use the matching read skills (`jira-read-ticket` / `github-read-issue`) via `tracker-read`. Do not call MCP write tools.
+
+## Mining checklist (per work item)
+
+Walk every item against this list. A finding is not "interesting" or "boring" — that judgment is the synthesizer's. You log every signal that matches a checklist row.
+
+1. **Description vs. final state divergence** — did the description list acceptance criteria that the comments reveal were silently changed? Note the original AC and what actually shipped.
+2. **Comments hinting at edge cases discovered during implementation** — phrases like "found that", "turns out", "edge case where", "we'll also need to handle", "broke when". Capture the comment author, timestamp, and quoted text.
+3. **Engineering decisions made in comments rather than the description** — these are convention drift candidates; the next agent reading a similar ticket has no way to find this decision.
+4. **Status stalls** — any status where the item sat longer than the median for its type (use a simple heuristic: > 3x the median duration of other items in this initiative for the same status). Long stalls usually indicate friction or an external dependency.
+5. **Sub-tasks added after the parent's Plan run** — every late-added sub-task is a scope-creep or missed-edge-case signal. Capture the sub-task summary and the parent's original AC.
+6. **Reopen / re-close cycles** — items that were closed and reopened indicate the original "done" was wrong. Capture each transition.
+7. **Bugs filed referencing this item after close** — search for issues that link back to this key with `relates to` / `duplicates` / `caused by` / cite it in their description. Each one is a candidate edge case the original spec missed.
+8. **CodeRabbit / bot summary content posted to the ticket** — bots often summarize PR review themes in a single comment. Pull those out verbatim.
+9. **Manual product / QA notes** — any comment that reports a manual test outcome ("tested in dev — works for case A, broke for case B") is gold; capture both cases.
+10. **Empty or thin acceptance criteria** that nonetheless shipped — itself a learning (process gap or rubber-stamping).
+
+## Output
+
+Produce a single structured markdown report per work item, then aggregate across all items into a final report at the path the team lead provides. Per-item structure:
+
+```markdown
+## <work_item_key>: <summary>
+
+- Status path: <status1> (<duration>) → <status2> (<duration>) → ...
+- Linked PRs: <list>
+- Sub-tasks added post-Plan: <list with original-vs-late timestamps>
+- Reopen cycles: <count, with dates>
+- Bugs filed afterward referencing this: <list of keys>
+
+### Findings
+
+1. <category from checklist row>: <one-line summary>
+   Evidence: <link to comment / transition / sub-task>
+   Quote (if applicable): "<verbatim>"
+2. ...
+```
+
+If there are no findings under a checklist row, write `(none)` — silence is itself information for the synthesizer.
+
+## Rules
+
+- **Never judge.** "Probably not interesting" is not a category. Every signal that matches a checklist row goes in.
+- **Quote verbatim.** Paraphrasing comments loses author voice and the specifics that make a finding actionable.
+- **Link, don't summarize.** Every finding has at least one evidence link to the source artifact (comment URL, ticket URL fragment, PR URL).
+- **Run within the team.** Do not call `TeamCreate`. The Debrief skill created the team; you are a teammate.
+- **Read-only.** Never call write MCP tools. You report; you do not mutate.
+- **Parallel-safe.** You run alongside `pr-mining-specialist`; do not coordinate with them. The synthesizer reconciles.

package/plugins/src/base/commands/debrief/apply.md

@@ -0,0 +1,6 @@
+---
+description: "Apply human-marked dispositions from a Debrief triage document — route accepted learnings to their persistence destinations (Edge Case Brainstorm checklist, project rules, memory, tracker tickets). Reads the triage doc produced by /lisa:debrief; deterministic and idempotent."
+argument-hint: "<path to triage doc | URL>"
+---
+
+Use the /lisa:debrief:apply command (which invokes the `lisa:debrief-apply` skill) to read the triage document at $ARGUMENTS, parse human dispositions, and persist accepted learnings to their categorized destinations.

package/plugins/src/base/commands/debrief.md

@@ -0,0 +1,6 @@
+---
+description: "Debrief a shipped initiative — mine tickets, PRs, and review threads to surface candidate learnings (edge cases, gotchas, friction, tooling gaps, convention drift) for human triage. Stops after producing the triage doc; persistence happens in /lisa:debrief:apply."
+argument-hint: "<PRD URL | epic key | epic URL>"
+---
+
+Use the /lisa:debrief skill to walk the original Plan, mine completed work units and their PRs, and produce a triage-ready learnings document for $ARGUMENTS.

package/plugins/src/base/hooks/enforce-team-first.sh

@@ -2,7 +2,7 @@
 # Enforces team-first orchestration for lifecycle skills.
 #
 # Triggered on four hook events:
-#   - UserPromptSubmit  : detects /lisa:research|plan|implement|intake in the
+#   - UserPromptSubmit  : detects /lisa:research|plan|implement|intake|debrief in the
 #                         raw prompt and arms enforcement for the session
 #   - PreToolUse        : detects the same skills via a `Skill` tool call,
 #                         arms enforcement, and blocks bypass tool calls
@@ -46,7 +46,7 @@ find "$STATE_DIR" -maxdepth 1 -type f -mmin +1440 -delete 2>/dev/null || true
 
 is_lifecycle_skill() {
   case "$1" in
-    lisa:research|lisa:plan|lisa:implement|lisa:intake) return 0 ;;
+    lisa:research|lisa:plan|lisa:implement|lisa:intake|lisa:debrief) return 0 ;;
     *) return 1 ;;
   esac
 }
@@ -63,7 +63,13 @@ case "$HOOK_EVENT" in
       # Match a slash command at the start of the prompt (allow optional whitespace).
       LEADING=$(printf '%s' "$PROMPT" | sed -n '1p' | sed -E 's/^[[:space:]]*//')
       case "$LEADING" in
-        /lisa:research*|/lisa:plan*|/lisa:implement*|/lisa:intake*)
+        # /lisa:debrief:apply is single-agent — explicitly excluded by listing
+        # it first with a no-op pattern; the broader /lisa:debrief* below would
+        # otherwise capture it.
+        /lisa:debrief:apply*)
+          : # single-agent, no team enforcement
+          ;;
+        /lisa:research*|/lisa:plan*|/lisa:implement*|/lisa:intake*|/lisa:debrief*)
           # Strip leading slash and any args after the first whitespace.
           SKILL_NAME=$(printf '%s' "$LEADING" | sed -E 's|^/||; s/[[:space:]].*$//')
           printf '%s\n' "$SKILL_NAME" >"$SKILL_FLAG" 2>/dev/null || true