| name | note-status |
| description | Verify meeting notes are fully processed. Args: <path>, [dates], all, pending [dates] [--step=X]. Shows which wrap steps are complete or missing. |
| license | MIT |
| compatibility | Requires Obsidian CLI (base:query, property:read/properties) with Obsidian running and Meetings.base (Pending view). QMD optional for date-filtered scans when Bases unavailable. |
Note Status
Usage
/note-status <path> — 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=<step>] — Filter to actionable pending notes and prompt the user to select which ones to act on. See 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 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 for vault discovery conventions.
Step 1: Discover meeting files
- Specific file (
<path>): 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="<file>" (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="<file>" 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=<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
- Run the standard workflow (Steps 1–4 above) with the given
[dates] or all if omitted.
- Filter — if
--step is set, keep only notes where that step is actionable. Otherwise keep notes where any step is missing.
- Present the filtered table to the user.
- Prompt the user to select which notes to act on (e.g. "all", "1,3", "none").
- 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.
