Meet the three

Day 3: Choose your adventure · Lesson 3 of 5 · 12 min

Three frameworks, one page, and the same five questions for each. Each tab answers them for one framework, and Exercise 1 installs the one you pick.

How to read this page

Pick a tab and read only that one: the panels answer the same questions in the same order, so skipping two costs you nothing the exercises need. The Show all three button beside the tabs stacks every panel on one page; it then reads Show one track, which takes you back. Your choice sticks for the rest of Day 3, and ?track=lid on this page's address opens the LID tab.

What a panel says a tool wrote was observed on the build machine on 2026-09-22, in copies of the Swift lane; Exercise 1's diff shows what yours writes. Read the install commands here and run nothing yet: Exercise 1 runs them from inside day3-work.

The five questions every panel answers

What it installs, and what that needs.
Where specs live once it is initialized.
The command that creates a spec.
The command that implements one.
What happens to the spec after the change ships.

Exercise 1 asks questions 2 to 5 again, from your own install.

Panel: OpenSpec

Watch first · 5 min

OpenSpec GitHub Tutorial: Spec-Driven Development for AI Coding Assistants

Alex Hitt, 2026-07-01, 1:11 to 6:04, delta specs through the explore-propose-apply-archive workflow. Watch for the step that moves text from the changes folder into the specs folder.

OpenSpec installs from npm as a global command (-g puts openspec on your PATH for every project) and needs Node 20.19.0 or higher.

npm install -g @fission-ai/openspec@latest

openspec init asks which tools to set up, and you choose Claude Code. On the build machine it wrote fifteen new files: openspec/config.yaml, placeholders that create openspec/specs/ and openspec/changes/archive/, and six /opsx commands and six skills under .claude/. Specs live in openspec/specs/, the requirements that are true of the system now.

/opsx:explore surveys the code before you commit to anything. /opsx:propose plus a feature description creates a change folder under openspec/changes/; on the build machine, Change C's folder held proposal.md, design.md, tasks.md, .openspec.yaml and a delta spec per capability under specs/. /opsx:apply implements it from the task list. /opsx:archive folds the deltas into openspec/specs/ and moves the folder to changes/archive/ under a date-prefixed name.

A delta spec holds only what the change does, under ## ADDED Requirements, ## MODIFIED Requirements or ## REMOVED Requirements: each ### Requirement: with #### Scenario: blocks in GIVEN, WHEN and THEN lines.

A change lives in its own folder until archive folds it into the live specs and files the folder by date.

Quick check

In OpenSpec, you finish a change and archive it. Which spec folder got bigger, and which listing lost an entry?

The live tree under openspec/specs/ absorbed the delta sections and grew. The change folder left the active list in openspec/changes/ and reappeared, date-prefixed, under openspec/changes/archive/.

Panel: LID

No video on this tab: research found no LID walkthrough on any channel.

LID installs as two Claude Code plugins, typed inside Claude Code: the marketplace, then the workflow and its arrow-maintenance overlay. They need nothing installed beyond Claude Code itself. On the build machine the two added about 1,090 tokens to every session:

/plugin marketplace add jszmajda/lid
/plugin install linked-intent-dev@jszmajda-lid
/plugin install arrow-maintenance@jszmajda-lid

The arrow is LID's one-way chain: high-level design, low-level designs, EARS requirements, tests, code, with changes flowing down and never up. /linked-intent-dev bootstraps a new project. LedgerKit already has code, so Exercise 1 runs /arrow-maintenance:map-codebase, which builds the tree from it. On the build machine, in a run that could not load the skill's own text, it wrote docs/high-level-design.md, a design file and a specs file per segment under docs/intent/<segment>/, and an overlay index, docs/arrows/index.yaml; the skill itself also asks for an arrow doc per segment under docs/arrows/.

Specs live in the specs files. Each requirement has a path-shaped ID, FEATURE-NNN growing one segment per level of nesting as in PEVAL-RUN-014, and a status: [x] implemented, [ ] gap, [D] deferred. Code cites it with // @spec AUTH-UI-001, AUTH-UI-002 on the topmost function or module that owns the behavior, and tests carry it too.

