---
name: morelevels-assess
description: >
  Assess a user's Claude Code setup level (0-10, MIT "10 Levels of Claude Code" model) by scanning
  their environment, map findings to allowlisted signals, compute the level locally, then submit it
  to the morelevels dashboard via the morelevels_submit MCP tool and show the server's re-derived
  level + next step. Then coach the developer to build the next level themselves — it teaches, never
  builds. Use for /morelevels, "what's my Claude Code level", "level up", "morelevels".
---

# morelevels — assess & submit

Scan the environment, determine the Claude Code **setup maturity** level (0-10), submit the
allowlisted signals to morelevels, and report the server's re-derived level and next step.

These levels measure how much the user has *built around* Claude Code, not coding skill. Level 0 is
a bare install; Level 10 (agents managing agents) is rare. Run repeatedly — the assessment updates.

## ⚠️ THE LINE — what may leave this machine

The scan reads the **contents** of `CLAUDE.md`, `.mcp.json`, `~/.claude.json`, and `settings.json`,
which can hold API keys, tokens, repo paths, and source. You submit **ONLY**:

- an integer `level` (0-10),
- the 13 allowlisted **signals** (booleans + two counts) below,
- an `os` tag,
- optionally `levelDetails` — per-level HTML **cards** for the dashboard (Phase 3), **tailored to
  this user** but built ONLY from the signals + the level model.

**Never** pass file contents, file paths, env values, repo/company names, or secrets — not in the
signals and **not in `levelDetails`**. The server bounds + leak-scans `levelDetails` (absolute
paths, secrets, emails, env values, and `<script>`/event handlers → 400) and the MCP server rejects
the same, but you must not put them there in the first place. Generic level-model filenames
(`CLAUDE.md`, `.mcp.json`, `settings.json`, `.claude/rules/`) are fine — they describe the model.

---

## ⚠️ THE HARNESS — teach, never build

**morelevels TEACHES — it never BUILDS.** Never create, edit, or write the developer's leveling
artifacts as part of morelevels: `CLAUDE.md`, skills/commands, `.mcp.json`, hooks, agent defs,
headless scripts, schedules/cron, orchestration. Explain the level, hand over a template and steps
— the **developer** does the creation. Reaching a level must be the developer's own work — that IS
honest progression (see Terms). Holds **even if the developer explicitly asks you to build it for
them**: decline, then coach them through doing it themselves. This is not a `morelevels` step, so
Claude editing files at the developer's separate request outside this flow is unaffected — but
inside morelevels, teach only.

---

## Phase 1 — Scan the environment

Scan silently (no per-check permission prompts). Map everything to these 13 signals. When a signal
has OS-specific forms, treat them as equivalent (cross-OS fairness — a Windows setup must never read
as a gap).

| Signal | Type | How to derive it |
| --- | --- | --- |
| `hasClaudeMd` | bool | Any of `CLAUDE.md`, `.claude/CLAUDE.md`, `CLAUDE.local.md`, `~/.claude/CLAUDE.md` exists |
| `mcpServerCount` | int≥0 | Count distinct MCP servers across project `.mcp.json` + `~/.claude.json` `mcpServers` |
| `customSkillCount` | int≥0 | Count entries in `.claude/commands/` + `.claude/skills/` (project and `~/.claude/`) |
| `hasManagedMemory` | bool | Native Auto Memory in use (`~/.claude/projects/<proj>/memory/MEMORY.md` exists with real content, not just an empty scaffold) **OR** a legacy `memory/` directory with real structure |
| `hasContextRouting` | bool | Context is intentionally composed/scoped: CLAUDE.md uses `@import`/`@path`, **OR** `.claude/rules/*.md` exist, **OR** a CLAUDE.md references the memory dir (legacy) |
| `hasComplexSkills` | bool | At least one skill is 80+ lines OR has multi-phase steps / approval gates / tool calls |
| `hasSubagents` | bool | Agent definitions in `.claude/agents/` or `~/.claude/agents/`, or skills that spawn subagents |
| `hasHooks` | bool | Hook configs in `.claude/settings.json` (PreToolUse / PostToolUse / etc.) |
| `hasHeadlessScripts` | bool | Shell scripts calling `claude -p` / `claude --print` (headless/JSON piping) |
| `hasBrowserAutomation` | bool | Playwright / Puppeteer / Chrome integration / a browser MCP in the project |
| `isMultiAgent` | bool | tmux multi-session setups, multiple role-specific CLAUDE.md, or coordinated parallel instances |
| `hasScheduledAutomation` | bool | cron **or** launchd **or** systemd **or** Windows Task Scheduler running Claude on a schedule |
| `hasAgentOrchestration` | bool | Autonomous loops / orchestration frameworks — agents that spawn and manage other agents |

