@fission-ai/openspec 0.23.0 → 1.0.0

package/dist/core/templates/skill-templates.js

@@ -293,7 +293,10 @@ But this summary is optional. Sometimes the thinking IS the value.
 - **Don't auto-capture** - Offer to save insights, don't just do it
 - **Do visualize** - A good diagram is worth many paragraphs
 - **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own`
+- **Do question assumptions** - Including the user's and your own`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
     };
 }
 /**
@@ -367,7 +370,10 @@ After completing the steps, summarize:
 - Do NOT advance beyond showing the first artifact template
 - If the name is invalid (not kebab-case), ask for a valid name
 - If a change with that name already exists, suggest continuing that change instead
-- Pass --schema if using a non-default workflow`
+- Pass --schema if using a non-default workflow`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
     };
 }
 /**
@@ -425,10 +431,17 @@ export function getContinueChangeSkillTemplate() {
      \`\`\`bash
      openspec instructions <artifact-id> --change "<name>" --json
      \`\`\`
-   - Parse the JSON to get template, dependencies, and what it unlocks
-   - **Create the artifact file** using the template as a starting point:
+   - Parse the JSON. The key fields are:
+     - \`context\`: Project background (constraints for you - do NOT include in output)
+     - \`rules\`: Artifact-specific rules (constraints for you - do NOT include in output)
+     - \`template\`: The structure to use for your output file
+     - \`instruction\`: Schema-specific guidance
+     - \`outputPath\`: Where to write the artifact
+     - \`dependencies\`: Completed artifacts to read for context
+   - **Create the artifact file**:
      - Read any completed dependency files for context
-     - Fill in the template based on context and user's goals
+     - Use \`template\` as the structure - fill in its sections
+     - Apply \`context\` and \`rules\` as constraints when writing - but do NOT copy them into the file
      - Write to the output path specified in instructions
    - Show what was created and what's now unlocked
    - STOP after creating ONE artifact
@@ -480,7 +493,13 @@ For other schemas, follow the \`instruction\` field from the CLI output.
 - Never skip artifacts or create out of order
 - If context is unclear, ask the user before creating
 - Verify the artifact file exists after writing before marking progress
-- Use the schema's artifact sequence, don't assume specific artifact names`
+- Use the schema's artifact sequence, don't assume specific artifact names
+- **IMPORTANT**: \`context\` and \`rules\` are constraints for YOU, not content for the file
+  - Do NOT copy \`<context>\`, \`<rules>\`, \`<project_context>\` blocks into the artifact
+  - These guide what you write, but should never appear in the output`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
     };
 }
 /**
@@ -636,7 +655,10 @@ What would you like to do?
 This skill supports the "actions on a change" model:
 
 - **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly`
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
     };
 }
 /**
@@ -688,12 +710,15 @@ export function getFfChangeSkillTemplate() {
         openspec instructions <artifact-id> --change "<name>" --json
         \`\`\`
       - The instructions JSON includes:
-        - \`template\`: The template content to use
+        - \`context\`: Project background (constraints for you - do NOT include in output)
+        - \`rules\`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - \`template\`: The structure to use for your output file
         - \`instruction\`: Schema-specific guidance for this artifact type
         - \`outputPath\`: Where to write the artifact
         - \`dependencies\`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file following the schema's \`instruction\`
+      - Create the artifact file using \`template\` as the structure
+      - Apply \`context\` and \`rules\` as constraints - but do NOT copy them into the file
       - Show brief progress: "✓ Created <artifact-id>"
 
    b. **Continue until all \`applyRequires\` artifacts are complete**
@@ -723,14 +748,20 @@ After completing all artifacts, summarize:
 - Follow the \`instruction\` field from \`openspec instructions\` for each artifact type
 - The schema defines what each artifact should contain - follow it
 - Read dependency artifacts for context before creating new ones
-- Use the \`template\` as a starting point, filling in based on context
+- Use \`template\` as the structure for your output file - fill in its sections
+- **IMPORTANT**: \`context\` and \`rules\` are constraints for YOU, not content for the file
+  - Do NOT copy \`<context>\`, \`<rules>\`, \`<project_context>\` blocks into the artifact
+  - These guide what you write, but should never appear in the output
 
 **Guardrails**
 - Create ALL artifacts needed for implementation (as defined by schema's \`apply.requires\`)
 - Always read dependency artifacts before creating a new one
 - If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
 - If a change with that name already exists, suggest continuing that change instead
-- Verify each artifact file exists after writing before proceeding to next`
+- Verify each artifact file exists after writing before proceeding to next`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
     };
 }
 /**
@@ -867,9 +898,549 @@ Main specs are now updated. The change remains active - archive when implementat
 - Preserve existing content not mentioned in delta
 - If something is unclear, ask for clarification
 - Show what you're changing as you go
-- The operation should be idempotent - running twice should give same result`
+- The operation should be idempotent - running twice should give same result`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
     };
 }
+/**
+ * Template for openspec-onboard skill
+ * Guided onboarding through the complete OpenSpec workflow
+ */
+export function getOnboardSkillTemplate() {
+    return {
+        name: 'openspec-onboard',
+        description: 'Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.',
+        instructions: getOnboardInstructions(),
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+/**
+ * Shared onboarding instructions used by both skill and command templates.
+ */
+function getOnboardInstructions() {
+    return `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.
+
+---
+
+## Preflight
+
+Before starting, check if OpenSpec is initialized:
+
+\`\`\`bash
+openspec status --json 2>&1 || echo "NOT_INITIALIZED"
+\`\`\`
+
+**If not initialized:**
+> OpenSpec isn't set up in this project yet. Run \`openspec init\` first, then come back to \`/opsx:onboard\`.
+
+Stop here if not initialized.
+
+---
+
+## 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:
+\`\`\`bash
+git log --oneline -10 2>/dev/null || 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 (\`/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.
+
+---
+
+## 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 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:
+\`\`\`bash
+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)
+├── 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):
+
+\`\`\`
+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:
+\`\`\`bash
+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.
+\`\`\`
+
+---
+
+## 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:** Create the spec file:
+\`\`\`bash
+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\`.
+
+---
+
+## 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:
+
+---
+
+## 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\`.
+
+---
+
+## 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.
+\`\`\`
+
+**DO:** Generate tasks based on specs and design:
+
+\`\`\`
+Here are the implementation tasks:
+
+---
+
+## 1. [Category or file]
+
+- [ ] 1.1 [Specific task]
+- [ ] 1.2 [Specific task]
+
+## 2. Verify
+
+- [ ] 2.1 [Verification step]
+
+---
+
+Each checkbox becomes a unit of work in the apply phase. Ready to implement?
+\`\`\`
+
+**PAUSE** - Wait for user to confirm they're ready to implement.
+
+Save to \`openspec/changes/<name>/tasks.md\`.
+
+---
+
+## Phase 9: Apply (Implementation)
+
+**EXPLAIN:**
+\`\`\`
+## Implementation
+
+Now we implement each task, checking them off as we go. I'll announce each one and occasionally note how the specs/design informed the approach.
+\`\`\`
+
+**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:
+
+\`\`\`
+## Implementation Complete
+
+All tasks done:
+- [x] Task 1
+- [x] Task 2
+- [x] ...
+
+The change is implemented! One more step—let's archive it.
+\`\`\`
+
+---
+
+## Phase 10: Archive
+
+**EXPLAIN:**
+\`\`\`
+## Archiving
+
+When a change is complete, we archive it. This moves it from \`openspec/changes/\` to \`openspec/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:**
+\`\`\`bash
+openspec archive "<name>"
+\`\`\`
+
+**SHOW:**
+\`\`\`
+Archived to: \`openspec/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.
+\`\`\`
+
+---
+
+## Phase 11: Recap & Next Steps
+
+\`\`\`
+## 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. **Design** - Decided HOW
+6. **Tasks** - Broke it into steps
+7. **Apply** - Implemented the work
+8. **Archive** - Preserved the record
+
+This same rhythm works for any size change—a small fix or a major feature.
+
+---
+
+## 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: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!
+\`\`\`
+
+---
+
+## Graceful Exit Handling
+
+### User wants to stop mid-way
+
+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:apply <name>\` - Jump to implementation (if tasks exist)
+
+The work won't be lost. Come back whenever you're ready.
+\`\`\`
+
+Exit gracefully without pressure.
+
+### User just wants command reference
+
+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: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.
+
+---
+
+## 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`;
+}
 /**
  * Template for /opsx:explore slash command
  * Explore mode - adaptive thinking partner
@@ -1179,10 +1750,17 @@ export function getOpsxContinueCommandTemplate() {
      \`\`\`bash
      openspec instructions <artifact-id> --change "<name>" --json
      \`\`\`
-   - Parse the JSON to get template, dependencies, and what it unlocks
-   - **Create the artifact file** using the template as a starting point:
+   - Parse the JSON. The key fields are:
+     - \`context\`: Project background (constraints for you - do NOT include in output)
+     - \`rules\`: Artifact-specific rules (constraints for you - do NOT include in output)
+     - \`template\`: The structure to use for your output file
+     - \`instruction\`: Schema-specific guidance
+     - \`outputPath\`: Where to write the artifact
+     - \`dependencies\`: Completed artifacts to read for context
+   - **Create the artifact file**:
      - Read any completed dependency files for context
-     - Fill in the template based on context and user's goals
+     - Use \`template\` as the structure - fill in its sections
+     - Apply \`context\` and \`rules\` as constraints when writing - but do NOT copy them into the file
      - Write to the output path specified in instructions
    - Show what was created and what's now unlocked
    - STOP after creating ONE artifact
@@ -1234,7 +1812,10 @@ For other schemas, follow the \`instruction\` field from the CLI output.
 - Never skip artifacts or create out of order
 - If context is unclear, ask the user before creating
 - Verify the artifact file exists after writing before marking progress
-- Use the schema's artifact sequence, don't assume specific artifact names`
+- Use the schema's artifact sequence, don't assume specific artifact names
+- **IMPORTANT**: \`context\` and \`rules\` are constraints for YOU, not content for the file
+  - Do NOT copy \`<context>\`, \`<rules>\`, \`<project_context>\` blocks into the artifact
+  - These guide what you write, but should never appear in the output`
     };
 }
 /**
@@ -1444,12 +2025,15 @@ export function getOpsxFfCommandTemplate() {
         openspec instructions <artifact-id> --change "<name>" --json
         \`\`\`
       - The instructions JSON includes:
-        - \`template\`: The template content to use
+        - \`context\`: Project background (constraints for you - do NOT include in output)
+        - \`rules\`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - \`template\`: The structure to use for your output file
         - \`instruction\`: Schema-specific guidance for this artifact type
         - \`outputPath\`: Where to write the artifact
         - \`dependencies\`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file following the schema's \`instruction\`
+      - Create the artifact file using \`template\` as the structure
+      - Apply \`context\` and \`rules\` as constraints - but do NOT copy them into the file
       - Show brief progress: "✓ Created <artifact-id>"
 
    b. **Continue until all \`applyRequires\` artifacts are complete**
@@ -1599,7 +2183,10 @@ All artifacts complete. All tasks complete.
 - Preserve .openspec.yaml when moving to archive (it moves with the directory)
 - Show clear summary of what happened
 - If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting`
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
     };
 }
 /**
@@ -1844,7 +2431,10 @@ No active changes found. Use \`/opsx:new\` to create a new change.
 - Track and report all outcomes (success/skip/fail)
 - Preserve .openspec.yaml when moving to archive
 - Archive directory target uses current date: YYYY-MM-DD-<name>
-- If archive target exists, fail that change but continue with others`
+- If archive target exists, fail that change but continue with others`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
     };
 }
 /**
@@ -2149,7 +2739,10 @@ Use clear markdown with:
 - Grouped lists for issues (CRITICAL/WARNING/SUGGESTION)
 - Code references in format: \`file.ts:123\`
 - Specific, actionable recommendations
-- No vague suggestions like "consider reviewing"`
+- No vague suggestions like "consider reviewing"`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
     };
 }
 /**
@@ -2313,6 +2906,19 @@ Target archive directory already exists.
 - If delta specs exist, always run the sync assessment and show the combined summary before prompting`
     };
 }
+/**
+ * Template for /opsx:onboard slash command
+ * Guided onboarding through the complete OpenSpec workflow
+ */
+export function getOpsxOnboardCommandTemplate() {
+    return {
+        name: 'OPSX: Onboard',
+        description: 'Guided onboarding - walk through a complete OpenSpec workflow cycle with narration',
+        category: 'Workflow',
+        tags: ['workflow', 'onboarding', 'tutorial', 'learning'],
+        content: getOnboardInstructions(),
+    };
+}
 /**
  * Template for /opsx:bulk-archive slash command
  */