vault-tech-note
Skill4 starsChanged 40 days agoMITView on GitHub
Trigger: technical note, tech note, vault note, documentation note, nota técnica. Write learning-first tech notes for an Obsidian vault with verified sources.
In this repository18 other files it gives its agents.
- api-designSkill
- changelog-maintenanceSkill
- code-mentorSkill
- create-readmeSkill
- database-designSkill
- dockerSkill
- frontend-design-anti-slopSkill
- frontend-engineeringSkill
- git-commitSkill
- github-essentialsSkill
- java-junitSkill
- java-springbootSkill
- java-springboot-testingSkill
- latexSkill
- solution-designSkill
- ui-componentsSkill
- update-readmeSkill
- web-mvcSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Not for: project plans, design decisions, Kanban boards, or config guides — those have their own note types.
- Distinctive: line 18
Never state a version, API, or behavior from memory.
- Distinctive: line 21
Every note links upward to its domain index, and the index links back.
- Distinctive: line 22
Never invent the vault's rules.
- Very specific: line 23
Follow references/note-anatomy.md.
- Distinctive: line 46
Read the vault README.md; locate the domain index and search for an existing note.
- Distinctive: line 50
Add "Pruébate": 5–9 questions in collapsible callouts designed to catch wrong mental models.
- Distinctive: line 52
Verify every version and API claim against its owning source, then confirm frontmatter parses, links resolve, and the note covers one topic.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Activation Contract
Load when asked to create, extend, or refactor a technical note in the user's Obsidian vault, for any language, library, or tool (Java, Docker, Spring, SQL...).
Not for: project plans, design decisions, Kanban boards, or config guides — those have their own note types.
Hard Rules
- Never state a version, API, or behavior from memory. Verify it against the source that owns the fact.
- One note = one topic. Two topics means two notes, cross-linked.
- Frontmatter in English; body in the user's language; code and identifiers always English.
- Every note links upward to its domain index, and the index links back.
- Never invent the vault's rules. Read the vault
README.mdfirst: it is the contract. - Follow
references/note-anatomy.md. Do not improvise sections.
Decision Gates
Which source owns the fact:
| Fact is about | Source |
| Release status, JEP, "final or preview in which version" | Web search (OpenJDK JEPs, release notes) |
| API, config, or syntax of a library/framework | context7 — resolve the ID, pass the target version |
| Language or JDK behavior | Official javadocs (web) |
Cross-check two sources when in doubt.
One topic or two:
| Signal | Action |
| Needs two "La idea" images | Split into two notes |
| Two stacks or audiences in one file | Split |
Execution Steps
- Read the vault
README.md; locate the domain index and search for an existing note. Update instead of duplicating. - Draft "La idea": the mental model that derives the rules below it, not a summary of them.
- Fill the rest of the anatomy from
references/note-anatomy.md, starting from the vault's tech-note template, and match the bar inreferences/exemplar.md. - Build "Ejemplo trabajado" from a real problem: transformations first, then code, then a variation.
- Add "Pruébate": 5–9 questions in collapsible callouts designed to catch wrong mental models.
- Link the note to its domain index and add it to that index.
- Verify every version and API claim against its owning source, then confirm frontmatter parses, links resolve, and the note covers one topic.
Output Contract
Return: the note path; its section list; every claim with the source used to verify it; confirmation it was added to its domain index. If a vault rule is unclear, report it instead of guessing.
References
references/note-anatomy.md— section-by-section spec of a learning tech note.references/exemplar.md— a condensed real note; the quality bar to match.- Vault
README.md— the vault contract (paths, frontmatter, types, linking).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.