Journaling

A journal is your structured long-term memory mechanism — experience, decisions, research, and methodology accumulated across sessions. With a journal, a later session can continue directly from where an earlier one stopped: read state, pick up work, avoid past pitfalls.

The Journal

The journal lives at <journal-root> and consists of:

• INDEX.md — cover page and dashboard. The journal's single entry point; shows current state signals. Every journal operation starts here.
• Rules document (RULES.md) — single entry point for rules; defines how this journal operates: INDEX structure, classification, note metadata fields, writing conventions, etc. Content is defined by the journal itself; the seed provides the initial scheme.
• Entries — individual notes. Entry organization (directories, lifecycle, etc.) is defined by journal rules.

Before You Begin

This skill's protocols depend on <journal-root>/INDEX.md context — the journal's current state and operating context (what's in progress, what needs attention, what you've learned before). If you have not read INDEX.md this session, open it now.

Operating without INDEX.md means operating blind.

Other reference documents load on demand per the references within each protocol.

Linked Files

• Init Protocol
• Discovery Contract Design Guide
• Write Protocol
• Note Writing Guide
• Frontmatter Specification
• Non-Read-Only Operations Reference
• Maintenance Protocol
• INDEX.md Specification
• INDEX Design Reference
• Rules Specification
• Rule Design Guide
• Project Dashboard Pattern
• Layered Rules Pattern
• Note Tags Pattern
• Maintenance Memo Pattern
• Classification Systems
• Script Tools Guide
• Templates

Scripts

The scripts/ directory provides dependency-free convenience tools (frontmatter, check-links), in both Python and Node.js versions. Full guide in references/script-tools.md.

Operating Principles

• The journal serves you, not the user — the autonomy domain covers writing and user-guided operations. You write it for your future self. Entry placement, splits, cross-references — these depend on patterns only you see; within the autonomy domain the decision and execution are yours. Dedicated maintenance is outside the autonomy domain: it is triggered only by the user, as a dedicated action (see the maintenance protocol).

• Tags follow journal rules — the tag system is self-managed by the journal. Before writing, read the tag-related content in the journal rules; when the rules define no tags, distill short words from content, purpose, etc. into the tags field.

• Directory placement is judged by journal rules — read before writing. Before writing, read the journal rules document (classification section) to decide which directory the content belongs to; when undefined, use the seed scheme. Directory placement is a content-organization decision, owned by journal rules, not prescribed by this skill.

• Verify actual entry state before proposing improvements — the spec is ideal, the disk is truth. Check files before recommending changes.

• Capture discussion decisions immediately. When the user confirms a design decision, write it to the target project document in the same turn. Do not defer to the journal; a journal summary can follow later during maintenance.

• Deletion handling is judged by journal rules — routed via the non-read-only operations reference. Deletion gets minimal guidance there and executes per the journal rules' deletion conventions; this skill presets no deletion protocol and no deletion semantics.