` - The five summary sections - Session Metadata section (if it existed) 7. Run `chmod 644 <filepath>` after writing. **Important:** Do NOT modify frontmatter. Do NOT change the filename. Do NOT add or remove tags. Move all upgraded files from `UNSUMMARIZED` into the working set alongside `SUMMARIZED`. Track the count of upgraded notes as `UPGRADED_COUNT`. ### Step 7 — Read and distill note content > **Security:** If you need to write temp files during distillation, use `~/.claude/obsidian-brain/` (NOT `/tmp/`). This is a security requirement — predictable `/tmp` paths are vulnerable to symlink attacks. Collect all matched files (now all summarized). Apply the /context-shield rule: For each note, check its size using `wc -l`. Apply the context-shield rule **per note** based on size: - **Notes under ~100 lines (~3000 tokens):** Read directly using the Read tool. - **Notes over ~100 lines:** Spawn a `/context-shield` sub-agent to read in isolation and return a distilled summary. When multiple notes need sub-agent reads, spawn them in parallel (one sub-agent per note). From each note (whether read directly or via sub-agent), extract: project name (from frontmatter `project:` field), note type (`type:` field), date, title (first `# Heading`), summary (content of `## Summary` section), decisions (bullets from `## Key Decisions`), errors resolved (bullets from `## Errors Encountered`), open items (checkboxes from `## Open Questions / Next Steps`), and the filename (for wikilinks). **Also extract closed items for the "Closed This Period" section:** For each session note in the date range, get the file modification time as a YYYY-MM-DD string (in the local timezone, matching how `START_DATE` and `END_DATE` were calculated): ```bash # Get mtime as epoch, then format. Both forms work cross-platform. MTIME_DATE=$(date -r "$file" +%Y-%m-%d 2>/dev/null || date -d @"$(stat -c %Y "$file")" +%Y-%m-%d) ``` The first form (`date -r FILE`) works on macOS. The Linux fallback uses `stat -c %Y` for the epoch then `date -d @EPOCH` to format. Both produce a YYYY-MM-DD string in the local timezone, which matches the format of `START_DATE` and `END_DATE`. If `MTIME_DATE` is lexicographically within the range (`MTIME_DATE >= START_DATE && MTIME_DATE <= END_DATE`), Grep the file for `- \[x\]` lines under the `## Open Questions / Next Steps` section using the same line-range verification as for open items. Collect `(project, item_text)` tuples for each checked item. Collect all distilled records as `NOTE_DATA`. ### Step 8 — Group by project Group `NOTE_DATA` by `project` field. Sort projects alphabetically. Within each project, sort notes by `date` ascending (oldest first within the range). Separate sessions from insights within each project group. If any notes have a missing or empty `project` field, group them under `(unknown project)`. ### Step 9 — Generate standup note body Build the standup note body using the grouped data. For each project, emit a section: ```markdown ## $PROJECT_NAME ### Sessions - [[filename-without-extension]] — $TITLE ($DATE) ### Insights - [[filename-without-extension]] — $TITLE ($DATE) ### Decisions - $DECISION_1 - $DECISION_2 ### Errors Resolved - $ERROR_1 ### Open Items - [ ] $OPEN_ITEM_1 - [ ] $OPEN_ITEM_2 ``` Rules: - Omit any subsection that has no content (e.g., if no decisions, skip `### Decisions` entirely). - Omit the `### Insights` subsection if no insight notes exist for that project in the range. - Wikilinks must use the bare filename without `.md` extension: `[[2026-04-05-my-note-a3f2]]`. - Decisions and errors should be deduplicated across sessions in the same project. - Open items should be listed as checkboxes (`- [ ]`). Precede all project sections with a header block that includes a highlights summary and consolidated open items: ```markdown # Standup: $START_DATE to $END_DATE **Range:** $START_DATE → $END_DATE **Projects covered:** $PROJECT_COUNT **Sessions:** $SESSION_COUNT | **Insights:** $INSIGHT_COUNT ### Highlights - **$PROJECT_A** — 1-2 sentences summarizing what was accomplished this period - **$PROJECT_B** — 1-2 sentences summarizing what was accomplished this period ### Key Open Items - [ ] $PROJECT_A: $MOST_IMPORTANT_OPEN_ITEM - [ ] $PROJECT_B: $MOST_IMPORTANT_OPEN_ITEM ``` ### Closed This Period For each project that had at least one item closed within the standup window, render: - **<project name>** (<N> closed) - <item text 1> - <item text 2> - ... After the list, append this footnote on its own line in italics: > _Detected via file modification time — may include items checked off earlier if a session note was edited during this window for unrelated reasons._ If zero items were closed across all projects, **omit this entire section** — do not render an empty header or the footnote. Order projects alphabetically. Within each project, preserve the order items were extracted (file mtime descending — newest checkoffs first). Rules for the header sections: - **Highlights:** Include only projects with substantive work (skip vault-import-only or config-tweak sessions). Write 1-2 sentences per project summarizing the outcome, not the process. Order by impact/significance, not alphabetically. - **Key Open Items:** Consolidate the most important open items across all projects (max ~5-7 items). Prefix each with the project name. These are the items that should drive next week's work. Skip low-priority or already-in-progress items. - Both sections are written in the saved note AND presented in the conversation output. If `IS_RANGE` is false (single day), use `# Standup: $DATE` and omit the "Range:" line. For single-day standups, the Highlights section may be omitted if only 1-2 sessions occurred. ### Step 10 — Build frontmatter Construct the `source_notes` array from ALL matched filenames (sessions + insights), formatted as wikilinks: ```yaml --- type: claude-standup date: YYYY-MM-DD date_range: "START_DATE to END_DATE" projects: - project-a - project-b source_notes: - "[[note-filename-1]]" - "[[note-filename-2]]" tags: - claude/standup - claude/project/project-a - claude/project/project-b --- ``` Where: - `date` is today's date (the date the standup was generated, not the range start) - `date_range` is `"$START_DATE to $END_DATE"` (use the same value for single-day standups) - `projects` lists all unique project names found, sorted alphabetically - `source_notes` lists every contributing note as a wikilink (filename without `.md`) - `tags` includes `claude/standup` plus a `claude/project/<name>` tag for each project covered by the standup - If `IS_DEEP`, also append `claude/standup-deep` to the tags list ### Step 11 — Generate filename Construct the filename: 1. **Date prefix:** `YYYY-MM-DD` (today's date, i.e., when the standup is generated) 2. **Slug:** - If `IS_RANGE` is false (single day): `standup-daily` - If `IS_RANGE` is true and the range spans exactly 7 days Mon-Sun: `standup-weekly` - Otherwise: `standup-range` 3. **Hash:** last 4 hex characters of the current timestamp hash: ```bash # macOS HASH=$(date +%s | md5 | cut -c29-32) # Linux fallback HASH=$(date +%s | md5sum | cut -c1-4) ``` Final filename: `YYYY-MM-DD-<slug>-<hash>.md` Example: `2026-04-05-standup-daily-a3f2.md` ### Step 12 — Write the note Run: ```bash mkdir -p "$VAULT_PATH/$INSIGHTS_FOLDER" ``` Then use the **Write** tool to write the full note (frontmatter + body) to: ``` $VAULT_PATH/$INSIGHTS_FOLDER/YYYY-MM-DD-<slug>-<hash>.md ``` Then set permissions: ```bash chmod 644 "$VAULT_PATH/$INSIGHTS_FOLDER/YYYY-MM-DD-<slug>-<hash>.md" ``` ### Step 13 — Present to user Display the full standup in the conversation: > **Standup for $START_DATE to $END_DATE:** Then output the standup body (without frontmatter) as formatted markdown. If `UPGRADED_COUNT > 0`, append: > _Upgraded $UPGRADED_COUNT session note(s) with AI summaries._ Then confirm the saved file: > **Saved:** `$VAULT_PATH/$INSIGHTS_FOLDER/<filename>` ### Step 14 — Cascade completed open items across vault When open items are checked off in the standup note (either during generation or by the user afterwards), those same items may appear as unchecked `- [ ]` entries in other session notes across the vault. This step ensures all references are updated. **14a — Collect confirmed completed items.** Gather all items that were marked `[x]` in the standup note's per-project `### Open Items` sections or the top-level `### Key Open Items` section. Include items from the `### Closed This Period` section as well. Extract just the item text (without the checkbox prefix or project prefix). **14b — For each project that has completed items, cascade checkoffs across the vault.** Run: ```bash cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" printf '%s' "$CHECKED_ITEMS_JSON" | python3 -c ' import sys, json, os import glob; sys.path.insert(0, max(glob.glob(os.path.expanduser("~/.claude/plugins/cache/*/obsidian-brain/*/hooks")), default="hooks")) from open_item_dedup import batch_cascade_checkoff items = json.load(sys.stdin) summary = batch_cascade_checkoff(sys.argv[1], sys.argv[2], sys.argv[3], items) print(summary) ' "$VAULT_PATH" "$SESSIONS_FOLDER" "$PROJECT" ``` Where `$CHECKED_ITEMS_JSON` is a JSON array of the confirmed item texts for that project (passed via stdin to avoid shell quoting issues with special characters in item text), and `$PROJECT` is the project name. Run one call per project that has completed items. If multiple projects have items, run the calls in parallel. If the command exits with a non-zero exit code, report the error to the user: > Cascade checkoff failed for $PROJECT: [first line of stderr]. The standup note is unaffected. Note: `batch_cascade_checkoff()` may emit warnings to stderr while still succeeding (e.g., a specific line changed). Only treat non-zero exit code as a failure. **14c — Report cascade results.** After all cascade calls complete, report: > Cascaded N checkoff(s) across M vault note(s) for project(s): list. If `batch_cascade_checkoff` is unavailable (import error), warn the user: > Could not cascade checkoffs: [error details]. The standup note is correct, but duplicate open items in other session notes were not updated. Run `/recall` to cascade manually. ### Steps 14b–19 — Deep mode (only if IS_DEEP) Skip to Edge Cases if `IS_DEEP` is false. > **STOP. Before ANY deep analysis work, create the task manifest.** > The user CANNOT see your progress without tasks. Create all 5 tasks below using TaskCreate tool calls RIGHT NOW — in your NEXT tool-call message — before proceeding to Step 15. **Step 14b — Create deep task manifest.** Call TaskCreate 5 times (all in one message): 1. `TaskCreate: subject="Collect data and gather evidence", activeForm="Analyzing vault and git history"` 2. `TaskCreate: subject="Classify open items", activeForm="Classifying items with AI"` 3. `TaskCreate: subject="Present deep analysis", activeForm="Presenting recommendations"` 4. `TaskCreate: subject="Execute confirmed actions", activeForm="Executing actions"` 5. `TaskCreate: subject="Cascade checkoffs", activeForm="Cascading checkoffs"` Then set task #1 to `in_progress` via TaskUpdate. **Do NOT proceed to Step 15 until all 5 tasks exist.** **Step 15 — Collect data and gather evidence.** First check for a fresh cache (avoids re-running the full pipeline if `/standup deep` or `/emerge` was run recently with the same data): ```bash cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" printf '{"basenames": %s, "projects": %s}' "$NOTE_BASENAMES_JSON" "$PROJECTS_JSON" | python3 -c ' import sys, os, glob; sys.path.insert(0, max(glob.glob(os.path.expanduser("~/.claude/plugins/cache/*/obsidian-brain/*/hooks")), default="hooks")) from deep_cli import run_pipeline; run_pipeline(sys.argv[1], sys.argv[2], sys.argv[3]) ' "$VAULT_PATH" "$SESSIONS_FOLDER" "$INSIGHTS_FOLDER" ``` If the status starts with `CACHED:`, report "Using cached deep analysis (< 15 min old)" and skip to Step 16. Where `$NOTE_BASENAMES_JSON` is a JSON array of note basenames from Step 7's NOTE_DATA, and `$PROJECTS_JSON` is the JSON string from Step 8's project list. Both are passed via stdin to avoid shell argument injection. Mark task #1 complete, task #2 in_progress. **Step 16 — Classify open items.** Spawn a single Agent sub-agent that: 1. Reads `~/.claude/obsidian-brain/deep-pipeline.json` 2. For each open item, classifies it as `done`, `stale`, `active`, or `duplicate` based on evidence 3. Writes classifications to `~/.claude/obsidian-brain/deep-classifications.json` Mark task #2 complete, task #3 in_progress. **Step 17 — Present deep analysis.** Run: ```bash cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" printf '%s' "$NOTE_BASENAMES_JSON" | python3 -c ' import sys, os, glob; sys.path.insert(0, max(glob.glob(os.path.expanduser("~/.claude/plugins/cache/*/obsidian-brain/*/hooks")), default="hooks")) from deep_cli import run_present; run_present(sys.argv[1], sys.argv[2], sys.argv[3]) ' "$VAULT_PATH" "$SESSIONS_FOLDER" "$INSIGHTS_FOLDER" ``` Display the output to the user. Wait for user response — they may confirm actions, edit classifications, or type `skip`. Mark task #3 complete, task #4 in_progress. **Step 18 — Execute confirmed actions.** Parse user response. If user typed `skip`, skip this step. **Important:** Do NOT use the Edit tool for batch vault edits — it requires Read first for each file, which is impractical for 20+ files. Instead, use a Python script that reads, modifies, and writes files directly: ```bash cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" printf '%s' "$EDITS_JSON" | python3 -c ' import sys, os, glob; sys.path.insert(0, max(glob.glob(os.path.expanduser("~/.claude/plugins/cache/*/obsidian-brain/*/hooks")), default="hooks")) from deep_cli import run_batch_edit; run_batch_edit() ' ``` Where `$EDITS_JSON` is a JSON array of `[filepath, old_text, new_text]` triples constructed from the confirmed actions. Use `errors="replace"` when reading to handle vault notes with encoding corruption (binary file matches). For confirmed link additions, use the same Python pattern to append wikilinks. Mark task #4 complete, task #5 in_progress. **Step 19 — Cascade checkoffs + cleanup.** For each project with newly checked items, run `batch_cascade_checkoff()` (same as Step 14b) in parallel. **Always clean up temp files** (even if user skipped actions — prevents stale cache from giving the same recommendations on next run): ```bash rm -f ~/.claude/obsidian-brain/deep-pipeline.json ~/.claude/obsidian-brain/deep-classifications.json ``` This invalidates the 15-min cache so the next `/standup deep` run gets fresh data reflecting any changes made. Mark task #5 complete. ## Edge Cases - **No notes found for range:** Tell the user and suggest narrowing or widening the range, or checking that vault path is correct. - **All notes are unsummarized:** Summarize all in Step 5 before proceeding — never skip summarization. - **Single project:** Omit the per-project `## $PROJECT_NAME` heading if there is exactly one project; output the sections directly under the top-level header. - **Config exists but vault path is invalid:** Warn the user and suggest running `/obsidian-setup` again. - **macOS vs Linux date syntax:** Always try macOS syntax (`date -v`) first; fall back to Linux (`date -d`) if it fails. - **Notes with missing project field:** Group under `(unknown project)` and note this to the user.

