/create-walnut

name: create-walnut
version: 3.0.0
description: "Something new is emerging. A venture, an experiment, a person entering the orbit, a life area getting serious. It needs its own walnut — its own identity, history, and future. Scaffolds the full structure, maps existing context sources, and optionally migrates files across."
user-invocable: true

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