alive:create-walnut

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.md people: frontmatter + ## Key People
• Phase — starting, planning, building, testing, launched -> _kernel/now.json phase:
• 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.md body

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