skynet/custom-claude-skills
2
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

feat(end-session): wire RCA document write-back into planning-store step

Browse Source 
Adds Step 2.4: when a session root-causes a real incident and the
project's planning store supports an incident type + rca-<date>-<slug>.md
convention, write the postmortem there via cp-cli and link affected
items via impacted/impacted_by. Skips cleanly for projects without
that convention. Adds a scoped cp_cli Bash allowlist entry.
This commit is contained in:
Paul O'Reilly
2026-07-13 12:54:03 +12:00
parent 36aa3d26ee
commit 1b62c256f6
1 changed files with 27 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
skills/end-session/SKILL.md
View File

@@ -4,7 +4,7 @@ description: >
End-of-session wrap-up. Captures a session log, updates CONTEXT.md for seamless
resumption, and refreshes project docs (README, CLAUDE.md, FUTURE.md) with anything
that changed this session. Just run /end-session when you're done working.
allowed-tools: Read, Edit, Write, Grep, Glob, Bash(git log *), Bash(git diff *), Bash(date *), Bash(ls *), Bash(cat *), Bash(find *), Bash(rm *), Bash(mkdir *), Bash(sed *)
allowed-tools: Read, Edit, Write, Grep, Glob, Bash(git log *), Bash(git diff *), Bash(date *), Bash(ls *), Bash(cat *), Bash(find *), Bash(rm *), Bash(mkdir *), Bash(sed *), Bash(python3 -m lib.cp_cli *)
---
# End-of-Session Skill
@@ -169,6 +169,32 @@ stores mislead every future session and agent that treats them as canonical.
Skip this step entirely only when the project has no external planning store.
### Step 2.4: RCA document write-back
If this session root-caused a real incident — a bug, outage, or regression with a clear
symptom, root cause, and fix, not just routine debugging — and the project's planning store
supports an `incident` item type (check the store's `DATA_VALUES.md`/`CLAUDE.md` for an
`incident` type and an `rca-<date>-<slug>.md` naming convention; most projects will not have
this, in which case skip this step entirely):
1. **Find or create the `incident` item.** Search the planning store for an existing
`type: incident` item covering this incident before creating a new one.
2. **Write the full postmortem** as `rca-<date>-<slug>.md`, where `<date>` is the date the
incident *occurred* (not today, if determinable from git history/logs) and `<slug>` is a
short kebab-case description. Cover symptom, root cause, fix, and impact — this is the
durable narrative; the item's `CONTEXT.md` body stays a short summary.
3. **Upload it to the `incident` item**:
- CP reachable: `python3 -m lib.cp_cli planner items documents put <incident-item-uuid> rca-<date>-<slug>.md --file <path>`
- CP unreachable but the store has a local git checkout: write the file directly under
`by-uuid/<incident-item-uuid>/rca-<date>-<slug>.md` there and note in CONTEXT.md that it
needs a commit/push.
- Neither: stage it in the project's offline staging dir (e.g. `local-planning/`) and
record the pending upload in CONTEXT.md.
4. **Link every affected item** to the incident via the `impacted`/`impacted_by`
relationship verb (or whatever the store's `DATA_VALUES.md` names it) — one document on
the `incident` item, one relationship edge per affected item, not copies of the document.
5. If nothing this session rises to postmortem-worthy, skip this step and say so.
---
## Phase 3: Update Project Documentation