Agents working in this repo
This is Yggdrasil, the plan & workflow design partner — and the base layer everything else composes on. Its job is active: brainstorm, author, and refine plans/workflows/roadmaps with Brad (domain-agnostic — code, game design, budgets, trips), which then hand off to an execution partner. See README.md for the full philosophy.
Orientation
- Not a target codebase. There's no application code here. This repo is
tooling: skills, commands, and metadata that get symlinked into
~/.claude/. - Designer, not executor. Yggdrasil designs plans; execution partners —
domain-driven toolkits like
../odin-codin/— carry them out, plan-driven and human-in-the-loop. The plan is the artifact that hands off between them. The same plan-walked-with-an-agent act recurs at every layer: Yggdrasil's native plans are meta/build (planning a toolkit's construction, or itself —working/current-plan.md); a toolkit's plans are domain-driven concrete instances; domain knowledge lives in the toolkits, never here. See the README's recursive plan section. - This is the base layer. Design & planning skills are Yggdrasil-native. Other general-purpose primitives also live here. Execution-partner-specific things live in their own repos.
- Live, not a skeleton. Unlike Odin Codin' at this stage, the skills here are in active use. Changes have immediate effect once symlinked.
- Composes, doesn't fork. Yggdrasil sits below the personal layer
(
CLAUDE.md) and above workflows. They compose via symlinks into~/.claude/rather than by merging or subclassing. See README for the layering scheme.
What this repo contains
| Path | Purpose | Status |
|---|---|---|
skills/ |
Skills — design & planning (brainstorming, planning) and general-purpose (bookmarking, learning-new-skills) |
live |
commands/ |
Slash commands — ergonomic sugar over skills (learn-new-skills), standalone session-bookend procedures (save-progress, good-morning), list-hygiene housekeeping (hygiene-check), and foreign-project adoption (puppet, scry) |
live |
.meta/ |
Workflow metadata (workflow.yaml) and the hygiene ledger (ledger.yaml — config knobs + machine-written stamps) |
live |
archive/ |
Append-only, out-of-context prune sinks for the accumulating lists (one file per source + README.md index) |
live |
working/ |
In-progress plans and cross-session handoff docs (current-plan.md) |
live |
bookmarks.md |
Deferred ideas to revisit; triaged via the session bookends + on demand | live |
AGENTS.md |
This file — entry point for non-Claude agents | present |
Conventions
- Skill names: gerund form (
bookmarking,learning-new-skills). - Command names: imperative (
/learn-new-skills). Commands are pure ergonomic sugar — only add one when the shortcut earns the extra file. - Skill descriptions: third-person; must state both what the skill does and when to use it. This is the single biggest factor in trigger reliability.
disable-model-invocation+allowed-toolsare a design vocabulary, not just flags. For every skill ask: "is this safe to auto-fire?" and "which tools should be pre-approved for frictionless use?"allowed-toolsis pre-approval only — it does not restrict the skill's tool access; unlisted tools follow normal session permission rules. Deliberately omit Write/Edit/Bash fromallowed-toolswhen you want those mutations to keep prompting for human approval — omitting is not a restriction, it's just not pre-approving. Invocation gotcha:disable-model-invocation: trueblocks all Claude-side invocation — not just unprompted auto-fire, but one skill invoking another via the Skill tool — and drops the skill'sdescriptionfrom context entirely. Only a human typing/namecan reach a disabled skill. So any skill that must be reachable by an orchestrating workflow or a skill-to-skill handoff has to leave it off. (This and theallowed-toolsnotes are the kind of guidance that will migrate into the futurecreating-workflow-skillsskill once it exists; AGENTS.md is their interim home.)- Lean
SKILL.md, heavyreferences/. Keep the main file under ~400 lines; push detail into reference files that load only when needed (progressive disclosure). - Self-housekeeping commands may auto-commit. Commands whose entire purpose is managing the toolkit itself (checkpoint saves, symlink management, etc.) are exempt from the "never auto-commit" rule — the commit is the point. Note the auto-commit explicitly in the command file so the behavior is transparent. See the personal CLAUDE.md "commit" convention for the full rule and exception. Consider this pattern for any future command that manages Yggdrasil's own state.
- Accumulating-list hygiene. Yggdrasil's growing lists (bookmarks, backburner,
session lessons, the design catalog, the Done log) are curated by
/hygiene-check, with state in.meta/ledger.yaml. The tunable knobs — bloat thresholds, the item-aging window, review cadences — live inledger.yaml→config(the only human-edited section; the hygiene restamp writes onlyskills/lists). A bloat-nudge escalates by bookmark count through the bands inconfig.bloat(heads-up → warn → firm) to keep the list pruned. Retired items are never deleted — they append toarchive/. Archive-file convention: when a hygiene pass drains a source that isn't one of the four canonical list-archives (bookmarks/session-lessons/done-log/catalog), name the file kebab-case after its source, give it the standard archive header, and add its line toarchive/README.md— asarchive/hygiene.mdalready does for the consistency-check drift scratchpad (the first such file). The convention travels to descendent scopes. - Session worktrees & disposition. Yggdrasil work is git-backed by default; every
session runs in its own
session-YYYY-MM-DDworktree under.worktrees/offmain(never editingmaindirectly)./good-morningcreates/resumes;/save-progressdisposes via merge / keep / discard. Branch prefixes are the detection spine:session-*are ours;xrepo-*(cross-repo) and nativeworktree-*are reserved. Disposition is always prompted — a deliberateAskUserQuestion, outside the self-housekeeping auto-commit exception above (the pin auto-commits; the disposition never does). "commit" house-style: a bare "commit" means the git op; in worktree mechanics lean on the domain words pin (the checkpoint write+commit) and disposition (merge / keep / discard), and write "the commit convention" when you mean the personal-CLAUDE.mdrule — so an ambiguous bare "commit" rarely appears. - Tone is calibrated, not fixed. Yggdrasil's design/planning skills use a
calm, firm voice: keep firm markers only at genuine gates (where compliance
actually matters) and de-shout the rest; skip decorative emoji. Forceful
"you MUST / not allowed" phrasing measurably improves model adherence (the
superpowers approach), so treat it as a deliberate tool to reach for in
high-structure execution contexts — e.g. an Odin Codin' crawl of a big,
complex codebase — not the default for collaborative design work.
House style for firm markers: mark a genuine hard stop with a blockquoted
bold-label directive —
> **Gate:**for a checkpoint (confirm or verify before proceeding) or> **Hard rule:**for a standing invariant — and leave soft checkpoints (ones the user may wave through) as plain prose. The marker's presence then reliably means "hard stop," its absence "soft." - Refer to phases and steps by name, not bare number, when talking to Brad.
Numbered labels (
Phase 5,step 3) are fine as internal anchors inworking/current-plan.md, but Brad doesn't hold the numbers in his head — translate them when you surface them ("the planning-skill build," "the constraints step," "the Odin Codin' methodology phase"). Once a topic's been covered recently in-session, it's fine to be more succinct. - Discipline rule (a promotion guard): something is promoted up into Yggdrasil from a workflow only after it has proven general across two or more workflows. When in doubt, build it downstream first and promote later on evidence. This guards against drift while working downstream; it does not gate design/planning skills, which are native to the base layer (build those here directly, just stay mindful of bloat). (Brad can override case-by-case — it's a default guard, not a hard gate.)
- Advisory subagents & design-review lenses. Yggdrasil rejects agent
autonomy, not agent parallelism. Independent subagents are allowed as
critique lenses when all hold: read-only/read-mostly, their product is
critique (findings, risks, sharper questions — never decisions, writing, or
actions), output routes through Claude → Brad, and the spawn is earned by genuine
independence (if one context could honestly produce the perspective, don't
spawn). Design/plan review draws on four orthogonal lenses — Skeptic
(failure), User Advocate (human experience), Steward (durability across a
/clearor a year), Constraint Guardian (the stated bar) — each a distinct axis so they don't collapse into agreement. Two forms: forward, woven single-thread into brainstorming's steps; backward, the finished-plan audit as a 3-way opt-in (skip / single-thread roleplay / independent subagents), scaled to how much the work matters. Shipped in theplanningskill; full rationale in theworking/current-plan.mddecisions catalog. - Standards posture: agentskills.io for skill structure (frontmatter, directory layout); Claude/Anthropic conventions for subagents, commands, and hooks where no open standard exists. "Married to Claude where it counts, open where it's cheap."
- Norse-mythology naming where it adds flavor (Yggdrasil the world-tree as the base; workflows like Odin Codin' hang off it). Not forced.
External references and known patterns
- obra/superpowers — a well-established
agentic skills framework built around
brainstorming → writing-plans → subagent-driven-development. For any software/coding project, check Superpowers — its design-spec workflow, plan structure, debugging patterns, and other skills may be worth porting or adapting regardless of whether TDD or autonomous execution is wanted. Brad decides what to keep when setting up each new project. Yggdrasil's defaults remain domain-agnostic and human-in-the-loop; Superpowers is a reference to consult, not a default to inherit. Bookmarks inbookmarks.mdtrack specific skills worth reading before designing OC's subagent layer.
For deeper context
- README.md — this repo, in human-facing prose
- working/current-plan.md — the live, multi-session implementation plan
- ../odin-codin/README.md — the first workflow built on this base
- The personal layer (
CLAUDE.md, symlinked from theclaude-personalsibling repo) sits above this repo and is not committed here.