Add minimax media skills and ABOUT.md; end-session/reflect updates; MiniMax-M3.1-Flash note in minimax-mesh
Includes the minimax-mesh switch to M3.1-Flash-Preview at effort low, README/reflection-state refresh, and removal of two old session logs.
This commit is contained in:
Paul O'Reilly
@@ -1,9 +1,11 @@
|
||||
---
|
||||
name: end-session
|
||||
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.
|
||||
End-of-session wrap-up. Captures a session log; for planner-backed projects writes
|
||||
a session status doc to the work-items store (the authoritative state source);
|
||||
updates CONTEXT.md as a thin cache for planner projects or fully for non-planner
|
||||
projects; 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 *), Bash(python3 -m lib.cp_cli *)
|
||||
---
|
||||
|
||||
@@ -111,11 +113,57 @@ Write the file using this format:
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Update CONTEXT.md
|
||||
## Phase 2: Update state — planning store (primary) or CONTEXT.md (fallback)
|
||||
|
||||
This is the most important phase for session resumption. CONTEXT.md tells the next session what to focus on.
|
||||
**Detect whether the project has a planner:** look for `cp-cli planner` in the project's
|
||||
CLAUDE.md. If found, the project has a live planner and Step 2.1 applies. Otherwise go
|
||||
to Step 2.2 (CONTEXT.md-only flow).
|
||||
|
||||
### Step 2.1: Assess current state
|
||||
> **Long-term goal:** for planner-backed projects, CONTEXT.md is being retired in favour
|
||||
> of `scripts/get_context` as the authoritative live state source. Until it is removed,
|
||||
> keep the CONTEXT.md "Current State" header updated as a thin cache — one line per major
|
||||
> change — but do NOT write new narrative detail there. All narrative goes to work-items.
|
||||
|
||||
### Step 2.1: Planning-store write-back (projects WITH a planner)
|
||||
|
||||
The session is **not finished until delivered work is written back to the planner**.
|
||||
`scripts/get_context` is what future sessions and agents see — stale items mislead them.
|
||||
|
||||
1. **Assess what this session delivered or advanced**: milestones progressed/completed,
|
||||
bugs fixed, features shipped, specs updated, pipelines deployed.
|
||||
|
||||
2. **Write a session status document** (`session-YYYY-MM-DD-<slug>.md`) capturing:
|
||||
- What was done and the key commits
|
||||
- Root causes / decisions / gotchas discovered
|
||||
- Current cluster/deployment state (image version, what's live)
|
||||
- What's next
|
||||
|
||||
Write to `/tmp/<name>.md`, then upload to the most relevant item(s) with:
|
||||
```bash
|
||||
python3 -m lib.cp_cli planner items documents put <item-uuid> <name>.md --file /tmp/<name>.md
|
||||
```
|
||||
Upload to whichever item(s) the work actually belongs to (milestone, epic, bug, etc.).
|
||||
If the work spans multiple items, one doc is enough — upload it to the primary one.
|
||||
|
||||
3. **Update item flow states** for anything that completed this session:
|
||||
- `python3 -m lib.cp_cli planner items update <uuid> --flow-state completed`
|
||||
- If the planner doesn't support direct state updates, note it in the doc and skip.
|
||||
|
||||
4. **Check roll-up documents for contradictions**: any epic overview or delivery map that
|
||||
summarises affected milestones must not contradict reality after this session's changes.
|
||||
Fix what you have ground truth for; flag the rest.
|
||||
|
||||
5. **Update CONTEXT.md as a thin cache only** — find the "Current State" section and
|
||||
update just the cluster image version and a one-liner about what changed. Do NOT add
|
||||
new narrative sections. Resist the urge to expand CONTEXT.md; that information belongs
|
||||
in work-items. If CONTEXT.md doesn't exist yet, do not create it.
|
||||
|
||||
6. If nothing this session touched milestone/epic-level state, still write a brief
|
||||
session doc to the most relevant item so `scripts/get_context --show-rca` captures it.
|
||||
|
||||
### Step 2.2: CONTEXT.md update (projects WITHOUT a planner)
|
||||
|
||||
For projects with no planner, CONTEXT.md is still the primary handoff mechanism.
|
||||
|
||||
Based on the full conversation, determine:
|
||||
- What work is actively in progress (not yet complete)?
|
||||
@@ -123,51 +171,52 @@ Based on the full conversation, determine:
|
||||
- What should the next session pick up first?
|
||||
- Are there blockers, pending decisions, or things to verify?
|
||||
|
||||
### Step 2.2: Update CONTEXT.md and context/ files
|
||||
|
||||
Follow the thin-index pattern:
|
||||
|
||||
1. **Remove completed entries** from CONTEXT.md that are no longer active.
|
||||
2. **Add or update entries** for active work streams, linking to detail files in `context/`.
|
||||
3. **Create or update `context/<topic>.md`** files with enough detail for a fresh session to resume without re-reading the full conversation:
|
||||
3. **Create or update `context/<topic>.md`** files with enough detail for a fresh session to
|
||||
resume without re-reading the full conversation:
|
||||
- What's the current state?
|
||||
- What was the last thing done?
|
||||
- What should be done next?
|
||||
- Any gotchas, blockers, or decisions pending?
|
||||
- Key file paths, commands, or references needed to continue.
|
||||
|
||||
4. If `context/` directory doesn't exist and there are active work streams, create it with `mkdir -p context/`.
|
||||
4. If `context/` directory doesn't exist and there are active work streams, create it.
|
||||
|
||||
**Principles:**
|
||||
- Write for a Claude session that has zero conversation history -- it only has CONTEXT.md and the linked files.
|
||||
- Write for a Claude session with zero conversation history.
|
||||
- Be specific: file paths, branch names, error messages, command sequences.
|
||||
- Don't duplicate what's in CLAUDE.md or MEMORY.md -- reference those instead.
|
||||
- If there's nothing active (session wrapped up cleanly with no follow-up), say so in CONTEXT.md: `No active work streams. Project is at a clean stopping point.`
|
||||
- Don't duplicate what's in CLAUDE.md or MEMORY.md — reference those instead.
|
||||
- If there's nothing active: `No active work streams. Project is at a clean stopping point.`
|
||||
|
||||
### Step 2.3: Planning-store status write-back
|
||||
### Step 2.3: RCA document write-back
|
||||
|
||||
If the project's CLAUDE.md declares a canonical planning store outside the repo (e.g. a
|
||||
work-items repo managed via `cp-cli planner items …`, like `agent-runtimes-work-items`),
|
||||
the session is **not finished until delivered work is written back to it**. Stale planning
|
||||
stores mislead every future session and agent that treats them as canonical.
|
||||
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. **List what this session delivered or advanced**: milestones completed or progressed,
|
||||
epics affected, specs shipped, pipelines deployed.
|
||||
2. **For each affected item**, update its status in the planning store:
|
||||
- CP reachable: update the item's flow state / status document via
|
||||
`cp-cli planner items …` / `documents put` (see the project CLAUDE.md for the exact
|
||||
workflow).
|
||||
- CP unreachable but the store has a local git checkout: edit the status/plan/CONTEXT
|
||||
docs there directly and note in CONTEXT.md that the edit needs upload/push.
|
||||
- Neither: stage the update in the project's offline staging dir (e.g.
|
||||
`local-planning/<item-uuid>/`) and record the pending upload in CONTEXT.md.
|
||||
3. **Check roll-up documents for contradictions**: any epic overview, delivery map, or
|
||||
roadmap doc that summarises the affected milestones must not now contradict reality
|
||||
(e.g. still saying "pending" for work that shipped this session). Fix the rows you have
|
||||
ground truth for; flag the ones you don't.
|
||||
4. If nothing this session touched milestone/epic-level state, say so and move on.
|
||||
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.
|
||||
|
||||
Skip this step entirely only when the project has no external planning store.
|
||||
Skip this step entirely when the project has no external planning store.
|
||||
|
||||
### Step 2.4: RCA document write-back
|
||||
|
||||
@@ -248,9 +297,9 @@ Print a concise summary:
|
||||
- Number of entries by section
|
||||
- Any files pruned or warnings issued
|
||||
|
||||
**Context update:**
|
||||
- What CONTEXT.md now points to (active work streams)
|
||||
- What the next session should pick up
|
||||
**State update:**
|
||||
- (planner project) Which items got a session doc uploaded; any flow-state changes; CONTEXT.md current-state one-liner
|
||||
- (no-planner project) What CONTEXT.md now points to; what the next session should pick up
|
||||
|
||||
**Doc updates:**
|
||||
- Which files were updated (FUTURE.md, README.md, CLAUDE.md) and what changed
|
||||
@@ -262,8 +311,8 @@ Print a concise summary:
|
||||
|
||||
- Gotchas include **symptom AND fix**, not just "X was tricky"
|
||||
- Process lessons are phrased as **rules** ("Always X before Y")
|
||||
- CONTEXT.md entries are **specific enough to resume from** without conversation history
|
||||
- Context detail files include **file paths, branch names, and next steps**
|
||||
- (planner) Session status doc is uploaded to the correct item; CONTEXT.md current-state is updated to one line
|
||||
- (no-planner) CONTEXT.md entries are **specific enough to resume from** without conversation history; detail files include file paths, branch names, and next steps
|
||||
- Future items have all four fields (Problem/Idea/Open questions/Depends on)
|
||||
- Doc updates are **minimal and accurate** -- only touch what actually changed this session
|
||||
- README scripts section lists every script with purpose and usage
|
||||
|
||||
Reference in New Issue
Block a user