fission-ai/openspec/openspec-onboard

Guide the user through their first complete OpenSpec workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.

Store selection: If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run openspec store list --json to discover registered store ids, then pass --store <id> on the commands that read or write specs and changes (new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view). Once selected, treat --store <id> as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run openspec status --change "<name>" --json --store "<id>", not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local openspec/ root.

Project check: These steps expect a project that already uses OpenSpec. Before the first step that writes anything (new change, archive, sync specs, or authoring an artifact file), confirm the project has a root: run openspec list --json (with --store <id> when a store is selected, since the store is then the root) and read root. A root object means the project is set up. "root": null means it is not - there is no openspec/ directory here, and a write such as openspec new change would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.

One "root": null is not about setup: when a status error message starts with Declared in or Invalid store declaration in and names this project's openspec/config.yaml (or config.yml), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the store: line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's message and fix.

Otherwise, with no root, what happens next depends on how this workflow was reached:

• Auto-selected: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or invoking this skill by name. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
• Explicit OpenSpec request: the user named OpenSpec, named this skill, or invoked this skill by name. Stop before writing and ask how to proceed: set this project up (openspec init), target a store they already have (--store <id>), or continue without OpenSpec for this request. Wait for their answer.

In both branches, never create the root as a side effect: do not run openspec init until the user asks for it, do not hand-create openspec/ files, and do not let a command create it.

Preflight

Before starting, check if the OpenSpec CLI is installed:

# Unix/macOS
openspec --version 2>&1 || echo "CLI_NOT_INSTALLED"
# Windows (PowerShell)
# if (Get-Command openspec -ErrorAction SilentlyContinue) { openspec --version } else { echo "CLI_NOT_INSTALLED" }

If CLI not installed:

OpenSpec CLI is not installed. Install it first, then come back to /openspec-onboard.

Stop here if not installed.

Phase 1: Welcome

Display:

## Welcome to OpenSpec!
 
I'll walk you through a complete change cycle—from idea to implementation—using a real task in your codebase. Along the way, you'll learn the workflow by doing it.
 
**What we'll do:**
1. Pick a small, real task in your codebase
2. Explore the problem briefly
3. Create a change (the container for our work)
4. Build the artifacts: proposal → specs → design → tasks
5. Implement the tasks
6. Archive the completed change
 
**Time:** ~15-20 minutes
 
Let's start by finding something to work on.

Phase 2: Task Selection

Codebase Analysis

Scan the codebase for small improvement opportunities. Look for:

1. TODO/FIXME comments - Search for TODO, FIXME, HACK, XXX in code files
2. Missing error handling - catch blocks that swallow errors, risky operations without try-catch
3. Functions without tests - Cross-reference src/ with test directories
4. Type issues - any types in TypeScript files (: any, as any)
5. Debug artifacts - console.log, console.debug, debugger statements in non-debug code
6. Missing validation - User input handlers without validation

Also check recent git activity:

# Unix/macOS
git log --oneline -10 2>/dev/null || echo "No git history"
# Windows (PowerShell)
# git log --oneline -10 2>$null; if ($LASTEXITCODE -ne 0) { echo "No git history" }

Present Suggestions

From your analysis, present 3-4 specific suggestions:

## Task Suggestions
 
Based on scanning your codebase, here are some good starter tasks:
 
**1. [Most promising task]**
   Location: `src/path/to/file.ts:42`
   Scope: ~1-2 files, ~20-30 lines
   Why it's good: [brief reason]
 
**2. [Second task]**
   Location: `src/another/file.ts`
   Scope: ~1 file, ~15 lines
   Why it's good: [brief reason]
 
**3. [Third task]**
   Location: [location]
   Scope: [estimate]
   Why it's good: [brief reason]
 
**4. Something else?**
   Tell me what you'd like to work on.
 
Which task interests you? (Pick a number or describe your own)

If nothing found: Fall back to asking what the user wants to build:

I didn't find obvious quick wins in your codebase. What's something small you've been meaning to add or fix?

Scope Guardrail

If the user picks or describes something too large (major feature, multi-day work):

That's a valuable task, but it's probably larger than ideal for your first OpenSpec run-through.
 
For learning the workflow, smaller is better—it lets you see the full cycle without getting stuck in implementation details.
 
**Options:**
1. **Slice it smaller** - What's the smallest useful piece of [their task]? Maybe just [specific slice]?
2. **Pick something else** - One of the other suggestions, or a different small task?
3. **Do it anyway** - If you really want to tackle this, we can. Just know it'll take longer.
 
What would you prefer?

Let the user override if they insist—this is a soft guardrail.

Phase 3: Explore Demo

Once a task is selected, briefly demonstrate explore mode:

