The spec slice helps you plan a change in files, do it, and check it. It keeps the plan, its specs, and its tasks in openspec/changes/<name>/, in the layout of OpenSpec. The slice ships the command minispec, three presets (task, story, and epic), and seven skills.

The first four skills are /claudetto:propose, /claudetto:apply, /claudetto:verify, and /claudetto:archive. They match the steps /opsx:propose, /opsx:apply, /opsx:verify, and /opsx:archive of OpenSpec. Only you can start a skill, because each has disable-model-invocation: true. So the skills add no description to the request at session start. The slice has no hook and no userConfig key. It runs no openspec init and changes no global config of OpenSpec.

Skill	Argument	What it does
/claudetto:propose	`[task	story
/claudetto:apply	[change]	Does the open tasks of tasks.md, and ticks each one when its check passes.
/claudetto:verify	[change]	Checks that the code does what the tasks, specs, and design say.
/claudetto:archive	[change]	Merges the delta specs into openspec/specs/, and moves the change to openspec/changes/archive/.
/claudetto:explore	[change or idea]	Thinks through an idea with you, and writes no code.
/claudetto:update	[change]	Revises the artifacts of a change, and keeps them equal to each other.
/claudetto:sync	[change]	Merges the delta specs into openspec/specs/ with no archive, and keeps the change.

The skills call minispec, a command in bin/ of the plugin. It reads and writes the files of the OpenSpec layout, so you can still run OpenSpec on the same files. A schema in openspec/schemas/<name>/ wins over the preset of the same name in the slice.

Command	What it does
minispec new change <name> [--schema <preset>] [--description <text>] [--json]	Makes openspec/changes/<name>/. The default preset is story.
minispec list [--specs] [--archived] [--all] [--sort recent|name] [--json]	Lists the changes with their task counts, or the specs with their requirement counts.
minispec status --change <name> [--json]	Prints the checklist of artifacts and a Next: line with the next skill. With --json, it gives each artifact with its status, template, and instruction, and next, context, rules, apply, and tasks.
minispec instructions apply|<artifact> --change <name> [--json]	Gives the task list and state of apply, or the template, dependencies, and unlocks of an artifact.
minispec show <change|spec> [--json] [--deltas-only] [--diff] [--requirements] [-r <n>]	Shows a change (proposal, deltas, diffs) or a spec.
minispec validate <name> | --all | --changes | --specs [--strict] [--json]	Checks the delta specs of a change, or the main specs.
minispec schemas [--json]	Lists the schemas of the project and the presets.
minispec schema validate [<name>] [--json]	Checks that each template and each requires of a schema exists.
minispec sync <name>	Merges the delta specs into openspec/specs/, and keeps the change folder.
minispec archive <name> [--yes] [--skip-specs] [--no-validate] [--json]	Validates the change, merges its delta specs, and moves it to the archive. With open tasks, it asks first unless you pass --yes.

MiniSpec has no size bound.

/claudetto:propose states the facts that it used. It then uses the first rule that fits:

1. You name a preset: that preset.
2. There is no openspec/specs/ and the repository is nearly empty: epic.
3. The change does not change behavior: task.
4. The change touches one capability: story.
5. Unsure: story, and ask you.

Each schema is version: 1 and has an apply step that tracks tasks.md. The tasks artifact asks for checkboxes - [ ] X.Y Task under ## N. headings, because the apply step parses them. Each task says how to verify it.

Schema	Use	Artifacts, in order
task	A bug fix, a small change, or a refactor	proposal, tasks
story	One feature in an existing codebase	proposal, specs, design, review, tasks
epic	A new project, a large feature, or a regulated system	prd, architecture, proposal, specs, design, review, tasks

The proposal has the sections Why, What Changes, and Impact. It lists no capability. If behavior changes, it says to use story. The apply step requires tasks.

The proposal adds Capabilities. It lists each new capability (a kebab-case path) and each modified capability (the exact path under openspec/specs/). Each listed capability gets a delta spec in specs/<capability-path>/spec.md. A spec states behavior that you can observe, with these rules:

• Use the headers ## ADDED Requirements, ## MODIFIED Requirements, ## REMOVED Requirements, and ## RENAMED Requirements.
• Write each requirement as ### Requirement: <name> with SHALL or MUST.
• Give each requirement at least one #### Scenario: <name> with WHEN and THEN.
• Start a new capability with a ## Purpose of 50 characters or more.
• Write [NEEDS CLARIFICATION: <question>] in place of a guess.

The design artifact has Context, Decisions, and Risks / Trade-offs. The review artifact checks that the proposal, the specs, the design, and the tasks agree. It stops while a gap or a [NEEDS CLARIFICATION marker is open. The apply step requires review. It asks for a fast check after a change of behavior, and the full checks at the end of each task group.

The epic schema adds two artifacts before the proposal:

• prd with Problem, Users, Goals, Non-Goals, and Success Measures.
• architecture with Components, Data and Interfaces, Constraints, and Decisions.

The proposal takes the why from prd.md. The review template adds checklists for the PM, the architect, and QA. The apply step requires review.

An optional openspec/config.yaml sets schema, a context block, and rules for each artifact. minispec status --json gives context and rules, and /claudetto:propose adds context to each artifact and rules.<artifact> to that artifact only. Write only what an agent cannot learn from the code, and delete each line that does not apply.

• Ground
• Bounds for Slices
• Handoff
• Setup