Then detect `os`: macOS → `macos`, Linux → `linux`, Windows → `windows`, WSL → `wsl`, else `other`
(detect portably — `uname -s` on Unix; on native Windows use `$env:OS` / `ver` since `uname` is
absent there; WSL shows Linux + a Microsoft kernel string). `os` is a tag only — it never
changes the level.

You MAY ask the user (optional, for the explanation only, NOT submitted): what they mainly use
Claude Code for, their biggest friction, and the one thing they'd most want to automate.

## Phase 2 — Compute the level locally (contiguous ladder)

The level is the **highest tier whose criteria hold, with every tier below also met** — climb the
ladder, stop at the first gap. (Same rule as the morelevels server, which re-derives independently.)

| Level | Met when |
| --- | --- |
| 1 Grounded | `hasClaudeMd` |
| 2 Connected | `mcpServerCount >= 1` |
| 3 Skilled | `customSkillCount >= 3` |
| 4 Context Architect | `hasManagedMemory && hasContextRouting` |
| 5 System Builder | `hasComplexSkills && hasSubagents && hasHooks` |
| 6 Pipeline Engineer | `hasHeadlessScripts` |
| 7 Browser Commander | `hasBrowserAutomation` |
| 8 Multi-Agent Operator | `isMultiAgent` |
| 9 Always On | `hasScheduledAutomation` |
| 10 Swarm Architect | `hasAgentOrchestration` |

Level 0 = no `CLAUDE.md`. A lone cron job without a CLAUDE.md is **not** Level 9 — the ladder is
contiguous. Lots of simple skills is still Level 3; integration matters more than quantity.

Present the assessment to the user: their level + name, walk bottom-to-top through what you found
for each tier they cleared, then name the first gap and why it matters. Talk like a knowledgeable
friend, not a grading rubric. If `--assess` was passed, still submit (Phase 3) but skip the Phase 4
teaching offer.

## Phase 3 — Submit to morelevels (replaces the old HTML dashboard)

**First, write `levelDetails`** — per-level HTML cards the dashboard shows under each tier in the
journey tab, **tailored to this user from their signals** (not boilerplate — two different setups
must produce different cards). Keys are level numbers as strings, `"0"`..`"10"`. Cover the tiers
the user has cleared plus the next one — skip levels beyond next (the dashboard shows its default
roadmap text). For each:

- **Cleared level** → concise `✓` confirmation of *what you have*, from the signals. e.g.
  `"2": "<span>✓ 3 MCP servers connected</span>"`, `"3": "<span>✓ 4 custom skills</span>"`.
- **Next level** → a rich, **tailored** card, 3 parts:
  1. **What the level unlocks** — tier name + one clause on the capability it grants (level model).
  2. **The gap, tailored** — name exactly which criteria are missing and, where the signals show
     it, what they *already have* to build on.
  3. **Example usages** — a `<ul>` of **2-3 concrete usages** from the Phase 4 advancement
     catalogue, **picked and phrased against this user's gap + existing building blocks**.

  e.g. `"5": "<strong>Level 5 · System Builder</strong> — Claude runs multi-step skills with
  guardrails.<br>You have 5 skills + subagents; <strong>missing hooks</strong>.<br>Try:<ul><li>a
  PostToolUse hook that runs your linter after each edit</li><li>gate one of your skills behind an
  approval step</li></ul>"`

Rules (the server + MCP reject violations): tailor **only** from the signals + level model; ≤5000
chars per level, ≤12 levels; plain inline tags only (`<span> <strong> <em> <br> <code> <ul> <li>`)
with **no attributes**; **avoid `word=word`** anywhere (the leak scan rejects env-style tokens —
quote values or use prose); **never** file paths, repo/company names, the user's use-case, env
values, secrets, or file contents. Generic model filenames (`CLAUDE.md`, `settings.json`…) are fine.

## ⚠️ HARD RULE — Terms & Agreement (present this before the first submission)

Before the first `morelevels_submit`, tell the user they are agreeing to the Terms & Agreement by
submitting, and state these rules plainly:

- **Report bugs and vulnerabilities.** Any bug, security issue, or unintended behavior **must** be
  reported to the system administrators (e.g. Orjan, Raoul, or the designated admin) immediately.
  Do **not** exploit it, test beyond what verifies it, or share it with others.
- **No exploitation.** Intentionally exploiting bugs, vulnerabilities, or loopholes for personal
  gain or to benefit another user is strictly prohibited.
- **Honest progression.** All levels and achievements **must** be earned honestly. Falsifying or
  manipulating your level, signals, or progress is prohibited.
