Create
Scaffold a new walnut — any type, any ALIVE domain. Understand it first, map where its context lives, then scaffold. Optionally bring in existing content (Step 7 — only if the human has files to migrate).
Not a setup wizard (that's world/setup.md — first-time only). Not opening an existing walnut (that's alive:load-context).
Template Locations
The squirrel MUST read these templates before writing — not reconstruct from memory. Templates live relative to the plugin install path.
templates/walnut/key.md → _kernel/key.md
templates/walnut/key-codebase.md → _kernel/key.md (codebase variant, Step 2b)
templates/walnut/log.md → _kernel/log.md
templates/walnut/insights.md → _kernel/insights.md
Placeholders
Used in key.md and key-codebase.md:
| Placeholder | Source |
|---|---|
{{type}} | Step 1 selection |
{{goal}} | Extracted from Step 2 free text |
{{name}} | Kebab-case slug derived from Step 2 |
{{date}} | Current ISO date (YYYY-MM-DD) |
{{description}} | The human's free text from Step 2, lightly cleaned |
Additional placeholders in key-codebase.md (Step 2b only):
| Placeholder | Source |
|---|---|
{{repo}} | Repository URL from Step 2b |
{{local_path}} | Local clone path from Step 2b |
{{github_account}} | GitHub account or org from Step 2b |
{{stack}} | Tech stack summary from Step 2b |
{{branch}} | Default branch name from Step 2b |
Used in entry.yaml (squirrel — written by session-new hook, not by this skill):
| Placeholder | Source |
|---|---|
{{session_id}} | Current session ID |
{{engine}} | Current model (e.g. claude-opus-4-6) |
{{walnut}} | Same as {{name}} |
{{squirrel_name}} | From preferences.yaml squirrel_name: or null |
{{timestamp}} | ISO timestamp at session start |
{{transcript}} | Path to session transcript JSONL |
{{cwd}} | Working directory at session start |
{{rules_loaded}} | Count of rules loaded at session start |
Domain Routing
| Type | ALIVE folder | Notes |
|---|---|---|
| venture | 04_Ventures/{name}/ | |
| experiment | 05_Experiments/{name}/ | |
| life | 02_Life/{name}/ | Under goals/ if it's a goal |
| person | 02_Life/people/{name}/ | Legacy subfolder conventions (professional/, inner/, orbit/) still recognized. |
| project | Inside parent walnut folder | Requires parent selection |
| campaign | Inside parent walnut folder | Requires parent selection |
Flow
Step 1 — Type Selection
-> AskUserQuestion: "What type of walnut?"
- Venture — revenue intent (business, client, product)
- Experiment — testing ground (idea, prototype, exploration)
- Life area — personal (goal, habit, health, identity)
- Person — someone who matters
- Project — scoped work inside a venture or experiment
- Campaign — time-bound push with a deadline
Step 2 — Describe It
Free text prompt: "Describe it in a sentence or two — what is it and what's the goal?"
The squirrel infers name (kebab-case slug), goal, and domain from the response.
If type is project or campaign:
-> AskUserQuestion: "Which walnut does this belong under?"
- [list active ventures/experiments by scanning _kernel/key.md frontmatter across ALIVE folders]
- Standalone (no parent)
To build the parent list: scan 04_Ventures/*/_kernel/key.md and 05_Experiments/*/_kernel/key.md — read frontmatter only (type, goal). Check _kernel/key.md first, fall back to walnut root. Present as options with goal as description.
Step 2b — Codebase Detection
Skip Step 2b entirely for type: person or type: life walnuts — they don't have codebases.
For venture, experiment, project, or campaign walnuts: if the description mentions code, a repo, a website, an app, or anything that lives in a git repository:
╭─ 🐿️ sounds like this has a codebase. That right?
│
│ ▸ Does this walnut track a code repo?
│ 1. Yes
│ 2. No — context only
╰─
If yes, ASK explicitly for each required field — do not infer from the description:
╭─ 🐿️ codebase details
│
│ ▸ What's the repo? (e.g., github.com/org/repo)
│ ▸ Where's it cloned locally? (e.g., ~/code/my-project)
│ ▸ Any of these apply?
│ - GitHub account (if you use multiple)
│ - Deploy platform (Vercel, Netlify, etc.)
│ - Database (Supabase, Postgres, etc.)
╰─
Even if the human gave repo/path in their description, confirm them here. This step is the only place codebase info is collected — don't skip it.
Set has_codebase: true — Step 6 will use templates/walnut/key-codebase.md instead of the standard template.
Step 3 — Pull the Thread
Five minutes of conversation here saves ten sessions of backfilling. Don't rush past this.
Ask follow-ups adapted to the type. Use natural conversation, not an interrogation — if they gave a rich answer in Step 2, skip questions you can already infer.
| Type | Ask about |
|---|---|
| Venture | Who's involved — names, roles, how you work with them? What's the business model or revenue path? What phase — idea, building, launched? Any hard deadlines or external commitments? |
| Experiment | What exactly are you testing? Who else is involved? What would make you kill it vs double down? |
| Person | How do you know them? What do you work on together? How do you usually communicate? |
| Life area | Why now? What does progress look like? Who else is involved or affected? |
| Project / Campaign | Who's on it? What's the deadline? What does done look like? |
From the answers, extract and hold for scaffolding:
- People — names, roles, contact info if offered ->
_kernel/key.mdpeople:frontmatter +## Key People - Phase — starting, planning, building, testing, launched ->
_kernel/now.jsonphase: - Rhythm — how often they'll touch this (override weekly default if appropriate)
- Tags — inferred from domain, industry, tools, people mentioned
- Description — 2-3 sentence identity paragraph ->
_kernel/key.mdbody
Step 4 — Context Map
Most new walnuts already have context scattered across tools. Map it now so the squirrel knows where to look later.
╭─ 🐿️ context map
│ Where does context for this currently live outside
│ your head? Knowing this helps me find things later
│ and reminds the human what to bring in.
│
│ Think about:
│ - Email threads (Gmail, Outlook)
│ - Chat history (Slack, WhatsApp, iMessage, Discord)
│ - Documents (Google Drive, Notion, Dropbox)
│ - Meeting recordings (Otter, Fathom, Zoom recordings)
│ - Notes (Apple Notes, Obsidian, paper notebook)
│ - Code or repos (GitHub, local projects)
│ - Social / public (Twitter, LinkedIn, website)
│ - Anything else — spreadsheets, Figma, Trello, etc.
╰─
-> AskUserQuestion (multiSelect): "Email (Gmail/Outlook)" / "Chat (Slack/WhatsApp/Discord)" / "Docs (Drive/Notion/Dropbox)" / "Other (tell me)"
Follow up briefly on each selected source — which channels, which folders, key threads. Not exhaustive, just enough to know where shadow context lives.
This becomes a ## Context Map section in _kernel/key.md:
## Context Map
| Source | Details | Status |
|--------|---------|--------|
| Gmail | Thread with jax@example.com re: shielding specs | Not captured |
| Slack | #nova-engineering channel | Ongoing |
| Google Drive | "Nova Station" shared folder | Not captured |
| Fathom | 3 recorded calls with engineering team | Not captured |
Status: Not captured - Partially captured - Ongoing (live channels) - Captured
This map is a living reminder. When the squirrel opens this walnut later, it can prompt: "Your context map shows 3 Fathom recordings marked 'Not captured' — want to bring those in?"
Step 5 — Confirm Before Writing
Present everything gathered so far:
╭─ 🐿️ new walnut
│
│ Name: flux-engine
│ Type: experiment
│ Goal: Buil