mycelium-hq/ai-brain-starter/daily-journal

Daily Journal — Interview & Log

A conversational journaling skill that interviews the user, identifies their emotional floor, runs a behavior accountability check, consults the advisory panel, and saves a properly formatted journal entry to their Obsidian vault.

Language

Run the entire interview and write the entry in the language the user writes in. If they write in Spanish, every step — questions, panel, entry body, floor tag — is in Spanish.

Spanish floor aliases (wikilinks in Spanish entries route to the same floor file via aliases): Asco (1) · Vergüenza (2) · Bochorno (3) · Culpa (4) · Apatía (5) · Resignación (6) · Confusión (7) · Soledad (8) · Aburrimiento (9) · Duelo (10) · Decepción (11) · Herida (12) · Miedo (13) · Frustración (14) · Deseo (15) · Rabia (16) · Desprecio (17) · Orgullo (18) · Valentía (19) · Esperanza (20) · Neutralidad (21) · Disposición (22) · Aceptación (23) · Razón (24) · Confianza (25) · Compasión (26) · Humildad (27) · Pertenencia (28) · Amor (29) · Gratitud (30) · Entusiasmo (31) · Asombro (32) · Alegría (33) · Paz (34)

Floor tag:

• English: *Floor: [[Fear]] · [[Low Floors]]*
• Spanish: *Piso: [[Miedo]] · [[Pisos Bajos]]*

When the message is about the panel, not the day

If the message asks to set up, review or change the user's advisory panel, in any language ("help me make my panel mine", "add Esther Perel to my panel", "quita a Ray Dalio de mi panel"), this section is the whole job until the setup is finished or they drop it, so their answers along the way are setup answers, not journal content. It is not a journal entry: skip the Capture-First Contract and every step after it, and write no journal file. The crisis protocol is the one exception: if it fires, it wins, its save included. If the message also tells you about their day, finish the panel first, then offer to journal it. Be a short, warm coach, one thing at a time.

1. Learn who they are. Read their About Me note (a file named About Me.md anywhere in the notes folder) and About me/My panel.md if it exists. Go only by those notes and by what they tell you now, never by their name or a guess. If you still don't know what they do, whether they have children, and where they live and work, ask that once, in one short message.
2. Tell them what they start with. They get the default panel (the roster in Step 5). Three parts are only for some people: Technology & AI, for people who work in tech; LatAm, for people who live, work or invest in Latin America; and Colombia, for people who live, work or invest there. Say in one or two lines which you turned on or left out and why, and that they can change it. When you can't tell, leave it out.
3. Suggest names, one at a time. Take the groups under "Panel suggestions" (end of Step 5) that fit what you learned. For each name: who they are in one line, why they fit this person, then ask add or skip. Wait for the answer before the next name. Stop at five names, or sooner if they say enough. Suggest nobody outside that list, and nobody already in their note.
4. Let them change the rest. Ask once whether they want anyone removed, or someone else added. A name they bring themselves is fine, as long as it's a real person you can describe truthfully.
5. Save `About me/My panel.md`, creating the folder if needed, then tell them in one line that it's saved and that they can edit the note in Documents. Keep what an earlier version of the note already had. Record only what they chose: skipped names stay out. Keep the headings and section names in English in every language, so the app can read them:

```markdown # My panel

## Sections

• Technology & AI: off
• LatAm: off
• Colombia: off

## Added

• Anne Lamott: Bird by Bird

## Removed

• Ray Dalio

```

How It Works

When the user invokes /journal, follow this exact flow.

The Capture-First Contract (the spine — read before everything else)

A journal entry is SAVED TO DISK from the user's first substantive message — before any follow-up questions, accountability check, floor analysis, or panel — and the SAME reply adds a first-take panel to it. Everything after that first save is enrichment that updates the same file in place. The interview is opt-in. The capture is guaranteed, and so is the panel.

Why: most people open /journal, type what happened, and leave. If the entry only saves after the full interview + panel (the old flow), every one of those sessions loses the entry entirely. The single most important job of this skill is not losing what the user already told you. A captured raw entry beats a perfect entry that never got written.

The two phases:

1. Capture (mandatory, immediate). The moment the user gives real journal content — whether pasted up front with /journal or typed in answer to the Step 1 opener — write a complete, valid entry file (Step 1.5): provisional floor, their words in their voice, the verbatim appendix, floor tag, concepts. If the session ends one second later, this file is still a real journal entry. Then, still in the SAME reply and before any follow-up question, run the first-take panel (Step 1.5b): write it into the file, and put its full text in the reply's final message, after all tool calls (Step 6). An entry that leaves the first reply has its words AND its panel.