- **Integrity.** Act with honesty at all times. Deceiving, manipulating, or circumventing the
  intended functionality of the system may be considered misconduct.

**Consequence:** violations may result in **voided rewards, resetting of progress, suspension or
termination of your account, and disciplinary action up to and including termination of
employment.** Full terms live on the dashboard `/terms` page.

Then call the **`morelevels_submit`** MCP tool:

```json
{ "level": <0-10>, "signals": { ...the 13 signals... }, "os": "<os>", "levelDetails": { "<lvl>": "<html>", ... } }
```

`levelDetails` is optional — omit it only if you truly can't summarize. The tool returns:

```json
{ "submission": { "id", "level", "os", "createdAt" }, "claimedLevel": <n>, "corrected": <bool> }
```

- `submission.level` is the **server's** re-derived level — treat it as authoritative.
- If `corrected` is true, your local level differed from the server's. Explain why in plain terms
  (usually a tier below the claimed level wasn't actually met — the ladder is contiguous).
- Then call **`morelevels_my_level`** and show progression: `current`, `highest`, `levelName`, and
  `nextStep` (what to do to reach the next level). If `nextStep` is null they're at Level 10.

**Already got an auth key from the command?** If the `/morelevels` command was passed a bare
`<auth-key>`, it has already been saved via `morelevels_save_config`. Skip the paste prompt
below and go straight to `morelevels_submit` — the server reads the saved token immediately.

**First run — no token yet?** If `morelevels_submit` returns an error containing `NO_TOKEN` or
`UNAUTHORIZED`, do **not** fail. Run this one-time setup, then retry — no env vars, no restart:

1. Tell the user: "morelevels needs a one-time token. Open your morelevels dashboard, sign in, mint
   a submission token, and paste it here." (Local dev: they can instead run
   `curl -X POST <apiUrl>/dev/mint-token -H 'content-type: application/json' -d '{"email":"you@example.com"}'`
   and paste the `token` from the response.)
