wavemind

Usage tracking: Run bash ~/.agents/hooks/track-skill.sh <<< '{"tool_input":{"skill":"wavemind"}}' at the start of every invocation. Do not skip this step.

WaveMind: Thought Capture + Visualization

Transform thinking artifacts into beautiful visual maps of how your ideas evolved.

Commands

$wavemind capture [filepath]

Capture a thinking artifact. Two modes:

Mode 1: Import existing file ($wavemind capture <filepath>)

1. Read the file at <filepath>
2. Analyze the content to extract: title, round count, word count, source type
3. Generate a short ID from the date and title (e.g., 20260327-zai-prep)
4. Run bash lib/capture.sh <filepath> "<title>" to copy and index it
5. Report what was captured

Mode 2: Live capture ($wavemind capture or $wavemind capture "Topic Name" or $wavemind capture "Topic Name" --output /path/to/file.md) When no filepath is given (or filepath doesn't exist as a file to import), start a live capture session:

1. Ask the user for a topic name if not provided
2. Determine output path:
   • If --output <path> is specified, write to that exact path. Skip folder selection and naming convention. This allows other skills (e.g. dadclawd) to call WaveMind and control where the conversation is recorded.
   • If no --output, pick the right folder based on topic:
     • Interview prep conversations → ~/Documents/lily-memory/Thoughts/interview_preps/<id>.md Interview prep = mock interviews, interview gameplan, company research for a specific role, day-plans whose primary focus is interview prep, course-selection conversations for interview prep, pre-interview check-ins.
     • Everything else → ~/Documents/lily-memory/Thoughts/artifacts/<id>.md
3. Naming convention (when no --output): YYYYMMDD-<topic-slug>.md. Use the format YYYYMMDD with the date the conversation happened. For interview prep, prefer YYYYMMDD-interview-<slug>.md or YYYYMMDD-interview-study-<day>.md / YYYYMMDD-interview-plan-MMDD.md over generic names like thursday-thinking or plan-apr17. The word "interview" in the slug makes the file self-describing.
4. Create the artifact file immediately at the chosen path with this structure:

   # Topic Name - YYYY-MM-DD
   
   **Participants:** Lily + Jackie
   **Topic:** Brief description
   
   ## Promises
   <!-- Updated as promises emerge from conversation -->
   
   ---
   
   ## Round 1: Title
   **Lily:** ...
   **Jackie:** ...
   

5. Run date "+%Y-%m-%d %H:%M %A" at the start of every capture session. Record the start time in the artifact header. Run date again when wrapping up to calculate session duration. Never estimate times.
6. Tell the user: "Recording. Talk naturally. Say 'done' or 'save' when finished."
7. Write-first flow: Write both the user's words AND your response directly to the artifact markdown file first. Then give a short terminal reply (1-2 sentences max, e.g. "Written to artifact, Round 3. [brief pointer to what you said]"). Never write a full response in terminal AND in the file. The file is the single source of truth. This avoids duplication and rephrasing.
   • Speak human. WaveMind is a conversation, usually with voice on. Your artifact responses must read like spoken language: short, plain, first-person, no report-style structure. No multi-part numbered breakdowns, no bolded headers inside a reply, no "the arc across the five tests" prose. If you'd catch yourself writing a paragraph you wouldn't say out loud, cut it down to the sentences you would say. Follow the anti-slop skill's banned words (no "surface," "load-bearing," "verdict," etc.). A good round reply is 3-6 plain sentences; go longer only when the user asked for depth.
   • Bullet long replies in the artifact. When a response runs long (multi-concept explanations, reading maps, analyses), do NOT write it as one big paragraph in the .md file — break it into bullet points (with sub-bullets where natural) so it stays readable on re-read. Keep the spoken, plain tone inside each bullet; the bullets are a formatting aid, not a license for report-style structure. Short replies stay as plain sentences. (Added 2026-07-29 per Lily's request.)
   • Break up long user quotes too. The same rule applies to the user's side: when Lily pastes a long paragraph (a take, a quote, meeting notes), split it into shorter paragraphs or bullets at natural boundaries when writing it to the artifact — without changing her words. One wall of text under **Lily:** is as unreadable as one under the agent's name. (Added 2026-07-29 per Lily's request.)
   • Embed links for every cited work — REQUIRED. (Added 2026-08-22 per Lily's request.) Any time a round names a paper, blog post, benchmark, or repo, write it as a markdown link in the artifact — [Let's Verify Step by Step](https://arxiv.org/abs/2305.20050), never a bare "Lightman et al." or a naked arXiv id. Verify the id/URL resolves before writing it (a wrong arXiv id was caught this way on 2026-08-22). No link findable → say "couldn't locate the source" instead of citing from memory.
   • Ground every analytical reply; no slop. (Added 2026-08-07 per Lily's request.) When a round analyzes something real (a job description, a company, a technical decision), every claim must trace to a source: a document quote, a fetched page, or Lily's own verified artifacts. If it can't be traced, either say "not verifiable" or cut it. Length without sources reads as hallucination and Lily will call it out.
     • Structure is a tool, not a mandate. Lily's full checklist is: problem / solution / impact / what others do / significance / in scope / out of scope / critical feedback. Use whichever points the question actually needs, 1-2 lines each. What is never optional: soul. That means a real position, a genuine debate from more than one perspective (hers, the counterparty's, the org's), and a skeptical read of her own stance when warranted. Agreement without something new added is slop.
     • Condition the answer on HER question and context, not on the generic topic. She asks from a specific situation (a referral in flight, an interview scheduled, a stated career goal); an answer that ignores that situation is generic even if factually correct.
     • Slop answer (real example, rejected 2026-08-07, on "what does a research TPM actually do?"): a long invented "day in the life" narrative: "the day looks like: morning scanning run health and transcripts, midday research review, afternoon chasing a compute-allocation conflict..." Plausible, unsourced, could describe any TPM at any company, and none of it traceable to the JD. Rejected as "blog slop, hallucinated."
     • Good answer (same question, accepted): quote the JD's own responsibility list ("deliver a regular read on the ground truth in RL research"), infer only what the quote supports ("you don't hire someone to build a read that already exists"), name what's verifiable from job boards (three research TPM reqs posted since April = building a bench, not backfilling), then debate: the hiring manager's skeptical read of Lily's profile, AND a skeptical read of her own motivation given her stated #1 goal of building agent products. End by asking her to pick a side, not with a summary.
8. Capture incrementally, not at the end. After each round (a topic reaches a natural pause, the user moves to a new question, or a decision is made), append that round to the artifact file right away. Each round gets:
   • A section header: ## Round N: Title
   • The raw dialogue with **Speaker:** labels
   • Original words preserved (including mixed languages). Fix obvious typos but do not rewrite or summarize.
   • This avoids the lossy "reconstruct everything from memory at the end" problem.
   • Images: When the user shares a screenshot or image during the conversation, save it to ~/Documents/lily-memory/Thoughts/artifacts/ with a descriptive filename (e.g., milli-cafe-session.png) and ensure the file has readable permissions (chmod 644). Embed it in the artifact markdown using standard markdown syntax with explicit relative path: ![description](./filename.png). Always use the ./ prefix so both VS Code and Obsidian can render the image. Place the image reference in the dialogue at the point it was shared, under the speaker who shared it.
   • Promises: When promises/action items emerge from the conversation (decisions made, tasks identified, next steps agreed), update the ## Promises section at the top of the file. Use - [ ] [MMDD-N] format with IDs so the /promise skill can auto-extract them. Group by category if natural. Promises are a living section that grows as the conversation progresses, not something reconstructed at the end.
9. When the user says "done", "save", or "stop recording":
   • Append any remaining conversation not yet written
   • Do a final pass on the Promises section to make sure all promises from the conversation are captured with IDs
   • Run bash lib/capture.sh to finalize and index it
   • Report: artifact ID, title, round count, word count, file path
   • Suggest: "Run $wavemind visualize <id> to generate the visual."