Before we create a change, let me quickly show you **explore mode**—it's how you think through problems before committing to a direction.

Spend 1-2 minutes investigating the relevant code:

• Read the file(s) involved
• Draw a quick ASCII diagram if it helps
• Note any considerations

## Quick Exploration
 
[Your brief analysis—what you found, any considerations]
 
┌─────────────────────────────────────────┐
│   [Optional: ASCII diagram if helpful]  │
└─────────────────────────────────────────┘
 
Explore mode (`/openspec-explore`) is for this kind of thinking—investigating before implementing. You can use it anytime you need to think through a problem.
 
Now let's create a change to hold our work.

PAUSE - Wait for user acknowledgment before proceeding.

Phase 4: Create the Change

EXPLAIN:

## Creating a Change
 
A "change" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives at the `changeRoot` reported by `openspec status --change "<name>" --json` and holds your artifacts—proposal, specs, design, tasks.
 
Let me create one for our task.

DO: Create the change with a derived kebab-case name:

openspec new change "<derived-name>"

SHOW:

Created: <changeRoot from status JSON>
 
The folder structure:

<changeRoot>/ ├── proposal.md ← Why we're doing this (empty, we'll fill it) ├── design.md ← How we'll build it (empty) ├── specs/ ← Detailed requirements (empty) └── tasks.md ← Implementation checklist (empty)

 
Now let's fill in the first artifact—the proposal.

Phase 5: Proposal

EXPLAIN:

## The Proposal
 
The proposal captures **why** we're making this change and **what** it involves at a high level. It's the "elevator pitch" for the work.
 
I'll draft one based on our task.

DO: Draft the proposal content (don't save yet):

<capability-path> is the spec directory relative to specs/ (for example, user-auth or identity/user-auth). Use the exact existing path for modified capabilities. For new capabilities, follow the project's established spec organization.

Here's a draft proposal:
 
---
 
# Proposal
 
## Why
 
[1-2 sentences explaining the problem/opportunity]
 
## What Changes
 
[Bullet points of what will be different]
 
## Capabilities
 
### New Capabilities
- `<capability-path>`: [brief description]
 
### Modified Capabilities
<!-- If modifying existing behavior -->
- `<existing-capability-path>`: [brief description]
 
## Impact
 
- `src/path/to/file.ts`: [what changes]
- [other files if applicable]
 
---
 
Does this capture the intent? I can adjust before we save it.

PAUSE - Wait for user approval/feedback.

After approval, save the proposal:

openspec instructions proposal --change "<name>" --json

Then write the content to the resolvedOutputPath from openspec instructions proposal --change "<name>" --json.

Proposal saved. This is your "why" document—you can always come back and refine it as understanding evolves.
 
Next up: specs.

Phase 6: Specs

EXPLAIN:

## Specs
 
Specs define **what** we're building in precise, testable terms. They use a requirement/scenario format that makes expected behavior crystal clear.
 
For a small task like this, we might only need one spec file.

DO: Resolve where the spec file should be created:

openspec instructions specs --change "<name>" --json
# Use resolvedOutputPath from the JSON. If it is a glob, choose the concrete file path using the schema instruction and the change's context.

Draft the spec content:

Here's the spec:
 
---
 
# Spec Delta
 
## ADDED Requirements
 
### Requirement: <Name>
 
<Description of what the system should do>
 
#### Scenario: <Scenario name>
 
- **WHEN** <trigger condition>
- **THEN** <expected outcome>
- **AND** <additional outcome if needed>
 
---
 
This format—WHEN/THEN/AND—makes requirements testable. You can literally read them as test cases.

Save to the concrete file path chosen from resolvedOutputPath.

Phase 7: Design

EXPLAIN:

## Design
 
The design captures **how** we'll build it—technical decisions, tradeoffs, approach.
 
For small changes, this might be brief. That's fine—not every change needs deep design discussion.

DO: Draft design.md:

Here's the design:
 
---
 
# Design
 
## Context
 
[Brief context about the current state]
 
## Goals / Non-Goals
 
**Goals:**
- [What we're trying to achieve]
 
**Non-Goals:**
- [What's explicitly out of scope]
 
## Decisions
 
### Decision 1: [Key decision]
 
[Explanation of approach and rationale]
 
---
 
For a small task, this captures the key decisions without over-engineering.

Save to the resolvedOutputPath from openspec instructions design --change "<name>" --json.

Phase 8: Tasks

EXPLAIN:

## Tasks
 
Finally, we break the work into implementation tasks—checkboxes that drive the apply phase.
 
These should be small, clear, and in logical order. Each group carries the tests and documentation for its own work - the last group is only for integration checks.

DO: Generate tasks based on specs and design:

Here are the implementation tasks:
 
---
 
# Tasks
 
## 1. [Category or file]