No command creates a change's spec: the directives LID appends to CLAUDE.md send any change that could touch code through the linked-intent-dev skill, so Exercise 2 starts Change C as an ordinary message. None of the five entry points the two plugins install implements one either: the same walk continues down the arrow to tests, then code. /arrow-maintenance:arrow-maintenance audits code against the tree. After ship nothing is archived; the design tree stays the source of truth.

Every link in the chain is a file that outlives the change, and edits travel only downward.

Quick check

You add a helper function that computes part of a behavior LID already has a requirement for. Where does the @spec annotation go?

Not on the helper. It goes on the topmost function or module that owns the behavior, so a reader walking down from the requirement lands once, at the entry point.

Panel: BMAD

Watch first · 5 min

BMad V6 is Finally Here… /bmad-help, /party-mode... Pure Magic

BMad Code, 2026-02-23, 6:34 to 11:23, the installer walkthrough. At each installer choice, ask whether you could make it where you cannot install Python tooling. It predates the 6.11.0 renames, so some skill names on screen are old.

BMAD needs Node 20.12 or later and uv, a Python package and environment runner:

npx bmad-method install

uv is not optional. /bmad-build and /bmad-build-auto open by running a uv run shell command, and their own text says to halt if it fails, uv missing included. On the build machine, a session that could not run shell commands halted before planning. In a locked-down environment that blocks either, they do not degrade; they do not start.

On the build machine, BMAD 6.12.0's install, with Claude Code as its tool (your answer at Integrate with:), wrote 235 files: a _bmad/ tree, 29 skills under .claude/skills/, and an empty _bmad-output/.

Specs live in _bmad-output/implementation-artifacts/, one spec-<slug>.md per change. /bmad-build creates it. The same /bmad-build run implements it after you answer its questions and approve its plan; a small change with no open questions and nothing irreversible skips both. The docs show /bmad-build write an implementation of mars rover kata; larger work chains bmad-sprint-planning, bmad-build, then bmad-code-review.

On the build machine on 2026-09-22, handed Exercise 2's prompt and told to halt after planning, /bmad-build wrote a folder instead: statement-periods/, holding SPEC.md, stories.yaml and a stories/<id>-<slug>.md per story, the layout BMAD's docs give for work split into stories. Exercise 2's checkpoint copies it in.

The status in the spec's frontmatter moves through draft, ready-for-dev, in-progress, in-review and done; BMAD's unattended loop, /bmad-build-auto, can also stop it at blocked. After ship the spec stays where it was written, its status at done.

One skill writes the spec and builds it; after ship the spec stays, marked done.

Quick check

In BMAD, a change ships. Where is its spec now, and what in it changed?

Where it was written, _bmad-output/implementation-artifacts/spec-<slug>.md. Only the status in its frontmatter moved, to done.

What each one does to your standing instructions (all tracks)

CLAUDE.md is the standing part of your spec, and Day 1 taught you to keep it short. On the build machine only LID wrote into it: OpenSpec 1.13.1's init left it untouched and created no AGENTS.md, and BMAD's install did the same. The published sources disagree about OpenSpec, and Exercise 1 has you check your own run. BMAD's managed region,  to  in AGENTS.md at the repo root, is written only by its bmad-project-context skill, when you invoke it.

LID's mapping run appended a 29-line ## LID section with no marker comments: mode, version, ID prefix, where the design documents live, and the rule that any change that could touch code walks the arrow. That run could not load the plugin's own skill body. LID's own template, in the pinned update-lid skill, is longer, about 48 lines in Full mode: a ## LID block with mode and version, then a ## Linked-Intent Development (MANDATORY) section with the arrow rule, a navigation table, terminology and the @spec rule. Exercise 1 has you read yours.

Shelf life and pinned versions (all tracks)

This page was checked against OpenSpec 1.13.1, released 2026-09-17; LID commit 831c1959 of 2026-08-12, still the tip of main on 2026-09-22; and BMAD 6.12.0, the latest on npm on 2026-09-22.

If an install hands you something newer, re-check BMAD's command names first. Its 6.11.0 release renamed bmad-quick-dev to bmad-build and bmad-dev-auto to bmad-build-auto, and a default 6.12.0 install leaves the old names out, so a tutorial's /bmad-quick-dev is an unknown command.

