Thought Forest Note Intake

Do not use this skill for the first-pass analysis of a large or multi-topic knowledge passage. Use thought-forest-note-intake-plan first.

Do not use this skill for large-scale cleanup of existing clusters. Use thought-forest-note-refactor or thought-forest-kb-audit first.

Default Workflow

1. Search for duplicates before creating anything.
   • If the input is a large or multi-topic knowledge passage, stop and use thought-forest-note-intake-plan first.
   • Check exact title, aliases, English name, abbreviation, and close variants.
   • Prefer rg against z/ and relevant MOC files.
2. Locate the surrounding context.
   • Find the current main note, nearby synthesis notes, and the nearest MOC.
3. Decide the note role before writing.
   • type/concept for one concept
   • type/synthesis for relations, comparisons, evolution, or learning paths
   • type/moc for navigation
   • type/howto, type/debug, type/resource, type/snippet only when they clearly fit better
4. Decide the action.
   • If a stable main note already exists, update it.
   • If the old note is too mixed, or the approved plan requires broader cluster changes or old entry pages to move, stop and switch to thought-forest-note-refactor.
   • If there is a real gap, create one new note.
5. Reuse the repository template shape.
   • Match template/ for the chosen note type.
   • Keep required frontmatter complete: title, aliases, tags, description, created, updated.
6. Apply tags carefully.
   • At least one type/*
   • At least one status/*
   • One to three topical tags
   • Prefer existing resource/* labels over inventing parallel tags
7. Add lightweight graph links.
   • related notes should stay short
   • relationship explanations belong in synthesis notes
8. Check whether the entry layer also needs work.
   • Update the nearest MOC if the new note changes the reading path
   • Add or update a synthesis note if the value lies in comparison or linkage
9. Keep the scope tight.
   • Do not rewrite an unrelated cluster just because you noticed other issues

Output Standard

The final note should satisfy all of these:

• role is unambiguous
• tags follow current repo dimensions
• no duplicate main note is introduced
• MOC or related notes provide enough navigation
• no old link is broken as a side effect

Guardrails

• Do not invent a new tag family because the current docs feel incomplete.
• Do not create a new note before deduplication.
• Do not let a concept note become a mini MOC.
• Do not let a MOC become a long-form explanation page.
• When uncertain, choose the more conservative and more compatible structure.