# Standup > Generates daily/weekly standup summaries across all projects from the Obsidian vault. Includes a Closed This Period section listing items checked off during the window, grouped by project. Use when: (1) /standup for today's summary, (2) /standup this week for weekly summary, (3) /standup for custom range. - Skill: `abhattacherjee/standup` (Agent Skill) - Install (CLI): `npx skillmds@latest add abhattacherjee/standup` - Raw SKILL.md: https://api.skillmd.com/api/skills/abhattacherjee/standup/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: abhattacherjee (https://skillmd.com/u/abhattacherjee) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/abhattacherjee/standup --- # Standup — Generate Standup Summaries from Obsidian Vault Searches the Obsidian vault for session notes and insights within a date range, upgrades any unsummarized notes with AI summaries, groups findings by project, and generates a structured standup note. **Tools needed:** Bash, Grep, Read, Write ## Procedure Follow these steps exactly. Do not skip steps or reorder them. ### Step 1 — Load config Run: ```bash cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" python3 -c ' import sys, os import glob; sys.path.insert(0, max(glob.glob(os.path.expanduser("~/.claude/plugins/cache/*/obsidian-brain/*/hooks")), default="hooks")) from obsidian_utils import load_config c = load_config() if not c.get("vault_path"): print("ERROR: vault_path not configured", file=sys.stderr) sys.exit(1) print("VAULT=" + c["vault_path"]) print("SESS=" + c.get("sessions_folder", "claude-sessions")) print("INS=" + c.get("insights_folder", "claude-insights")) ' ``` Parse each output line as KEY=VALUE, splitting on the first `=`. If the command exits non-zero or prints ERROR, tell the user: > Config not found. Run `/obsidian-setup` first to configure your Obsidian vault. Stop here if config is missing. ### Step 2 — Validate vault access Run: ```bash test -d "$VAULT_PATH/$SESSIONS_FOLDER" && test -d "$VAULT_PATH/$INSIGHTS_FOLDER" && echo "OK" || echo "FAIL" ``` If FAIL, tell the user: > The vault folders do not exist or are not accessible. Run `/obsidian-setup` to fix this. Stop here if FAIL. ### Step 3 — Parse date range from arguments Before date parsing, check if the argument string contains the word `deep` (case-insensitive). If found, set `IS_DEEP = true` and remove `deep` from the argument string before passing to date parsing. Otherwise `IS_DEEP = false`. Inspect the argument passed after `/standup`. Calculate `START_DATE` and `END_DATE` as `YYYY-MM-DD` strings using bash `date` commands. **No argument (bare `/standup`):** today only. ```bash START_DATE=$(date +%Y-%m-%d) END_DATE=$START_DATE ``` **`yesterday`:** ```bash # macOS START_DATE=$(date -v-1d +%Y-%m-%d) END_DATE=$START_DATE # Linux fallback START_DATE=$(date -d "yesterday" +%Y-%m-%d) END_DATE=$START_DATE ``` **`this week`:** Monday of the current week through today. ```bash # macOS DOW=$(date +%u) # 1=Mon … 7=Sun DAYS_BACK=$((DOW - 1)) START_DATE=$(date -v-${DAYS_BACK}d +%Y-%m-%d) END_DATE=$(date +%Y-%m-%d) # Linux fallback START_DATE=$(date -d "last Monday" +%Y-%m-%d 2>/dev/null || date -d "$(date +%Y-%m-%d) -$(date +%u)-1 days" +%Y-%m-%d) END_DATE=$(date +%Y-%m-%d) ``` **`last week`:** Monday through Sunday of the previous week. ```bash # macOS DOW=$(date +%u) START_DATE=$(date -v-${DOW}d -v-6d +%Y-%m-%d) END_DATE=$(date -v-${DOW}d +%Y-%m-%d) # Linux fallback START_DATE=$(date -d "last week Monday" +%Y-%m-%d) END_DATE=$(date -d "last week Sunday" +%Y-%m-%d) ``` **`YYYY-MM-DD to YYYY-MM-DD`:** use the two dates directly as `START_DATE` and `END_DATE`. Store both dates. Also compute `IS_RANGE` = true if `START_DATE != END_DATE`, false otherwise. This controls the filename slug in Step 11. **Validate the parsed dates:** Check that `START_DATE` and `END_DATE` are non-empty and match `YYYY-MM-DD` format. If either is empty or malformed, tell the user: > Could not parse the date range from your input. Supported formats: > - `/standup` (today) > - `/standup yesterday` > - `/standup this week` > - `/standup last week` > - `/standup 2026-03-25 to 2026-03-31` Stop here if validation fails. Also verify that `START_DATE <= END_DATE`. If not, tell the user the start date must be before or equal to the end date. ### Step 4 — Search for notes in date range (parallel) Run two Grep searches in parallel to find notes whose `date:` frontmatter field falls within the range. **Search A — Sessions:** ``` pattern: "^date: " path: $VAULT_PATH/$SESSIONS_FOLDER/ output_mode: content glob: "*.md" ``` **Search B — Insights:** ``` pattern: "^date: " path: $VAULT_PATH/$INSIGHTS_FOLDER/ output_mode: content glob: "*.md" ``` For each result, parse the `date:` value and keep only files where `START_DATE <= date <= END_DATE`. Collect the matching file paths into `MATCHED_FILES`. If `MATCHED_FILES` is empty, tell the user: > No session or insight notes found for the range **$START_DATE to $END_DATE**. Stop here. ### Step 5 — Identify unsummarized session notes From `MATCHED_FILES`, isolate those in `$SESSIONS_FOLDER/`. Use Grep to check each for the unsummarized frontmatter status (NOT body text — body text matches cause false positives from logged tool usage): ``` pattern: "^status: auto-logged" path: output_mode: files_with_matches ``` **Defense-in-depth:** For each file matching `^status: auto-logged`, also check if it already has a real `## Summary` section (without `"AI summary unavailable"`). If so, the note was summarized by a legacy code path that never flipped the status. Skip it and fix the status: ```bash python3 -c ' import sys, os import glob; sys.path.insert(0, max(glob.glob(os.path.expanduser("~/.claude/plugins/cache/*/obsidian-brain/*/hooks")), default="hooks")) from obsidian_utils import flip_note_status flip_note_status(sys.argv[1], "auto-logged", "summarized") ' "$FILE_PATH" ``` Split into: - `UNSUMMARIZED` — session files with `status: auto-logged` AND no real `## Summary` - `SUMMARIZED` — all other matched files (sessions + insights + auto-fixed legacy notes) ### Step 6 — Deferred summarization for unsummarized notes If `UNSUMMARIZED` is empty, skip to Step 7. **Always parallelize unsummarized note upgrades.** For each unsummarized note, spawn a sub-agent immediately — even for 1-2 notes. Each sub-agent should call: ```bash cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" python3 -c ' import sys, os import glob; sys.path.insert(0, max(glob.glob(os.path.expanduser("~/.claude/plugins/cache/*/obsidian-brain/*/hooks")), default="hooks")) from obsidian_utils import upgrade_unsummarized_note status = upgrade_unsummarized_note(sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4]) print(status) ' "$NOTE_PATH" "$VAULT_PATH" "$SESSIONS_FOLDER" "$PROJECT" ``` The function returns a one-line status. If the status starts with `Failed:`, note the failure and fall back to the manual procedure below for that note. Collect results from all sub-agents before proceeding. For each file in `UNSUMMARIZED`, if `upgrade_unsummarized_note()` is unavailable or returns a `Failed:` status, fall back to the manual upgrade procedure: 1. **Read the full file** using the Read tool. 2. **Extract frontmatter** — preserve it exactly as-is (everything between the opening `---` and closing `---`). 3. **Extract the full conversation** — read all content after frontmatter, including: - `## Conversation (raw)` — interleaved user and assistant messages - `## Tool Usage` — commands run, files edited, searches performed - `## Changes Made` — files touched - `## Errors Encountered` — errors from tool results 4. **Generate a detailed, specific summary** with these sections: - `## Summary` — 3-5 sentence overview: what problem was solved, what approach was taken, what was the outcome. Name specific technologies, files, and patterns. - `## Key Decisions` — Bulleted list with rationale. If none, write "None noted." - `## Changes Made` — Bulleted list with file paths and descriptions. If none, write "None noted." - `## Errors Encountered` — Bulleted list with error messages, root causes, and fixes. If none, write "None." - `## Open Questions / Next Steps` — Checkbox list of specific, actionable items. If none, write "None." 5. **Preserve the Session Metadata section** at the bottom if it exists. 6. **Write the upgraded note** using the Write tool to the same file path. Structure: - Original frontmatter (unchanged) - `# ` - The five summary sections - Session Metadata section (if it existed) 7. Run `chmod 644 <filepath>` after writing. **Important:** Do NOT modify frontmatter. Do NOT change the filename. Do NOT add or remove tags. Move all upgraded files from `UNSUMMARIZED` into the working set alongside `SUMMARIZED`. Track the count of upgraded notes as `UPGRADED_COUNT`. ### Step 7 — Read and distill note content > **Security:** If you need to write temp files during distillation, use `~/.claude/obsidian-brain/` (NOT `/tmp/`). This is a security requirement — predictable `/tmp` paths are vulnerable to symlink attacks. Collect all matched files (now all summarized). Apply the /context-shield rule: For each note, check its size using `wc -l`. Apply the context-shield rule **per note** based on size: - **Notes under ~100 lines (~3000 tokens):** Read directly using the Read tool. - **Notes over ~100 lines:** Spawn a `/context-shield` sub-agent to read in isolation and return a distilled summary. When multiple notes need sub-agent reads, spawn them in parallel (one sub-agent per note). From each note (whether read directly or via sub-agent), extract: project name (from frontmatter `project:` field), note type (`type:` field), date, title (first `# Heading`), summary (content of `## Summary` section), decisions (bullets from `## Key Decisions`), errors resolved (bullets from `## Errors Encountered`), open items (checkboxes from `## Open Questions / Next Steps`), and the filename (for wikilinks). **Also extract closed items for the "Closed This Period" section:** For each session note in the date range, get the file modification time as a YYYY-MM-DD string (in the local timezone, matching how `START_DATE` and `END_DATE` were calculated): ```bash # Get mtime as epoch, then format. Both forms work cross-platform. MTIME_DATE=$(date -r "$file" +%Y-%m-%d 2>/dev/null || date -d @"$(stat -c %Y "$file")" +%Y-%m-%d) ``` The first form (`date -r FILE`) works on macOS. The Linux fallback uses `stat -c %Y` for the epoch then `date -d @EPOCH` to format. Both produce a YYYY-MM-DD string in the local timezone, which matches the format of `START_DATE` and `END_DATE`. If `MTIME_DATE` is lexicographically within the range (`MTIME_DATE >= START_DATE && MTIME_DATE <= END_DATE`), Grep the file for `- \[x\]` lines under the `## Open Questions / Next Steps` section using the same line-range verification as for open items. Collect `(project, item_text)` tuples for each checked item. Collect all distilled records as `NOTE_DATA`. ### Step 8 — Group by project Group `NOTE_DATA` by `project` field. Sort projects alphabetically. Within each project, sort notes by `date` ascending (oldest first within the range). Separate sessions from insights within each project group. If any notes have a missing or empty `project` field, group them under `(unknown project)`. ### Step 9 — Generate standup note body Build the standup note body using the grouped data. For each project, emit a section: ```markdown ## $PROJECT_NAME ### Sessions - [[filename-without-extension]] — $TITLE ($DATE) ### Insights - [[filename-without-extension]] — $TITLE ($DATE) ### Decisions - $DECISION_1 - $DECISION_2 ### Errors Resolved - $ERROR_1 ### Open Items - [ ] $OPEN_ITEM_1 - [ ] $OPEN_ITEM_2 ``` Rules: - Omit any subsection that has no content (e.g., if no decisions, skip `### Decisions` entirely). - Omit the `### Insights` subsection if no insight notes exist for that project in the range. - Wikilinks must use the bare filename without `.md` extension: `[[2026-04-05-my-note-a3f2]]`. - Decisions and errors should be deduplicated across sessions in the same project. - Open items should be listed as checkboxes (`- [ ]`). Precede all project sections with a header block that includes a highlights summary and consolidated open items: ```markdown # Standup: $START_DATE to $END_DATE **Range:** $START_DATE → $END_DATE **Projects covered:** $PROJECT_COUNT **Sessions:** $SESSION_COUNT | **Insights:** $INSIGHT_COUNT ### Highlights - **$PROJECT_A** — 1-2 sentences summarizing what was accomplished this period - **$PROJECT_B** — 1-2 sentences summarizing what was accomplished this period ### Key Open Items - [ ] $PROJECT_A: $MOST_IMPORTANT_OPEN_ITEM - [ ] $PROJECT_B: $MOST_IMPORTANT_OPEN_ITEM ``` ### Closed This Period For each project that had at least one item closed within the standup window, render: - **<project name>** (<N> closed) - <item text 1> - <item text 2> - ... After the list, append this footnote on its own line in italics: > _Detected via file modification time — may include items checked off earlier if a session note was edited during this window for unrelated reasons._ If zero items were closed across all projects, **omit this entire section** — do not render an empty header or the footnote. Order projects alphabetically. Within each project, preserve the order items were extracted (file mtime descending — newest checkoffs first). Rules for the header sections: - **Highlights:** Include only projects with substantive work (skip vault-import-only or config-tweak sessions). Write 1-2 sentences per project summarizing the outcome, not the process. Order by impact/significance, not alphabetically. - **Key Open Items:** Consolidate the most important open items across all projects (max ~5-7 items). Prefix each with the project name. These are the items that should drive next week's work. Skip low-priority or already-in-progress items. - Both sections are written in the saved note AND presented in the conversation output. If `IS_RANGE` is false (single day), use `# Standup: $DATE` and omit the "Range:" line. For single-day standups, the Highlights section may be omitted if only 1-2 sessions occurred. ### Step 10 — Build frontmatter Construct the `source_notes` array from ALL matched filenames (sessions + insights), formatted as wikilinks: ```yaml --- type: claude-standup date: YYYY-MM-DD date_range: "START_DATE to END_DATE" projects: - project-a - project-b source_notes: - "[[note-filename-1]]" - "[[note-filename-2]]" tags: - claude/standup - claude/project/project-a - claude/project/project-b --- ``` Where: - `date` is today's date (the date the standup was generated, not the range start) - `date_range` is `"$START_DATE to $END_DATE"` (use the same value for single-day standups) - `projects` lists all unique project names found, sorted alphabetically - `source_notes` lists every contributing note as a wikilink (filename without `.md`) - `tags` includes `claude/standup` plus a `claude/project/<name>` tag for each project covered by the standup - If `IS_DEEP`, also append `claude/standup-deep` to the tags list ### Step 11 — Generate filename Construct the filename: 1. **Date prefix:** `YYYY-MM-DD` (today's date, i.e., when the standup is generated) 2. **Slug:** - If `IS_RANGE` is false (single day): `standup-daily` - If `IS_RANGE` is true and the range spans exactly 7 days Mon-Sun: `standup-weekly` - Otherwise: `standup-range` 3. **Hash:** last 4 hex characters of the current timestamp hash: ```bash # macOS HASH=$(date +%s | md5 | cut -c29-32) # Linux fallback HASH=$(date +%s | md5sum | cut -c1-4) ``` Final filename: `YYYY-MM-DD-<slug>-<hash>.md` Example: `2026-04-05-standup-daily-a3f2.md` ### Step 12 — Write the note Run: ```bash mkdir -p "$VAULT_PATH/$INSIGHTS_FOLDER" ``` Then use the **Write** tool to write the full note (frontmatter + body) to: ``` $VAULT_PATH/$INSIGHTS_FOLDER/YYYY-MM-DD-<slug>-<hash>.md ``` Then set permissions: ```bash chmod 644 "$VAULT_PATH/$INSIGHTS_FOLDER/YYYY-MM-DD-<slug>-<hash>.md" ``` ### Step 13 — Present to user Display the full standup in the conversation: > **Standup for $START_DATE to $END_DATE:** Then output the standup body (without frontmatter) as formatted markdown. If `UPGRADED_COUNT > 0`, append: > _Upgraded $UPGRADED_COUNT session note(s) with AI summaries._ Then confirm the saved file: > **Saved:** `$VAULT_PATH/$INSIGHTS_FOLDER/<filename>` ### Step 14 — Cascade completed open items across vault When open items are checked off in the standup note (either during generation or by the user afterwards), those same items may appear as unchecked `- [ ]` entries in other session notes across the vault. This step ensures all references are updated. **14a — Collect confirmed completed items.** Gather all items that were marked `[x]` in the standup note's per-project `### Open Items` sections or the top-level `### Key Open Items` section. Include items from the `### Closed This Period` section as well. Extract just the item text (without the checkbox prefix or project prefix). **14b — For each project that has completed items, cascade checkoffs across the vault.** Run: ```bash cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" printf '%s' "$CHECKED_ITEMS_JSON" | python3 -c ' import sys, json, os import glob; sys.path.insert(0, max(glob.glob(os.path.expanduser("~/.claude/plugins/cache/*/obsidian-brain/*/hooks")), default="hooks")) from open_item_dedup import batch_cascade_checkoff items = json.load(sys.stdin) summary = batch_cascade_checkoff(sys.argv[1], sys.argv[2], sys.argv[3], items) print(summary) ' "$VAULT_PATH" "$SESSIONS_FOLDER" "$PROJECT" ``` Where `$CHECKED_ITEMS_JSON` is a JSON array of the confirmed item texts for that project (passed via stdin to avoid shell quoting issues with special characters in item text), and `$PROJECT` is the project name. Run one call per project that has completed items. If multiple projects have items, run the calls in parallel. If the command exits with a non-zero exit code, report the error to the user: > Cascade checkoff failed for $PROJECT: [first line of stderr]. The standup note is unaffected. Note: `batch_cascade_checkoff()` may emit warnings to stderr while still succeeding (e.g., a specific line changed). Only treat non-zero exit code as a failure. **14c — Report cascade results.** After all cascade calls complete, report: > Cascaded N checkoff(s) across M vault note(s) for project(s): list. If `batch_cascade_checkoff` is unavailable (import error), warn the user: > Could not cascade checkoffs: [error details]. The standup note is correct, but duplicate open items in other session notes were not updated. Run `/recall` to cascade manually. ### Steps 14b–19 — Deep mode (only if IS_DEEP) Skip to Edge Cases if `IS_DEEP` is false. > **STOP. Before ANY deep analysis work, create the task manifest.** > The user CANNOT see your progress without tasks. Create all 5 tasks below using TaskCreate tool calls RIGHT NOW — in your NEXT tool-call message — before proceeding to Step 15. **Step 14b — Create deep task manifest.** Call TaskCreate 5 times (all in one message): 1. `TaskCreate: subject="Collect data and gather evidence", activeForm="Analyzing vault and git history"` 2. `TaskCreate: subject="Classify open items", activeForm="Classifying items with AI"` 3. `TaskCreate: subject="Present deep analysis", activeForm="Presenting recommendations"` 4. `TaskCreate: subject="Execute confirmed actions", activeForm="Executing actions"` 5. `TaskCreate: subject="Cascade checkoffs", activeForm="Cascading checkoffs"` Then set task #1 to `in_progress` via TaskUpdate. **Do NOT proceed to Step 15 until all 5 tasks exist.** **Step 15 — Collect data and gather evidence.** First check for a fresh cache (avoids re-running the full pipeline if `/standup deep` or `/emerge` was run recently with the same data): ```bash cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" printf '{"basenames": %s, "projects": %s}' "$NOTE_BASENAMES_JSON" "$PROJECTS_JSON" | python3 -c ' import sys, os, glob; sys.path.insert(0, max(glob.glob(os.path.expanduser("~/.claude/plugins/cache/*/obsidian-brain/*/hooks")), default="hooks")) from deep_cli import run_pipeline; run_pipeline(sys.argv[1], sys.argv[2], sys.argv[3]) ' "$VAULT_PATH" "$SESSIONS_FOLDER" "$INSIGHTS_FOLDER" ``` If the status starts with `CACHED:`, report "Using cached deep analysis (< 15 min old)" and skip to Step 16. Where `$NOTE_BASENAMES_JSON` is a JSON array of note basenames from Step 7's NOTE_DATA, and `$PROJECTS_JSON` is the JSON string from Step 8's project list. Both are passed via stdin to avoid shell argument injection. Mark task #1 complete, task #2 in_progress. **Step 16 — Classify open items.** Spawn a single Agent sub-agent that: 1. Reads `~/.claude/obsidian-brain/deep-pipeline.json` 2. For each open item, classifies it as `done`, `stale`, `active`, or `duplicate` based on evidence 3. Writes classifications to `~/.claude/obsidian-brain/deep-classifications.json` Mark task #2 complete, task #3 in_progress. **Step 17 — Present deep analysis.** Run: ```bash cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" printf '%s' "$NOTE_BASENAMES_JSON" | python3 -c ' import sys, os, glob; sys.path.insert(0, max(glob.glob(os.path.expanduser("~/.claude/plugins/cache/*/obsidian-brain/*/hooks")), default="hooks")) from deep_cli import run_present; run_present(sys.argv[1], sys.argv[2], sys.argv[3]) ' "$VAULT_PATH" "$SESSIONS_FOLDER" "$INSIGHTS_FOLDER" ``` Display the output to the user. Wait for user response — they may confirm actions, edit classifications, or type `skip`. Mark task #3 complete, task #4 in_progress. **Step 18 — Execute confirmed actions.** Parse user response. If user typed `skip`, skip this step. **Important:** Do NOT use the Edit tool for batch vault edits — it requires Read first for each file, which is impractical for 20+ files. Instead, use a Python script that reads, modifies, and writes files directly: ```bash cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" printf '%s' "$EDITS_JSON" | python3 -c ' import sys, os, glob; sys.path.insert(0, max(glob.glob(os.path.expanduser("~/.claude/plugins/cache/*/obsidian-brain/*/hooks")), default="hooks")) from deep_cli import run_batch_edit; run_batch_edit() ' ``` Where `$EDITS_JSON` is a JSON array of `[filepath, old_text, new_text]` triples constructed from the confirmed actions. Use `errors="replace"` when reading to handle vault notes with encoding corruption (binary file matches). For confirmed link additions, use the same Python pattern to append wikilinks. Mark task #4 complete, task #5 in_progress. **Step 19 — Cascade checkoffs + cleanup.** For each project with newly checked items, run `batch_cascade_checkoff()` (same as Step 14b) in parallel. **Always clean up temp files** (even if user skipped actions — prevents stale cache from giving the same recommendations on next run): ```bash rm -f ~/.claude/obsidian-brain/deep-pipeline.json ~/.claude/obsidian-brain/deep-classifications.json ``` This invalidates the 15-min cache so the next `/standup deep` run gets fresh data reflecting any changes made. Mark task #5 complete. ## Edge Cases - **No notes found for range:** Tell the user and suggest narrowing or widening the range, or checking that vault path is correct. - **All notes are unsummarized:** Summarize all in Step 5 before proceeding — never skip summarization. - **Single project:** Omit the per-project `## $PROJECT_NAME` heading if there is exactly one project; output the sections directly under the top-level header. - **Config exists but vault path is invalid:** Warn the user and suggest running `/obsidian-setup` again. - **macOS vs Linux date syntax:** Always try macOS syntax (`date -v`) first; fall back to Linux (`date -d`) if it fails. - **Notes with missing project field:** Group under `(unknown project)` and note this to the user.