Add journal skill for local note capture with delegated docs and ticket export

[bracyw]

Problem Statement

Good thoughts, half-formed decisions, and research surface constantly while working, but there's no low-friction place to park them. Filing an issue or writing docs mid-task derails the current work, so notes get lost. There's also no bridge from a rough local note to the right permanent home (an ADR, a CONTEXT term, an issue, a PRD) that respects existing conventions.

Solution

A journal skill with two clearly-separated halves. Capture is local, formless, and git-free: notes drop into a gitignored .journal/ folder, so there is zero ceremony and nothing to push. Export is a deliberate, opt-in dispatcher: when a note is ripe, the skill proposes the best-fit destination and hands the note off to whichever existing skill already owns that kind of output. The journal never reimplements formatting, ticketing, or branching — it captures and routes.

User Stories

1. As a developer mid-task, I want to jot a note without leaving my flow, so that a good thought is not lost.
2. As a developer, I want notes stored locally and gitignored, so that capturing costs nothing and commits nothing.
3. As a developer, I want to organize notes into categories (subfolders), so that related thoughts cluster.
4. As a developer, I want to leave loose, uncategorized notes too, so that capture stays frictionless.
5. As a developer, I want a category of related entries to merge into one output on export, so that scattered fragments become one coherent note.
6. As a developer, I want a single entry holding several distinct notes to split across destinations on export, so that a jumbled note still lands correctly.
7. As a developer, when I export, I want the skill to propose how to group my notes (merge/split/standalone), so that I don't hand-sort them.
8. As a developer, I want the skill to find the best existing docs area before ever proposing a new one, so that docs don't sprawl.
9. As a developer, I want to always confirm the destination and reshaped text before anything is created, even into an existing area, so that nothing lands silently.
10. As a developer, I want the skill to propose which export flow fits (idea / spec / issues / decision / research), so that the right downstream skill does the work.
11. As a developer exporting a rough idea, I want it filed via log-future-addition as an un-triaged issue, so that triage picks it up later.
12. As a developer exporting a set of work items, I want it handed to to-issues, so that I get tracer-bullet tickets.
13. As a developer exporting a fleshed-out feature, I want it handed to to-prd, so that I get a PRD.
14. As a developer exporting a decision or new term, I want it handed to grill-with-docs, so that it lands as an ADR or CONTEXT entry in the right format.
15. As a developer exporting research, I want it recorded in the appropriate docs section, so that the thinking is preserved.
16. As a developer, I want to be prompted whether to delete the source note after export, so that I control cleanup case-by-case.
17. As a developer, I want the journal to never push or contact GitHub on its own, so that all outward actions stay owned by the flow I chose.

Implementation Decisions

• Delivered as a skill (SKILL.md), the repo's only team-committed reusable unit — not a subagent (gitignore un-ignores only .claude/skills/).
• Two halves: capture (local, formless, git-free) and export (opt-in dispatcher). Capture never touches git; all git/ticket/branch/PR machinery lives only in the chosen export flow.
• Storage: a gitignored .journal/ at repo root, organized as categories (subfolders) containing entries (note files). Loose root entries allowed. New gitignore line required; kept separate from .context/, which holds cloned reference repos.
• Export handles many-to-one (merge a category) and one-to-many (split an entry). The dispatcher reads layout plus content and proposes grouping; the user adjusts.
• Destination selection biases hard toward an existing docs area/section; a brand-new section is a last resort and is always surfaced for approval.
• Unconditional confirm gate: the skill shows destination and reshaped text and waits for approval before any creation, existing area or not.
• Export is a flow-picker that delegates, never reimplements: log-future-addition (rough idea to un-triaged issue), to-issues (work items), to-prd (spec), grill-with-docs (decision/term to ADR or CONTEXT), or a plain docs write for recorded research. Each downstream skill already owns its formatting, conventions, ticketing, and any GitHub contact.
• Lifecycle: after a successful export the skill prompts whether to delete the source entry (default keep).
• Conventions are linked, not duplicated: issue/label rules via docs/agents/issue-tracker.md (through the delegated skills), ADR/CONTEXT shapes via grill-with-docs. The workflow terms Journal, entry (journal entry), and category get added to docs/agents/glossary.md alongside the existing Idea term.
• No new ADR: this is reversible tooling, not a hard-to-reverse architectural decision.

Testing Decisions

This is an AI-driven skill — instructions the agent follows, with at most a thin capture helper. There is little executable logic to unit-test, consistent with the other skills in .claude/skills/, none of which carry tests. Verification is manual: capture an entry into a category and confirm it lands gitignored; run an export and confirm the grouping proposal, the existing-area bias, the confirm gate, correct delegation to each downstream skill, and the delete prompt. Good verification checks observable behavior (files created, correct skill invoked, nothing pushed without consent), not internal phrasing.

Out of Scope

• Reimplementing any formatting, ticketing, branching, or PR logic — all delegated.
• The journal itself opening PRs or pushing to GitHub.
• A capture UI beyond the command and hand-editing files.
• Auto-triaging or auto-labeling exported ideas (log-future-addition and /triage own that).
• Cross-machine sync of the journal — it is intentionally local and gitignored.

Further Notes

Depends on log-future-addition (already merged to develop) for the rough-idea flow; this branch should be based on the latest develop so that skill and the Idea glossary term are present. Simplicity is the guiding constraint: the journal's whole value is capture plus routing; everything else is borrowed from skills that already exist.