levelsSAFE

Claude Code skills that rate parts of a project on a 1 to 5 scale, propose options, and delegate the chosen work to cheaper models behind a confirmation gate.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: levels
description: Conduct the connected level skills as one workflow. Asks the user what they want to do with a multi-select prompt, sets a target level per chosen skill, then runs the skills in a fixed safe order with a gate before each one. Use when the user runs /levels or asks to take a project through the whole level process.
summary: Run several skills as one workflow
argument-hint: "[new|raise|redesign|release|present] [audit|build] [from <phase>]"
model: opus
---

# Levels

Arguments: `$ARGUMENTS`

Parse the arguments:

- **ROUTE**: `new`, `raise`, `redesign`, `release` or `present`. Optional shortcut. When given, it pre-selects skills and the question prompt in Step 1 is skipped.
- **MODE**: `audit` (every skill audits only) or `build` (skills may build). Default `audit`.
- **FROM**: a phase name to resume from. Default: the first phase not marked done in `LEVELS.md`.

State the parsed settings in one line before starting. If AskUserQuestion is unavailable, ask in plain text and wait for the answer.

You are the conductor. You do not audit, plan or build anything yourself, apart from the cross-layer check in Step 3. You decide which level skill runs next, pass it context, and keep the record. Every skill keeps its own rules, its own delegation gate and its own model warnings.

## Phases

| Phase | Skills, in order | Skipped when |
|---|---|---|
| Orient | `levels-status` | never |
| Define | `idea-level` | a confirmed blueprint or a working product exists |
| Shape | `ux-level`, `restyle-level` | the project has no interface |
| Build | `data-level`, then `backend-level`, then `design-level` | nothing chosen to build. Skip `data-level` when nothing is stored. Skip a layer that does not exist or is not in scope |
| Harden | `test-level`, `security-level`, `perf-level`, `code-level` | never as a whole. Skip single skills by the level plan |
| Release | `docs-level`, `ship-level` | the product is not going to be run by anyone else or anywhere else |
| Present | `pitch-level` | nobody needs persuading |

The order inside a phase is fixed, whatever order the user picked things in. Flow comes before look. Stored data comes before the layers that use it. Tests come before any skill that changes working code. Structure work comes last in Harden. Written steps come before the release rehearsal that follows them.

## Routes

Shortcuts for the common selections:

- **new**: Define, Shape, Build, Harden, Release.
- **raise**: the skills `levels-next` ranks highest, one at a time.
- **redesign**: Shape, then `design-level` in `build` mode, then `test-level`.
- **release**: `test-level`, `security-level`, then Release.
- **present**: Present only.

## Step 1: Orient and ask

1. Run `levels-status`. Read `LEVELS.md` and its flow section if present.
   If `LEVELS.md` does not exist, print one line before the prompt: `New here? Run /levels-help for a short guide.`
2. If a flow is recorded as unfinished and no ROUTE was given, ask first: **Resume it** (Recommended), or **Start a new selection**.
3. If no ROUTE was given, ask what the user wants to do. Use one AskUserQuestion call with four questions, each with `multiSelect: true`. The user may tick any number in each, or none.

   - **Plan and shape**, "What do you want to work out?"
     - Find or sharpen the idea (`idea-level`)
     - Fix how tasks flow (`ux-level`)
     - Pitch new looks or layouts (`restyle-level`)
   - **Build**, "What do you want built or raised?"
     - Interface (`design-level`)
     - Server and logic (`backend-level`)
     - Stored data and migrations (`data-level`)
   - **Harden**, "What do you want made safer?"
     - Tests (`test-level`)
     - Security (`security-level`)
     - Speed (`perf-level`)
     - Code structure (`code-level`)
   - **Ship and show**, "What do you want ready for others?"
     - Documentation (`docs-level`)
     - Release and deploy (`ship-level`)
     - Pitch or presentation (`pitch-level`)

   Write each option's description from the project state: the current level from the levels block, and the count of open gaps. From the state, mark up to two options per question as recommended: put them first and end the label with "(Recommended)". Leave out options that cannot apply, such as interface options in a project with no interface, and say which were left out and why.

4. Resolve the selection:
   - Nothing ticked anywhere: run `levels-next` and offer its single recommendation.
   - A ticked skill depends on one not ticked (a build with no tests after it, a release with no written steps, a restyle on a flow never checked): name the missing skill and ask once whether to add it. Follow the answer.
5. Ask once, in one round, only what `LEVELS.md` does not answer: what the product is for, who uses it, where it runs, any date, and how much model spend the user accepts for this run (low, medium, no limit).
6. Write the selection and the answers to the shared part of `LEVELS.md` so no later skill asks them again.

## Step 2: Level plan

1. Put the selected skills into phase order.
2. Show one table: each selected skill, its current level, the target level you propose, and one line of reason. Size targets to the product. A small tool does not need level 4 everywhere.
3. With a low spend limit, propose running fewer of the selected skills first, not lower quality inside each one. Say which you would defer.
4. Wait for the user to confirm or edit the table. Record it in the flow section.

## Step 3: Run

For each skill in the plan, in order:

1. Print one line: `Phase <name> → <skill> <level> <mode>`.
2. Ask with AskUserQuestion: **Run** (Recommended), **Skip**, **Change level or mode**, **Stop here**. State that the skill starts its own model spend.
3. Invoke the skill with the Skill tool, passing level, mode and scope. Tell it that `levels` called it: it reuses the shared record, reports back, and offers no handoff of its own.
4. When it returns, read its findings for anything that belongs

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.