Add project structure documentation (AGENTS.md) and initial README files that organize skills by bucket and invocation type (user-invoked vs model-invoked). Introduce three skills: - forge-interaction: GitHub/Gitea CLI automation for issues, PRs, releases - forge-preferences: personal forge conventions (companion to forge-interaction) - pkm-curation: Obsidian vault curation and note management Include reference docs for vault conventions, agent integration, and the invocation model that separates user-only from model-reachable skills.
1.5 KiB
1.5 KiB
id, aliases, tags, area, project
| id | aliases | tags | area | project | |||||
|---|---|---|---|---|---|---|---|---|---|
| pkm-curation-vault-conventions |
|
|
Personal Knowledge Management |
Vault Conventions
Required Frontmatter
All notes should include YAML frontmatter with:
---
id: unique-id
aliases: []
tags: []
area: Primary area/domain
project: [[Project Note]]
---
Use an empty value for project: when there is no relevant project note.
Core Principles
- Markdown-first
- explicit
[[wikilinks]] - atomic notes for durable ideas
- project, topic, and date-based organization
- consistency over novelty
Folder Roles
Inbox/: raw capture and unprocessed notesDailies/: day-specific notes and reflectionTemplates/: note templatesKnowledge/: preferred home for evergreen atomic notes if the folder exists or is created- project/topic folders: active work and structured reference material
Task Conventions
- Use Markdown task items:
- [ ] Task description [[Project Name]] - Add status and priority tags where useful
- Use
due:: YYYY-MM-DDfor due dates - Add
start::andend::only when explicitly requested or when tracking active work
Curation Heuristics
- A saved thing is not yet a knowledge note.
- A source note is not the same as an evergreen note.
- A link should reflect a real conceptual or project relationship.
- A long note may remain long if it is reference material; only extract notes when reuse is likely.
- Prefer gradual improvement over mass refactoring.