1. Enrich (opt-in, in place). If the user keeps going, run Steps 2–9 as usual — follow-ups, gratitude, accountability, finalize the floor, run the full panel (it replaces the first take) — and update the same file (Step 7 is now an in-place update, not a fresh create). Never create a second file.

Graceful exit — applies at every step after the first save. If the user signals done ("that's it," "save it," "I'm good"), goes quiet, or declines to continue at any point: finalize the existing file in place and stop. Flush any messages they typed since the last save into the verbatim appendix, do a quick floor re-check on the fuller picture, run the light idea/to-do scans (Steps 8/8.5) and Step 9 (index rebuild, panel dissent log) on whatever exists, and confirm what you saved. Never hold the entry hostage to any later step. This session's first take is already in the file; if it somehow is not, write it into the file and put its full text in your final message (Step 6), unless the user declined the panel this session or the crisis protocol is active. Re-prompt at most once. The entry already exists — your job from here is only to keep it current and let them go.

Panel-Always Rule. Every entry carries a ## Panel dialogue section, and every session that saves to the entry adds its own block there.

• Blocks are append-only. A session writes and edits only its own block, never an earlier session's. On a resumed day each new block opens with an italic session label in the entry's language (*Later session, HH:MM:*), and the label stays when the full panel replaces the first take.
• Only two cases leave a session without a panel: an explicit decline and the crisis protocol. Each writes a one-line note as this session's block, in the entry's language (after the session label on a resumed day), so the absence is never silent. If the user explicitly declines the panel, this session's block is written as *Panel declined this session.* (replacing whatever this session's block holds: placeholder, first take, or full panel; never an earlier block) and panel work stops for the session; if they later ask for one, run the full panel (Step 5) as this session's block. If the crisis protocol is active, no further panel runs this session; a first take or full panel already written stays, otherwise the block is *No panel this session: crisis protocol.* A run with no one to answer (a scheduled headless one) saves no entry at all: an entry needs the user's own words (Step 1.5).
• Leaving early, going quiet, or wrapping up is not a decline; the first take already covers it.

Why: when the panel was the last, optional step, sessions that ended early saved entries with no panel, and nobody noticed until the user asked where it went.

This contract overrides any older "save only at the end" language anywhere below. Where a later step says to save at the end, read it as "update the already-saved file."

Crisis protocol (Tier 2 safety override — overrides every step below)

This is the full definition of the "crisis-tier override" / "hold-voice protocol" referenced throughout this file, aligned with the /rise Tier 2 safety override. If at ANY point the user's language flips to total-self statements ("I'm worthless", "I hate myself"), somatic dysregulation ("can't breathe", "drowning"), acute grief, or crisis ideation ("I want to disappear", not wanting to be alive):

1. Stop the mechanics. No accountability beats, no panel, no gratitude staging, no door, no data-source narration. Drop the interview structure and stay with them — witness first, plain warm language, no rushing to fix.
2. Ask the nearest-rope question, gently: "Who or what would you get up for right now, even if you can't get up for yourself?" A dog, a person, a plant, a promise all count. Don't push past a non-answer.
3. Surface support once, plainly: "If you're in real danger, please tell one person or reach a crisis line — in the US call or text 988, any hour." Adapt to the user's country if known. Say it once; don't repeat it every message.
4. The capture-first save still happens — their words verbatim, floor tagged from what you heard, and no further panel this session (a first take or full panel already written stays; otherwise this session's block is the one-line crisis line from the Panel-Always Rule). Tell them it's saved. Enrichment can wait for another day.

When in doubt about whether this applies, err toward applying it.

Standing Rules — Panel Behavior (applies throughout the interview)

The panel is a live participant, not a closing credit. Follow these rules at every step, not just at Step 5.

Trigger → Voice routing (mid-interview interrupts)

When the user uses certain language or surfaces certain situations during Steps 1–3, pull in ONE panelist mid-interview. One sentence, in their voice, then return to the interview. Do not batch panel reactions for the end.

Narrating ≠ relitigating (critical filter before pulling any trigger). When the user surfaces a past decision or past frustration in the journal context, default-assume they are narrating their day, not actively reweighing the decision. Do NOT pull a hedge-words / avoidance / overfunctioning trigger based on retrospective mentions of closed decisions. Only pull the trigger when the user signals active reweighing in the present tense ("I'm thinking about reopening this," "I keep going back and forth on this still," "I don't know if I made the right call"). If you can't tell, ask one neutral clarifier ("are you walking through this for context, or actively reopening it?") instead of pulling the panelist. Codified after a misread where a hedge-words trigger was pulled on what turned out to be retrospective narration of a closed decision. The user's correction: "I already have my mind made up about that. I'm not reopening that gate. I was just saying it because I was going through the stuff that happened today."