@devtrack-solution/codesdd 1.2.2 → 1.2.4-rc3

package/dist/core/templates/workflows/explore.js

@@ -1,17 +1,17 @@
 export function getExploreSkillTemplate() {
     return {
-        name: 'openspec-explore',
+        name: 'codesdd-explore',
         description: 'Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.',
         instructions: `Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
 
-**OpenSDD-native guardrail**
+**CodeSDD-native guardrail**
 
-If this repository has a \`.sdd/\` directory, do not create or recreate \`openspec/changes\`.
-Capture durable decisions with \`opensdd sdd insight\`, \`opensdd sdd debate\`, and
-\`opensdd sdd decide\` instead of writing OpenSpec artifacts, unless the user explicitly
-asks for legacy OpenSpec compatibility artifacts.
+If this repository has a \`.sdd/\` directory, do not create or recreate \`legacy-spec/changes\`.
+Capture durable decisions with \`codesdd sdd insight\`, \`codesdd sdd debate\`, and
+\`codesdd sdd decide\` instead of writing CodeSDD artifacts, unless the user explicitly
+asks for legacy CodeSDD compatibility artifacts.
 
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create CodeSDD artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
 
 **This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
 
@@ -75,15 +75,15 @@ Depending on what the user brings, you might:
 
 ---
 
-## OpenSpec Awareness
+## CodeSDD Awareness
 
-You have full context of the OpenSpec system. Use it naturally, don't force it.
+You have full context of the CodeSDD system. Use it naturally, don't force it.
 
 ### Check for context
 
 At the start, quickly check what exists:
 \`\`\`bash
-openspec list --json
+codesdd list --json
 \`\`\`
 
 This tells you:
@@ -103,9 +103,9 @@ Think freely. When insights crystallize, you might offer:
 If the user mentions a change or you detect one is relevant:
 
 1. **Read existing artifacts for context**
-   - \`openspec/changes/<name>/proposal.md\`
-   - \`openspec/changes/<name>/design.md\`
-   - \`openspec/changes/<name>/tasks.md\`
+   - \`legacy-spec/changes/<name>/proposal.md\`
+   - \`legacy-spec/changes/<name>/design.md\`
+   - \`legacy-spec/changes/<name>/tasks.md\`
    - etc.
 
 2. **Reference them naturally in conversation**
@@ -278,7 +278,7 @@ But this summary is optional. Sometimes the thinking IS the value.
 
 ## Guardrails
 
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't implement** - Never write code or implement features. Creating CodeSDD artifacts is fine, writing application code is not.
 - **Don't fake understanding** - If something is unclear, dig deeper
 - **Don't rush** - Discovery is thinking time, not task time
 - **Don't force structure** - Let patterns emerge naturally
@@ -287,8 +287,8 @@ But this summary is optional. Sometimes the thinking IS the value.
 - **Do explore the codebase** - Ground discussions in reality
 - **Do question assumptions** - Including the user's and your own`,
         license: 'MIT',
-        compatibility: 'Requires opensdd CLI.',
-        metadata: { author: 'openspec', version: '1.0' },
+        compatibility: 'Requires codesdd CLI.',
+        metadata: { author: 'codesdd', version: '1.0' },
     };
 }
 export function getOpsxExploreCommandTemplate() {
@@ -299,14 +299,14 @@ export function getOpsxExploreCommandTemplate() {
         tags: ['workflow', 'explore', 'experimental', 'thinking'],
         content: `Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
 
-**OpenSDD-native guardrail**
+**CodeSDD-native guardrail**
 
-If this repository has a \`.sdd/\` directory, do not create or recreate \`openspec/changes\`.
-Capture durable decisions with \`opensdd sdd insight\`, \`opensdd sdd debate\`, and
-\`opensdd sdd decide\` instead of writing OpenSpec artifacts, unless the user explicitly
-asks for legacy OpenSpec compatibility artifacts.
+If this repository has a \`.sdd/\` directory, do not create or recreate \`legacy-spec/changes\`.
+Capture durable decisions with \`codesdd sdd insight\`, \`codesdd sdd debate\`, and
+\`codesdd sdd decide\` instead of writing CodeSDD artifacts, unless the user explicitly
+asks for legacy CodeSDD compatibility artifacts.
 
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create CodeSDD artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
 
 **This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
 
@@ -377,15 +377,15 @@ Depending on what the user brings, you might:
 
 ---
 
-## OpenSpec Awareness
+## CodeSDD Awareness
 
-You have full context of the OpenSpec system. Use it naturally, don't force it.
+You have full context of the CodeSDD system. Use it naturally, don't force it.
 
 ### Check for context
 
 At the start, quickly check what exists:
 \`\`\`bash
-openspec list --json
+codesdd list --json
 \`\`\`
 
 This tells you:
@@ -407,9 +407,9 @@ Think freely. When insights crystallize, you might offer:
 If the user mentions a change or you detect one is relevant:
 
 1. **Read existing artifacts for context**
-   - \`openspec/changes/<name>/proposal.md\`
-   - \`openspec/changes/<name>/design.md\`
-   - \`openspec/changes/<name>/tasks.md\`
+   - \`legacy-spec/changes/<name>/proposal.md\`
+   - \`legacy-spec/changes/<name>/design.md\`
+   - \`legacy-spec/changes/<name>/tasks.md\`
    - etc.
 
 2. **Reference them naturally in conversation**
@@ -462,7 +462,7 @@ When things crystallize, you might offer a summary - but it's optional. Sometime
 
 ## Guardrails
 
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't implement** - Never write code or implement features. Creating CodeSDD artifacts is fine, writing application code is not.
 - **Don't fake understanding** - If something is unclear, dig deeper
 - **Don't rush** - Discovery is thinking time, not task time
 - **Don't force structure** - Let patterns emerge naturally

package/dist/core/templates/workflows/feedback.js

@@ -1,8 +1,8 @@
 export function getFeedbackSkillTemplate() {
     return {
         name: 'feedback',
-        description: 'Collect and submit user feedback about OpenSpec with context enrichment and anonymization.',
-        instructions: `Help the user submit feedback about OpenSpec.
+        description: 'Collect and submit user feedback about CodeSDD with context enrichment and anonymization.',
+        instructions: `Help the user submit feedback about CodeSDD.
 
 **Goal**: Guide the user through collecting, enriching, and submitting feedback while ensuring privacy through anonymization.
 
@@ -37,8 +37,8 @@ export function getFeedbackSkillTemplate() {
    - Allow the user to request modifications
 
 5. **Submit on confirmation**
-   - Use the \`opensdd feedback\` command to submit
-   - Format: \`opensdd feedback "title" --body "body content"\`
+   - Use the \`codesdd feedback\` command to submit
+   - Format: \`codesdd feedback "title" --body "body content"\`
    - The command will automatically add metadata (version, platform, timestamp)
 
 **Example Draft**
@@ -101,8 +101,8 @@ Does this look good? I can modify it if you'd like, or submit it as-is.
 
 Only proceed with submission after user confirms.`,
         license: 'MIT',
-        compatibility: 'Requires opensdd CLI.',
-        metadata: { author: 'openspec', version: '1.0' },
+        compatibility: 'Requires codesdd CLI.',
+        metadata: { author: 'codesdd', version: '1.0' },
     };
 }
 //# sourceMappingURL=feedback.js.map

