@devtrack-solution/codesdd 1.2.2 → 1.2.3

package/dist/core/templates/workflows/bulk-archive-change.js

@@ -1,14 +1,14 @@
 export function getBulkArchiveChangeSkillTemplate() {
     return {
-        name: 'openspec-bulk-archive-change',
+        name: 'codesdd-bulk-archive-change',
         description: 'Archive multiple completed changes at once. Use when archiving several parallel changes.',
         instructions: `Archive multiple completed changes in a single operation.
 
-**OpenSDD-native guardrail**
+**CodeSDD-native guardrail**
 
 If this repository has a \`.sdd/\` directory, do not create, move, archive, or recreate
-\`openspec/changes\`. Use \`opensdd sdd finalize --ref <FEAT-ID>\` for canonical
-feature archival. Use this bulk archive flow only for explicitly legacy OpenSpec
+\`legacy-spec/changes\`. Use \`codesdd sdd finalize --ref <FEAT-ID>\` for canonical
+feature archival. Use this bulk archive flow only for explicitly legacy CodeSDD
 compatibility artifacts.
 
 This skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.
@@ -19,7 +19,7 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
 1. **Get active changes**
 
-   Run \`openspec list --json\` to get all active changes.
+   Run \`codesdd list --json\` to get all active changes.
 
    If no active changes exist, inform user and stop.
 
@@ -36,15 +36,15 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
    For each selected change, collect:
 
-   a. **Artifact status** - Run \`opensdd status --change "<name>" --json\`
+   a. **Artifact status** - Run \`codesdd status --change "<name>" --json\`
       - Parse \`schemaName\` and \`artifacts\` list
       - Note which artifacts are \`done\` vs other states
 
-   b. **Task completion** - Read \`openspec/changes/<name>/tasks.md\`
+   b. **Task completion** - Read \`legacy-spec/changes/<name>/tasks.md\`
       - Count \`- [ ]\` (incomplete) vs \`- [x]\` (complete)
       - If no tasks file exists, note as "No tasks"
 
-   c. **Delta specs** - Check \`openspec/changes/<name>/specs/\` directory
+   c. **Delta specs** - Check \`legacy-spec/changes/<name>/specs/\` directory
       - List which capability specs exist
       - For each, extract requirement names (lines matching \`### Requirement: <name>\`)
 
@@ -121,14 +121,14 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
    Process changes in the determined order (respecting conflict resolution):
 
    a. **Sync specs** if delta specs exist:
-      - Use the openspec-sync-specs approach (agent-driven intelligent merge)
+      - Use the codesdd-sync-specs approach (agent-driven intelligent merge)
       - For conflicts, apply in resolved order
       - Track if sync was done
 
    b. **Perform the archive**:
       \`\`\`bash
-      mkdir -p openspec/changes/archive
-      mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+      mkdir -p legacy-spec/changes/archive
+      mv legacy-spec/changes/<name> legacy-spec/changes/archive/YYYY-MM-DD-<name>
       \`\`\`
 
    c. **Track outcome** for each change:
@@ -241,12 +241,12 @@ No active changes found. Create a new change to get started.
 - Show clear per-change status before confirming
 - Use single confirmation for entire batch
 - Track and report all outcomes (success/skip/fail)
-- Preserve .openspec.yaml when moving to archive
+- Preserve .sdd.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`,
         license: 'MIT',
-        compatibility: 'Requires opensdd CLI.',
-        metadata: { author: 'openspec', version: '1.0' },
+        compatibility: 'Requires codesdd CLI.',
+        metadata: { author: 'codesdd', version: '1.0' },
     };
 }
 export function getOpsxBulkArchiveCommandTemplate() {
@@ -257,11 +257,11 @@ export function getOpsxBulkArchiveCommandTemplate() {
         tags: ['workflow', 'archive', 'experimental', 'bulk'],
         content: `Archive multiple completed changes in a single operation.
 
-**OpenSDD-native guardrail**
+**CodeSDD-native guardrail**
 
 If this repository has a \`.sdd/\` directory, do not create, move, archive, or recreate
-\`openspec/changes\`. Use \`opensdd sdd finalize --ref <FEAT-ID>\` for canonical
-feature archival. Use this bulk archive flow only for explicitly legacy OpenSpec
+\`legacy-spec/changes\`. Use \`codesdd sdd finalize --ref <FEAT-ID>\` for canonical
+feature archival. Use this bulk archive flow only for explicitly legacy CodeSDD
 compatibility artifacts.
 
 This skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.
@@ -272,7 +272,7 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
 1. **Get active changes**
 
-   Run \`openspec list --json\` to get all active changes.
+   Run \`codesdd list --json\` to get all active changes.
 
    If no active changes exist, inform user and stop.
 
@@ -289,15 +289,15 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
    For each selected change, collect:
 
-   a. **Artifact status** - Run \`opensdd status --change "<name>" --json\`
+   a. **Artifact status** - Run \`codesdd status --change "<name>" --json\`
       - Parse \`schemaName\` and \`artifacts\` list
       - Note which artifacts are \`done\` vs other states
 
-   b. **Task completion** - Read \`openspec/changes/<name>/tasks.md\`
+   b. **Task completion** - Read \`legacy-spec/changes/<name>/tasks.md\`
       - Count \`- [ ]\` (incomplete) vs \`- [x]\` (complete)
       - If no tasks file exists, note as "No tasks"
 
-   c. **Delta specs** - Check \`openspec/changes/<name>/specs/\` directory
+   c. **Delta specs** - Check \`legacy-spec/changes/<name>/specs/\` directory
       - List which capability specs exist
       - For each, extract requirement names (lines matching \`### Requirement: <name>\`)
 
@@ -374,14 +374,14 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
    Process changes in the determined order (respecting conflict resolution):
 
    a. **Sync specs** if delta specs exist:
-      - Use the openspec-sync-specs approach (agent-driven intelligent merge)
+      - Use the codesdd-sync-specs approach (agent-driven intelligent merge)
       - For conflicts, apply in resolved order
       - Track if sync was done
 
    b. **Perform the archive**:
       \`\`\`bash
-      mkdir -p openspec/changes/archive
-      mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+      mkdir -p legacy-spec/changes/archive
+      mv legacy-spec/changes/<name> legacy-spec/changes/archive/YYYY-MM-DD-<name>
       \`\`\`
 
    c. **Track outcome** for each change:
@@ -494,7 +494,7 @@ No active changes found. Create a new change to get started.
 - Show clear per-change status before confirming
 - Use single confirmation for entire batch
 - Track and report all outcomes (success/skip/fail)
-- Preserve .openspec.yaml when moving to archive
+- Preserve .sdd.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`
     };

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

@@ -1,7 +1,7 @@
 export function getContinueChangeSkillTemplate() {
     return {
-        name: 'openspec-continue-change',
-        description: 'Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.',
+        name: 'codesdd-continue-change',
+        description: 'Continue working on an CodeSDD change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.',
         instructions: `Continue working on a change by creating the next artifact.
 
 **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.
@@ -10,7 +10,7 @@ export function getContinueChangeSkillTemplate() {
 
 1. **If no change name provided, prompt for selection**
 
-   Run \`openspec list --json\` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
+   Run \`codesdd list --json\` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
 
    Present the top 3-4 most recently modified changes as options, showing:
    - Change name
@@ -24,7 +24,7 @@ export function getContinueChangeSkillTemplate() {
 
 2. **Check current status**
    \`\`\`bash
-   opensdd status --change "<name>" --json
+   codesdd status --change "<name>" --json
    \`\`\`
    Parse the JSON to understand current state. The response includes:
    - \`schemaName\`: The workflow schema being used (e.g., "spec-driven")
@@ -47,7 +47,7 @@ export function getContinueChangeSkillTemplate() {
    - Pick the FIRST artifact with \`status: "ready"\` from the status output
    - Get its instructions:
      \`\`\`bash
-     opensdd instructions <artifact-id> --change "<name>" --json
+     codesdd instructions <artifact-id> --change "<name>" --json
      \`\`\`
    - Parse the JSON. The key fields are:
      - \`context\`: Project background (constraints for you - do NOT include in output)
@@ -72,7 +72,7 @@ export function getContinueChangeSkillTemplate() {
 
 4. **After creating an artifact, show progress**
    \`\`\`bash
-   opensdd status --change "<name>"
+   codesdd status --change "<name>"
    \`\`\`
 
 **Output**
@@ -110,8 +110,8 @@ For other schemas, follow the \`instruction\` field from the CLI output.
   - 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 opensdd CLI.',
-        metadata: { author: 'openspec', version: '1.0' },
+        compatibility: 'Requires codesdd CLI.',
+        metadata: { author: 'codesdd', version: '1.0' },
     };
 }
 export function getOpsxContinueCommandTemplate() {
@@ -128,7 +128,7 @@ export function getOpsxContinueCommandTemplate() {
 
 1. **If no change name provided, prompt for selection**
 
-   Run \`openspec list --json\` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
+   Run \`codesdd list --json\` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
 
    Present the top 3-4 most recently modified changes as options, showing:
    - Change name
@@ -142,7 +142,7 @@ export function getOpsxContinueCommandTemplate() {
 
 2. **Check current status**
    \`\`\`bash
-   opensdd status --change "<name>" --json
+   codesdd status --change "<name>" --json
    \`\`\`
    Parse the JSON to understand current state. The response includes:
    - \`schemaName\`: The workflow schema being used (e.g., "spec-driven")
@@ -165,7 +165,7 @@ export function getOpsxContinueCommandTemplate() {
    - Pick the FIRST artifact with \`status: "ready"\` from the status output
    - Get its instructions:
      \`\`\`bash
-     opensdd instructions <artifact-id> --change "<name>" --json
+     codesdd instructions <artifact-id> --change "<name>" --json
      \`\`\`
    - Parse the JSON. The key fields are:
      - \`context\`: Project background (constraints for you - do NOT include in output)
@@ -190,7 +190,7 @@ export function getOpsxContinueCommandTemplate() {
 
 4. **After creating an artifact, show progress**
    \`\`\`bash
-   opensdd status --change "<name>"
+   codesdd status --change "<name>"
    \`\`\`
 
 **Output**

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.