@devtrack-solution/codesdd 1.2.2 → 1.2.3

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(),

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

@@ -1,16 +1,16 @@
 export function getOpsxProposeSkillTemplate() {
     return {
-        name: 'openspec-propose',
+        name: 'codesdd-propose',
         description: 'Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.',
         instructions: `Propose a new change - create the change and generate all artifacts in one step.
 
-**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 the OPSX/OpenSpec change flow below 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 the OPSX/CodeSDD change flow below only for explicitly legacy projects or when
+the user explicitly asks for legacy CodeSDD compatibility artifacts.
 
 I'll create a change with artifacts:
 - proposal.md (what & why)
@@ -36,13 +36,13 @@ When ready to implement, run /opsx:apply
 
 2. **Create the change directory**
    \`\`\`bash
-   opensdd new change "<name>"
+   codesdd new change "<name>"
    \`\`\`
-   This creates a scaffolded change at \`openspec/changes/<name>/\` with \`.openspec.yaml\`.
+   This creates a scaffolded change at \`legacy-spec/changes/<name>/\` with \`.sdd.yaml\`.
 
 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"]\`)
@@ -57,7 +57,7 @@ When ready to implement, run /opsx:apply
    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)
@@ -72,7 +72,7 @@ When ready to implement, run /opsx:apply
       - 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
 
@@ -82,7 +82,7 @@ When ready to implement, run /opsx:apply
 
 5. **Show final status**
    \`\`\`bash
-   opensdd status --change "<name>"
+   codesdd status --change "<name>"
    \`\`\`
 
 **Output**
@@ -95,7 +95,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
@@ -110,8 +110,8 @@ After completing all artifacts, summarize:
 - If a change with that name already exists, ask if user wants to continue it or create a new one
 - 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 getOpsxProposeCommandTemplate() {
@@ -146,13 +146,13 @@ When ready to implement, run /opsx:apply
 
 2. **Create the change directory**
    \`\`\`bash
-   opensdd new change "<name>"
+   codesdd new change "<name>"
    \`\`\`
-   This creates a scaffolded change at \`openspec/changes/<name>/\` with \`.openspec.yaml\`.
+   This creates a scaffolded change at \`legacy-spec/changes/<name>/\` with \`.sdd.yaml\`.
 
 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"]\`)
@@ -167,7 +167,7 @@ When ready to implement, run /opsx:apply
    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)
@@ -182,7 +182,7 @@ When ready to implement, run /opsx:apply
       - 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
 
@@ -192,7 +192,7 @@ When ready to implement, run /opsx:apply
 
 5. **Show final status**
    \`\`\`bash
-   opensdd status --change "<name>"
+   codesdd status --change "<name>"
    \`\`\`
 
 **Output**
@@ -205,7 +205,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/sdd.js

@@ -1,6 +1,6 @@
 export function getSddSkillTemplate() {
     return {
-        name: 'openspec-sdd',
+        name: 'codesdd-sdd',
         description: 'Atue como Arquiteto Principal para manter o Software Design Document (SDD) continuo.',
         instructions: `Voce e o Arquiteto Principal de Software responsavel por manter o Software Design Document (SDD) continuo do sistema.
 Seu foco principal e design de alto nivel, arquitetura, estrutura do projeto e consistencia documental, e NAO escrever codigo de aplicacao.
@@ -28,22 +28,22 @@ Voce pode ler arquivos, escrever Markdown e organizar estruturas de diretorios.
 - Escrever novas especificacoes quando solicitado.
 - Se o usuario pedir implementacao direta de codigo, orientar primeiro o planejamento e a documentacao da mudanca.
 
-## Consciencia OpenSDD
+## Consciencia CodeSDD
 
-Voce tem contexto do sistema OpenSDD. O estado operacional canonico vive em
+Voce tem contexto do sistema CodeSDD. O estado operacional canonico vive em
 \`.sdd/state/*.yaml\`; arquivos Markdown sao visoes, guias ou documentacao
-curada. Material OpenSpec importado em \`.sdd/sources/legacy/spec-corpus\` e
+curada. Material Legacy spec importado em \`.sdd/sources/legacy/spec-corpus\` e
 somente contexto legado, nao fonte operacional de verdade.
 
 ### Checagem de contexto
 
-No inicio, consulte \`opensdd sdd next\`, \`opensdd sdd check --render\` e leia
+No inicio, consulte \`codesdd sdd next\`, \`codesdd sdd check --render\` e leia
 \`README.md\`, \`.sdd/core/\`, \`.sdd/state/*.yaml\` e artefatos SDD relevantes.
 
 ### Atualizacao documental
 
 Se houver divergencia entre codigo e documentacao, proponha ajuste nos documentos
-e no estado OpenSDD canonico quando aplicavel. Se o usuario anunciar uma decisao,
+e no estado CodeSDD canonico quando aplicavel. Se o usuario anunciar uma decisao,
 registre-a no artefato correto.
 
 ## Guardrails
@@ -53,8 +53,8 @@ registre-a no artefato correto.
 - **Evitar suposicoes:** validar com o usuario quando houver incerteza de direcao arquitetural.
     `,
         license: 'MIT',
-        compatibility: 'Requires opensdd CLI.',
-        metadata: { author: 'openspec', version: '1.0' },
+        compatibility: 'Requires codesdd CLI.',
+        metadata: { author: 'codesdd', version: '1.0' },
     };
 }
 export function getOpsxSddCommandTemplate() {

package/dist/core/templates/workflows/sync-specs.js

@@ -1,13 +1,13 @@
 export function getSyncSpecsSkillTemplate() {
     return {
-        name: 'openspec-sync-specs',
+        name: 'codesdd-sync-specs',
         description: 'Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.',
         instructions: `Sync delta specs from a change to main specs.
 
-**OpenSDD-native guardrail**
+**CodeSDD-native guardrail**
 
-If this repository has a \`.sdd/\` directory, do not create or recreate \`openspec/specs\`
-or \`openspec/changes\`. Treat imported OpenSpec files under
+If this repository has a \`.sdd/\` directory, do not create or recreate \`legacy-spec/specs\`
+or \`legacy-spec/changes\`. Treat imported CodeSDD files under
 \`.sdd/sources/legacy/spec-corpus\` as read-only legacy context unless the user explicitly
 asks for legacy compatibility maintenance.
 
@@ -19,7 +19,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 1. **If no change name provided, prompt for selection**
 
-   Run \`openspec list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+   Run \`codesdd list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have delta specs (under \`specs/\` directory).
 
@@ -27,7 +27,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 2. **Find delta specs**
 
-   Look for delta spec files in \`openspec/changes/<name>/specs/*/spec.md\`.
+   Look for delta spec files in \`legacy-spec/changes/<name>/specs/*/spec.md\`.
 
    Each delta spec file contains sections like:
    - \`## ADDED Requirements\` - New requirements to add
@@ -39,11 +39,11 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 3. **For each delta spec, apply changes to main specs**
 
-   For each capability with a delta spec at \`openspec/changes/<name>/specs/<capability>/spec.md\`:
+   For each capability with a delta spec at \`legacy-spec/changes/<name>/specs/<capability>/spec.md\`:
 
    a. **Read the delta spec** to understand the intended changes
 
-   b. **Read the main spec** at \`openspec/specs/<capability>/spec.md\` (may not exist yet)
+   b. **Read the main spec** at \`legacy-spec/specs/<capability>/spec.md\` (may not exist yet)
 
    c. **Apply changes intelligently**:
 
@@ -66,7 +66,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
       - Find the FROM requirement, rename to TO
 
    d. **Create new main spec** if capability doesn't exist yet:
-      - Create \`openspec/specs/<capability>/spec.md\`
+      - Create \`legacy-spec/specs/<capability>/spec.md\`
       - Add Purpose section (can be brief, mark as TBD)
       - Add Requirements section with the ADDED requirements
 
@@ -137,8 +137,8 @@ Main specs are now updated. The change remains active - archive when implementat
 - Show what you're changing as you go
 - The operation should be idempotent - running twice should give same result`,
         license: 'MIT',
-        compatibility: 'Requires opensdd CLI.',
-        metadata: { author: 'openspec', version: '1.0' },
+        compatibility: 'Requires codesdd CLI.',
+        metadata: { author: 'codesdd', version: '1.0' },
     };
 }
 export function getOpsxSyncCommandTemplate() {
@@ -149,10 +149,10 @@ export function getOpsxSyncCommandTemplate() {
         tags: ['workflow', 'specs', 'experimental'],
         content: `Sync delta specs from a change to main specs.
 
-**OpenSDD-native guardrail**
+**CodeSDD-native guardrail**
 
-If this repository has a \`.sdd/\` directory, do not create or recreate \`openspec/specs\`
-or \`openspec/changes\`. Treat imported OpenSpec files under
+If this repository has a \`.sdd/\` directory, do not create or recreate \`legacy-spec/specs\`
+or \`legacy-spec/changes\`. Treat imported CodeSDD files under
 \`.sdd/sources/legacy/spec-corpus\` as read-only legacy context unless the user explicitly
 asks for legacy compatibility maintenance.
 
@@ -164,7 +164,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 1. **If no change name provided, prompt for selection**
 
-   Run \`openspec list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+   Run \`codesdd list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have delta specs (under \`specs/\` directory).
 
@@ -172,7 +172,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 2. **Find delta specs**
 
-   Look for delta spec files in \`openspec/changes/<name>/specs/*/spec.md\`.
+   Look for delta spec files in \`legacy-spec/changes/<name>/specs/*/spec.md\`.
 
    Each delta spec file contains sections like:
    - \`## ADDED Requirements\` - New requirements to add
@@ -184,11 +184,11 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 3. **For each delta spec, apply changes to main specs**
 
-   For each capability with a delta spec at \`openspec/changes/<name>/specs/<capability>/spec.md\`:
+   For each capability with a delta spec at \`legacy-spec/changes/<name>/specs/<capability>/spec.md\`:
 
    a. **Read the delta spec** to understand the intended changes
 
-   b. **Read the main spec** at \`openspec/specs/<capability>/spec.md\` (may not exist yet)
+   b. **Read the main spec** at \`legacy-spec/specs/<capability>/spec.md\` (may not exist yet)
 
    c. **Apply changes intelligently**:
 
@@ -211,7 +211,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
       - Find the FROM requirement, rename to TO
 
    d. **Create new main spec** if capability doesn't exist yet:
-      - Create \`openspec/specs/<capability>/spec.md\`
+      - Create \`legacy-spec/specs/<capability>/spec.md\`
       - Add Purpose section (can be brief, mark as TBD)
       - Add Requirements section with the ADDED requirements
 

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

@@ -1,14 +1,14 @@
 export function getVerifyChangeSkillTemplate() {
     return {
-        name: 'openspec-verify-change',
+        name: 'codesdd-verify-change',
         description: 'Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.',
         instructions: `Verify that an implementation matches the change artifacts (specs, tasks, design).
 
-**OpenSDD-native guardrail**
+**CodeSDD-native guardrail**
 
-If this repository has a \`.sdd/\` directory, verify against OpenSDD canonical state
+If this repository has a \`.sdd/\` directory, verify against CodeSDD canonical state
 first: \`.sdd/state/*.yaml\`, \`.sdd/active/<FEAT-ID>\`, and \`.sdd/planned/<FEAT-ID>\`.
-Use OpenSpec paths only as imported legacy context or when the user explicitly asks
+Use CodeSDD paths only as imported legacy context or when the user explicitly asks
 for legacy compatibility validation.
 
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
@@ -17,7 +17,7 @@ for legacy compatibility validation.
 
 1. **If no change name provided, prompt for selection**
 
-   Run \`openspec list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+   Run \`codesdd list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have implementation tasks (tasks artifact exists).
    Include the schema used for each change if available.
@@ -27,7 +27,7 @@ for legacy compatibility validation.
 
 2. **Check status to understand the schema**
    \`\`\`bash
-   opensdd status --change "<name>" --json
+   codesdd status --change "<name>" --json
    \`\`\`
    Parse the JSON to understand:
    - \`schemaName\`: The workflow being used (e.g., "spec-driven")
@@ -36,7 +36,7 @@ for legacy compatibility validation.
 3. **Get the change directory and load artifacts**
 
    \`\`\`bash
-   opensdd instructions apply --change "<name>" --json
+   codesdd instructions apply --change "<name>" --json
    \`\`\`
 
    This returns the change directory and context files. Read all available artifacts from \`contextFiles\`.
@@ -61,7 +61,7 @@ for legacy compatibility validation.
      - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
 
    **Spec Coverage**:
-   - If delta specs exist in \`openspec/changes/<name>/specs/\`:
+   - If delta specs exist in \`legacy-spec/changes/<name>/specs/\`:
      - Extract all requirements (marked with "### Requirement:")
      - For each requirement:
        - Search codebase for keywords related to the requirement
@@ -167,8 +167,8 @@ Use clear markdown with:
 - Specific, actionable recommendations
 - No vague suggestions like "consider reviewing"`,
         license: 'MIT',
-        compatibility: 'Requires opensdd CLI.',
-        metadata: { author: 'openspec', version: '1.0' },
+        compatibility: 'Requires codesdd CLI.',
+        metadata: { author: 'codesdd', version: '1.0' },
     };
 }
 export function getOpsxVerifyCommandTemplate() {
@@ -179,11 +179,11 @@ export function getOpsxVerifyCommandTemplate() {
         tags: ['workflow', 'verify', 'experimental'],
         content: `Verify that an implementation matches the change artifacts (specs, tasks, design).
 
-**OpenSDD-native guardrail**
+**CodeSDD-native guardrail**
 
-If this repository has a \`.sdd/\` directory, verify against OpenSDD canonical state
+If this repository has a \`.sdd/\` directory, verify against CodeSDD canonical state
 first: \`.sdd/state/*.yaml\`, \`.sdd/active/<FEAT-ID>\`, and \`.sdd/planned/<FEAT-ID>\`.
-Use OpenSpec paths only as imported legacy context or when the user explicitly asks
+Use CodeSDD paths only as imported legacy context or when the user explicitly asks
 for legacy compatibility validation.
 
 **Input**: Optionally specify a change name after \`/opsx:verify\` (e.g., \`/opsx:verify add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
@@ -192,7 +192,7 @@ for legacy compatibility validation.
 
 1. **If no change name provided, prompt for selection**
 
-   Run \`openspec list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+   Run \`codesdd list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have implementation tasks (tasks artifact exists).
    Include the schema used for each change if available.
@@ -202,7 +202,7 @@ for legacy compatibility validation.
 
 2. **Check status to understand the schema**
    \`\`\`bash
-   opensdd status --change "<name>" --json
+   codesdd status --change "<name>" --json
    \`\`\`
    Parse the JSON to understand:
    - \`schemaName\`: The workflow being used (e.g., "spec-driven")
@@ -211,7 +211,7 @@ for legacy compatibility validation.
 3. **Get the change directory and load artifacts**
 
    \`\`\`bash
-   opensdd instructions apply --change "<name>" --json
+   codesdd instructions apply --change "<name>" --json
    \`\`\`
 
    This returns the change directory and context files. Read all available artifacts from \`contextFiles\`.
@@ -236,7 +236,7 @@ for legacy compatibility validation.
      - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
 
    **Spec Coverage**:
-   - If delta specs exist in \`openspec/changes/<name>/specs/\`:
+   - If delta specs exist in \`legacy-spec/changes/<name>/specs/\`:
      - Extract all requirements (marked with "### Requirement:")
      - For each requirement:
        - Search codebase for keywords related to the requirement

package/dist/core/update.d.ts

@@ -1,7 +1,7 @@
 /**
  * Update Command
  *
- * Refreshes OpenSpec skills and commands for configured tools.
+ * Refreshes CodeSDD skills and commands for configured tools.
  * Supports profile-aware updates, delivery changes, migration, and smart update detection.
  */
 /**
@@ -59,7 +59,7 @@ export declare class UpdateCommand {
      */
     private removeUnselectedCommandFiles;
     /**
-     * Detect and handle legacy OpenSpec artifacts.
+     * Detect and handle legacy CodeSDD artifacts.
      * Unlike init, update warns but continues if legacy files found in non-interactive mode.
      * Returns array of tool IDs that were newly configured during legacy upgrade.
      */