Tutorial 08: Plan with past decisions

Continue from Tutorial 07. The setup in Tutorial 03 prepares the [loom_demo] store and local palmerpenguins repository used below.

The scenario is simple: palmerpenguins is a small Python package with bundled CSV data and a local loader. A proposed runtime network fetch conflicts with an earlier project decision. You will watch Loom surface that conflict before planning begins.

Start here: make `loom_demo` the session default

YouLoad the configured store named loom_demo and make it the default for this session only. Confirm the effective session default, and do not edit ~/.loom/stores.toml.

AgentThe agent connects to the existing loom_demo store and changes only this session's default routing.

Resultloom_demo is now the default for this session. Persistent configuration was not changed.

1. Verify Loom is active for coding

YouCheck that the loom-coding skill is loaded and that you can read from [loom_demo].

AgentThe agent loads [loom_demo], describes it, resolves the project and git-user nodes — recreating either with the idempotent get-or-create bootstrap from Tutorial 03 if it is missing — and verifies that the store's current coding-memory guidance is available.

Result[loom_demo] is reachable and healthy. Project("palmerpenguins") and the GitUser derived from this repository's current git email are in place (from Tutorial 03, or bootstrapped just now), and the coding prompt returned populated capture, read, and answer guidance.

Start each planning session this way. It catches a wrong store, missing skill, absent scope node, or invalid prompt contract before planning begins.

2. Save or confirm the current roadmap

A Roadmap records work the project intends to do, so a future planning session can recover the backlog without reconstructing it from chat history. Here, the result should be three distinct, project-scoped items rather than one undifferentiated note.

YouIn [loom_demo], remember these roadmap items for the palmerpenguins project: "add a simple package usage example", "document the bundled CSV columns", and "add tests that preserve the current drop_na and return_X_y loader behavior".

AgentThe agent resolves the project and author nodes first (creating any missing one, as in Tutorial 03), then saves the three exact Roadmap identities with project and author edges. Re-saving an existing canonical is an idempotent no-op, so this works identically on a first run and a rerun.

Result[loom_demo] contains all three current Roadmap items for palmerpenguins: add a simple package usage example; document the bundled CSV columns; and add tests preserving drop_na and return_X_y. Each item is scoped to the project and attributed to the git user.

These are not tasks yet. They are planning context that future agents can recover.

3. Save or confirm the design decision

A Decision records a settled direction that should constrain later plans. Saving it separately from the Roadmap lets Loom surface both what the team wants to do and the boundary within which it should be done.

YouIn [loom_demo], remember this Decision: keep palmerpenguins as a lightweight local dataset package. Do not replace the bundled CSV loader with a runtime network download unless I explicitly approve the change in direction.

AgentThe agent saves the exact critical Decision identity with project and author edges. If it already exists, Loom returns the existing fact rather than creating a duplicate.

Result[loom_demo] contains the current critical Decision: keep palmerpenguins as a lightweight local dataset package and do not replace the bundled loader with runtime network access without explicit approval.

The Decision is now project memory rather than chat-only context.

4. Test a conflicting plan

YouPlan a change that fetches the penguins CSV from GitHub at runtime instead of using the bundled package data.

AgentBefore planning, the agent reads the current Decision and Roadmap identities scoped to Project("palmerpenguins").

ResultI found a current critical Decision that palmerpenguins must remain a lightweight local dataset package and must not switch to runtime network downloads without explicit approval. Do you want to override that Decision, or should I plan a package-local update?

That pause is the point. Loom does not silently block you, but it makes the current project decision visible before development goes down the wrong path.

5. Build a compatible plan

YouPlan a package-local update instead.

AgentThe agent rereads [loom_demo] rather than relying on the previous chat turn, then plans around the saved Roadmap and Decision.

ResultPlan: add a simple package usage example, document the bundled CSV columns, and add tests that preserve the current drop_na and return_X_y loader behavior. Keep using the packaged CSV resource; do not add runtime network access.

When a calculation starts repeating across plans like this, it is a promotion candidate: Tutorial 09 promotes a repeated penguin-count query into a named rule and compares the user and root rule tiers.

6. Takeaways

Loom makes current Roadmap items and Decisions the starting point for planning, even after the original session ends.

Resolve project and author nodes before writing scoped facts, creating them idempotently if they are missing.
Save exact canonicals so repeated setup is idempotent.
Re-read current Decisions and Roadmaps before each plan.
Ask before overriding a conflicting critical Decision.
When a calculation repeats across plans, promote it into a named rule — Tutorial 09 shows how and compares the rule tiers.