Guided onboarding - walk through a complete OpenSpec workflow cycle with narration. Use when a new user wants to learn the OpenSpec workflow by doing real work in their codebase.
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.
Before starting, check if OpenSpec is initialized:
openspec status --json 2>&1 || echo "NOT_INITIALIZED"
If not initialized:
OpenSpec isn't set up in this project yet. Run
openspec initfirst, then come back to/opsx-onboard.
Stop here if not initialized.
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
5. Generate task files (self-contained work items) from design and specs
6. Implement the tasks
7. Archive the completed change
**Note:** Implementation work is tracked in markdown task files under
`openspec/changes/<name>/tasks/open/` and `tasks/closed/`. Each task file is
self-contained — it embeds all context from design and specs so an agent can
implement it without flipping back to other artifacts.
**Time:** ~15-20 minutes
Let's start by finding something to work on.
Scan the codebase for small improvement opportunities. Look for:
TODO, FIXME, HACK, XXX in code filescatch blocks that swallow errors, risky operations without try-catchsrc/ with test directoriesany types in TypeScript files (: any, as any)console.log, console.debug, debugger statements in non-debug codeAlso check recent git activity:
git log --oneline -10 2>/dev/null || echo "No git history"
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?
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.
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:
## Quick Exploration
[Your brief analysis—what you found, any considerations]
┌─────────────────────────────────────────┐
│ [Optional: ASCII diagram if helpful] │
└─────────────────────────────────────────┘
Explore mode (`/opsx-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.
EXPLAIN:
## Creating a Change
A "change" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives in `openspec/changes/<name>/` 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: `openspec/changes/<name>/`
The folder structure:
openspec/changes/<name>/ ├── proposal.md ← Why we're doing this (empty, we'll fill it) ├── architecture.md← How to structure and test it (empty) ├── design.md ← How we'll build it (empty) ├── specs/ ← Detailed requirements (empty) └── tasks/ ← Open and closed task files (created later)
After creating these artifacts, we'll generate task files in `tasks/open/`
from the design and specs. Each task is a markdown file with frontmatter
(name, description, status, relations) and a self-contained body.
Now let's fill in the first artifact—the 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):
Here's a draft proposal:
---
## Why
[1-2 sentences explaining the problem/opportunity]
## What Changes
[Bullet points of what will be different]
## Capabilities
### New Capabilities
- `<capability-name>`: [brief description]
### Modified Capabilities
<!-- If modifying existing behavior -->
## 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 openspec/changes/<name>/proposal.md.
Proposal saved. This is your "why" document—you can always come back and refine it as understanding evolves.
Next up: 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: Create the spec file:
mkdir -p openspec/changes/<name>/specs/<capability-name>
Draft the spec content:
Here's the spec:
---
## 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 openspec/changes/<name>/specs/<capability>/spec.md.
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:
---
## 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 openspec/changes/<name>/design.md.
EXPLAIN:
## Generating Tasks
Instead of a checkbox list, we create self-contained task files—one markdown
file per work item, each embedding all the context needed to implement it.
Each task file has:
- Frontmatter: name, description, status, relations (blocked-by, discovered-from)
- The "why" (design rationale, extracted from design.md)
- The "what" (files to modify, specific implementation steps)
- The "done" (verification commands and acceptance criteria)
Files live in `openspec/changes/<name>/tasks/open/*.md` while active, then
move to `tasks/closed/` when complete. You can grep them, diff them, and
they travel with the change.
Let me generate tasks from our design and specs.
DO: Generate tasks using /opsx-tasks generate:
tasks/open/<name>.md files## Proposed Tasks
1. <name-1> — [description] [ready]
Scope: ~1-2 hours
Files: [specific paths]
2. <name-2> — [description] [blocked-by: <name-1>]
Scope: ~1 hour
Files: [specific paths]
Total: N tasks, ~M hours estimated
Ready to create these task files?
PAUSE - Wait for user approval.
After approval, create the files and show summary:
Created N task files in openspec/changes/<name>/tasks/open/:
- <name-1>.md — [description]
- <name-2>.md — [description]
All context embedded—each task is self-contained. Ready to implement?
PAUSE - Wait for user to confirm they're ready to implement.
EXPLAIN:
## Implementation
Now we implement each task. I'll work through them in order, showing how
each task file contains all the context needed—no need to flip back to
design.md.
After each one, I'll move the file from `tasks/open/` to `tasks/closed/`
and set its status to `done`.
DO: For each task:
git mv tasks/open/<name>.md tasks/closed/<name>.md and
set status: done in frontmatterKeep narration light—emphasize how the self-contained context helps.
After all tasks:
## Implementation Complete
All tasks closed:
- ✓ <name-1>: [description]
- ✓ <name-2>: [description]
- ✓ ...
The change is implemented! One more step—let's archive it.
EXPLAIN:
## Archiving
When a change is complete, we archive it. This moves it from `openspec/changes/` to `openspec/changes/archive/YYYY-MM-DD-<name>/`.
Archived changes become your project's decision history—you can always find them later to understand why something was built a certain way.
DO:
openspec archive "<name>"
SHOW:
Archived to: `openspec/changes/archive/YYYY-MM-DD-<name>/`
The change is now part of your project's history. The code is in your codebase, the decision record is preserved.
## Congratulations!
You just completed a full OpenSpec cycle:
1. **Explore** - Thought through the problem
2. **New** - Created a change container
3. **Proposal** - Captured WHY
4. **Specs** - Defined WHAT in detail
5. **Architecture** - Decided on structure + testing approach
6. **Design** - Decided HOW
7. **Generate Tasks** - Created self-contained task files from design
8. **Apply** - Implemented the tasks
9. **Archive** - Preserved the record
This same rhythm works for any size change—a small fix or a major feature.
Task files are your implementation tracking system—self-contained markdown
files under `tasks/open/` and `tasks/closed/`, generated from both design
(the "how") and specs (the "what") with all the context needed.
---
## Command Reference
| Command | What it does |
|---------|--------------|
| `/opsx-explore` | Think through problems before/during work |
| `/opsx-new` | Start a new change, step through artifacts |
| `/opsx-ff` | Fast-forward: create all artifacts at once |
| `/opsx-continue` | Continue working on an existing change |
| `/opsx-tasks` | Manage task files (list/show/create/update/generate) |
| `/opsx-apply` | Implement tasks from a change |
| `/opsx-verify` | Verify implementation matches artifacts |
| `/opsx-archive` | Archive a completed change |
---
## What's Next?
Try `/opsx-new` or `/opsx-ff` on something you actually want to build. You've got the rhythm now!
If the user says they need to stop, want to pause, or seem disengaged:
No problem! Your change is saved at `openspec/changes/<name>/`.
To pick up where we left off later:
- `/opsx-continue <name>` - Resume artifact creation
- `/opsx-tasks generate <name>` - Generate task files when design is ready
- `/opsx-apply <name>` - Jump to implementation (if tasks exist)
The work won't be lost. Come back whenever you're ready.
Exit gracefully without pressure.
If the user says they just want to see the commands or skip the tutorial:
## OpenSpec Quick Reference
| Command | What it does |
|---------|--------------|
| `/opsx-explore` | Think through problems (no code changes) |
| `/opsx-new <name>` | Start a new change, step by step |
| `/opsx-ff <name>` | Fast-forward: all artifacts at once |
| `/opsx-continue <name>` | Continue an existing change |
| `/opsx-tasks <subcmd> [name]` | Manage task files (list/show/create/update/generate) |
| `/opsx-apply <name>` | Implement tasks |
| `/opsx-verify <name>` | Verify implementation |
| `/opsx-archive <name>` | Archive when done |
Try `/opsx-new` to start your first change, or `/opsx-ff` if you want to move fast.
Exit gracefully.