When your tab is the wrong tab (all tracks)

If you picked BMAD for a blog's roster of named agents, the personas still ship as bmad-agent-* skills, but v6 is a catalog of skills you invoke, and Change C uses /bmad-build. If you cannot install uv on this machine, pick again now.

If you picked LID for a video, there is none. If you picked the track that looked lightest, Lesson 4 asks the question again from the failure you actually have.

Quick check

On the build machine, which of the three wrote into CLAUDE.md?

Only LID: its mapping run appended a 29-line ## LID section. OpenSpec's init and BMAD's install left it untouched, and BMAD writes its AGENTS.md region only when you invoke bmad-project-context.

Lesson 3 read, and I can answer the five questions for my track.

Sources

Every citation for this page

Each project's own documentation and repository, accessed 2026-09-22, and observations on the build machine the same day.

openspec-01 — the npm install command, from OpenSpec installation.
openspec-03 — the Node requirement, from the npm registry entry for @fission-ai/openspec.
openspec-04 — version 1.13.1 and its release date, from OpenSpec's latest release.
openspec-05, openspec-06 — openspec init and the folders it scaffolds, from OpenSpec setup.
openspec-07, openspec-08, openspec-09, openspec-10 — the four /opsx commands, from OpenSpec getting started.
openspec-13 to openspec-17, openspec-20 — the delta spec headers, requirement and scenario syntax, and what archive does, from OpenSpec concepts.
lid-01, lid-02, lid-03, lid-05, lid-06, lid-07, lid-08, lid-09 — the plugin install commands and the five LID commands, from the LID README.
lid-11, lid-12, lid-13 — the @spec annotation, the status markers and the ID shape, from LID's AGENTS.md.
lid-25 — commit 831c1959 and its date, from LID's main branch.
The directives LID appends to CLAUDE.md and their line count, from plugins/linked-intent-dev/skills/update-lid/references/agents-md-template.md, and the per-segment arrow docs, from Phase 5 of plugins/arrow-maintenance/skills/map-codebase/SKILL.md, both in the pinned snapshot under starter/vendored/lid-831c1959/lid/. On the build machine the Change C run started with /linked-intent-dev:update-lid (lid-06, lid-obs-07), which the README lists for drift and configuration.
bmad-01, bmad-05 — the install command and the Node requirement, from Install BMAD.
bmad-06, bmad-09, bmad-11 — the uv requirement, the 6.11.0 renames and the three-skill chain, from the BMAD changelog.
bmad-07 — the /bmad-build example, from Build your first change.
bmad-12, bmad-13 — the status values and the folder layout for work split into stories, from Autonomous development loops. The spec path, the halts for your answers and your approval, the small-change exception and the status at done are from step-01-clarify-and-route.md, step-02-plan.md and step-05-present.md of the pinned bmad-build skill under starter/vendored/bmad-6.12.0/, the five values /bmad-build writes from its spec-template.md, blocked from bmad-build-auto's step-01-clarify-and-route.md and workflow.md, and the folder from that snapshot's _bmad/config.toml.
bmad-19 — the bmad:context region in AGENTS.md, recorded from a search summary of Project context rather than a fetched page; bmad-obs-08 confirms the markers in the installed skill.
Observed on the build machine on 2026-09-22, in copies of the Swift lane, after each tool's own install and initialization: openspec-obs-02, openspec-obs-03, openspec-obs-07 (the fifteen files, the untouched CLAUDE.md, the change folder); lid-obs-01, lid-obs-03 to lid-obs-08 (the pinned commit, the five entry points, the token cost, the ## LID section, the mapped tree, the skill body that did not load, the Change C run's design and specs); bmad-obs-01, bmad-obs-02, bmad-obs-03, bmad-obs-05 to bmad-obs-11, bmad-obs-13 (the npm version, the installer's uv warning and tool prompt, the 235 files, the 29 skills, the missing old names, the bmad:context marker, the personas, the halt without shell access, the folder the Change C run wrote when told to halt after planning, recorded in starter/checkpoints/bmad/CHECKPOINT.md).