Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.

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 running its slash command. 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 ran its slash command. 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: 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: 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: Present Suggestions From your analysis, present 3 4 specific suggestions: 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): 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: Spend 1 2 minutes investigating the relevant code: Read the file(s) involved Draw a quick ASCII diagram if it helps Note any considerations PAUSE Wait for user acknowledgment before proceeding. Phase 4: Create the Change EXPLAIN: DO: Create the change with a derived kebab case name: SHOW: <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) Phase 5: Proposal EXPLAIN: 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. PAUSE Wait for user approval/feedback. After approval, save the proposal: Then write the content to the resolvedOutputPath from openspec instructions proposal change "<name " json . Phase 6: Specs EXPLAIN: DO: Resolve where the spec file should be created: Draft the spec content: Save to the concrete file path chosen from resolvedOutputPath . Phase 7: Design EXPLAIN: DO: Draft design.md: Save to the resolvedOutputPath from openspec instructions design change "<name " json . Phase 8: Tasks EXPLAIN: DO: Generate tasks based on specs and design: PAUSE Wait for user approval/feedback. After approval, save to the resolvedOutputPath from openspec instructions tasks change "<name " json . Then ask: "Tasks are saved. Ready to implement?" PAUSE Wait for user to confirm before implementation. Phase 9: Apply (Implementation) EXPLAIN: DO: For each task: 1. Announce: "Working on task N: [description]" 2. Implement the change in the codebase 3. Reference specs/design naturally: "The spec says X, so I'm doing Y" 4. Mark complete in tasks.md: [ ] → [x] 5. Brief status: "✓ Task N complete" Keep narration light—don't over explain every line of code. After all tasks: Phase 10: Archive EXPLAIN: DO: Archive the change ( yes answers the confirmation prompts, which you cannot answer from a tool call): SHOW: Phase 11: Recap & Next Steps Graceful Exit Handling User wants to stop mid way If the user says they need to stop, want to pause, or seem disengaged: Exit gracefully without pressure. User just wants command reference If the user says they just want to see the commands or skip the tutorial: Exit gracefully. Guardrails Follow the EXPLAIN → DO → SHOW → PAUSE pattern at key transitions (after explore, after proposal draft, after tasks, after archive) Keep narration light during implementation—teach without lecturing Don't skip phases even if the change is small—the goal is teaching the workflow Pause for acknowledgment at marked points, but don't over pause Handle exits gracefully —never pressure the user to continue Use real codebase tasks —don't simulate or use fake examples Adjust scope gently —guide toward smaller tasks but respect user choice

openspec-onboard