Yggdrasil

The plan & workflow design partner. Yggdrasil is where plans, workflows, and roadmaps get designed — collaboratively, with a human in the loop — before they hand off to an execution partner that carries them out. It is the base layer everything else composes on top of, but its purpose is active, not passive: it is the partner you think and plan with.

In Norse mythology, Yggdrasil is the world-tree connecting and supporting the nine realms — everything else hangs off it. That's the role this repo plays: the foundation where the work of every realm is planned before it branches out. Domain-specific execution partners (Odin Codin', and others to come) compose on top and do the doing.

Designer and executor

Two roles, one collaboration model. Neither is autonomous — both keep the human in the loop at every step. The plan is the artifact that hands off between them.

  • Yggdrasil — the design partner. Domain-agnostic. It brainstorms with you, authors the plan, walks you through its reasoning, and refines it with you. Its first-class output is the blueprint for building a plan-designing toolkit — Odin Codin' (source diving), a Travel Planner, a Budget Designer — or a plan for Yggdrasil's own construction. It can also produce a one-off concrete plan directly (a single trip, a quick budget) when standing up a whole toolkit would be overkill.
  • Execution partners (toolkits) — e.g. Odin Codin'. Built by carrying out a Yggdrasil blueprint, then domain-driven: each is specialized to one domain and generates its own concrete plans for specific instances. Odin Codin' (source diving + documentation) is the first; it won't be the only one, and not all will be code-related.

Parallel, never autonomous. The no-autonomy stance rejects agents acting on their own — not agents thinking in parallel. Yggdrasil will spin up independent subagents as advisory critique lenses (read-only; their product is findings and sharper questions, never decisions or actions, always routed back through the human), and pressure-tests a design through a few orthogonal perspectives — Skeptic, User Advocate, Steward, Constraint Guardian — so blind spots surface before a plan is committed. The human stays the arbiter throughout.

The recursive plan (and where each kind lives)

The whole system is one artifact and one act, repeated at every layer: a markdown plan walked through with an agent, human-in-the-loop, git-backed. A toolkit builds concrete plans the same way Yggdrasil builds toolkits the same way Yggdrasil plans its own construction — turtles all the way down. What changes between layers is only what's being planned and how domain-specialized the planner is:

  • Yggdrasil's native plans — meta/build. Planning the construction of a toolkit, or Yggdrasil planning itself (working/current-plan.md). Domain-agnostic, because "design a toolkit that plans domain X" is itself a domain-neutral act — the domain knowledge is injected into the toolkit, never held in Yggdrasil.
  • A toolkit's plans — domain-driven. Once built, a toolkit generates concrete plans for specific instances (a Chicago trip: lodging, travel, itinerary, packing list). Domain knowledge lives here. Within a toolkit, a plan may itself specialize from a reusable template to a tailored per-project instance (e.g. "legacy-code exploration" → adapted to one target repo), saved in the project layer alongside output.
  • The exception. Yggdrasil can produce a one-off concrete plan directly, skipping the toolkit, for small things not worth a toolkit — still git-backed; you still end up with artifacts.

"plan" and "workflow" are used interchangeably; the canonical term is plan.

What lives here

  • Design & planning skills — Yggdrasil's core competency: turning ideas into validated, executable plans. brainstorming (idea → validated design) is the front of the pipe; planning (design → executable, checkpoint-able plan) is the flagship. These are Yggdrasil-native, not subject to the promotion discipline below.
  • General-purpose skills useful regardless of which execution partner is running. Currently: bookmarking, learning-new-skills. Invoke directly as /bookmarking or /learning-new-skills, or conversationally ("bookmark this").
  • Metadata in .meta/ tracking workflow state (last-run times, version info, dependencies).
  • bookmarks.md — captured ideas to revisit later, triaged via the session bookends and on demand.

What does NOT live here

The discipline rule is a promotion guard: something gets pulled up into Yggdrasil from a workflow only after proving general across two or more workflows. Execution-partner-specific skills belong in that partner's own repo. When in doubt, build it downstream first; promote later if a second workflow needs it.

The rule guards against drift while you're working downstream and tempted to stash things upstream. It does not apply when you're deliberately building Yggdrasil itself — design and planning skills are native to the base layer, not promotions into it (stay mindful of bloat regardless). This is what keeps Yggdrasil from collapsing into a junk drawer without freezing its core purpose.

Naming convention

Infrastructure components and workflows in this ecosystem get Norse mythology names where it adds flavor. Yggdrasil is the base; Odin Codin' is the code-crawling workflow; Hugin and Munin are the agent/memory split inside Odin Codin'. Not a hard rule, just a coherent theme.

Relationship to other layers

Personal layer (CLAUDE.md, personal preferences)
    |
    v
Yggdrasil (this repo — the plan/design partner + shared primitives)
    |
    v
Execution partners (e.g., Odin Codin' — domain-specific, plan-driven)
    |
    v
Project-specific (per-project .claude/ + the tailored plan and output)

Each layer composes on top of the previous via symlinks into ~/.claude/. See the personal CLAUDE.md and new-machine-setup skill for symlink details.

Setup

This repo is cloned to C:\Projects\yggdrasil\ and symlinked into ~/.claude/ at the subdirectory level. See new-machine-setup for the exact commands.