@devtrack-solution/codesdd 1.2.2

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

@@ -0,0 +1,224 @@
+export function getOpsxProposeSkillTemplate() {
+    return {
+        name: 'openspec-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**
+
+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.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → \`add-user-auth\`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   \`\`\`bash
+   opensdd new change "<name>"
+   \`\`\`
+   This creates a scaffolded change at \`openspec/changes/<name>/\` with \`.openspec.yaml\`.
+
+3. **Get the artifact build order**
+   \`\`\`bash
+   opensdd status --change "<name>" --json
+   \`\`\`
+   Parse the JSON to get:
+   - \`applyRequires\`: array of artifact IDs needed before implementation (e.g., \`["tasks"]\`)
+   - \`artifacts\`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is \`ready\` (dependencies satisfied)**:
+      - Get instructions:
+        \`\`\`bash
+        opensdd instructions <artifact-id> --change "<name>" --json
+        \`\`\`
+      - The instructions JSON includes:
+        - \`context\`: Project background (constraints for you - do NOT include in output)
+        - \`rules\`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - \`template\`: The structure to use for your output file
+        - \`instruction\`: Schema-specific guidance for this artifact type
+        - \`outputPath\`: Where to write the artifact
+        - \`dependencies\`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using \`template\` as the structure
+      - Apply \`context\` and \`rules\` as constraints - but do NOT copy them into the file
+      - Show brief progress: "Created <artifact-id>"
+
+   b. **Continue until all \`applyRequires\` artifacts are complete**
+      - After creating each artifact, re-run \`opensdd 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
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   \`\`\`bash
+   opensdd status --change "<name>"
+   \`\`\`
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run \`/opsx:apply\` or ask me to implement to start working on the tasks."
+
+**Artifact Creation Guidelines**
+
+- Follow the \`instruction\` field from \`opensdd 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
+- **IMPORTANT**: \`context\` and \`rules\` are constraints for YOU, not content for the file
+  - Do NOT copy \`<context>\`, \`<rules>\`, \`<project_context>\` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's \`apply.requires\`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, 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' },
+    };
+}
+export function getOpsxProposeCommandTemplate() {
+    return {
+        name: 'OPSX: Propose',
+        description: 'Propose a new change - create it and generate all artifacts in one step',
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The argument after \`/opsx:propose\` is the change name (kebab-case), OR a description of what the user wants to build.
+
+**Steps**
+
+1. **If no input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → \`add-user-auth\`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   \`\`\`bash
+   opensdd new change "<name>"
+   \`\`\`
+   This creates a scaffolded change at \`openspec/changes/<name>/\` with \`.openspec.yaml\`.
+
+3. **Get the artifact build order**
+   \`\`\`bash
+   opensdd status --change "<name>" --json
+   \`\`\`
+   Parse the JSON to get:
+   - \`applyRequires\`: array of artifact IDs needed before implementation (e.g., \`["tasks"]\`)
+   - \`artifacts\`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is \`ready\` (dependencies satisfied)**:
+      - Get instructions:
+        \`\`\`bash
+        opensdd instructions <artifact-id> --change "<name>" --json
+        \`\`\`
+      - The instructions JSON includes:
+        - \`context\`: Project background (constraints for you - do NOT include in output)
+        - \`rules\`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - \`template\`: The structure to use for your output file
+        - \`instruction\`: Schema-specific guidance for this artifact type
+        - \`outputPath\`: Where to write the artifact
+        - \`dependencies\`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using \`template\` as the structure
+      - Apply \`context\` and \`rules\` as constraints - but do NOT copy them into the file
+      - Show brief progress: "Created <artifact-id>"
+
+   b. **Continue until all \`applyRequires\` artifacts are complete**
+      - After creating each artifact, re-run \`opensdd 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
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   \`\`\`bash
+   opensdd status --change "<name>"
+   \`\`\`
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run \`/opsx:apply\` to start implementing."
+
+**Artifact Creation Guidelines**
+
+- Follow the \`instruction\` field from \`opensdd 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
+- **IMPORTANT**: \`context\` and \`rules\` are constraints for YOU, not content for the file
+  - Do NOT copy \`<context>\`, \`<rules>\`, \`<project_context>\` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's \`apply.requires\`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next`
+    };
+}
+//# sourceMappingURL=propose.js.map