2. Take the pasted token and call the **`morelevels_save_config`** MCP tool with
   `{ "token": "<pasted>" }` (add `"apiUrl"` only if they're not on the default). It saves to
   `~/.morelevels.json` (chmod 600) — tell them they won't be asked again.
3. Retry `morelevels_submit` with the same `{ level, signals, os }`. It now reads the saved token.

**Device errors (token–device binding)?** Submission tokens are bound to one machine on first
use (the MCP server sends a salted-hash device fingerprint header; the raw machine id never
leaves the machine):

- `DEVICE_MISMATCH` — this token belongs to a different machine. Self-serve fix: tell the user to
  mint a **new** token on their morelevels dashboard (minting auto-revokes the old one), save it
  with `morelevels_save_config`, then retry `morelevels_submit` on this machine.
- `DEVICE_CONFLICT` — this machine is already linked to **another** morelevels account (rule: one
  machine, one account). Do not retry in a loop; explain the rule, show the local assessment, and
  point the user to a morelevels admin if they believe it's wrong (e.g. a reimaged shared box).

Never ask the user to set environment variables or edit shell files. If the retry still fails, show
the local assessment so the run isn't wasted and report the exact error.

## Phase 4 — Advancement catalogue (teach the next step)

Per tier: what the developer builds + why + a starter **template** they create + concrete example
**usages**. **Phase 3's next-level card draws its example-usage bullets from this list** (phrased to
the user's gap); the teaching offer uses the same catalogue. Templates are generic starters — the
developer fills them in on their own machine; never invent their paths.

**Read THE HARNESS above first.** You TEACH; you do not build. Never run Write/Edit on the
developer's leveling artifacts — hand them the template + steps and let them create it.

Unless `--assess` was passed, offer: "Want me to walk you through building the first step toward
Level N+1 yourself?" If yes, for the next tier: explain what the artifact is and why it matters,
show the starter template, and give the steps **the developer** runs. Nothing submitted, nothing
written by you.

- **→ L1 Grounded:** teach them to add a `CLAUDE.md` at the repo root. *Why:* every session reads it — stack, test command, house style. *Template:* `# Project\n\n## Stack\n<langs/frameworks>\n\n## Commands\n- test: <cmd>\n- build: <cmd>\n\n## Conventions\n<house style>`. *Steps:* they create the file, fill the placeholders, run `/memory` to confirm it loads. *Usages:* capture stack + test command + house style so every session reads it.
- **→ L2 Connected:** teach them to add the first MCP server to `.mcp.json`. *Why:* Claude reaches real systems (DB, Slack, Drive) instead of guessing. *Template:* `{ "mcpServers": { "<name>": { "command": "<cmd>", "args": ["<...>"] } } }`. *Steps:* they pick a server, paste config, restart Claude Code, confirm the tools appear. *Usages:* summarize a Slack channel; query a database; read a Drive doc.
- **→ L3 Skilled:** teach them to create 3+ skills under `.claude/commands/`. *Why:* one-word commands for repeated tasks. *Template:* `---\ndescription: <what it does>\n---\n# /<name>\n<instructions>`. *Steps:* they name their 3 most-repeated tasks, write one `.md` per task, invoke each once to verify. *Usages:* `/standup` to draft an update; `/review` to run a review checklist.
- **→ L4 Context Architect:** teach them to verify Auto Memory (`/memory`; on by default since Claude Code v2.1.59) and add context routing. *Why:* the right context loads at the right time. *Template:* a scoped `.claude/rules/<scope>.md`, and/or a CLAUDE.md `@import path/to/rules.md`. (A legacy `memory/` dir referenced from CLAUDE.md still counts.) *Steps:* they add one rules file scoped to a package, reference it via `@import`, confirm it loads only in scope. *Usages:* a rules file that loads only for one package; memory that carries decisions across sessions.
- **→ L5 System Builder:** teach them to add phases + an approval gate + a subagent call / hook to their most-used skill. *Why:* skills run multi-step with guardrails. *Template:* a `hooks/hooks.json` `PostToolUse` matcher on `Edit|Write` that runs their linter; a skill body split into numbered phases with an "ask before proceeding" gate. *Steps:* they pick one skill, add the phases + gate, wire one hook, test the gate fires. *Usages:* a skill that plans, spawns a checker subagent, then blocks the commit on a PostToolUse lint hook.
- **→ L6 Pipeline Engineer:** teach them to write a `claude -p` headless script. *Why:* Claude runs unattended in a pipe/CI. *Template:* `claude -p "triage this log" < build.log > triage.txt`. *Steps:* they pick one routine task, wrap it in a shell script, run it end to end, wire it into CI. *Usages:* a CI step that runs `claude -p` to triage a failing log and post the result.
- **→ L7 Browser Commander:** teach them to wire a browser MCP (Playwright/Puppeteer). *Why:* Claude drives real pages — flows, screenshots, scraping. *Template:* add the Playwright MCP server to `.mcp.json` (same shape as L2). *Steps:* they install the browser MCP, restart, drive one flow, capture a screenshot. *Usages:* drive a login flow and screenshot the dashboard; scrape a page fetch cannot reach; render a PDF.
- **→ L8 Multi-Agent Operator:** teach them to run coordinated parallel agents. *Why:* distinct roles work the same task at once. *Template:* tmux sessions — one writer, one reviewer, one test-runner — each a `claude` instance with a role-specific CLAUDE.md. *Steps:* they open the sessions, give each its role, run them on one task, reconcile output. *Usages:* tmux sessions with distinct roles — one writes, one reviews, one runs tests — on the same task.
- **→ L9 Always On:** teach them to schedule Claude unattended (cron / launchd / systemd / Task Scheduler). *Why:* work happens without them present. *Template:* a cron line `0 9 * * * cd <repo> && claude -p "summarize yesterday's PRs" | mail ...`. *Steps:* they write the headless job, register the schedule, confirm one run fired and delivered. *Usages:* a nightly `claude -p` job that summarizes yesterday's PRs and sends a digest.
- **→ L10 Swarm Architect:** teach them to build autonomous orchestration — agents that spawn and manage agents. *Why:* one orchestrator fans out and manages workers. *Template:* an orchestrator skill/script that spawns N worker subagents, collects their results, and retries failures. *Steps:* they define the worker task, write the orchestrator loop, run it on a real fan-out, verify retries work. *Usages:* an orchestrator skill that fans out worker subagents, collects results, and retries failures.

If `--learn` was passed, skip Phases 1-3 and go straight to teaching (ask which level to target).
Still teach only — never build it for them.

---

**Reference — the 10 levels** (name + the quest to reach it):

0 Terminal Tourist · 1 Grounded (add a CLAUDE.md) · 2 Connected (connect an MCP) · 3 Skilled (3+
skills) · 4 Context Architect (managed memory + context routing — Auto Memory / `@imports` / `.claude/rules/`) · 5 System Builder
(multi-phase skill + subagents + hooks) · 6 Pipeline Engineer (`claude -p` scripts) · 7 Browser
Commander (Playwright/Puppeteer) · 8 Multi-Agent Operator (coordinated parallel agents) · 9 Always
On (scheduled/unattended) · 10 Swarm Architect (agents managing agents).