Tutorial 00: Connect your coding harness to Loom

Loom gives agents in coding harnesses shared, durable memory: decisions, instructions, and project knowledge survive session boundaries and return when they become relevant. This tutorial connects that memory before any later tutorial depends on it.

This tutorial opens the public tutorial repository in your coding harness, installs Loom, adds your private store bundle, and verifies the connection. After connecting, take the five-minute cross-session memory loop in Tutorial 01; the repository-specific setup begins in Tutorial 03.

If you do not have Loom access, sign in at https://loomcloud.ai, submit the private-beta request, and wait until the site shows your Stores or Install page. Do not continue while the request is pending. If you have an access code, enter it in the request form. The site confirms Access request received; return through the same sign-in flow after approval. Keep your connection bundle private.

1. Check out the tutorial repository and open it in your agent

The tutorial path uses the public palmerpenguins Python repository because it has real package code, tests, and bundled CSV data without requiring access to a private repository. Check it out into a folder named demo:

git clone https://github.com/mcnakhaee/palmerpenguins.git demo
cd demo

Open the cloned demo folder as your agent's workspace, or start your agent from that directory. Keep that workspace open as you continue through the tutorials.

YouConfirm that this workspace is the cloned palmerpenguins repository. Show the repository root and configured Git remote, but do not modify any files.

AgentThe agent checks the workspace root and Git remote without writing to the repository.

ResultThis workspace is the cloned palmerpenguins repository. Its root is the open demo folder, and its configured remote points to the public upstream repository. No files were changed.

Only continue after the repository is open in your agent. This gives Loom a real project scope for the memory exercises that follow.

2. Install the Loom plugin

The plugin gives your coding harness three pieces that work together. Loom skills teach the agent how to use memory. The MCP connection is the bridge that reads and writes stores. Lifecycle hooks bring relevant context into the conversation automatically. A successful install means all three are available in a fresh session, not merely that an install command completed.

Install the Loom plugin from the marketplace for your coding harness. The authenticated install page at https://loomcloud.ai/install shows the current command for Claude Code, Codex, or Hermes. The rest of the tutorials use shared prompts that work in Claude Code and Codex; this installation section calls out each harness only where its commands or hook behavior differ.

First ask the agent to run the installed loom-install skill as a plugin-only preflight. Store connectivity is verified only after §3 installs your private bundle:

YouRun the loom-install skill as a plugin-only preflight. Verify the bundled runtime, skills, MCP startup, and hooks, but do not claim store connectivity until I install my private bundle in §3.

AgentThe agent follows the installed plugin's checks for plugin wiring, its bundled runtime, Loom skills, and MCP startup. It does not try to bypass the authenticated install page, invent a store, or claim that an unconfigured store is reachable.

ResultLoom's plugin preflight passed: the bundled runtime and skills are present and the MCP server starts without a traceback. Store connectivity is not verified yet; install the private bundle in §3 first.

Only continue after the plugin-only preflight completes cleanly.

After every Loom upgrade

An upgrade refreshes the plugin or bundle, but it does not prove that its runtime dependencies, connection bundle, and lifecycle hooks still match the new version. After every upgrade, start a fresh Codex, Claude Code, or Hermes session so it discovers the new loom-install skill, rerun that skill, and follow any final restart or hook-trust step it reports. Do not assume that a successful plugin-manager command alone completed the upgrade.

Trust, enable, and verify the lifecycle hooks

Installing the plugin is not enough by itself. Loom depends on lifecycle hooks to prime memory at session start, refresh relevant context on each prompt, check actions before and after tools run, and preserve optional compaction checkpoints.

For Codex, fully restart Codex or open a fresh task after installation. When Codex asks whether to trust a Loom plugin hook, review that it comes from loom@loom and choose the persistent Trust/Enable action. Trust and enable all six Loom hook events: SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PreCompact, and PostCompact. In the Codex desktop app, you can also review them under Settings → Hooks.

For Claude Code, installing the plugin enables it. Start a fresh session, then open the read-only hook browser:

# start a fresh Claude Code session, then run:
/hooks

In /hooks, verify that Loom appears with source Plugin under SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, and PreCompact. In the Claude desktop app, you can also verify them under Settings → Hooks. Claude Code must not be launched with --bare, and disableAllHooks must be absent or false. Claude trusts hooks as part of the plugin you chose to install; /hooks is where you verify that the enabled plugin contributed them.

Now start one more fresh coding-harness session in the tutorial repository. Verify that its opening context includes Loom's standing-memory prime. Then submit an ordinary prompt and confirm the harness reports the Loom prompt hook running. If either check is missing, stop: re-enable the plugin, complete any harness-specific trust prompts, and repeat the verification before continuing. MCP calls can still work while hooks are disabled, which is why a successful store listing alone is not sufficient.