package/dist/core/templates/workflows/ff-change.js

@@ -1,16 +1,16 @@
 export function getFfChangeSkillTemplate() {
     return {
-        name: 'openspec-ff-change',
-        description: 'Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.',
+        name: 'codesdd-ff-change',
+        description: 'Fast-forward through CodeSDD artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.',
         instructions: `Fast-forward through artifact creation - generate everything needed to start implementation in one go.
 
-**OpenSDD-native guardrail**
+**CodeSDD-native guardrail**
 
-If this repository has a \`.sdd/\` directory, do not create or recreate \`openspec/changes\`.
-Use the OpenSDD lifecycle instead: \`opensdd sdd insight\`, \`opensdd sdd debate\`,
-\`opensdd sdd decide\`, \`opensdd sdd breakdown\`, and \`opensdd sdd start\`.
-Use this OPSX/OpenSpec fast-forward workflow only for explicitly legacy projects or
-when the user explicitly asks for legacy OpenSpec compatibility artifacts.
+If this repository has a \`.sdd/\` directory, do not create or recreate \`legacy-spec/changes\`.
+Use the CodeSDD lifecycle instead: \`codesdd sdd insight\`, \`codesdd sdd debate\`,
+\`codesdd sdd decide\`, \`codesdd sdd breakdown\`, and \`codesdd sdd start\`.
+Use this OPSX/CodeSDD fast-forward workflow only for explicitly legacy projects or
+when the user explicitly asks for legacy CodeSDD compatibility artifacts.
 
 **Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
 
@@ -27,13 +27,13 @@ when the user explicitly asks for legacy OpenSpec compatibility artifacts.
 
 2. **Create the change directory**
    \`\`\`bash
-   opensdd new change "<name>"
+   codesdd new change "<name>"
    \`\`\`
-   This creates a scaffolded change at \`openspec/changes/<name>/\`.
+   This creates a scaffolded change at \`legacy-spec/changes/<name>/\`.
 
 3. **Get the artifact build order**
    \`\`\`bash
-   opensdd status --change "<name>" --json
+   codesdd status --change "<name>" --json
    \`\`\`
    Parse the JSON to get:
    - \`applyRequires\`: array of artifact IDs needed before implementation (e.g., \`["tasks"]\`)
@@ -48,7 +48,7 @@ when the user explicitly asks for legacy OpenSpec compatibility artifacts.
    a. **For each artifact that is \`ready\` (dependencies satisfied)**:
       - Get instructions:
         \`\`\`bash
-        opensdd instructions <artifact-id> --change "<name>" --json
+        codesdd instructions <artifact-id> --change "<name>" --json
         \`\`\`
       - The instructions JSON includes:
         - \`context\`: Project background (constraints for you - do NOT include in output)
@@ -63,7 +63,7 @@ when the user explicitly asks for legacy OpenSpec compatibility artifacts.
       - Show brief progress: "✓ Created <artifact-id>"
 
    b. **Continue until all \`applyRequires\` artifacts are complete**
-      - After creating each artifact, re-run \`opensdd status --change "<name>" --json\`
+      - After creating each artifact, re-run \`codesdd status --change "<name>" --json\`
       - Check if every artifact ID in \`applyRequires\` has \`status: "done"\` in the artifacts array
       - Stop when all \`applyRequires\` artifacts are done
 
@@ -73,7 +73,7 @@ when the user explicitly asks for legacy OpenSpec compatibility artifacts.
 
 5. **Show final status**
    \`\`\`bash
-   opensdd status --change "<name>"
+   codesdd status --change "<name>"
    \`\`\`
 
 **Output**
@@ -86,7 +86,7 @@ After completing all artifacts, summarize:
 
 **Artifact Creation Guidelines**
 
-- Follow the \`instruction\` field from \`opensdd instructions\` for each artifact type
+- Follow the \`instruction\` field from \`codesdd 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 \`template\` as the structure for your output file - fill in its sections
@@ -101,8 +101,8 @@ After completing all artifacts, summarize:
 - If a change with that name already exists, suggest continuing that change instead
 - Verify each artifact file exists after writing before proceeding to next`,
         license: 'MIT',
-        compatibility: 'Requires opensdd CLI.',
-        metadata: { author: 'openspec', version: '1.0' },
+        compatibility: 'Requires codesdd CLI.',
+        metadata: { author: 'codesdd', version: '1.0' },
     };
 }
 export function getOpsxFfCommandTemplate() {
@@ -128,13 +128,13 @@ export function getOpsxFfCommandTemplate() {
 
 2. **Create the change directory**
    \`\`\`bash
-   opensdd new change "<name>"
+   codesdd new change "<name>"
    \`\`\`
-   This creates a scaffolded change at \`openspec/changes/<name>/\`.
+   This creates a scaffolded change at \`legacy-spec/changes/<name>/\`.
 
 3. **Get the artifact build order**
    \`\`\`bash
-   opensdd status --change "<name>" --json
+   codesdd status --change "<name>" --json
    \`\`\`
    Parse the JSON to get:
    - \`applyRequires\`: array of artifact IDs needed before implementation (e.g., \`["tasks"]\`)
@@ -149,7 +149,7 @@ export function getOpsxFfCommandTemplate() {
    a. **For each artifact that is \`ready\` (dependencies satisfied)**:
       - Get instructions:
         \`\`\`bash
-        opensdd instructions <artifact-id> --change "<name>" --json
+        codesdd instructions <artifact-id> --change "<name>" --json
         \`\`\`
       - The instructions JSON includes:
         - \`context\`: Project background (constraints for you - do NOT include in output)
@@ -164,7 +164,7 @@ export function getOpsxFfCommandTemplate() {
       - Show brief progress: "✓ Created <artifact-id>"
 
    b. **Continue until all \`applyRequires\` artifacts are complete**
-      - After creating each artifact, re-run \`opensdd status --change "<name>" --json\`
+      - After creating each artifact, re-run \`codesdd status --change "<name>" --json\`
       - Check if every artifact ID in \`applyRequires\` has \`status: "done"\` in the artifacts array
       - Stop when all \`applyRequires\` artifacts are done
 
@@ -174,7 +174,7 @@ export function getOpsxFfCommandTemplate() {
 
 5. **Show final status**
    \`\`\`bash
-   opensdd status --change "<name>"
+   codesdd status --change "<name>"
    \`\`\`
 
 **Output**
@@ -187,7 +187,7 @@ After completing all artifacts, summarize:
 
 **Artifact Creation Guidelines**
 
-- Follow the \`instruction\` field from \`opensdd instructions\` for each artifact type
+- Follow the \`instruction\` field from \`codesdd 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 \`template\` as the structure for your output file - fill in its sections

package/dist/core/templates/workflows/new-change.js

@@ -1,16 +1,16 @@
 export function getNewChangeSkillTemplate() {
     return {
-        name: 'openspec-new-change',
-        description: 'Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.',
+        name: 'codesdd-new-change',
+        description: 'Start a new CodeSDD change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.',
         instructions: `Start a new change using the experimental artifact-driven approach.
 
-**OpenSDD-native guardrail**
+**CodeSDD-native guardrail**
 
-If this repository has a \`.sdd/\` directory, do not create or recreate \`openspec/changes\`.
-Use the OpenSDD lifecycle instead: \`opensdd sdd insight\`, \`opensdd sdd debate\`,
-\`opensdd sdd decide\`, \`opensdd sdd breakdown\`, and \`opensdd sdd start\`.
-Use this OPSX/OpenSpec change workflow only for explicitly legacy projects or when
-the user explicitly asks for legacy OpenSpec compatibility artifacts.
+If this repository has a \`.sdd/\` directory, do not create or recreate \`legacy-spec/changes\`.
+Use the CodeSDD lifecycle instead: \`codesdd sdd insight\`, \`codesdd sdd debate\`,
+\`codesdd sdd decide\`, \`codesdd sdd breakdown\`, and \`codesdd sdd start\`.
+Use this OPSX/CodeSDD change workflow only for explicitly legacy projects or when
+the user explicitly asks for legacy CodeSDD compatibility artifacts.
 
 **Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
 
@@ -31,20 +31,20 @@ the user explicitly asks for legacy OpenSpec compatibility artifacts.
 
    **Use a different schema only if the user mentions:**
    - A specific schema name → use \`--schema <name>\`
-   - "show workflows" or "what workflows" → run \`opensdd schemas --json\` and let them choose
+   - "show workflows" or "what workflows" → run \`codesdd schemas --json\` and let them choose
 
    **Otherwise**: Omit \`--schema\` to use the default.
 
 3. **Create the change directory**
    \`\`\`bash
-   opensdd new change "<name>"
+   codesdd new change "<name>"
    \`\`\`
    Add \`--schema <name>\` only if the user requested a specific workflow.
-   This creates a scaffolded change at \`openspec/changes/<name>/\` with the selected schema.
+   This creates a scaffolded change at \`legacy-spec/changes/<name>/\` with the selected schema.
 
 4. **Show the artifact status**
    \`\`\`bash
-   opensdd status --change "<name>"
+   codesdd status --change "<name>"
    \`\`\`
    This shows which artifacts need to be created and which are ready (dependencies satisfied).
 
@@ -52,7 +52,7 @@ the user explicitly asks for legacy OpenSpec compatibility artifacts.
    The first artifact depends on the schema (e.g., \`proposal\` for spec-driven).
    Check the status output to find the first artifact with status "ready".
    \`\`\`bash
-   opensdd instructions <first-artifact-id> --change "<name>"
+   codesdd instructions <first-artifact-id> --change "<name>"
    \`\`\`
    This outputs the template and context for creating the first artifact.
 
@@ -74,8 +74,8 @@ After completing the steps, summarize:
 - If a change with that name already exists, suggest continuing that change instead
 - Pass --schema if using a non-default workflow`,
         license: 'MIT',
-        compatibility: 'Requires opensdd CLI.',
-        metadata: { author: 'openspec', version: '1.0' },
+        compatibility: 'Requires codesdd CLI.',
+        metadata: { author: 'codesdd', version: '1.0' },
     };
 }
 export function getOpsxNewCommandTemplate() {
@@ -105,27 +105,27 @@ export function getOpsxNewCommandTemplate() {
 
    **Use a different schema only if the user mentions:**
    - A specific schema name → use \`--schema <name>\`
-   - "show workflows" or "what workflows" → run \`opensdd schemas --json\` and let them choose
+   - "show workflows" or "what workflows" → run \`codesdd schemas --json\` and let them choose
 
    **Otherwise**: Omit \`--schema\` to use the default.
 
 3. **Create the change directory**
    \`\`\`bash
-   opensdd new change "<name>"
+   codesdd new change "<name>"
    \`\`\`
    Add \`--schema <name>\` only if the user requested a specific workflow.
-   This creates a scaffolded change at \`openspec/changes/<name>/\` with the selected schema.
+   This creates a scaffolded change at \`legacy-spec/changes/<name>/\` with the selected schema.
 
 4. **Show the artifact status**
    \`\`\`bash
-   opensdd status --change "<name>"
+   codesdd status --change "<name>"
    \`\`\`
    This shows which artifacts need to be created and which are ready (dependencies satisfied).
 
 5. **Get instructions for the first artifact**
    The first artifact depends on the schema. Check the status output to find the first artifact with status "ready".
    \`\`\`bash
-   opensdd instructions <first-artifact-id> --change "<name>"
+   codesdd instructions <first-artifact-id> --change "<name>"
    \`\`\`
    This outputs the template and context for creating the first artifact.
 

package/dist/core/templates/workflows/onboard.js

@@ -1,29 +1,29 @@
 export function getOnboardSkillTemplate() {
     return {
-        name: 'openspec-onboard',
-        description: 'Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.',
+        name: 'codesdd-onboard',
+        description: 'Guided onboarding for CodeSDD - walk through a complete workflow cycle with narration and real codebase work.',
         instructions: getOnboardInstructions(),
         license: 'MIT',
-        compatibility: 'Requires opensdd CLI.',
-        metadata: { author: 'openspec', version: '1.0' },
+        compatibility: 'Requires codesdd CLI.',
+        metadata: { author: 'codesdd', version: '1.0' },
     };
 }
 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.
+    return `Guide the user through their first complete CodeSDD workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.
 
-**OpenSDD-native guardrail**
+**CodeSDD-native guardrail**
 
-If this repository has a \`.sdd/\` directory, do not create or recreate \`openspec/changes\`.
-Use \`opensdd sdd onboard system\`, \`opensdd sdd insight\`, \`opensdd sdd debate\`,
-\`opensdd sdd decide\`, \`opensdd sdd breakdown\`, \`opensdd sdd start\`, and
-\`opensdd sdd finalize\` for the canonical lifecycle.
-Use this OpenSpec onboarding flow only for explicitly legacy compatibility projects.
+If this repository has a \`.sdd/\` directory, do not create or recreate \`legacy-spec/changes\`.
+Use \`codesdd sdd onboard system\`, \`codesdd sdd insight\`, \`codesdd sdd debate\`,
+\`codesdd sdd decide\`, \`codesdd sdd breakdown\`, \`codesdd sdd start\`, and
+\`codesdd sdd finalize\` for the canonical lifecycle.
+Use this CodeSDD onboarding flow only for explicitly legacy compatibility projects.
 
 ---
 
 ## Preflight
 
-Before starting, check if the OpenSpec CLI is installed:
+Before starting, check if the CodeSDD CLI is installed:
 
 \`\`\`bash
 # Unix/macOS
@@ -33,7 +33,7 @@ codesdd --version 2>&1 || echo "CLI_NOT_INSTALLED"
 \`\`\`
 
 **If CLI not installed:**
-> OpenSpec CLI is not installed. Install it first, then come back to \`/opsx:onboard\`.
+> CodeSDD CLI is not installed. Install it first, then come back to \`/opsx:onboard\`.
 
 Stop here if not installed.
 
@@ -44,7 +44,7 @@ Stop here if not installed.
 Display:
 
 \`\`\`
-## Welcome to OpenSpec!
+## Welcome to CodeSDD!
 
 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.
 
@@ -122,7 +122,7 @@ Which task interests you? (Pick a number or describe your own)
 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.
+That's a valuable task, but it's probably larger than ideal for your first CodeSDD run-through.
 
 For learning the workflow, smaller is better—it lets you see the full cycle without getting stuck in implementation details.
 
@@ -175,23 +175,23 @@ Now let's create a change to hold our work.
 \`\`\`
 ## 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.
+A "change" in CodeSDD is a container for all the thinking and planning around a piece of work. It lives in \`legacy-spec/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
-opensdd new change "<derived-name>"
+codesdd new change "<derived-name>"
 \`\`\`
 
 **SHOW:**
 \`\`\`
-Created: \`openspec/changes/<name>/\`
+Created: \`legacy-spec/changes/<name>/\`
 
 The folder structure:
 \`\`\`
-openspec/changes/<name>/
+legacy-spec/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)
@@ -251,9 +251,9 @@ Does this capture the intent? I can adjust before we save it.
 
 After approval, save the proposal:
 \`\`\`bash
-opensdd instructions proposal --change "<name>" --json
+codesdd instructions proposal --change "<name>" --json
 \`\`\`
-Then write the content to \`openspec/changes/<name>/proposal.md\`.
+Then write the content to \`legacy-spec/changes/<name>/proposal.md\`.
 
 \`\`\`
 Proposal saved. This is your "why" document—you can always come back and refine it as understanding evolves.
@@ -277,9 +277,9 @@ For a small task like this, we might only need one spec file.
 **DO:** Create the spec file:
 \`\`\`bash
 # Unix/macOS
-mkdir -p openspec/changes/<name>/specs/<capability-name>
+mkdir -p legacy-spec/changes/<name>/specs/<capability-name>
 # Windows (PowerShell)
-# New-Item -ItemType Directory -Force -Path "openspec/changes/<name>/specs/<capability-name>"
+# New-Item -ItemType Directory -Force -Path "legacy-spec/changes/<name>/specs/<capability-name>"
 \`\`\`
 
 Draft the spec content:
@@ -306,7 +306,7 @@ Here's the spec:
 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\`.
+Save to \`legacy-spec/changes/<name>/specs/<capability>/spec.md\`.
 
 ---
 
@@ -351,7 +351,7 @@ Here's the design:
 For a small task, this captures the key decisions without over-engineering.
 \`\`\`
 
-Save to \`openspec/changes/<name>/design.md\`.
+Save to \`legacy-spec/changes/<name>/design.md\`.
 
 ---
 
@@ -389,7 +389,7 @@ 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\`.
+Save to \`legacy-spec/changes/<name>/tasks.md\`.
 
 ---
 
@@ -433,19 +433,19 @@ The change is implemented! One more step—let's archive it.
 \`\`\`
 ## Archiving
 
-When a change is complete, we archive it. This moves it from \`openspec/changes/\` to \`openspec/changes/archive/YYYY-MM-DD-<name>/\`.
+When a change is complete, we archive it. This moves it from \`legacy-spec/changes/\` to \`legacy-spec/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:**
 \`\`\`bash
-openspec archive "<name>"
+codesdd archive "<name>"
 \`\`\`
 
 **SHOW:**
 \`\`\`
-Archived to: \`openspec/changes/archive/YYYY-MM-DD-<name>/\`
+Archived to: \`legacy-spec/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.
 \`\`\`
@@ -457,7 +457,7 @@ The change is now part of your project's history. The code is in your codebase,
 \`\`\`
 ## Congratulations!
 
-You just completed a full OpenSpec cycle:
+You just completed a full CodeSDD cycle:
 
 1. **Explore** - Thought through the problem
 2. **New** - Created a change container
@@ -508,7 +508,7 @@ Try \`/opsx:propose\` on something you actually want to build. You've got the rh
 If the user says they need to stop, want to pause, or seem disengaged:
 
 \`\`\`
-No problem! Your change is saved at \`openspec/changes/<name>/\`.
+No problem! Your change is saved at \`legacy-spec/changes/<name>/\`.
 
 To pick up where we left off later:
 - \`/opsx:continue <name>\` - Resume artifact creation
@@ -524,7 +524,7 @@ Exit gracefully without pressure.
 If the user says they just want to see the commands or skip the tutorial:
 
 \`\`\`
-## OpenSpec Quick Reference
+## CodeSDD Quick Reference
 
 **Core workflow:**
 
@@ -564,7 +564,7 @@ Exit gracefully.
 export function getOpsxOnboardCommandTemplate() {
     return {
         name: 'OPSX: Onboard',
-        description: 'Guided onboarding - walk through a complete OpenSpec workflow cycle with narration',
+        description: 'Guided onboarding - walk through a complete CodeSDD workflow cycle with narration',
         category: 'Workflow',
         tags: ['workflow', 'onboarding', 'tutorial', 'learning'],
         content: getOnboardInstructions(),