package/dist/core/templates/workflows/sdd.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getSddSkillTemplate(): SkillTemplate;
+export declare function getOpsxSddCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=sdd.d.ts.map

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

@@ -0,0 +1,107 @@
+export function getSddSkillTemplate() {
+    return {
+        name: 'openspec-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.
+
+**IMPORTANTE: o modo SDD e para arquitetura e documentacao, nao para implementar codigo.**
+Voce pode ler arquivos, escrever Markdown e organizar estruturas de diretorios. Deve garantir que mudancas arquiteturais relevantes, dependencias e comportamentos complexos sejam documentados antes da implementacao.
+
+**Idioma obrigatorio:** responda sempre em portugues do Brasil (pt-BR), salvo pedido explicito em outro idioma.
+
+---
+
+## Postura
+
+- **Guardiao arquitetural:** garanta que o repositorio siga a estrutura e as decisoes acordadas.
+- **Documentacao primeiro:** trate documentacao como codigo. Ela deve ser clara, versionada e precisa.
+- **Analitico e preciso:** quebre sistemas complexos em visoes estruturadas e rastreaveis.
+
+---
+
+## O que fazer
+
+- Verificar o estado de \`.sdd/\`, \`.sdd/state/*.yaml\`, \`.sdd/active/\`, \`.sdd/planned/\` e \`README.md\`.
+- Registrar decisoes em ADR/ADL ou logs equivalentes em Markdown.
+- Mapear componentes, APIs, responsabilidades de modulo e fluxo de dados com Mermaid ou ASCII.
+- Escrever novas especificacoes quando solicitado.
+- Se o usuario pedir implementacao direta de codigo, orientar primeiro o planejamento e a documentacao da mudanca.
+
+## Consciencia OpenSDD
+
+Voce tem contexto do sistema OpenSDD. 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
+somente contexto legado, nao fonte operacional de verdade.
+
+### Checagem de contexto
+
+No inicio, consulte \`opensdd sdd next\`, \`opensdd 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,
+registre-a no artefato correto.
+
+## Guardrails
+
+- **Nao implementar codigo de aplicacao:** foque em estrutura, governanca e documentacao.
+- **Manter legibilidade:** garantir padrao textual limpo, sem redundancia desnecessaria.
+- **Evitar suposicoes:** validar com o usuario quando houver incerteza de direcao arquitetural.
+    `,
+        license: 'MIT',
+        compatibility: 'Requires opensdd CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+export function getOpsxSddCommandTemplate() {
+    return {
+        name: 'OPSX: Arquiteto SDD',
+        description: 'Entrar no modo Arquiteto SDD para analisar, revisar e manter documentacao e arquitetura',
+        category: 'Workflow',
+        tags: ['workflow', 'sdd', 'architecture', 'documentation'],
+        content: `Entre no modo Arquiteto SDD. Analise profundamente a estrutura do sistema e mantenha a documentacao coerente.
+
+**IMPORTANTE: o modo Arquiteto SDD e para documentar e arquitetar, nao para implementar.** Voce pode ler arquivos, pesquisar codigo e investigar o repositorio para manter o SDD correto, mas NAO deve escrever codigo de aplicacao.
+
+**Idioma obrigatorio:** responda em portugues do Brasil (pt-BR), salvo solicitacao explicita diferente.
+
+**Entrada**: o argumento apos \`/opsx:sdd\` e o topico arquitetural a tratar. Exemplos:
+- "revisar estado atual"
+- "criar spec para feature X"
+- "atualizar diagramas de fluxo"
+
+---
+
+## Postura
+
+- **Guardiao arquitetural:** garanta aderencia a estrutura e decisoes acordadas.
+- **Documentacao primeiro:** documentacao deve ser clara, versionada e rastreavel.
+- **Analitico e preciso:** decompor o sistema em blocos e fluxos compreensiveis.
+
+---
+
+## O que fazer
+
+Dependendo do pedido:
+
+**Analisar arquitetura**
+- Ler componentes existentes e identificar lacunas de especificacao.
+- Mapear dependencias e acoplamentos.
+
+**Escrever documentacao**
+- Criar specs de modulos novos.
+- Atualizar \`README.md\`, \`.sdd/core/\`, \`.sdd/state/*.yaml\` e registros de decisao arquitetural quando aplicavel.
+- Gerar diagramas Mermaid para dar visao de contexto.
+
+## Guardrails
+
+- **Nao implementar codigo de aplicacao:** focar em estruturas, blueprint e decisoes.
+- **Sempre verificar:** antes de assumir algo sobre o codigo, confirmar no repositorio.
+- **Ser estruturado:** produzir markdown claro e bem organizado.`,
+    };
+}
+//# sourceMappingURL=sdd.js.map

package/dist/core/templates/workflows/sync-specs.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getSyncSpecsSkillTemplate(): SkillTemplate;
+export declare function getOpsxSyncCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=sync-specs.d.ts.map

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

@@ -0,0 +1,286 @@
+export function getSyncSpecsSkillTemplate() {
+    return {
+        name: 'openspec-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**
+
+If this repository has a \`.sdd/\` directory, do not create or recreate \`openspec/specs\`
+or \`openspec/changes\`. Treat imported OpenSpec files under
+\`.sdd/sources/legacy/spec-corpus\` as read-only legacy context unless the user explicitly
+asks for legacy compatibility maintenance.
+
+This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
+
+**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.
+
+**Steps**
+
+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.
+
+   Show changes that have delta specs (under \`specs/\` directory).
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Find delta specs**
+
+   Look for delta spec files in \`openspec/changes/<name>/specs/*/spec.md\`.
+
+   Each delta spec file contains sections like:
+   - \`## ADDED Requirements\` - New requirements to add
+   - \`## MODIFIED Requirements\` - Changes to existing requirements
+   - \`## REMOVED Requirements\` - Requirements to remove
+   - \`## RENAMED Requirements\` - Requirements to rename (FROM:/TO: format)
+
+   If no delta specs found, inform user and stop.
+
+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\`:
+
+   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)
+
+   c. **Apply changes intelligently**:
+
+      **ADDED Requirements:**
+      - If requirement doesn't exist in main spec → add it
+      - If requirement already exists → update it to match (treat as implicit MODIFIED)
+
+      **MODIFIED Requirements:**
+      - Find the requirement in main spec
+      - Apply the changes - this can be:
+        - Adding new scenarios (don't need to copy existing ones)
+        - Modifying existing scenarios
+        - Changing the requirement description
+      - Preserve scenarios/content not mentioned in the delta
+
+      **REMOVED Requirements:**
+      - Remove the entire requirement block from main spec
+
+      **RENAMED Requirements:**
+      - Find the FROM requirement, rename to TO
+
+   d. **Create new main spec** if capability doesn't exist yet:
+      - Create \`openspec/specs/<capability>/spec.md\`
+      - Add Purpose section (can be brief, mark as TBD)
+      - Add Requirements section with the ADDED requirements
+
+4. **Show summary**
+
+   After applying all changes, summarize:
+   - Which capabilities were updated
+   - What changes were made (requirements added/modified/removed/renamed)
+
+**Delta Spec Format Reference**
+
+\`\`\`markdown
+## ADDED Requirements
+
+### Requirement: New Feature
+The system SHALL do something new.
+
+#### Scenario: Basic case
+- **WHEN** user does X
+- **THEN** system does Y
+
+## MODIFIED Requirements
+
+### Requirement: Existing Feature
+#### Scenario: New scenario to add
+- **WHEN** user does A
+- **THEN** system does B
+
+## REMOVED Requirements
+
+### Requirement: Deprecated Feature
+
+## RENAMED Requirements
+
+- FROM: \`### Requirement: Old Name\`
+- TO: \`### Requirement: New Name\`
+\`\`\`
+
+**Key Principle: Intelligent Merging**
+
+Unlike programmatic merging, you can apply **partial updates**:
+- To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios
+- The delta represents *intent*, not a wholesale replacement
+- Use your judgment to merge changes sensibly
+
+**Output On Success**
+
+\`\`\`
+## Specs Synced: <change-name>
+
+Updated main specs:
+
+**<capability-1>**:
+- Added requirement: "New Feature"
+- Modified requirement: "Existing Feature" (added 1 scenario)
+
+**<capability-2>**:
+- Created new spec file
+- Added requirement: "Another Feature"
+
+Main specs are now updated. The change remains active - archive when implementation is complete.
+\`\`\`
+
+**Guardrails**
+- Read both delta and main specs before making changes
+- Preserve existing content not mentioned in delta
+- If something is unclear, ask for clarification
+- Show what you're changing as you go
+- The operation should be idempotent - running twice should give same result`,
+        license: 'MIT',
+        compatibility: 'Requires opensdd CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+export function getOpsxSyncCommandTemplate() {
+    return {
+        name: 'OPSX: Sync',
+        description: 'Sync delta specs from a change to main specs',
+        category: 'Workflow',
+        tags: ['workflow', 'specs', 'experimental'],
+        content: `Sync delta specs from a change to main specs.
+
+**OpenSDD-native guardrail**
+
+If this repository has a \`.sdd/\` directory, do not create or recreate \`openspec/specs\`
+or \`openspec/changes\`. Treat imported OpenSpec files under
+\`.sdd/sources/legacy/spec-corpus\` as read-only legacy context unless the user explicitly
+asks for legacy compatibility maintenance.
+
+This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
+
+**Input**: Optionally specify a change name after \`/opsx:sync\` (e.g., \`/opsx:sync add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+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.
+
+   Show changes that have delta specs (under \`specs/\` directory).
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Find delta specs**
+
+   Look for delta spec files in \`openspec/changes/<name>/specs/*/spec.md\`.
+
+   Each delta spec file contains sections like:
+   - \`## ADDED Requirements\` - New requirements to add
+   - \`## MODIFIED Requirements\` - Changes to existing requirements
+   - \`## REMOVED Requirements\` - Requirements to remove
+   - \`## RENAMED Requirements\` - Requirements to rename (FROM:/TO: format)
+
+   If no delta specs found, inform user and stop.
+
+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\`:
+
+   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)
+
+   c. **Apply changes intelligently**:
+
+      **ADDED Requirements:**
+      - If requirement doesn't exist in main spec → add it
+      - If requirement already exists → update it to match (treat as implicit MODIFIED)
+
+      **MODIFIED Requirements:**
+      - Find the requirement in main spec
+      - Apply the changes - this can be:
+        - Adding new scenarios (don't need to copy existing ones)
+        - Modifying existing scenarios
+        - Changing the requirement description
+      - Preserve scenarios/content not mentioned in the delta
+
+      **REMOVED Requirements:**
+      - Remove the entire requirement block from main spec
+
+      **RENAMED Requirements:**
+      - Find the FROM requirement, rename to TO
+
+   d. **Create new main spec** if capability doesn't exist yet:
+      - Create \`openspec/specs/<capability>/spec.md\`
+      - Add Purpose section (can be brief, mark as TBD)
+      - Add Requirements section with the ADDED requirements
+
+4. **Show summary**
+
+   After applying all changes, summarize:
+   - Which capabilities were updated
+   - What changes were made (requirements added/modified/removed/renamed)
+
+**Delta Spec Format Reference**
+
+\`\`\`markdown
+## ADDED Requirements
+
+### Requirement: New Feature
+The system SHALL do something new.
+
+#### Scenario: Basic case
+- **WHEN** user does X
+- **THEN** system does Y
+
+## MODIFIED Requirements
+
+### Requirement: Existing Feature
+#### Scenario: New scenario to add
+- **WHEN** user does A
+- **THEN** system does B
+
+## REMOVED Requirements
+
+### Requirement: Deprecated Feature
+
+## RENAMED Requirements
+
+- FROM: \`### Requirement: Old Name\`
+- TO: \`### Requirement: New Name\`
+\`\`\`
+
+**Key Principle: Intelligent Merging**
+
+Unlike programmatic merging, you can apply **partial updates**:
+- To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios
+- The delta represents *intent*, not a wholesale replacement
+- Use your judgment to merge changes sensibly
+
+**Output On Success**
+
+\`\`\`
+## Specs Synced: <change-name>
+
+Updated main specs:
+
+**<capability-1>**:
+- Added requirement: "New Feature"
+- Modified requirement: "Existing Feature" (added 1 scenario)
+
+**<capability-2>**:
+- Created new spec file
+- Added requirement: "Another Feature"
+
+Main specs are now updated. The change remains active - archive when implementation is complete.
+\`\`\`
+
+**Guardrails**
+- Read both delta and main specs before making changes
+- Preserve existing content not mentioned in delta
+- If something is unclear, ask for clarification
+- Show what you're changing as you go
+- The operation should be idempotent - running twice should give same result`
+    };
+}
+//# sourceMappingURL=sync-specs.js.map

package/dist/core/templates/workflows/verify-change.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getVerifyChangeSkillTemplate(): SkillTemplate;
+export declare function getOpsxVerifyCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=verify-change.d.ts.map