refactor: extract tmux-launch-agent from implement-issue/setup-skills, overhaul PKM skills
- New common/misc/tmux-launch-agent skill with detect-agent script and agents-seed.md (moved from engineering/setup-skills) - implement-issue simplified: delegates agent dispatch to tmux-launch-agent instead of inlining it - setup-skills stripped of Section E (agent CLI config) - New in-progress/agent-handoff skill using tmux-launch-agent - PKM skills simplified: conversation-summary and pkm-curation rewritten with leaner process, crit streamlined - knowledge-gardener removed (moved to common/in-progress/) - All READMEs updated to match
This commit is contained in:
@@ -2,10 +2,10 @@
|
||||
|
||||
## User-invoked
|
||||
|
||||
- [conversation-summary](conversation-summary/SKILL.md) — Summarize the current AI conversation into a new Obsidian markdown note and matching transcript file.
|
||||
- [conversation-summary](conversation-summary/SKILL.md) — Save the current conversation as a comprehensive report note in your Obsidian vault.
|
||||
- [crit](crit/SKILL.md) — Brainstorm with AI using the CRIT framework to generate and evaluate ideas.
|
||||
- [knowledge-gardener](knowledge-gardener/SKILL.md) — Run vault-aware semantic search, synthesis, note creation, linking, and Zettelkasten workflows for this Obsidian vault.
|
||||
- [pkm-curation](pkm-curation/SKILL.md) — Curate an Obsidian-style personal knowledge vault by classifying notes, normalizing frontmatter, improving structure, extracting atomic notes, and adding meaningful wikilinks.
|
||||
- [pkm-curation](pkm-curation/SKILL.md) — Curate an Obsidian vault — classify notes, normalize frontmatter, add wikilinks, extract atomic notes. Use when curating, batch-processing, reviewing, or doing a serendipity pick.
|
||||
- [research-vault](research-vault/SKILL.md) — Research a topic through a one-question-at-a-time learning conversation and save a linked Obsidian research packet.
|
||||
|
||||
## Model-invoked
|
||||
|
||||
@@ -1,224 +1,43 @@
|
||||
---
|
||||
name: conversation-summary
|
||||
description: Summarize the current AI conversation into a new Obsidian markdown note and matching transcript file. Use when the user asks to save, export, log, archive, or summarize the current chat into an Obsidian vault, research note, markdown note, meeting note, decision log, or second-brain workflow.
|
||||
description: Save the current conversation as a comprehensive report note in your Obsidian vault.
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
Create exactly one new Obsidian summary note for the current conversation. Also create exactly one transcript note for the same conversation.
|
||||
Save this conversation as two linked files in your Obsidian vault: a report (the narrative) and a transcript (the raw conversation).
|
||||
|
||||
## Default location
|
||||
## Report
|
||||
|
||||
- Write notes to `obsidian vault` unless the user requests another path.
|
||||
- Ask if you don't know the location of the obsidian vault.
|
||||
- Create the directory if it does not exist.
|
||||
- Never overwrite an existing note.
|
||||
- Never append to an existing note unless the user explicitly asks.
|
||||
Write a thorough, standalone report as a Markdown note. A rich narrative in prose, organized under natural headings that follow the conversation's own shape. Capture everything of substance:
|
||||
|
||||
## Required behavior
|
||||
- What prompted the conversation and what context was shared
|
||||
- What was explored, investigated, or discussed in detail — including code, files, paths, URLs, tools, or skills that came up
|
||||
- What was found, decided, agreed, or concluded
|
||||
- Explanations given and concepts clarified
|
||||
- Open questions or unresolved items
|
||||
|
||||
1. Read the current conversation context only.
|
||||
2. Generate a filesystem-safe title.
|
||||
3. Write one summary note.
|
||||
4. Write one transcript note.
|
||||
5. Verify both files exist.
|
||||
6. Return the exact paths, generated title, and count of action items captured.
|
||||
The report must be self-contained — someone reading it later should understand the full discussion, including the reasoning and all relevant details, without having been there. Err on the side of including too much detail rather than too little.
|
||||
|
||||
## Title rules
|
||||
Include a link to the companion transcript where it fits naturally — an Obsidian wikilink like `[[{{title}}_transcript]]` in the section where it makes the most sense (often near the end).
|
||||
|
||||
Use this format:
|
||||
## Transcript
|
||||
|
||||
`YYYY-MM-DD_HH-mm_<descriptor>_<ID>`
|
||||
Save the raw conversation as a separate Markdown note alongside the report. Keep it chronological with no editorializing. Redact likely credentials, secrets, tokens, and private keys.
|
||||
|
||||
Rules:
|
||||
- `<descriptor>`: 3-6 word slug based on the main topic.
|
||||
- Allowed characters in the full title: letters, digits, `.`, `_`, `-`.
|
||||
- Replace spaces with `-`.
|
||||
- Remove other punctuation.
|
||||
- Collapse repeated separators.
|
||||
- `<ID>`: 4-character uppercase alphanumeric suffix.
|
||||
- If a filename collision occurs, regenerate only `<ID>` until unique.
|
||||
- If too long for the filesystem, shorten only `<descriptor>`.
|
||||
## Location
|
||||
|
||||
## Obsidian-specific rules
|
||||
Save both files to `AI Conversation Summaries/` under your vault root. Create the directory if needed. Never overwrite existing notes — if a filename collides, append a numeric suffix.
|
||||
|
||||
- Use valid YAML frontmatter.
|
||||
- Keep frontmatter simple and machine-safe.
|
||||
- Use wikilink-friendly filenames.
|
||||
- Include both standard markdown links and Obsidian wikilinks where useful.
|
||||
- Keep headings shallow and scannable.
|
||||
- Use UTF-8 markdown.
|
||||
- Prefer stable tags in frontmatter plus inline hashtag tags at the end.
|
||||
- If the conversation mentions files, URLs, papers, repos, tools, docs, or paths, capture them in a dedicated `References` section.
|
||||
- If the conversation includes explicit choices, approvals, rejections, or resolved tradeoffs, capture them in `Decisions Made`.
|
||||
## Filenames
|
||||
|
||||
## Summary quality rules
|
||||
- Report: `YYYY-MM-DD_HH-mm_<topic-slug>.md`
|
||||
- Transcript: `YYYY-MM-DD_HH-mm_<topic-slug>_transcript.md`
|
||||
|
||||
- Use only facts available in the current conversation.
|
||||
- Do not invent references, decisions, action items, or conclusions.
|
||||
- Do not write a play-by-play transcript in the summary note.
|
||||
- Synthesize the conversation into a compact research/work summary.
|
||||
- If information is missing, say so explicitly.
|
||||
- If the conversation is short, still use the full template with fallback lines.
|
||||
- If the transcript available to you is incomplete, mark it as partial.
|
||||
## Safety
|
||||
|
||||
## Automatic tags
|
||||
- Use only facts from the conversation. Do not invent references, decisions, or conclusions.
|
||||
- Redact likely credentials, secrets, tokens, and private keys from any inline content.
|
||||
|
||||
Generate 4-8 tags total.
|
||||
## Done
|
||||
|
||||
Always include:
|
||||
- `ai-summary`
|
||||
- one domain/topic tag based on the conversation
|
||||
- one workflow tag based on the type of work, if clear
|
||||
|
||||
Add tags from these categories when supported by the conversation:
|
||||
- domain: `research`, `coding`, `obsidian`, `automation`, `writing`, `planning`, `debugging`
|
||||
- artifact: `skill`, `note`, `transcript`, `review`, `decision-log`
|
||||
- status: `draft`, `completed`, `follow-up`
|
||||
- technology/tool names in lowercase slug form when clearly central
|
||||
|
||||
Tag rules:
|
||||
- Use lowercase kebab-case only.
|
||||
- Prefer specific tags over generic ones.
|
||||
- Do not add unsupported tags.
|
||||
|
||||
## References capture
|
||||
|
||||
In the `References` section, capture conversation-specific source material that was explicitly mentioned or used, such as:
|
||||
- local file paths
|
||||
- URLs
|
||||
- repository paths
|
||||
- document names
|
||||
- tool names
|
||||
- named skills, scripts, or commands
|
||||
|
||||
Format each reference as one bullet with a short label and what it was used for.
|
||||
|
||||
If none were mentioned, write:
|
||||
- `- No explicit references or source artifacts captured.`
|
||||
|
||||
## Decisions capture
|
||||
|
||||
Capture only explicit decisions. Include items such as:
|
||||
- accepted approach
|
||||
- rejected alternative
|
||||
- agreed file location
|
||||
- approved implementation direction
|
||||
- confirmed formatting preference
|
||||
|
||||
If none were made, write:
|
||||
- `- No explicit decisions captured.`
|
||||
|
||||
## Transcript rules
|
||||
|
||||
- Save transcript in a separate file named `{{title}}_transcript.md`.
|
||||
- Keep chronological order.
|
||||
- Redact likely secrets or credentials.
|
||||
- Add `[Transcript may be partial]` at the top if the available transcript is incomplete.
|
||||
- Do not inline the full transcript inside the summary note.
|
||||
|
||||
## Summary note template
|
||||
|
||||
```md
|
||||
---
|
||||
id: {{title}}
|
||||
aliases:
|
||||
- {{descriptor}}
|
||||
- {{short human title}}
|
||||
tags:
|
||||
- ai-summary
|
||||
- {{tag1}}
|
||||
- {{tag2}}
|
||||
- {{tag3}}
|
||||
created: {{ISO-8601 timestamp}}
|
||||
source: current-ai-conversation
|
||||
conversation_type: {{research|coding|planning|review|general}}
|
||||
status: {{draft|completed|follow-up}}
|
||||
---
|
||||
|
||||
# {{short human title}}
|
||||
|
||||
> [!abstract]
|
||||
> **Created:** {{ISO-8601 timestamp}}
|
||||
> **Source:** Current AI conversation
|
||||
> **Main Topic:** {{one sentence, 8-20 words}}
|
||||
|
||||
## Research Question / Objective
|
||||
{{One concise sentence. If none: `Not explicitly provided.`}}
|
||||
|
||||
## Summary
|
||||
{{3-5 sentences synthesizing the main discussion, findings, constraints, and outcome. If none: `No meaningful summary could be derived beyond the limited conversation context.`}}
|
||||
|
||||
## Key Points
|
||||
- {{3-7 concrete bullets}}
|
||||
|
||||
## Decisions Made
|
||||
- {{explicit decision}}
|
||||
|
||||
## Action Items
|
||||
- [ ] {{explicit next step}}
|
||||
|
||||
## Limitations / Unresolved Assumptions
|
||||
- {{limitation or assumption}}
|
||||
|
||||
## Open Questions
|
||||
- {{unresolved question}}
|
||||
|
||||
## References
|
||||
- {{reference label}} — {{why it mattered}}
|
||||
|
||||
## Related Notes
|
||||
- Transcript: [[{{title}}_transcript]]
|
||||
- Markdown link: [{{title}}_transcript.md]({{title}}_transcript.md)
|
||||
|
||||
## Tags
|
||||
#ai-summary {{inline_tags}}
|
||||
```
|
||||
|
||||
## Transcript template
|
||||
|
||||
```md
|
||||
[Transcript may be partial]
|
||||
|
||||
# {{short human title}} — Transcript
|
||||
|
||||
**Summary Note:** [[{{title}}]]
|
||||
**Created:** {{ISO-8601 timestamp}}
|
||||
|
||||
{{verbatim conversation transcript with likely secrets redacted}}
|
||||
```
|
||||
|
||||
If the transcript is complete, omit the `[Transcript may be partial]` line.
|
||||
|
||||
## Fallback lines
|
||||
|
||||
Use these exact fallbacks when needed:
|
||||
- Decisions Made: `- No explicit decisions captured.`
|
||||
- Action Items: `- [ ] No explicit action items identified.`
|
||||
- Limitations / Unresolved Assumptions: `- No limitations or unresolved assumptions captured.`
|
||||
- Open Questions: `- No open questions identified.`
|
||||
- References: `- No explicit references or source artifacts captured.`
|
||||
|
||||
## File paths
|
||||
|
||||
- Summary: `AI Conversation Summaries/{{title}}.md`
|
||||
- Transcript: `AI Conversation Summaries/{{title}}_transcript.md`
|
||||
|
||||
## Safety rules
|
||||
|
||||
- Never overwrite existing notes.
|
||||
- Never fabricate transcript lines.
|
||||
- Never fabricate references or decisions.
|
||||
- Redact likely credentials, secrets, tokens, and private keys.
|
||||
- If writing fails, return the full markdown for both files plus intended paths.
|
||||
- If required context is unavailable, state that clearly in the note instead of guessing.
|
||||
|
||||
## Final response format
|
||||
|
||||
Confirm success with:
|
||||
- summary file path
|
||||
- transcript file path
|
||||
- generated title
|
||||
- number of action items captured
|
||||
- tags generated
|
||||
- number of references captured
|
||||
- number of explicit decisions captured
|
||||
Confirm both file paths and a one-sentence description of what the report covers.
|
||||
|
||||
@@ -6,7 +6,7 @@ disable-model-invocation: true
|
||||
|
||||
## Purpose
|
||||
|
||||
This skill implements the CRIT (Context-Request-Input-Tone) framework for structured brainstorming and idea evaluation. It transforms abstract discussions into concrete, actionable outcomes through systematic analysis and iterative refinement.
|
||||
This skill implements the CRIT (Context-Request-Ideation-Tone) framework for structured brainstorming and idea evaluation.
|
||||
|
||||
## Core Workflow
|
||||
|
||||
@@ -23,7 +23,7 @@ Before generating ideas, establish the foundation:
|
||||
- What has been tried before (if applicable)?
|
||||
- What resources are available?
|
||||
|
||||
**Completion Criterion**: Clear understanding of domain, constraints, and current state documented.
|
||||
**Completion Criterion**: Domain, constraints, and current state captured in a compact summary (3-5 sentences).
|
||||
|
||||
### Step 2: Request Clarification
|
||||
Structure the brainstorming request:
|
||||
@@ -38,9 +38,9 @@ Structure the brainstorming request:
|
||||
- What assumptions should be validated?
|
||||
- What data or resources are required?
|
||||
|
||||
**Completion Criterion**: Specific goal and input requirements clearly defined.
|
||||
**Completion Criterion**: Goal and input requirements captured as 1-3 concrete statements, each with a checkable success criterion.
|
||||
|
||||
### Step 3: Idea Generation
|
||||
### Step 3: Ideation
|
||||
Generate diverse, high-quality ideas:
|
||||
|
||||
1. **Divergent Thinking Phase**
|
||||
@@ -86,34 +86,5 @@ Adapt communication to the audience:
|
||||
- Include examples or analogies for clarity
|
||||
- Suggest next steps and follow-up questions
|
||||
|
||||
**Completion Criterion**: Response delivered in appropriate tone with clear structure.
|
||||
|
||||
## Quality Guardrails
|
||||
|
||||
- Never generate ideas without clear context and goals
|
||||
- Always evaluate ideas against defined success criteria
|
||||
- Maintain transparency about assumptions and limitations
|
||||
- Encourage iteration and collaboration throughout the process
|
||||
- Ensure all recommendations are practical and actionable
|
||||
|
||||
## Trigger Hints
|
||||
|
||||
Load this skill when the user asks to:
|
||||
- Generate ideas for a specific problem or opportunity
|
||||
- Brainstorm solutions with structured evaluation
|
||||
- Get expert guidance through systematic analysis
|
||||
- Develop actionable plans from abstract concepts
|
||||
- Evaluate multiple approaches to a challenge
|
||||
|
||||
## Output Format
|
||||
|
||||
Return results in this structure:
|
||||
|
||||
1. **Context Analysis**: Documented understanding of domain and constraints
|
||||
2. **Request Clarification**: Defined goals and input requirements
|
||||
3. **Idea Generation**: List of ideas with evaluation scores
|
||||
4. **Refined Solutions**: Detailed action plans for top candidates
|
||||
5. **Next Steps**: Suggested follow-up actions and questions
|
||||
|
||||
Each section should be clearly labeled and include completion criteria verification.
|
||||
**Completion Criterion**: Response delivered in chosen role with sections clearly labeled (Context, Request, Ideation, Refinement, Next Steps).
|
||||
|
||||
|
||||
@@ -1,106 +0,0 @@
|
||||
---
|
||||
name: knowledge-gardener
|
||||
description: Run vault-aware semantic search, synthesis, note creation, linking, and Zettelkasten workflows for this Obsidian vault.
|
||||
metadata:
|
||||
vault_style: para-plus-zettelkasten
|
||||
default_write_folder: Inbox
|
||||
daily_folder: Dailies
|
||||
templates_folder: Templates
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
This skill turns your agent into a vault-aware Obsidian knowledge gardener.
|
||||
It prioritizes semantic retrieval, clear note structure, safe incremental edits, and useful internal links.
|
||||
|
||||
## Vault Conventions
|
||||
|
||||
- Preserve folder casing and names used in this vault: `Inbox/`, `Dailies/`, `projects/`, `resources/`, `archive/`, `Templates/`.
|
||||
- Use Obsidian wikilinks: `[[Note Title]]`.
|
||||
- Keep existing frontmatter schema compatible with existing notes:
|
||||
|
||||
```yaml
|
||||
---
|
||||
id: <slug-or-date-id>
|
||||
aliases: []
|
||||
tags: []
|
||||
area: ""
|
||||
project: ""
|
||||
---
|
||||
```
|
||||
|
||||
- Default location for new AI-generated notes is `Inbox/` unless explicitly asked otherwise.
|
||||
|
||||
## Core Workflows
|
||||
|
||||
1. Semantic Search
|
||||
- Use `python tools/obsidian_semantic_query.py --vault-root . --query "..." --k 12`.
|
||||
- Return ranked notes with short relevance rationale.
|
||||
|
||||
2. Summarization
|
||||
- Retrieve nearest notes first, then synthesize.
|
||||
- Include conflicts, unknowns, and suggested next notes.
|
||||
|
||||
3. New Note Creation
|
||||
- Create with canonical frontmatter.
|
||||
- Include `## Summary` and optional scaffold sections.
|
||||
- If a summary is provided, include it verbatim under `## Summary`.
|
||||
|
||||
4. Automatic Linking
|
||||
- Suggest links from semantically related notes.
|
||||
- Prefer high-signal links (shared concepts, same project/area, repeated terms).
|
||||
|
||||
5. Refactor to Atomic Notes
|
||||
- Split long mixed-topic notes into smaller notes.
|
||||
- Keep parent note as a structure note and link to children.
|
||||
|
||||
6. Metadata Maintenance
|
||||
- Keep `id`, `aliases`, `tags`, `area`, `project` valid.
|
||||
- Suggest tags from note content; avoid noisy tag spam.
|
||||
|
||||
7. Research Capture
|
||||
- Store source summary in vault.
|
||||
- Extract key claims, evidence, confidence, and follow-up questions.
|
||||
- Distinguish raw source claims, agent synthesis, user opinions, and open questions.
|
||||
- Convert durable insights into permanent notes.
|
||||
|
||||
8. Compiled Wiki Maintenance
|
||||
- For bounded research topics, maintain a Karpathy-style compiled wiki layer: immutable raw sources → maintained concept/claim/synthesis notes → retrievable answers.
|
||||
- On ingest, update existing pages before creating duplicates; the graph should get denser, not just larger.
|
||||
- File durable query answers back into notes, then add or update links from indexes/MOCs.
|
||||
- Keep a lightweight log of ingests, filed answers, lint passes, promotions, and major corrections when the folder has a `Log.md` or equivalent.
|
||||
|
||||
9. Retrieval Lint
|
||||
- Check for unsupported claims, stale or contradictory claims, orphan notes, missing backlinks, missing glossary terms, and unanswered questions.
|
||||
- Verify a future agent can answer the main question from the maintained notes without rereading raw sources.
|
||||
|
||||
10. Packet Promotion
|
||||
- Treat research packets as incubators and the main vault as the indexed library.
|
||||
- Promote notes only when they are reusable beyond the packet, stand alone, have evidence/provenance, and connect to existing vault concepts.
|
||||
- Leave a link behind in the packet and update relevant indexes/MOCs.
|
||||
|
||||
11. Zettelkasten Conversion
|
||||
- Convert source note into atomic permanent notes.
|
||||
- Add explicit links and one short structure note (MOC-lite) when useful.
|
||||
|
||||
## Quality Guardrails
|
||||
|
||||
- Never delete user content unless explicitly requested.
|
||||
- Prefer additive edits and clear section boundaries.
|
||||
- Keep writing concise and skimmable.
|
||||
- Keep tags focused and reusable.
|
||||
- Keep citations close to claims; do not let synthesized notes obscure source provenance.
|
||||
- Before finalizing research edits, run a retrieval check: likely future questions should have obvious entry points through indexes, links, claims, or glossary terms.
|
||||
- Rebuild semantic index after major note creation/refactor sessions.
|
||||
|
||||
## Operational Commands
|
||||
|
||||
- Build index: `python tools/obsidian_semantic_index.py --vault-root .`
|
||||
- Query index: `python tools/obsidian_semantic_query.py --vault-root . --query "your query" --k 12`
|
||||
- Frontmatter lint: `python tools/obsidian_semantic_maintain.py lint --vault-root .`
|
||||
- Related notes: `python tools/obsidian_semantic_maintain.py related --vault-root . --note "Inbox/your-note.md" --k 8`
|
||||
|
||||
## Trigger Hints
|
||||
|
||||
Load this skill when the user asks to search, summarize, connect, refactor, or organize Obsidian notes.
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: pkm-curation
|
||||
description: Curate an Obsidian-style personal knowledge vault by classifying notes, normalizing frontmatter, improving structure, extracting atomic notes, and adding meaningful wikilinks.
|
||||
description: Curate an Obsidian vault — classify notes, normalize frontmatter, add wikilinks, extract atomic notes. Use when curating, batch-processing, reviewing, or doing a serendipity pick.
|
||||
---
|
||||
|
||||
# PKM Curation
|
||||
@@ -9,11 +9,10 @@ Use this skill when working inside a Markdown-first vault that values curation o
|
||||
|
||||
## Goals
|
||||
|
||||
- Turn raw notes into clear, reusable notes.
|
||||
- Turn raw notes into reusable atomic notes.
|
||||
- Keep new notes consistent with vault conventions.
|
||||
- Strengthen the link graph with meaningful `[[wikilinks]]` syntax `[[Note Title]]`.
|
||||
- Strengthen the link graph with meaningful `[[wikilinks]]`.
|
||||
- Extract atomic notes from long or mixed-topic notes.
|
||||
- Avoid unnecessary reorganization and weak links.
|
||||
|
||||
## Read This First
|
||||
|
||||
@@ -23,9 +22,7 @@ Use this skill when working inside a Markdown-first vault that values curation o
|
||||
- Keep changes small and reviewable.
|
||||
- Keep file operations local to the vault unless the user explicitly asks otherwise.
|
||||
|
||||
## Workflows
|
||||
|
||||
## Search for notes
|
||||
## Search
|
||||
|
||||
```bash
|
||||
# Search by filename
|
||||
@@ -33,33 +30,15 @@ fd --type f ".md" "path/to/obsidian-vault" | rg -i "keyword"
|
||||
|
||||
# Search by content
|
||||
rg -l "keyword" "path/to/obsidian-vault" --include "*.md"
|
||||
```
|
||||
|
||||
## Curate existing note
|
||||
1. Inspect the target note or note set.
|
||||
2. Identify the note type: inbox, source, atomic, project, daily, or reference.
|
||||
3. Normalize frontmatter and basic structure.
|
||||
4. Clarify the title if the current one is vague or timestamp-like.
|
||||
5. Summarize or distill the note if it mixes too many ideas.
|
||||
6. Add or suggest meaningful `[[wikilinks]]` to related notes.
|
||||
7. If a note contains multiple durable ideas, extract 1-3 atomic notes.
|
||||
8. Suggest moving the note only if the destination is clearly better.
|
||||
|
||||
## Find related notes
|
||||
|
||||
Search for `[[Note Title]]` across the vault to find backlinks:
|
||||
|
||||
```bash
|
||||
# Find backlinks to a note
|
||||
rg -l "\\[\\[Note Title\\]\\]" "path/to/obsidian-vault" --include "*.md"
|
||||
```
|
||||
|
||||
### Find index notes
|
||||
|
||||
```bash
|
||||
# Find index notes
|
||||
fd --type f "Index" "path/to/obsidian-vault"
|
||||
```
|
||||
|
||||
## Operating Rules
|
||||
## Rules
|
||||
|
||||
- Prefer curation over reorganization.
|
||||
- Do not move, rename, or delete many notes at once unless the user asks.
|
||||
@@ -149,16 +128,17 @@ Keep extracted notes short. One note, one idea.
|
||||
|
||||
### Curate one note
|
||||
|
||||
- inspect the note
|
||||
- identify note type
|
||||
- normalize frontmatter
|
||||
- tighten headings and summary
|
||||
- add a few strong links
|
||||
- suggest extracted atomic notes if warranted
|
||||
- locate the target file in the vault
|
||||
- inspect nearby related notes before adding links
|
||||
- patch the note in place
|
||||
- return a short summary of edits and suggested follow-up notes
|
||||
1. Inspect the target note and locate its file in the vault.
|
||||
2. Identify the note type: inbox, source, atomic, project, daily, or reference.
|
||||
3. Normalize frontmatter and basic structure.
|
||||
4. Clarify the title if vague or timestamp-like.
|
||||
5. Tighten headings and summary; distill if it mixes too many ideas.
|
||||
6. Inspect nearby related notes, then add a few strong `[[wikilinks]]`.
|
||||
7. If the note contains multiple durable ideas, extract 1-3 atomic notes.
|
||||
8. Suggest moving only if the destination is clearly better.
|
||||
9. Patch the note in place and return a short summary of edits.
|
||||
|
||||
**Completion Criterion**: Note inspected, classified, normalized, linked, and patched, with a summary returned to the user.
|
||||
|
||||
### Curate an inbox batch
|
||||
|
||||
@@ -171,6 +151,8 @@ Keep extracted notes short. One note, one idea.
|
||||
- process them one at a time
|
||||
- stop and summarize after each batch
|
||||
|
||||
**Completion Criterion**: Each note in the batch classified and normalized, with a summary returned after the batch.
|
||||
|
||||
### Review recent notes
|
||||
|
||||
- inspect recently edited notes
|
||||
@@ -180,6 +162,8 @@ Keep extracted notes short. One note, one idea.
|
||||
- search by recent filenames or recent folders when file metadata is available
|
||||
- keep edits conservative and return a review summary
|
||||
|
||||
**Completion Criterion**: Recently edited notes inspected, missing links and mixed concerns flagged, with a review summary returned.
|
||||
|
||||
### Serendipity review
|
||||
|
||||
- choose a note from the vault
|
||||
@@ -189,6 +173,8 @@ Keep extracted notes short. One note, one idea.
|
||||
- pick one note from a user-specified folder or from curated folders only
|
||||
- avoid randomizing across obviously raw capture unless the user asks for that
|
||||
|
||||
**Completion Criterion**: One curated note chosen, briefly summarized, compared to active topic, with only high-confidence connections suggested.
|
||||
|
||||
## Output Style
|
||||
|
||||
When responding to the user:
|
||||
|
||||
Reference in New Issue
Block a user