3. Install your private store bundle

The plugin provides Loom's behavior, while the private store bundle tells it which stores your account can reach. Keeping this configuration outside the repository lets the same project remain safe to share without exposing connection material.

After signing in to Loom Cloud, open https://loomcloud.ai/install. The current bundle renders a configured default store plus tutorial and Kanban stores. An older installed bundle can lack the top-level default entry or use an older tutorial-store alias; if so, replace it with the current bundle before continuing.

Copy the bundle to ~/.loom/stores.toml yourself or provide it to the agent during loom-install. Use the rendered values; never hand-type or invent keys from a reference example.

A redacted bundle has this shape:

default = "coding"

[coding]
description      = "Primary coding memory store."
endpoint         = "tcp://loomcloud.ai:7443"
store            = "<your coding store id>"
namespace_scheme = "loom-8"
server_key       = "<redacted broker key>"
store_key        = "<redacted coding store key>"
domain           = "CodingDomain"

[loom_demo]
description      = "Seeded Loom tutorial demo store with sample data."
endpoint         = "tcp://loomcloud.ai:7443"
store            = "<your demo store id>"
namespace_scheme = "loom-8"
server_key       = "<redacted broker key>"
store_key        = "<redacted demo store key>"
domain           = "CodingDomain"

[kanban]
description      = "Kanban store for multi-agent coordination."
endpoint         = "tcp://loomcloud.ai:7443"
store            = "<your kanban store id>"
namespace_scheme = "loom-8"
server_key       = "<redacted broker key>"
store_key        = "<redacted kanban store key>"
domain           = "LogDomain"

Do not paste live keys into source files, issues, commits, screenshots, or tutorial content.

Now rerun the full connection check:

YouMy current private bundle is installed. Rerun loom-install and verify that every configured store is reachable. Do not expose any connection keys.

AgentThe agent reruns the installed skill against the now-configured bundle, checks MCP access to each named store, and reports only store names and health—not credentials.

ResultLoom is installed and connected. The runtime, skills, MCP startup, hooks, and configured store connections all pass.

Do not continue to store exercises until this post-bundle check succeeds.

4. Verify your agent can see the configured stores

The starter bundle normally reserves loom_demo and kanban; your primary coding-store alias and any stores you create may vary. Always confirm the live list before continuing.

YouUse Loom to list every store in my installed bundle. Show each store's exact name and registry description, and tell me which one is configured as the default. Do not load or modify a store yet.

AgentThe agent asks Loom for the configured stores and reports their names and descriptions.

ResultThe connection is working. Here are the exact store names and descriptions returned by this bundle. Its configured default is <exact name>, its writable tutorial store is <exact name>, and its Kanban store is <exact name>. I will use those returned names in later prompts rather than guessing aliases.

If Loom lists named stores but describing default reports that no endpoint is configured, or if no writable tutorial store is present, the connection is only partially configured. Install the current signed-in bundle and rerun loom-install; do not silently substitute an unrelated store.

If the list is empty or the MCP connection fails, stop here and rerun loom-install. Connecting to and describing individual stores belongs to Tutorial 02: Connect to multiple stores.

Start the tutorial sequence with `loom_demo`

Once the installed bundle confirms that the exact loom_demo alias exists, make it the working store for this session:

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.

This is intentionally the first store-selection action after connection. A new coding-harness session returns to the default from your installed bundle until you repeat this prompt.

5. Verify the coding-memory skill

The loom-coding skill is the main coding-agent discipline: it loads relevant project context, checks standing directives, and captures durable decisions as work progresses.

This check separates “the agent can reach a store” from “the agent knows how to use project memory safely.” You should see both before saving any tutorial facts.

YouCheck that the loom-coding skill is installed and can load its current guidance. Do not write a fact yet.

AgentThe agent checks the available skills, loads loom-coding, and verifies that its live guidance is readable.

ResultThe loom-coding skill is available and active. I can use its read, capture, and action-checking discipline in the later repository tutorials.

If the skill is missing, repair the Loom plugin installation before continuing.

6. Takeaways

Check out the public palmerpenguins repository and open its demo folder in your agent before installing Loom.
Install the plugin and run loom-install before working with Loom memory.
Install the private bundle before claiming that any store connection works; stop while beta access is pending.
Trust and enable every Loom lifecycle hook, start a fresh session, and verify the opening memory prime before continuing.
Treat ~/.loom/stores.toml as private connection material.
Ask Loom to list the account-specific store names instead of guessing.
Make loom_demo the session-only default before beginning the tutorial exercises.
Verify loom-coding is available before starting repository work.
Continue to Tutorial 01: Build your first memory in five minutes for the fastest cross-session first win, or Tutorial 02: Connect to multiple stores to connect, describe, and safely target the configured stores.