openloomi-tour
Walk a brand-new OpenLoomi user through the entire pipeline in one guided session: setup health → pet reaction → connector onboarding → run a Loop tick → inspect & approve a decision card → seed Memory → optionally register a custom Loop channel / classifier rule / decision type. Triggers: openloomi tour, guided tour, walk me through openloomi, show me everything, end-to-end demo, 带我看一下, 体验一下, 一条龙, 一键体验, first time using openloomi, what's next after setup.
npx skills add melandlabs/openloomi --skill openloomi-tour --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
The skill conducts a hands-on, multi-phase OpenLoomi onboarding tour. It sequences phases from pre-flight checks through Phase 1 (Pet reaction), Phase 2 (Onboarding & input sources), Phase 3 (Run one Loop tick), and Phase 4 (Seed Memory). Each phase runs a set of explicit commands and checks prerequisites, providing an interactive, idempotent, and skippable experience that is non-destructive and can be navigated with next/skip/back, with the option to register additional Loop components at the end.
How it works
- Phase 0 (Pre-flight): executes three node/CLI checks via the loomi-bridge script to determine readiness, host probe, and execution provider status, then prints the user state before Phase 1.
- Phase 1 — Pet reaction: runs four pet state commands to display different sprites (happy, thinking, working, juggling) and ends with the pet in the happy state, signaling readiness.
- Phase 2 — Onboarding & input sources: offers three input paths (Native bot, Composio OAuth, Screen memory) and provides concrete commands to verify connections or memory captures. It supports a skip option with rules for Phase 3 and memory seeding implications.
- Phase 3 — Run one Loop tick: if there is at least one signal source, dispatches a background Loop tick by posting to /api/loop/tick, then (a) guides the user to discuss architecture, (b) polls for lastTickAt completion, and (c) inspects outcomes, including decisions. If a decision exists, shows its card and provides a one-tap approve command.
- Phase 4 — Seed Memory: uses the openloomi-memory tool to add tour-owned memory entries (About me, Current project, Values) with explicit add-memory commands, followed by a search-all to confirm indexing. It notes that these are tour-owned and may be overwritten on reruns and that user-authored memory paths are protected.
Commands and file names are quoted exactly as shown in the skill, such as:
- node "${CLAUDE_PLUGIN_ROOT}/scripts/loomi-bridge.mjs" setup-status --json
- node "${CLAUDE_PLUGIN_ROOT}/scripts/loomi-bridge.mjs" pet happy
- node "${CLAUDE_PLUGIN_ROOT}/skills/openloomi-connectors/scripts/openloomi-connectors.cjs" list-accounts
- /api/loop/tick (POST)
- MEM="${CLAUDE_PLUGIN_ROOT}/skills/openloomi-memory/scripts/openloomi-memory.cjs"
- node "$MEM" add-memory "About me: <text>" --file=tour/about-me.md
When to use it
Triggered by phrases like openloomi tour, guided tour, walk me through openloomi, end-to-end demo, first time using openloomi, what's next after setup. It is the canonical first-run experience and is designed to be interactive, idempotent, and skippable, ensuring phases are not destructive and can be revisited as needed.
What it can touch
- Scripts and endpoints under ${CLAUDE_PLUGIN_ROOT}, including:
- scripts/loomi-bridge.mjs
- skills/openloomi-connectors/scripts/openloomi-connectors.cjs
- skills/openloomi-memory/scripts/openloomi-memory.cjs
- The memory tool via the command memory scripts and add-memory / search-all calls
- HTTP endpoints such as http://localhost:3414/api/loop/tick and related /api/loop/state, /api/loop/decisions
Caveats
- Phase 3 tick runs in the background and is not guaranteed to complete before Phase 4; user is guided to proceed and monitor progress.
- Phase 4 seeds tour-owned memory under ~/.openloomi/data/memory/tour/ and may overwrite tour artifacts on reruns; user-authored memory paths are protected.
- The tour is non-destructive and reversible in terms of ensuring no irreversible actions during onboarding.
# OpenLoomi Tour — Hands-on Walkthrough This skill is the **canonical first-run experience** for Claude Code users. After `/openloomi:setup` finishes and prints its post-ready walkthrough, the user can type **`/openloomi:tour`** (or any of the trigger phrases) and you'll run the same pipeline live, stopping between phases so the user can react. The tour is **interactive, idempotent, and skippable**. Each phase checks its own prerequisite and lets the user move on with `next` / `skip` / `back`. Nothing is destructive — if the user already did a phase, you re-confirm it and move on. --- ## Reference docs Quick links to the OpenLoomi docs that this tour draws from. Every phase below cites the relevant entries inline. | Topic | Doc | | --- | --- | | Getting started / install / one-time setup | <https://openloomi.ai/docs/getting-started> | | What OpenLoomi is (the pipeline in one page) | <https://openloomi.ai/docs/what-is-openloomi> | | Glossary — every term used here (Connector / Signal / Loop channel / Action Runner / etc.) | <https://openloomi.ai/docs/glossary> | | Loop engine — ticks, Decisions, cards, channels, classifier rules | <https://openloomi.ai/docs/loop> | | Loop — Approve
- Reference docs
- Phase 0 — Pre-flight
- Phase 1 — Pet reaction (always run)
- Phase 2 — Onboarding & input sources (interactive)
- Skipping this phase
- Phase 3 — Run one Loop tick (only if a signal source exists)
- Phase 4 — Seed Memory (always run, idempotent)
- Phase 5 — Optional extensions (only on user request)
- 5b. Classifier rule (deterministic override)
- 5c. Custom [decision type](https://openloomi.ai/docs/loop)
- 5d. Inventory dump — what did we just register?
- Hand-off
- Sandbox and network
node "${CLAUDE_PLUGIN_ROOT}/scripts/loomi-bridge.mjs" setup-status --json
node "${CLAUDE_PLUGIN_ROOT}/scripts/loomi-bridge.mjs" run-host-probe
Claude is selected; Codex/OpenCode/Hermes/OpenClaw use their own auth.
node "${CLAUDE_PLUGIN_ROOT}/scripts/loomi-bridge.mjs" pet happy
node "${CLAUDE_PLUGIN_ROOT}/scripts/loomi-bridge.mjs" pet thinking
node "${CLAUDE_PLUGIN_ROOT}/scripts/loomi-bridge.mjs" pet working
node "${CLAUDE_PLUGIN_ROOT}/scripts/loomi-bridge.mjs" pet juggling
node "${CLAUDE_PLUGIN_ROOT}/skills/openloomi-connectors/scripts/openloomi-connectors.cjs" list-accounts
composio execute GMAIL_GET_PROFILE -d '{}' # or toolkit-specific probe
Screen memory: verify via the Memory surfaces after the first captureWhat does the openloomi-tour skill do?
Walk a brand-new OpenLoomi user through the entire pipeline in one guided session: setup health → pet reaction → connector onboarding → run a Loop tick → inspect & approve a decision card → seed Memory → optionally register a custom Loop channel / classifier rule / decision type. Triggers: openloomi tour, guided tour, walk me through openloomi, show me everything, end-to-end demo, 带我看一下, 体验一下, 一条龙, 一键体验, first time using openloomi, what's next after setup.
How do I install it?
Run `npx skills add melandlabs/openloomi --skill openloomi-tour --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From melandlabs/openloomi, a repository with 764 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.
