jpmschweitzer/council
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add /reflect, /triage-inbox, and weekly / monthly review commands

Browse Source 
Four meta-lens commands that operate across the PKB rather than on a
single note.

/reflect — single member (default Vale) reads the last N daily notes
(default 7) plus any intersecting open threads from members/*/revisit
files and surfaces patterns, recurring questions, tensions, and
intersections. Reflective, not prescriptive. Output lands in
reflections/YYYY-MM-DD_reflect-<member>.md.

/triage-inbox — a member (default Koskela) reads every file in inbox/
and proposes a destination per note (daily/, notes/<slug>.md,
projects/<slug>/log.md, reading/<slug>.md, keep, delete). Proposals
are shown via AskUserQuestion in batches of 4 for user approval;
approved moves preserve provenance via source: inbox/<original> in
frontmatter.

/review-week — three complementary lenses (Koskela practice,
Vale meaning, Prochazka execution) read the ISO week's daily notes +
project logs + sessions + all revisit files in parallel. Moderator
composes a synthesis. Output at reviews/YYYY-WNN_week.md.

/review-month — five lenses (Okafor trajectory, Vale what-it-was-
about, Holt brittleness, Vaasa minimal-model, Vire foreshadowing)
zoom out across the month's weekly reviews, sessions, project
trajectories, and reflections. Output at reviews/YYYY-MM_month.md.

Neither review runs auto-scheduled — commands are always explicit.
Pair with the schedule skill to automate.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
jpmschweitzer
2026-04-19 20:17:28 +02:00
co-authored by Claude Opus 4.7
parent 97d71c4c49
commit 2d5615b1ba
4 changed files with 323 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/commands/reflect.md
+73
View File
@@ -0,0 +1,73 @@
---
description: Have a single Council member read your recent daily notes and surface patterns, recurring questions, and tensions. Reflective, not prescriptive.
argument-hint: [--member <slug>] [--days <N>] [--on <path>]
---
You are the Moderator. The user wants a single-member reflection on their recent thinking — patterns, questions they've been circling, tensions worth naming. This is **reflective**, not advisory. The member reflects back; they don't prescribe.
**Steps:**
1. **Parse `$ARGUMENTS`.**
- `--member <slug>` — pick the reflector. Default: `vale` (gentle, non-prescriptive, good at surfacing what's actually being said underneath).
- `--days <N>` — how far back to read daily notes. Default: `7`. Applies only when `--on` is not given.
- `--on <path>` — reflect on a specific note or project log instead of the daily-notes window. Mutually exclusive with `--days`.
- If `$ARGUMENTS` is empty, use defaults.
2. **Gather the material.**
- If `--on <path>` was given: read that path (and any wikilinks it references that are relevant).
- Otherwise: list `daily/*.md` files, sort by filename (ISO dates sort naturally), take the last N. Also gather:
- All `projects/*/log.md` files modified within the same window.
- All `members/*/revisit.md` files (for open-thread intersection).
- Note: if fewer than N daily notes exist, reflect on what is available and say so at the top of the output.
3. **Invoke `council-<member>`** via the `Agent` tool (default Sonnet, no model override). Prompt:
> You are reflecting, not advising, via `/reflect`. The user wants you to read their recent thinking and surface what's actually there — patterns, questions they've been circling, tensions worth naming. Do not prescribe. Do not tell them what to do. Reflect what you see.
>
> Before answering:
> 1. Read every file in `/var/mnt/data/projects/council/members/<member>/` — persona, journal, on-the-user, revisit.
> 2. Read the material the Moderator is giving you: [list of paths — daily notes, project logs, revisit files, or the --on target].
>
> Produce your reflection with these exact section headers:
>
> ## Patterns
> What recurs across the material? Themes, moods, preoccupations. Name them plainly.
>
> ## Questions circling
> What questions does the user keep asking, implicitly or explicitly, without fully answering?
>
> ## Tensions
> Where do things the user said contradict, or pull in different directions?
>
> ## Open threads that intersect
> From your fellow members' `revisit.md` files, are any open threads touching what's in this window? Wikilink them.
>
> No advice. No "you should". No summary-of-what-happened. Reflection is what it does.
4. **Display the reflection** to the user, prefixed with:
```
## Reflection — <Name> — <window description>
```
Where `<window description>` is e.g. "last 7 daily notes (2026-04-13 to 2026-04-19)" or "on notes/some-permanent-note.md".
5. **Write it to disk.**
File path: `/var/mnt/data/projects/council/reflections/YYYY-MM-DD_reflect-<member>.md` (today's date; append `_2`, `_3`, … on same-day collisions).
Frontmatter:
```yaml
---
type: reflection
member: <slug>
scope: <daily-window | note | project-log>
window: <e.g. "7 days, 2026-04-13 to 2026-04-19" or "notes/foo.md">
date: <YYYY-MM-DD>
---
```
Body: the member's full reflection (verbatim).
6. **Do not run any Council phases.** Single-agent reflection; no debate, no vote, no Scribe.
.claude/commands/review-month.md
+87
View File
@@ -0,0 +1,87 @@
---
description: Zoom-out monthly review. Five members read the month's weekly reviews + sessions + project trajectories in parallel; the Moderator synthesises trends.
argument-hint: [--month YYYY-MM] [--members <slug>,<slug>,<slug>,<slug>,<slug>]
---
You are the Moderator. Monthly review ritual — five Council members read the month's material in parallel, producing a zoom-out synthesis that names trends rather than events.
**Default members (five lenses for the long view):**
- **Okafor** — systems / trajectory over time
- **Vale** — meaning / what this month was actually about
- **Holt** — failure modes / what's brittle
- **Vaasa** — structure / the simplest model of the month
- **Vire** — projection / what this month foreshadows
**Steps:**
1. **Parse `$ARGUMENTS`.**
- `--month YYYY-MM` — specific calendar month. Default: current month.
- `--members <a>,<b>,<c>,<d>,<e>` — override the default five (must be exactly 5 valid voting-member slugs).
2. **Compute the window.**
- First and last day of the target calendar month.
- Gather `reviews/YYYY-WNN_week.md` files for weeks that overlap the month.
- Gather `sessions/*/outcome.md` files with `date` frontmatter in the window.
- Gather `projects/*/log.md` files (full content — trajectory matters).
- Gather `members/*/revisit.md` files (all).
- Gather `reflections/YYYY-MM-DD_*.md` files with dates in the window.
3. **Dispatch the five members in parallel** via `Agent` tool calls in a single message. Each gets the same material + their lens:
> You are participating in `/review-month` for <YYYY-MM>. Your role this review: **<ROLE>**.
>
> Before answering:
> 1. Read every file in `/var/mnt/data/projects/council/members/<your-slug>/` — persona, journal, on-the-user, revisit.
> 2. Read the material the Moderator has collected: [list — weekly reviews, session outcomes, project logs, revisit files, reflections].
>
> Produce your section:
>
> ## <Your name> — <role label>
>
> **What this month was about, through your lens.** Two to four paragraphs. Zoom out from events to trajectory. Wikilink specific artefacts (weekly reviews, sessions, project logs) where relevant.
>
> **What's shifting.** What's moving in a direction worth naming? What looks stable? What's decaying or accelerating?
>
> **Questions this month raised that next month should hold.** One to three bullets. These become candidates for `revisit.md` updates or future `/council` sessions.
Role labels:
- Okafor → "systems over time"
- Vale → "what it was really about"
- Holt → "failure modes & brittleness"
- Vaasa → "the simplest model"
- Vire → "what this foreshadows"
4. **Collect the five sections.** Tolerate up to one failure; if two or more fail, surface and ask whether to proceed.
5. **Compose the Moderator synthesis** and write `reviews/YYYY-MM_month.md`:
```markdown
---
type: review-month
date: <last day of month, YYYY-MM-DD>
month: <YYYY-MM>
members: [<5 slugs>]
weekly_reviews: [<list of weekly-review wikilinks>]
sessions: [<list of session wikilinks>]
---
# Monthly review — <Month Year>
<brief factual framing — how many weekly reviews, sessions, reflections, project logs updated.>
<five member sections verbatim.>
## Moderator synthesis
**Trajectory.** One paragraph — what direction is the overall arc pointing, reading across all five lenses?
**Divergences across members.** Where did the five disagree, and what's the interesting thing in the disagreement?
**Candidates for next /council run.** One or two concrete question-shapes that emerged, if any.
**Revisit-list additions.** Bulleted list of open threads to carry forward (from any member's section).
```
6. **Display a short terminal summary.** Just the five "what's shifting" headlines, the trajectory paragraph, and pointers to the full file and any intersecting weekly reviews.
7. **Memory update.** As with weekly reviews: no Phase-5 batch. The review itself is the artefact.
.claude/commands/review-week.md
+87
View File
@@ -0,0 +1,87 @@
---
description: Structured weekly review. Three members read the week's daily notes + project logs + open revisit items in parallel; the Moderator synthesises.
argument-hint: [--week YYYY-WNN] [--members <slug>,<slug>,<slug>]
---
You are the Moderator. This is the weekly review ritual — three Council members read the week's material in parallel, each through their own lens, and you produce a structured synthesis the user can revisit.
**Default members (complementary lenses):**
- **Koskela** — practice / what actually happened
- **Vale** — meaning / what mattered
- **Prochazka** — execution / what needs doing
**Steps:**
1. **Parse `$ARGUMENTS`.**
- `--week YYYY-WNN` — specific ISO week. Default: current week (determine from today's date; ISO week number; weeks start Monday).
- `--members <a>,<b>,<c>` — override the default trio (must be exactly 3 valid slugs from the 10 voting members).
2. **Compute the window.**
- Determine the Monday and Sunday of the target ISO week.
- Identify all `daily/YYYY-MM-DD.md` files with dates within that window.
- Identify `projects/*/log.md` files modified within the window.
- Identify `sessions/*/outcome.md` files with a `date` frontmatter value in the window.
- Gather `members/*/revisit.md` paths (all of them — review time is also revisit-check time).
3. **Dispatch the three members in parallel** via `Agent` tool calls in a single message. Each member gets the same file list + role directive:
> You are participating in `/review-week` for ISO week `<YYYY-WNN>` (Monday YYYY-MM-DD → Sunday YYYY-MM-DD). Your role this review: **<ROLE>**.
>
> Before answering:
> 1. Read every file in `/var/mnt/data/projects/council/members/<your-slug>/` — persona, journal, on-the-user, revisit.
> 2. Read the material the Moderator has collected: [list of paths — daily notes, project logs, session outcomes, all revisit.md files].
>
> Produce your section exactly:
>
> ## <Your name> — <role label>
>
> **What you notice.** Two to four paragraphs. Through your lens. Specific, referring to daily notes and project logs by wikilink where relevant.
>
> **Open threads.** If any items in your own `revisit.md` or other members' `revisit.md` intersect with this week's material, surface them as bullets. Wikilink.
>
> **One thing worth carrying forward.** One sentence.
Role labels:
- Koskela → "practice"
- Vale → "meaning"
- Prochazka → "execution"
- Custom trio → ask each member to pick the role that fits their lens
4. **Collect the three sections.** If any member fails, surface which and whether to retry or proceed with two.
5. **Compose the Moderator synthesis** (your own voice, neutral, short). Combine into a single `reviews/YYYY-WNN_week.md` file:
```markdown
---
type: review-week
date: <Sunday of the week, YYYY-MM-DD>
week: <YYYY-WNN>
window_start: <Monday YYYY-MM-DD>
window_end: <Sunday YYYY-MM-DD>
members: [<slug>, <slug>, <slug>]
---
# Weekly review — Week <NN>, <YYYY>
*Window: <Monday> to <Sunday>.*
<brief factual framing — e.g. "X daily notes this week, Y project logs updated, Z new session outcomes.">
<three member sections verbatim, in order Koskela → Vale → Prochazka (or custom trio in the order given).>
## Moderator synthesis
**Themes across the three lenses.** Two to four sentences. What's the intersection? Where do the three members disagree?
**Open threads to carry forward.** Bulleted wikilinks, deduped across the three members.
**Proposed focus for next week.** One or two sentences. A hypothesis, not a prescription. The user decides.
```
6. **Display a short summary to the user** in the terminal — not the full file. Include:
- The window covered
- One-sentence distillation of each member's "one thing worth carrying forward"
- The list of open threads
- Pointer: "Full review → `reviews/YYYY-WNN_week.md`"
7. **Memory update** (lightweight): do NOT run a Phase-5-style memory batch. Reviews don't update member journals — the review itself is the artefact.
.claude/commands/triage-inbox.md
+76
View File
@@ -0,0 +1,76 @@
---
description: Process the inbox of fleeting notes (voice captures from AudioPen, quick drops). A Council member proposes destinations; you approve in batch; notes move into daily/, notes/, projects/, or reading/ with provenance preserved.
argument-hint: [--member <slug>] [--dry-run]
---
You are the Moderator. The user wants to clear the inbox — fleeting notes (usually AudioPen voice drops) routed to their right homes in the PKB.
**Steps:**
1. **Parse `$ARGUMENTS`.**
- `--member <slug>` — pick the triager. Default: `koskela` (practice-focused, good at noticing what a note actually is).
- `--dry-run` — show proposals without applying any moves. Default: false.
2. **List inbox contents.** Read `/var/mnt/data/projects/council/inbox/*.md` (top level only — don't touch `inbox/raw/`; those are pre-normalised files awaiting the ingest wrapper).
- If empty, tell the user "Inbox is empty" and stop.
- Otherwise list count + filenames.
3. **Invoke `council-<member>`** via the `Agent` tool (default Sonnet). Prompt:
> You are triaging the user's inbox via `/triage-inbox`. For each fleeting note, propose exactly one destination and a short transformation note. Do not apply anything — only propose. The user approves before any moves happen.
>
> Before answering:
> 1. Read every file in `/var/mnt/data/projects/council/members/<member>/` — persona, journal, on-the-user, revisit.
> 2. Read every file in `/var/mnt/data/projects/council/inbox/` (top level only).
> 3. Glance at `projects/` (project slugs and their briefs) and `reading/` (reading slugs) so you know what existing homes are available.
>
> For each inbox note, choose a destination:
>
> - `daily` — append to today's daily note (`daily/<today>.md`) as a dated section. Best for in-the-moment observations, mood, fleeting thoughts that belong in the journal rather than standing alone.
> - `note` — promote to a new permanent note at `notes/<slug>.md`. Best when the voice note contains one distinct idea worth atomicising.
> - `project:<existing-project-slug>` — append to `projects/<slug>/log.md`. Best when the note names an ongoing thread you can see in the projects list.
> - `reading:<existing-reading-slug>` — append to `reading/<slug>.md`. Best when the note is a reaction to an entry in `reading/`.
> - `keep` — leave in inbox. Best when the note is unclassifiable or still forming.
> - `delete` — suggest removal. Use sparingly; the user explicitly approves each delete.
>
> Return your proposals as a markdown table plus a short reasoning block per row. Exact format:
>
> ## Triage proposals
>
> | # | Inbox file | Destination | Reason |
> |---|---|---|---|
> | 1 | `<filename>` | `<destination>` | <≤15-word reason> |
> | 2 | … | … | … |
>
> ## Notes
> (anything that didn't fit in the table — ambiguity, suggested re-titles, linked-to-each-other inbox items, etc.)
4. **Display the proposals** to the user under the header:
```
## Triage proposals — <Name>
```
5. **If `--dry-run`**, stop here. The user can re-run without the flag to apply.
6. **Otherwise, confirm with the user via `AskUserQuestion`.** For each inbox file, present an option list:
- "Apply as proposed"
- "Change destination" (Other; user types the override)
- "Keep in inbox"
- "Delete"
Batch up to 4 files per `AskUserQuestion` call. If there are more than 4 files, iterate.
7. **For each approved move**, perform the action:
- **daily**: Read `daily/<today>.md` (create from template if missing). Append a new section with a ISO-time header and the normalised note body. Add `source: inbox/<filename>` as a comment at the top of the appended section.
- **note**: Create `notes/<slug-from-filename-or-user-override>.md` using the permanent-note template. Body = note content. Frontmatter includes `source: inbox/<filename>`.
- **project:<slug>**: Append to `projects/<slug>/log.md`. Add a dated entry with `source: inbox/<filename>`.
- **reading:<slug>**: Append to `reading/<slug>.md` under a "New thoughts" section (create the section if missing). `source: inbox/<filename>`.
- **delete**: `rm inbox/<filename>`. Only after explicit user approval per item.
- **keep**: do nothing; note remains.
After applying, `rm` the original inbox file (except for `keep`). Provenance is preserved via the `source:` field in the destination.
8. **Summarise the result** to the user — counts per destination + names of files remaining in inbox.
9. **Do not run any Council phases.** Single-agent triage.