--- name: Note Status slug: note-status category: Automation description: "Note Status checks meeting notes for the four wrap steps: notes, cache, participants, and todos. Use it to see which notes are complete, pending, or blocked before continuing wrap-up work." github: "https://github.com/benoror/obsidianos_work/tree/main/.agents/skills/note-status" language: JavaScript stars: 165 forks: 13 install: "npx degit https://github.com/benoror/obsidianos_work/tree/main/.agents/skills/note-status ~/.claude/skills/note-status" installs_to: ~/.claude/skills/note-status source_path: .agents/skills/note-status/SKILL.md collection_size: 24 category_size: 2226 collection_url: "https://dirskills.com/collections/benoror/obsidianos_work" added: 2026-09-08T05:35:06.015Z last_synced: 2026-09-08T05:35:06.015Z canonical_url: "https://dirskills.com/skills/note-status" --- # Note Status Note Status checks meeting notes for the four wrap steps: notes, cache, participants, and todos. Use it to see which notes are complete, pending, or blocked before continuing wrap-up work. **Install:** ```bash npx degit https://github.com/benoror/obsidianos_work/tree/main/.agents/skills/note-status ~/.claude/skills/note-status ``` ## README # Note Status ## Usage - `/note-status ` — Check processing status of a specific meeting note. - `/note-status [dates]` — Check all meeting notes matching a date filter. - `/note-status all` — Check every meeting note in the vault. - `/note-status` (no args) — Defaults to `this week`. - `/note-status pending [dates] [--step=]` — Filter to actionable pending notes and prompt the user to select which ones to act on. See [Pending Mode](#pending-mode). ## Processing Checklist A meeting note is **fully processed** when all four frontmatter properties are present: | Step | Property | Set by | Requires | |------|----------|--------|----------| | `notes` | `Notes:` with URLs (not empty/absent) | User or `/cache-notes` prompt | — | | `cache` | `NotesCached:` | `/cache-notes` | `notes` with a supported provider URL | | `participants` | `Participants:` | `/fill-participants` | — | | `todos` | `TodosExtracted:` | `/followup-todos` | — | A note is **pending** when any of these are missing. ### Detection Rules - `Notes:` counts as missing if the property is absent, empty, or contains no URLs. - `NotesCached:` counts as missing if absent. Presence of the timestamp (any value) means cached. - `Participants:` counts as missing if absent. Presence (even `—`) means filled. - `TodosExtracted:` counts as missing if absent. Presence of the timestamp means extracted. ### Dependency Chain Some steps have prerequisites. A note is **actionable** for a step only when the step is missing *and* its prerequisites are met: | Step | Actionable when | |------|-----------------| | `notes` | `Notes:` absent/empty — always actionable | | `cache` | `NotesCached:` absent **and** `Notes:` contains at least one supported provider URL (e.g. `docs.google.com`). Notes with only unsupported URLs (e.g. Otter-only) are not actionable for caching. | | `participants` | `Participants:` absent — always actionable | | `todos` | `TodosExtracted:` absent — always actionable | The dependency chain matters for `--step` filtering (see Pending Mode) and for the status table, where a step can be shown as ❌ (missing but actionable), ⏸️ (missing, blocked by prerequisite), or ✅ (done). ## Date Filtering See [date-filter](../_shared/date-filter.md) for the full syntax and date parsing rules. When `[dates]` is provided, only consider meetings whose date matches. Default (no args): `this week`. ## Workflow See [vault-context](../_shared/vault-context.md) for vault discovery conventions. ### Step 1: Discover meeting files - **Specific file** (``): Read that file directly. - **`pending`** (no other args): query the live Base view — `obsidian base:query path=Meetings.base view=Pending format=paths`. Returns only files missing one or more of the four wrap properties. Use this in preference to a vault-wide scan. - **`pending [dates]`**: same Base query, then post-filter by date from the filename pattern. - **Date-filtered** (`[dates]`, no `pending`): Use QMD — `qmd-search` for `YYYY-MM-DD` date strings in the range under `Meetings/`. For ranges longer than 7 days, search by `YYYY-MM` prefix. - **All**: Use `qmd-multi_get` with glob `Meetings/**/*.md` (or `obsidian files path=Meetings`). ### Step 2: Check the four properties — batch, don't read full files For each discovered file, you only need to know whether each of the four properties is *present and non-empty*. Don't read the full file body. Two efficient options: - **Per-property via Obsidian CLI**: `obsidian property:read name=NotesCached path=""` (and similarly for `Participants`, `TodosExtracted`, `Notes`) — returns empty string when absent. Cheaper than reading the entire file. - **Frontmatter-only via `obsidian properties`**: `obsidian properties path="" format=json` returns the full property map in one call per file. Prefer the second option when checking all four properties at once on the same file (one call instead of four). ### Step 3: Filter by date If `[dates]` was provided, extract the date from the filename (`YYYY-MM-DD` pattern — files use varying formats, don't assume a specific naming convention). Discard files outside the range. ### Step 4: Present status table Display results as a table, sorted oldest-first by date: ``` | # | File | Notes | Cached | Participants | Todos | Date | |---|------|-------|--------|--------------|-------|------| | 1 | Meetings/Engineering/Some Meeting - 2026-02-20.md | ❌ | ⏸️ | ❌ | ❌ | 2026-02-20 | | 2 | Meetings/Engineering/Sync - 2026-02-22.md | ✅ | ✅ | ❌ | ❌ | 2026-02-22 | | 3 | Meetings/Engineering/Scrum/2026-02-25.md | ✅ | ❌ | ✅ | ❌ | 2026-02-25 | ``` - ✅ = done - ❌ = missing and actionable - ⏸️ = missing but blocked (prerequisite not met) After the table, print a summary line: ``` 3 notes checked — 0 fully processed, 3 pending ``` ## Pending Mode **Input**: `/note-status pending [dates] [--step=]` Filters to notes that are pending, presents them, and prompts the user to select which ones to act on. This is the common entry point used by other skills' batch modes. ### Step filtering (`--step`) When `--step` is provided, only show notes where that specific step is **actionable** (missing *and* prerequisites met, per the Dependency Chain). Valid values: `notes`, `cache`, `participants`, `todos`. When `--step` is omitted, show notes where *any* step is missing (what `/meeting wrap pending` needs). ### Workflow 1. Run the standard workflow (Steps 1–4 above) with the given `[dates]` or `all` if omitted. 2. **Filter** — if `--step` is set, keep only notes where that step is actionable. Otherwise keep notes where any step is missing. 3. **Present** the filtered table to the user. 4. **Prompt** the user to select which notes to act on (e.g. "all", "1,3", "none"). 5. **Return** the user's selection as the list of file paths. The calling skill iterates over them. ### Callers | Caller | Invocation | What it does with the selection | |--------|------------|---------------------------------| | `/meeting wrap pending [dates]` | `/note-status pending [dates]` | Runs full wrap sequence on each | | `/cache-notes all` | `/note-status pending --step=cache` | Caches each selected note | | `/fill-participants all` | `/note-status pending --step=participants` | Fills participants for each | | `/followup-todos` (no args) | `/note-status pending --step=todos` | User picks one to extract todos from | ## Important Notes - This is a **read-only** skill — it never modifies files. - Always read a file before checking — frontmatter may have changed since last indexed by QMD. - Do NOT skip files that look "empty" — a note with only frontmatter still needs status tracking. - Files outside `Meetings/` are ignored.