Generate or update the description frontmatter property for a note. Selects Summary mode or Meta mode based on content type. Use when asked to create a description frontmatter summary for a note.
Generate a description property for $ARGUMENTS and write it to the note's YAML frontmatter.
If no note is specified, ask which note to summarize before proceeding.
Act as a markdown file analysis assistant. Read the note and generate a description for discoverability. Either follow any specified mode or intelligently select based on content type.
If the user specifies a mode, use it. Otherwise, select based on content type:
These are documents where the insights or events are the value—you likely won't re-read the whole thing, you need the crystallized takeaway or memory anchor.
These are documents you retrieve by need—you're searching for something that solves a problem or answers a question, not recalling what you concluded.
Evaluate what the document fundamentally is (rather than looking at individual sentences to infer purpose). If signals conflict, default to the document's primary purpose:
Hybrid documents (e.g., daily log containing a reusable process): Default to the document's primary purpose. A daily log with an incidental process note is still a daily log—use summary and mention the process as a notable item. If the process becomes valuable enough, it should be extracted to its own note.
Meeting notes: Use summary. Focus on decisions, action items, and key discussion points—not "Notes from the Q3 planning meeting. Use when..."
Book/article notes:
Specs, briefs, proposals: Use meta. These are structural documents—readers need to know what problem space they address, not a summary of their conclusions.
Stubs and placeholders: Use meta. Describe intended purpose: "Placeholder for API authentication documentation. Use when documenting the auth flow."
Content that defies categorization: Default to summary. Capturing what's actually there is more useful than a vague meta-description of ambiguous content.
Create a concise 1-2 sentence summary crystallizing what the content says—insights, conclusions, main points. For logs, include memorable events, proper nouns, and landmarks that jog memory. For exploratory content, capture main themes.
Write in telegraphic style: use semicolons, commas, and dashes to separate ideas rather than conjunctive adverbs or transition words (avoid "followed by", "and then", "however", "moreover" etc. unless truly needed for comprehension). Substance over connective tissue.
For periodic notes:
"Timeline padding 20-30% prevents Acme Corp delays; upfront alignment with Sarah's team saves more time than detailed technical planning.""Struggling to delegate Marcus's onboarding—equate doing it myself with caring; reframe delegation as trust-building.""Productive morning on Shopify integration; afternoon derailed—AWS outage, mom's appointment; Kleppmann reading exposed distributed systems gaps."Describe what this document IS—type, purpose, scope—plus when to reference it. Follow the What + When pattern:
[Document type/topic] [scope or focus]. Use when [explicit trigger conditions].
Be specific about trigger conditions. "Use when relevant" is useless; "Use when debugging authentication failures or onboarding new backend engineers" is searchable.
For periodic notes in meta mode (rare, but possible if requested): focus on domains, projects, or themes as searchable anchors.
"Guide to vault metadata conventions and Base file integration. Use when designing folder structure, troubleshooting queries, or onboarding to the knowledge system.""Template for project retrospectives with prompts for timeline, collaboration, and technical debt. Use when closing out projects or preparing team retros.""Reading list on distributed systems with progress notes. Use when selecting next technical reading or recommending resources to others.""Spec for Shopify inventory sync covering error handling and retry logic. Use when implementing inventory features or debugging sync failures."Stay under 1024 characters for the description value; avoid paragraph length.
Add or update the description property in the YAML frontmatter at this position:
description: "your summary here"For periodic notes:
When summarizing a parent note (like a periodic weekly note) that links to component child notes (like daily notes) via properties like related or body links:
description properties in their frontmatterThis creates hierarchical abstraction where each level captures the essence of its component parts.
Note: Some expected child notes (like a specific daily note) may not exist — that simply means one may not have been created for that period.