@zhuan-ai/zhuanspec 1.3.0

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

@@ -0,0 +1,2131 @@
+/**
+ * Agent Skill Templates
+ *
+ * Templates for generating Agent Skills compatible with:
+ * - Claude Code
+ * - Cursor (Settings → Rules → Import Settings)
+ * - Windsurf
+ * - Other Agent Skills-compatible editors
+ */
+/**
+ * Template for zhuanspec-new-change skill
+ * Based on /opsx:new command
+ */
+export function getNewChangeSkillTemplate() {
+    return {
+        name: 'zhuanspec-new-change',
+        description: 'Start a new ZhuanSpec 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.
+
+**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. **Select a workflow schema**
+
+   Run \`zhuanspec schemas --json\` to get available schemas with descriptions.
+
+   Use the **AskUserQuestion tool** to let the user choose a workflow:
+   - Present each schema with its description
+   - Mark \`spec-driven\` as "(default)" if it's available
+   - Example options: "spec-driven - proposal → specs → design → tasks (default)", "tdd - tests → implementation → docs"
+
+   If user doesn't have a preference, default to \`spec-driven\`.
+
+3. **Create the change directory**
+   \`\`\`bash
+   zhuanspec new change "<name>" --schema "<selected-schema>"
+   \`\`\`
+   This creates a scaffolded change at \`zhuanspec/changes/<name>/\` with the selected schema.
+
+4. **Show the artifact status**
+   \`\`\`bash
+   zhuanspec 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 (e.g., \`proposal\` for spec-driven, \`spec\` for tdd).
+   Check the status output to find the first artifact with status "ready".
+   \`\`\`bash
+   zhuanspec instructions <first-artifact-id> --change "<name>"
+   \`\`\`
+   This outputs the template and context for creating the first artifact.
+
+6. **STOP and wait for user direction**
+
+**Output**
+
+After completing the steps, summarize:
+- Change name and location
+- Selected schema/workflow and its artifact sequence
+- Current status (0/N artifacts complete)
+- The template for the first artifact
+- Prompt: "Ready to create the first artifact? Just describe what this change is about and I'll draft it, or ask me to continue."
+
+**Guardrails**
+- Do NOT create any artifacts yet - just show the instructions
+- Do NOT advance beyond showing the first artifact template
+- If the name is invalid (not kebab-case), ask for a valid name
+- If a change with that name already exists, suggest continuing that change instead
+- Always pass --schema to preserve the user's workflow choice`
+    };
+}
+/**
+ * Template for zhuanspec-continue-change skill
+ * Based on /opsx:continue command
+ */
+export function getContinueChangeSkillTemplate() {
+    return {
+        name: 'zhuanspec-continue-change',
+        description: 'Continue working on an ZhuanSpec 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, MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run \`zhuanspec 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
+   - Schema (from \`schema\` field if present, otherwise "spec-driven")
+   - Status (e.g., "0/5 tasks", "complete", "no tasks")
+   - How recently it was modified (from \`lastModified\` field)
+
+   Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to continue.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check current status**
+   \`\`\`bash
+   zhuanspec status --change "<name>" --json
+   \`\`\`
+   Parse the JSON to understand current state. The response includes:
+   - \`schemaName\`: The workflow schema being used (e.g., "spec-driven", "tdd")
+   - \`artifacts\`: Array of artifacts with their status ("done", "ready", "blocked")
+   - \`isComplete\`: Boolean indicating if all artifacts are complete
+
+3. **Act based on status**:
+
+   ---
+
+   **If all artifacts are complete (\`isComplete: true\`)**:
+   - Congratulate the user
+   - Show final status including the schema used
+   - Suggest: "All artifacts created! You can now implement this change or archive it."
+   - STOP
+
+   ---
+
+   **If artifacts are ready to create** (status shows artifacts with \`status: "ready"\`):
+   - Pick the FIRST artifact with \`status: "ready"\` from the status output
+   - Get its instructions:
+     \`\`\`bash
+     zhuanspec instructions <artifact-id> --change "<name>" --json
+     \`\`\`
+   - Parse the JSON to get template, dependencies, and what it unlocks
+   - **Create the artifact file** using the template as a starting point:
+     - Read any completed dependency files for context
+     - Fill in the template based on context and user's goals
+     - Write to the output path specified in instructions
+   - Show what was created and what's now unlocked
+   - STOP after creating ONE artifact
+
+   ---
+
+   **If no artifacts are ready (all blocked)**:
+   - This shouldn't happen with a valid schema
+   - Show status and suggest checking for issues
+
+4. **After creating an artifact, show progress**
+   \`\`\`bash
+   zhuanspec status --change "<name>"
+   \`\`\`
+
+**Output**
+
+After each invocation, show:
+- Which artifact was created
+- Schema workflow being used
+- Current progress (N/M complete)
+- What artifacts are now unlocked
+- Prompt: "Want to continue? Just ask me to continue or tell me what to do next."
+
+**Artifact Creation Guidelines**
+
+The artifact types and their purpose depend on the schema. Use the \`instruction\` field from the instructions output to understand what to create.
+
+Common artifact patterns:
+
+**spec-driven schema** (proposal → specs → design → tasks):
+- **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
+  - The Capabilities section is critical - each capability listed will need a spec file.
+- **specs/*.md**: Create one spec per capability listed in the proposal.
+- **design.md**: Document technical decisions, architecture, and implementation approach.
+- **tasks.md**: Break down implementation into checkboxed tasks.
+
+**tdd schema** (spec → tests → implementation → docs):
+- **spec.md**: Feature specification defining what to build.
+- **tests/*.test.ts**: Write tests BEFORE implementation (TDD red phase).
+- **src/*.ts**: Implement to make tests pass (TDD green phase).
+- **docs/*.md**: Document the implemented feature.
+
+For other schemas, follow the \`instruction\` field from the CLI output.
+
+**Guardrails**
+- Create ONE artifact per invocation
+- Always read dependency artifacts before creating a new one
+- Never skip artifacts or create out of order
+- If context is unclear, use **AskUserQuestion tool** with preset options to clarify before creating
+- Verify the artifact file exists after writing before marking progress
+- Use the schema's artifact sequence, don't assume specific artifact names`
+    };
+}
+/**
+ * Template for zhuanspec-apply-change skill
+ * For implementing tasks from a completed (or in-progress) change
+ */
+export function getApplyChangeSkillTemplate() {
+    return {
+        name: 'zhuanspec-apply-change',
+        description: 'Implement tasks from an ZhuanSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.',
+        instructions: `Implement tasks from an ZhuanSpec change.
+
+**Input**: Optionally specify a change name. If omitted, MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run \`zhuanspec list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that are implementation-ready (have tasks artifact).
+   Include the schema used for each change if available.
+   Mark changes with incomplete tasks as "(In Progress)".
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check status to understand the schema**
+   \`\`\`bash
+   zhuanspec status --change "<name>" --json
+   \`\`\`
+   Parse the JSON to understand:
+   - \`schemaName\`: The workflow being used (e.g., "spec-driven", "tdd")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   \`\`\`bash
+   zhuanspec instructions apply --change "<name>" --json
+   \`\`\`
+
+   This returns:
+   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If \`state: "blocked"\` (missing artifacts): show message, suggest using zhuanspec-continue-change
+   - If \`state: "all_done"\`: proceed to code review step (see step 8)
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in \`contextFiles\` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - **tdd**: spec, tests, implementation, docs
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Parse the task text for \`@skill\` tags (format: \`@skill:name1,name2\`)
+   - If \`@skill\` tags found, invoke the corresponding skill(s) for guidance before making changes
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: \`- [ ]\` → \`- [x]\`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → use **AskUserQuestion tool** with preset options to clarify (never ask for free-text input)
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: proceed to code review step (step 8)
+   - If paused: explain why and wait for guidance
+
+8. **Code Review (when all tasks complete)**
+
+   **WHEN** all tasks are complete (\`state: "all_done"\`):
+   
+   a. **Prompt for code review**
+   
+      Use the **AskUserQuestion tool** with options:
+      - "是，进行代码审查" / "Yes, perform code review"
+      - "跳过，直接归档" / "Skip, proceed to archive"
+      
+      Wait for user selection before proceeding.
+   
+   b. **If user selects "Yes, perform code review"**:
+      
+      1. **Read code files related to the change**
+         - Based on context files from apply instructions
+         - Scan the change directory for code files (e.g., \`*.java\`, \`*.ts\`, \`*.py\`, etc.)
+         - Read all relevant code files that were modified or created for this change
+      
+      2. **Perform code review**
+         
+         Review code for:
+         - **Code standards and conventions compliance**: naming, formatting, structure
+         - **Logic correctness**: edge cases, error handling, business logic
+         - **Performance issues**: inefficient algorithms, unnecessary operations, potential bottlenecks
+         - **Security concerns**: input validation, authentication, authorization, data exposure
+         - **Best practices adherence**: design patterns, SOLID principles, maintainability
+         
+         **For Java code specifically**, pay special attention to:
+         - Java-specific patterns and conventions (e.g., builder pattern, factory pattern)
+         - Common Java pitfalls:
+           - Null handling (NullPointerException prevention)
+           - Exception handling (proper try-catch, resource management)
+           - Resource management (try-with-resources, closing streams/connections)
+         - Performance considerations:
+           - Collections usage (ArrayList vs LinkedList, HashMap vs TreeMap)
+           - Streams vs loops (when to use each)
+           - Concurrency (thread safety, synchronization)
+      
+      3. **Generate review report**
+         
+         Create a structured report listing:
+         - **Issues found** (if any):
+           - Severity (Critical, High, Medium, Low)
+           - Location (file path and line number)
+           - Description
+           - Suggestion for improvement
+         - **Suggestions for improvement** (even if no critical issues)
+         - **Positive findings** (good practices observed)
+      
+      4. **Handle review results**
+         
+         - **If issues are found**:
+           
+           Display the review report with all issues.
+           
+           Use **AskUserQuestion tool** with options:
+           - "是，现在修复" / "Yes, fix now"
+           - "稍后修复" / "Fix later"
+           - "跳过" / "Skip"
+           
+           - If user chooses "Yes, fix now": proceed with fixing the issues one by one
+           - If user chooses "Fix later" or "Skip": continue to archive workflow
+         
+         - **If no issues are found**:
+           
+           Display: "代码审查完成，未发现问题。" (or "Code review complete. No issues found.")
+           Proceed to suggest archive workflow.
+   
+   c. **If user selects "Skip, proceed to archive"**:
+      
+      Skip the code review step.
+      Proceed directly to suggesting archive workflow.
+      The workflow SHALL NOT be blocked.
+
+**Output During Implementation**
+
+\`\`\`
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+\`\`\`
+
+**Output On Completion**
+
+\`\`\`
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! Ready for code review or archive.
+\`\`\`
+
+**Output After Code Review (Issues Found)**
+
+\`\`\`
+## Code Review Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+
+### Issues Found
+
+**Critical:**
+- [File: path/to/file.java:42] Description of critical issue
+  - Suggestion: How to fix
+
+**High:**
+- [File: path/to/file.java:58] Description of high priority issue
+  - Suggestion: How to fix
+
+**Medium:**
+- [File: path/to/file.java:73] Description of medium priority issue
+  - Suggestion: How to fix
+
+### Positive Findings
+- Good use of try-with-resources for resource management
+- Clear variable naming conventions
+- Proper exception handling
+
+发现了一些问题。是否现在修复？
+\`\`\`
+
+**Output After Code Review (No Issues)**
+
+\`\`\`
+## Code Review Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+
+代码审查完成，未发现问题。
+
+Ready to archive this change.
+\`\`\`
+
+**Output On Pause (Issue Encountered)**
+
+\`\`\`
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+\`\`\`
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, use **AskUserQuestion tool** with preset options to clarify before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly`
+    };
+}
+/**
+ * Template for zhuanspec-ff-change skill
+ * Fast-forward through artifact creation
+ */
+export function getFfChangeSkillTemplate() {
+    return {
+        name: 'zhuanspec-ff-change',
+        description: 'Fast-forward through ZhuanSpec 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.
+
+**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
+   zhuanspec new change "<name>"
+   \`\`\`
+   This creates a scaffolded change at \`zhuanspec/changes/<name>/\`.
+
+3. **Get the artifact build order**
+   \`\`\`bash
+   zhuanspec 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
+        zhuanspec instructions <artifact-id> --change "<name>" --json
+        \`\`\`
+      - The instructions JSON includes:
+        - \`template\`: The template content to use
+        - \`instruction\`: Schema-specific guidance for this artifact type
+        - \`outputPath\`: Where to write the artifact
+        - \`dependencies\`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file following the schema's \`instruction\`
+      - Show brief progress: "✓ Created <artifact-id>"
+
+   b. **Continue until all \`applyRequires\` artifacts are complete**
+      - After creating each artifact, re-run \`zhuanspec 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** with preset options to clarify (never ask for free-text input)
+      - Then continue with creation
+
+5. **Show final status**
+   \`\`\`bash
+   zhuanspec 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 \`zhuanspec instructions\` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use the \`template\` as a starting point, filling in based on context
+
+**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, use **AskUserQuestion tool** with preset options to clarify - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, suggest continuing that change instead
+- Verify each artifact file exists after writing before proceeding to next`
+    };
+}
+/**
+ * Template for zhuanspec-sync-specs skill
+ * For syncing delta specs from a change to main specs (agent-driven)
+ */
+export function getSyncSpecsSkillTemplate() {
+    return {
+        name: 'zhuanspec-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.
+
+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, MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run \`zhuanspec 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 \`zhuanspec/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 \`zhuanspec/changes/<name>/specs/<capability>/spec.md\`:
+
+   a. **Read the delta spec** to understand the intended changes
+
+   b. **Read the main spec** at \`zhuanspec/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 \`zhuanspec/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, use **AskUserQuestion tool** with preset options to clarify
+- Show what you're changing as you go
+- The operation should be idempotent - running twice should give same result`
+    };
+}
+/**
+ * Template for zhuanspec-propose-change skill
+ * One-step workflow: create change + generate all planning artifacts
+ */
+export function getProposeChangeSkillTemplate() {
+    return {
+        name: 'zhuanspec-propose-change',
+        description: 'Create a complete ZhuanSpec change proposal in one step. Use when the user wants to propose a new feature, fix, or modification. Generates proposal, specs, design, and tasks all at once.',
+        instructions: `Create a complete change proposal in one step - proposal, specs, design, and tasks.
+
+**Input**: The user's request should describe what they want to build or change. Can include a change name (kebab-case) or a natural language description.
+
+**Steps**
+
+1. **强制澄清检查（必须首先执行，不可跳过）**
+
+   Before creating anything, analyze the user's request for ambiguity:
+
+   a. **先查阅现有来源**：
+      - 审查 \`zhuanspec/project.md\` 了解项目约定
+      - 运行 \`zhuanspec list\` 和 \`zhuanspec list --specs\` 了解当前状态
+      - 检查相关代码和文档
+
+   b. **识别模糊点**（仅在无法从现有来源确定时询问）：
+      - 范围是否明确？
+      - 技术选择是否明确？
+      - 优先级是否明确？
+      - 验收标准是否明确？
+      - 实现细节是否明确？
+
+   c. **如果发现模糊点**，使用 **AskUserQuestion tool** 以选项式交互提问：
+      - 每个问题提供 2-5 个预设选项
+      - 严禁要求用户手动输入大段文字
+      - 必须等待用户回答后才继续
+
+   d. 只有所有模糊点都明确后，才继续后续步骤。
+
+2. **Derive change name**
+
+   From the user's description, derive a kebab-case name (e.g., "add user authentication" → \`add-user-auth\`).
+   Name should be: verb-first, descriptive, unique (check with \`zhuanspec list\`).
+
+3. **Create the change directory**
+   \`\`\`bash
+   zhuanspec new change "<name>"
+   \`\`\`
+
+4. **Create all planning artifacts in sequence**
+
+   Use the **TodoWrite tool** to track progress.
+
+   a. **Get artifact build order**:
+      \`\`\`bash
+      zhuanspec status --change "<name>" --json
+      \`\`\`
+
+   b. **For each artifact in dependency order** (proposal → specs → design → tasks):
+      - Get instructions: \`zhuanspec instructions <artifact-id> --change "<name>" --json\`
+      - Read any completed dependency files for context
+      - **For proposal artifact**: When filling Skill Mapping section, analyze each skill's description and match based on actual functionality (not just module names). Simple changes like enum modifications should map to general coding standards, not architecture-level skills.
+      - **For tasks artifact only**: Before creating tasks.md, run \`zhuanspec skills list --json\` to discover available skills with their descriptions. For each task, read skill descriptions carefully and annotate with \`@skill:<real-skill-name>\` tags only when there's a clear semantic match between the task's functionality and the skill's purpose. Supports multiple: \`@skill:name1,name2\`.
+      - Create the artifact following the schema's instruction
+      - Show brief progress: "✓ Created <artifact-id>"
+
+   c. **Artifact creation guidelines**:
+      - **proposal.md**: Fill in Why, What Changes, Capabilities, Impact based on clarified requirements. For Skill Mapping, match based on skill descriptions, not module names.
+      - **specs/\\*/spec.md**: Create one spec per capability using ADDED/MODIFIED/REMOVED format with Scenarios
+      - **design.md**: Only if needed (cross-cutting changes, new dependencies, security/performance)
+      - **tasks.md**: Break into small, verifiable tasks with checkboxes. Annotate with @skill tags based on semantic matching of skill descriptions to task functionality.
+
+5. **Validate the change**
+   \`\`\`bash
+   zhuanspec validate <name> --strict
+   \`\`\`
+   Fix any validation errors before presenting.
+
+6. **Present the complete proposal**
+
+   Show summary:
+   - Change name and location
+   - Proposal overview (Why + What Changes)
+   - Affected capabilities
+   - Task count
+   - Prompt: "提案已创建，请审核后确认是否开始实施。"
+
+**Output**
+
+\`\`\`
+## Proposal Created: <change-name>
+
+**Location:** zhuanspec/changes/<name>/
+
+✓ proposal.md — Why and What Changes
+✓ specs/       — Requirements and scenarios
+✓ design.md    — Technical approach (if needed)
+✓ tasks.md     — Implementation checklist (N tasks)
+
+Ready for review. Run \`/zhuanspec:apply\` to start implementation.
+\`\`\`
+
+**Guardrails**
+- MUST complete clarification before creating any files
+- Create ALL planning artifacts in one invocation
+- Do NOT start implementation - only create planning docs
+- Validate with --strict before presenting
+- If validation fails, fix and re-validate`
+    };
+}
+/**
+ * Template for zhuanspec-explore skill
+ * For exploration before committing to a change
+ */
+export function getExploreSkillTemplate() {
+    return {
+        name: 'zhuanspec-explore',
+        description: 'Explore ideas and investigate the codebase before creating a ZhuanSpec change. Use when requirements are unclear, the user wants to compare approaches, or needs to investigate before committing to a plan.',
+        instructions: `Explore ideas, investigate problems, and clarify requirements before committing to a change.
+
+**Input**: A topic, question, or area the user wants to explore.
+
+**Purpose**: Help the user think through ideas without creating any formal artifacts. This is the "thinking" phase before the "doing" phase.
+
+**Steps**
+
+1. **Understand what to explore**
+
+   If the topic is vague, use **AskUserQuestion tool** with options to narrow scope:
+   - "性能优化" / "Performance optimization"
+   - "架构改进" / "Architecture improvement"
+   - "新功能可行性" / "New feature feasibility"
+   - "技术债务" / "Technical debt"
+
+2. **Investigate the codebase**
+
+   Based on the topic:
+   - Search for relevant code patterns (\`rg\`, \`ls\`, file reads)
+   - Review existing specs: \`zhuanspec list --specs\`
+   - Check active changes: \`zhuanspec list\`
+   - Read project conventions: \`zhuanspec/project.md\`
+   - Analyze code structure, dependencies, and patterns
+
+3. **Present findings**
+
+   Provide a structured analysis:
+   - **Current State**: What exists now, how it works
+   - **Options**: Multiple approaches with pros/cons
+   - **Recommendation**: Suggested approach with reasoning
+   - **Impact**: What would need to change, estimated scope
+
+4. **Guide next steps**
+
+   Use **AskUserQuestion tool** to offer:
+   - "创建变更提案" / "Create a change proposal" → suggest \`/zhuanspec:propose\`
+   - "继续探索其他方面" / "Explore another aspect"
+   - "不需要变更" / "No change needed"
+
+**Output Format**
+
+\`\`\`
+## Exploration: <topic>
+
+### Current State
+[What exists, how it works]
+
+### Options
+1. **Option A**: [description]
+   - Pros: ...
+   - Cons: ...
+2. **Option B**: [description]
+   - Pros: ...
+   - Cons: ...
+
+### Recommendation
+[Suggested approach and why]
+
+### Estimated Impact
+- Files affected: ~N
+- Complexity: Low/Medium/High
+- Risk: Low/Medium/High
+
+Ready to proceed? Run \`/zhuanspec:propose\` to create a formal proposal.
+\`\`\`
+
+**Guardrails**
+- Do NOT create any artifacts (no proposal, specs, tasks)
+- Do NOT modify any code
+- Focus on investigation and analysis only
+- Present multiple options when possible
+- Be honest about unknowns and risks
+- If the user wants to proceed, guide them to /zhuanspec:propose`
+    };
+}
+/**
+ * Template for zhuanspec-verify skill
+ * For verifying implementation matches artifacts
+ */
+export function getVerifySkillTemplate() {
+    return {
+        name: 'zhuanspec-verify',
+        description: 'Verify that implementation matches ZhuanSpec change artifacts. Use when the user wants to check if code matches specs, validate implementation quality, or review before archiving.',
+        instructions: `Verify that implementation matches the change artifacts across three dimensions: completeness, correctness, and coherence.
+
+**Input**: Optionally specify a change name. If omitted, prompt for selection.
+
+**Steps**
+
+1. **Select change to verify**
+
+   If no change name provided:
+   - Run \`zhuanspec list --json\` to get available changes
+   - Use **AskUserQuestion tool** to let user select
+   - Prefer changes with completed tasks
+
+2. **Load change context**
+
+   Read all artifacts:
+   - \`proposal.md\` — understanding intent and scope
+   - \`specs/*/spec.md\` — requirements and scenarios
+   - \`design.md\` — technical decisions (if exists)
+   - \`tasks.md\` — implementation checklist
+
+3. **Check Completeness**
+
+   a. **Task completion**: Parse tasks.md, count checked vs unchecked
+   b. **Requirement coverage**: For each requirement in specs:
+      - Search codebase for implementation evidence
+      - Check if scenarios have corresponding test coverage
+   c. **Report**: List requirements with/without implementation evidence
+
+4. **Check Correctness**
+
+   a. **Spec intent match**: For each requirement:
+      - Read the requirement and its scenarios
+      - Find the implementation code
+      - Verify the implementation matches the spec intent
+   b. **Edge cases**: Check if scenarios' edge cases are handled
+   c. **Error handling**: Verify error states match spec definitions
+   d. **Report**: List any mismatches between spec and implementation
+
+5. **Check Coherence**
+
+   a. **Design alignment**: If design.md exists:
+      - Verify design decisions are reflected in code structure
+      - Check naming conventions match design.md
+      - Verify architectural patterns are followed
+   b. **Consistency**: Check code follows project conventions
+   c. **Report**: List inconsistencies
+
+6. **Generate verification report**
+
+**Output Format**
+
+\`\`\`
+## Verification: <change-name>
+
+### COMPLETENESS
+✓ All N tasks in tasks.md are checked
+✓ M/K requirements have implementation evidence
+⚠ Scenario "XXX" not covered by tests
+
+### CORRECTNESS
+✓ Implementation matches spec intent
+✓ Edge cases handled
+⚠ Error state "XXX" not matching spec
+
+### COHERENCE
+✓ Design decisions reflected in code
+✓ Naming conventions consistent
+⚠ Design mentions "XXX" but implementation uses "YYY"
+
+### SUMMARY
+─────────────────────────────
+Critical issues: N
+Warnings: N
+Ready to archive: Yes/No (with warnings)
+
+### Recommendations
+1. [Actionable suggestion]
+2. [Actionable suggestion]
+\`\`\`
+
+**Severity Levels**
+- **Critical**: Implementation contradicts spec or missing required behavior
+- **Warning**: Suboptimal but functional, or missing test coverage
+- **Suggestion**: Could be improved but acceptable
+
+**Guardrails**
+- Do NOT modify any code during verification
+- Report findings objectively
+- Verify won't block archive - only surfaces issues
+- If codebase is too large, focus on files related to the change
+- Use grep/search to find implementation evidence, don't guess`
+    };
+}
+/**
+ * Template for /opsx:propose slash command
+ */
+export function getOpsxProposeCommandTemplate() {
+    return {
+        name: 'OPSX: Propose',
+        description: 'Create a complete change proposal with all planning artifacts in one step',
+        category: 'Workflow',
+        tags: ['workflow', 'proposal', 'planning'],
+        content: `Create a complete change proposal in one step.
+
+**Input**: The argument after \`/opsx:propose\` is a change name (kebab-case) or a description of what the user wants to build.
+
+**Workflow**: This command combines the creation of a change directory with fast-forward artifact generation.
+
+**Steps**
+
+1. **Mandatory clarification checkpoint**
+
+   - Review \`zhuanspec/project.md\`, run \`zhuanspec list\` and \`zhuanspec list --specs\`
+   - Analyze user request for ambiguity (scope, tech choices, priorities, acceptance criteria)
+   - If any unclear aspects found, use **AskUserQuestion tool** with preset options to clarify
+   - Do NOT proceed until all ambiguities are resolved
+
+2. **Derive change name** from input (kebab-case, verb-first, unique)
+
+3. **Create change**: \`zhuanspec new change "<name>"\`
+
+4. **Generate all planning artifacts** in dependency order:
+   - For each artifact: \`zhuanspec instructions <id> --change "<name>" --json\`
+   - Read dependencies, create artifact, show progress
+   - Artifacts: proposal.md → specs/ → design.md (if needed) → tasks.md
+
+5. **Validate**: \`zhuanspec validate <name> --strict\`
+
+6. **Present** the complete proposal for review
+
+**Output**
+
+\`\`\`
+## Proposal Created: <change-name>
+
+✓ proposal.md
+✓ specs/
+✓ design.md (if applicable)
+✓ tasks.md
+
+Ready for implementation. Run \`/opsx:apply\` to begin.
+\`\`\`
+
+**Guardrails**
+- Complete clarification before creating files
+- Create all planning artifacts in one step
+- Do NOT implement code - only planning docs
+- Validate before presenting`
+    };
+}
+/**
+ * Template for /opsx:explore slash command
+ */
+export function getOpsxExploreCommandTemplate() {
+    return {
+        name: 'OPSX: Explore',
+        description: 'Think through ideas before committing to a change',
+        category: 'Workflow',
+        tags: ['workflow', 'exploration', 'planning'],
+        content: `Explore ideas, investigate problems, and clarify requirements before committing to a change.
+
+**Input**: The argument after \`/opsx:explore\` is a topic or question to investigate.
+
+**Steps**
+
+1. Understand what to explore (narrow scope if needed via AskUserQuestion)
+2. Investigate codebase: search code, review specs, check active changes
+3. Present structured findings: Current State, Options with pros/cons, Recommendation
+4. Guide next steps: offer to create proposal or continue exploring
+
+**Output**
+
+Structured analysis with options, recommendation, and estimated impact.
+No artifacts are created - this is the thinking phase before doing.
+
+**Guardrails**
+- Do NOT create artifacts or modify code
+- Present multiple options when possible
+- Be honest about unknowns
+- Guide to \`/opsx:propose\` when ready to proceed`
+    };
+}
+/**
+ * Template for /opsx:verify slash command
+ */
+export function getOpsxVerifyCommandTemplate() {
+    return {
+        name: 'OPSX: Verify',
+        description: 'Validate implementation matches change artifacts',
+        category: 'Workflow',
+        tags: ['workflow', 'verification', 'quality'],
+        content: `Verify implementation matches change artifacts across three dimensions.
+
+**Input**: Optionally specify \`--change <name>\` after \`/opsx:verify\`.
+
+**Steps**
+
+1. Select change to verify (prompt if not specified)
+2. Load all artifacts (proposal, specs, design, tasks)
+3. Check **Completeness**: tasks done, requirements implemented, scenarios covered
+4. Check **Correctness**: implementation matches spec intent, edge cases handled
+5. Check **Coherence**: design decisions reflected in code, patterns consistent
+6. Generate structured verification report
+
+**Output**
+
+Structured report with:
+- Completeness, Correctness, Coherence sections
+- Issues categorized as Critical/Warning/Suggestion
+- Summary with archive readiness
+- Actionable recommendations
+
+**Guardrails**
+- Do NOT modify code during verification
+- Report findings objectively
+- Won't block archive, only surfaces issues`
+    };
+}
+/**
+ * Template for /opsx:new slash command
+ */
+export function getOpsxNewCommandTemplate() {
+    return {
+        name: 'OPSX: New',
+        description: 'Start a new change using the experimental artifact workflow (OPSX)',
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `Start a new change using the experimental artifact-driven approach.
+
+**Input**: The argument after \`/opsx:new\` 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. **Select a workflow schema**
+
+   Run \`zhuanspec schemas --json\` to get available schemas with descriptions.
+
+   Use the **AskUserQuestion tool** to let the user choose a workflow:
+   - Present each schema with its description
+   - Mark \`spec-driven\` as "(default)" if it's available
+   - Example options: "spec-driven - proposal → specs → design → tasks (default)", "tdd - tests → implementation → docs"
+
+   If user doesn't have a preference, default to \`spec-driven\`.
+
+3. **Create the change directory**
+   \`\`\`bash
+   zhuanspec new change "<name>" --schema "<selected-schema>"
+   \`\`\`
+   This creates a scaffolded change at \`zhuanspec/changes/<name>/\` with the selected schema.
+
+4. **Show the artifact status**
+   \`\`\`bash
+   zhuanspec 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
+   zhuanspec instructions <first-artifact-id> --change "<name>"
+   \`\`\`
+   This outputs the template and context for creating the first artifact.
+
+6. **STOP and wait for user direction**
+
+**Output**
+
+After completing the steps, summarize:
+- Change name and location
+- Selected schema/workflow and its artifact sequence
+- Current status (0/N artifacts complete)
+- The template for the first artifact
+- Prompt: "Ready to create the first artifact? Run \`/opsx:continue\` or just describe what this change is about and I'll draft it."
+
+**Guardrails**
+- Do NOT create any artifacts yet - just show the instructions
+- Do NOT advance beyond showing the first artifact template
+- If the name is invalid (not kebab-case), ask for a valid name
+- If a change with that name already exists, suggest using \`/opsx:continue\` instead
+- Always pass --schema to preserve the user's workflow choice`
+    };
+}
+/**
+ * Template for /opsx:continue slash command
+ */
+export function getOpsxContinueCommandTemplate() {
+    return {
+        name: 'OPSX: Continue',
+        description: 'Continue working on a change - create the next artifact (Experimental)',
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `Continue working on a change by creating the next artifact.
+
+**Input**: Optionally specify \`--change <name>\` after \`/opsx:continue\`. If omitted, MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run \`zhuanspec 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
+   - Schema (from \`schema\` field if present, otherwise "spec-driven")
+   - Status (e.g., "0/5 tasks", "complete", "no tasks")
+   - How recently it was modified (from \`lastModified\` field)
+
+   Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to continue.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check current status**
+   \`\`\`bash
+   zhuanspec status --change "<name>" --json
+   \`\`\`
+   Parse the JSON to understand current state. The response includes:
+   - \`schemaName\`: The workflow schema being used (e.g., "spec-driven", "tdd")
+   - \`artifacts\`: Array of artifacts with their status ("done", "ready", "blocked")
+   - \`isComplete\`: Boolean indicating if all artifacts are complete
+
+3. **Act based on status**:
+
+   ---
+
+   **If all artifacts are complete (\`isComplete: true\`)**:
+   - Congratulate the user
+   - Show final status including the schema used
+   - Suggest: "All artifacts created! You can now implement this change or archive it."
+   - STOP
+
+   ---
+
+   **If artifacts are ready to create** (status shows artifacts with \`status: "ready"\`):
+   - Pick the FIRST artifact with \`status: "ready"\` from the status output
+   - Get its instructions:
+     \`\`\`bash
+     zhuanspec instructions <artifact-id> --change "<name>" --json
+     \`\`\`
+   - Parse the JSON to get template, dependencies, and what it unlocks
+   - **Create the artifact file** using the template as a starting point:
+     - Read any completed dependency files for context
+     - Fill in the template based on context and user's goals
+     - Write to the output path specified in instructions
+   - Show what was created and what's now unlocked
+   - STOP after creating ONE artifact
+
+   ---
+
+   **If no artifacts are ready (all blocked)**:
+   - This shouldn't happen with a valid schema
+   - Show status and suggest checking for issues
+
+4. **After creating an artifact, show progress**
+   \`\`\`bash
+   zhuanspec status --change "<name>"
+   \`\`\`
+
+**Output**
+
+After each invocation, show:
+- Which artifact was created
+- Schema workflow being used
+- Current progress (N/M complete)
+- What artifacts are now unlocked
+- Prompt: "Run \`/opsx:continue\` to create the next artifact"
+
+**Artifact Creation Guidelines**
+
+The artifact types and their purpose depend on the schema. Use the \`instruction\` field from the instructions output to understand what to create.
+
+Common artifact patterns:
+
+**spec-driven schema** (proposal → specs → design → tasks):
+- **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
+  - The Capabilities section is critical - each capability listed will need a spec file.
+- **specs/*.md**: Create one spec per capability listed in the proposal.
+- **design.md**: Document technical decisions, architecture, and implementation approach.
+- **tasks.md**: Break down implementation into checkboxed tasks.
+
+**tdd schema** (spec → tests → implementation → docs):
+- **spec.md**: Feature specification defining what to build.
+- **tests/*.test.ts**: Write tests BEFORE implementation (TDD red phase).
+- **src/*.ts**: Implement to make tests pass (TDD green phase).
+- **docs/*.md**: Document the implemented feature.
+
+For other schemas, follow the \`instruction\` field from the CLI output.
+
+**Guardrails**
+- Create ONE artifact per invocation
+- Always read dependency artifacts before creating a new one
+- Never skip artifacts or create out of order
+- If context is unclear, use **AskUserQuestion tool** with preset options to clarify before creating
+- Verify the artifact file exists after writing before marking progress
+- Use the schema's artifact sequence, don't assume specific artifact names`
+    };
+}
+/**
+ * Template for /opsx:apply slash command
+ */
+export function getOpsxApplyCommandTemplate() {
+    return {
+        name: 'OPSX: Apply',
+        description: 'Implement tasks from an ZhuanSpec change (Experimental)',
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `Implement tasks from an ZhuanSpec change.
+
+**Input**: Optionally specify \`--change <name>\` after \`/opsx:apply\`. If omitted, MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run \`zhuanspec list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that are implementation-ready (have tasks artifact).
+   Include the schema used for each change if available.
+   Mark changes with incomplete tasks as "(In Progress)".
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check status to understand the schema**
+   \`\`\`bash
+   zhuanspec status --change "<name>" --json
+   \`\`\`
+   Parse the JSON to understand:
+   - \`schemaName\`: The workflow being used (e.g., "spec-driven", "tdd")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   \`\`\`bash
+   zhuanspec instructions apply --change "<name>" --json
+   \`\`\`
+
+   This returns:
+   - Context file paths (varies by schema)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If \`state: "blocked"\` (missing artifacts): show message, suggest using \`/opsx:continue\`
+   - If \`state: "all_done"\`: proceed to code review step (see step 8)
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in \`contextFiles\` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - **tdd**: spec, tests, implementation, docs
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Parse the task text for \`@skill\` tags (format: \`@skill:name1,name2\`)
+   - If \`@skill\` tags found, invoke the corresponding skill(s) for guidance before making changes
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: \`- [ ]\` → \`- [x]\`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → use **AskUserQuestion tool** with preset options to clarify (never ask for free-text input)
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: proceed to code review step (step 8)
+   - If paused: explain why and wait for guidance
+
+8. **Code Review (when all tasks complete)**
+
+   **WHEN** all tasks are complete (\`state: "all_done"\`):
+   
+   a. **Prompt for code review**
+   
+      Use the **AskUserQuestion tool** with options:
+      - "是，进行代码审查" / "Yes, perform code review"
+      - "跳过，直接归档" / "Skip, proceed to archive"
+      
+      Wait for user selection before proceeding.
+   
+   b. **If user selects "Yes, perform code review"**:
+      
+      1. **Read code files related to the change**
+         - Based on context files from apply instructions
+         - Scan the change directory for code files (e.g., \`*.java\`, \`*.ts\`, \`*.py\`, etc.)
+         - Read all relevant code files that were modified or created for this change
+      
+      2. **Perform code review**
+         
+         Review code for:
+         - **Code standards and conventions compliance**: naming, formatting, structure
+         - **Logic correctness**: edge cases, error handling, business logic
+         - **Performance issues**: inefficient algorithms, unnecessary operations, potential bottlenecks
+         - **Security concerns**: input validation, authentication, authorization, data exposure
+         - **Best practices adherence**: design patterns, SOLID principles, maintainability
+         
+         **For Java code specifically**, pay special attention to:
+         - Java-specific patterns and conventions (e.g., builder pattern, factory pattern)
+         - Common Java pitfalls:
+           - Null handling (NullPointerException prevention)
+           - Exception handling (proper try-catch, resource management)
+           - Resource management (try-with-resources, closing streams/connections)
+         - Performance considerations:
+           - Collections usage (ArrayList vs LinkedList, HashMap vs TreeMap)
+           - Streams vs loops (when to use each)
+           - Concurrency (thread safety, synchronization)
+      
+      3. **Generate review report**
+         
+         Create a structured report listing:
+         - **Issues found** (if any):
+           - Severity (Critical, High, Medium, Low)
+           - Location (file path and line number)
+           - Description
+           - Suggestion for improvement
+         - **Suggestions for improvement** (even if no critical issues)
+         - **Positive findings** (good practices observed)
+      
+      4. **Handle review results**
+         
+         - **If issues are found**:
+           
+           Display the review report with all issues.
+           
+           Use **AskUserQuestion tool** with options:
+           - "是，现在修复" / "Yes, fix now"
+           - "稍后修复" / "Fix later"
+           - "跳过" / "Skip"
+           
+           - If user chooses "Yes, fix now": proceed with fixing the issues one by one
+           - If user chooses "Fix later" or "Skip": continue to archive workflow
+         
+         - **If no issues are found**:
+           
+           Display: "代码审查完成，未发现问题。" (or "Code review complete. No issues found.")
+           Proceed to suggest archive workflow.
+   
+   c. **If user selects "Skip, proceed to archive"**:
+      
+      Skip the code review step.
+      Proceed directly to suggesting archive workflow.
+      The workflow SHALL NOT be blocked.
+
+**Output During Implementation**
+
+\`\`\`
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+\`\`\`
+
+**Output On Completion**
+
+\`\`\`
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! Ready for code review or archive.
+\`\`\`
+
+**Output After Code Review (Issues Found)**
+
+\`\`\`
+## Code Review Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+
+### Issues Found
+
+**Critical:**
+- [File: path/to/file.java:42] Description of critical issue
+  - Suggestion: How to fix
+
+**High:**
+- [File: path/to/file.java:58] Description of high priority issue
+  - Suggestion: How to fix
+
+**Medium:**
+- [File: path/to/file.java:73] Description of medium priority issue
+  - Suggestion: How to fix
+
+### Positive Findings
+- Good use of try-with-resources for resource management
+- Clear variable naming conventions
+- Proper exception handling
+
+发现了一些问题。是否现在修复？
+\`\`\`
+
+**Output After Code Review (No Issues)**
+
+\`\`\`
+## Code Review Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+
+代码审查完成，未发现问题。
+
+Ready to archive this change.
+\`\`\`
+
+**Output On Pause (Issue Encountered)**
+
+\`\`\`
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+\`\`\`
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, use **AskUserQuestion tool** with preset options to clarify before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly`
+    };
+}
+/**
+ * Template for /opsx:ff slash command
+ */
+export function getOpsxFfCommandTemplate() {
+    return {
+        name: 'OPSX: Fast Forward',
+        description: 'Create a change and generate all artifacts needed for implementation in one go',
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `Fast-forward through artifact creation - generate everything needed to start implementation.
+
+**Input**: The argument after \`/opsx:ff\` 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
+   zhuanspec new change "<name>"
+   \`\`\`
+   This creates a scaffolded change at \`zhuanspec/changes/<name>/\`.
+
+3. **Get the artifact build order**
+   \`\`\`bash
+   zhuanspec 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
+        zhuanspec instructions <artifact-id> --change "<name>" --json
+        \`\`\`
+      - The instructions JSON includes:
+        - \`template\`: The template content to use
+        - \`instruction\`: Schema-specific guidance for this artifact type
+        - \`outputPath\`: Where to write the artifact
+        - \`dependencies\`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file following the schema's \`instruction\`
+      - Show brief progress: "✓ Created <artifact-id>"
+
+   b. **Continue until all \`applyRequires\` artifacts are complete**
+      - After creating each artifact, re-run \`zhuanspec 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** with preset options to clarify (never ask for free-text input)
+      - Then continue with creation
+
+5. **Show final status**
+   \`\`\`bash
+   zhuanspec 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 \`zhuanspec instructions\` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use the \`template\` as a starting point, filling in based on context
+
+**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, use **AskUserQuestion tool** with preset options to clarify - 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`
+    };
+}
+/**
+ * Template for zhuanspec-archive-change skill
+ * For archiving completed changes in the experimental workflow
+ */
+export function getArchiveChangeSkillTemplate() {
+    return {
+        name: 'zhuanspec-archive-change',
+        description: 'Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.',
+        instructions: `Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name. If omitted, MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run \`zhuanspec list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run \`zhuanspec status --change "<name>" --json\` to check artifact completion.
+
+   Parse the JSON to understand:
+   - \`schemaName\`: The workflow being used
+   - \`artifacts\`: List of artifacts with their status (\`done\` or other)
+
+   **If any artifacts are not \`done\`:**
+   - Display warning listing incomplete artifacts
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically \`tasks.md\`) to check for incomplete tasks.
+
+   Count tasks marked with \`- [ ]\` (incomplete) vs \`- [x]\` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Check if delta specs need syncing**
+
+   Check if \`specs/\` directory exists in the change with spec files.
+
+   **If delta specs exist, perform a quick sync check:**
+
+   a. **For each delta spec** at \`zhuanspec/changes/<name>/specs/<capability>/spec.md\`:
+      - Extract requirement names (lines matching \`### Requirement: <name>\`)
+      - Note which sections exist (ADDED, MODIFIED, REMOVED)
+
+   b. **Check corresponding main spec** at \`zhuanspec/specs/<capability>/spec.md\`:
+      - If main spec doesn't exist → needs sync
+      - If main spec exists, check if ADDED requirement names appear in it
+      - If any ADDED requirements are missing from main spec → needs sync
+
+   c. **Report findings:**
+
+      **If sync needed:**
+      \`\`\`
+      ⚠️ Delta specs may not be synced:
+      - specs/auth/spec.md → Main spec missing requirement "Token Refresh"
+      - specs/api/spec.md → Main spec doesn't exist yet
+
+      Would you like to sync now before archiving?
+      \`\`\`
+      - Use **AskUserQuestion tool** with options: "Sync now", "Archive without syncing"
+      - If user chooses sync, execute /opsx:sync logic (use the zhuanspec-sync-specs skill)
+
+      **If already synced (all requirements found):**
+      - Proceed without prompting (specs appear to be in sync)
+
+   **If no delta specs exist:** Proceed without sync-related checks.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   \`\`\`bash
+   mkdir -p zhuanspec/changes/archive
+   \`\`\`
+
+   Generate target name using current date: \`YYYY-MM-DD-<change-name>\`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   \`\`\`bash
+   mv zhuanspec/changes/<name> zhuanspec/changes/archive/YYYY-MM-DD-<name>
+   \`\`\`
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Whether specs were synced (if applicable)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+\`\`\`
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** zhuanspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs (or "No delta specs" or "⚠️ Not synced")
+
+All artifacts complete. All tasks complete.
+\`\`\`
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (zhuanspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .zhuanspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use zhuanspec-sync-specs approach (agent-driven)
+- Quick sync check: look for requirement names in delta specs, verify they exist in main specs`
+    };
+}
+/**
+ * Template for /opsx:sync slash command
+ */
+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.
+
+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 \`--change <name>\` after \`/opsx:sync\`. If omitted, MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run \`zhuanspec 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 \`zhuanspec/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 \`zhuanspec/changes/<name>/specs/<capability>/spec.md\`:
+
+   a. **Read the delta spec** to understand the intended changes
+
+   b. **Read the main spec** at \`zhuanspec/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 \`zhuanspec/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, use **AskUserQuestion tool** with preset options to clarify
+- Show what you're changing as you go
+- The operation should be idempotent - running twice should give same result`
+    };
+}
+/**
+ * Template for /opsx:archive slash command
+ */
+export function getOpsxArchiveCommandTemplate() {
+    return {
+        name: 'OPSX: Archive',
+        description: 'Archive a completed change in the experimental workflow',
+        category: 'Workflow',
+        tags: ['workflow', 'archive', 'experimental'],
+        content: `Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify \`--change <name>\` after \`/opsx:archive\`. If omitted, MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run \`zhuanspec list --json\` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run \`zhuanspec status --change "<name>" --json\` to check artifact completion.
+
+   Parse the JSON to understand:
+   - \`schemaName\`: The workflow being used
+   - \`artifacts\`: List of artifacts with their status (\`done\` or other)
+
+   **If any artifacts are not \`done\`:**
+   - Display warning listing incomplete artifacts
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically \`tasks.md\`) to check for incomplete tasks.
+
+   Count tasks marked with \`- [ ]\` (incomplete) vs \`- [x]\` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Check if delta specs need syncing**
+
+   Check if \`specs/\` directory exists in the change with spec files.
+
+   **If delta specs exist, perform a quick sync check:**
+
+   a. **For each delta spec** at \`zhuanspec/changes/<name>/specs/<capability>/spec.md\`:
+      - Extract requirement names (lines matching \`### Requirement: <name>\`)
+      - Note which sections exist (ADDED, MODIFIED, REMOVED)
+
+   b. **Check corresponding main spec** at \`zhuanspec/specs/<capability>/spec.md\`:
+      - If main spec doesn't exist → needs sync
+      - If main spec exists, check if ADDED requirement names appear in it
+      - If any ADDED requirements are missing from main spec → needs sync
+
+   c. **Report findings:**
+
+      **If sync needed:**
+      \`\`\`
+      ⚠️ Delta specs may not be synced:
+      - specs/auth/spec.md → Main spec missing requirement "Token Refresh"
+      - specs/api/spec.md → Main spec doesn't exist yet
+
+      Would you like to sync now before archiving?
+      \`\`\`
+      - Use **AskUserQuestion tool** with options: "Sync now", "Archive without syncing"
+      - If user chooses sync, execute \`/opsx:sync\` logic
+
+      **If already synced (all requirements found):**
+      - Proceed without prompting (specs appear to be in sync)
+
+   **If no delta specs exist:** Proceed without sync-related checks.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   \`\`\`bash
+   mkdir -p zhuanspec/changes/archive
+   \`\`\`
+
+   Generate target name using current date: \`YYYY-MM-DD-<change-name>\`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   \`\`\`bash
+   mv zhuanspec/changes/<name> zhuanspec/changes/archive/YYYY-MM-DD-<name>
+   \`\`\`
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Spec sync status (synced / not synced / no delta specs)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+\`\`\`
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** zhuanspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs
+
+All artifacts complete. All tasks complete.
+\`\`\`
+
+**Output On Success (No Delta Specs)**
+
+\`\`\`
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** zhuanspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** No delta specs
+
+All artifacts complete. All tasks complete.
+\`\`\`
+
+**Output On Success With Warnings**
+
+\`\`\`
+## Archive Complete (with warnings)
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** zhuanspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ⚠️ Not synced
+
+**Warnings:**
+- Archived with 2 incomplete artifacts
+- Archived with 3 incomplete tasks
+- Delta specs were not synced (user chose to skip)
+
+Review the archive if this was not intentional.
+\`\`\`
+
+**Output On Error (Archive Exists)**
+
+\`\`\`
+## Archive Failed
+
+**Change:** <change-name>
+**Target:** zhuanspec/changes/archive/YYYY-MM-DD-<name>/
+
+Target archive directory already exists.
+
+**Options:**
+1. Rename the existing archive
+2. Delete the existing archive if it's a duplicate
+3. Wait until a different date to archive
+\`\`\`
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (zhuanspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .zhuanspec.yaml when moving to archive (it moves with the directory)
+- Quick sync check: look for requirement names in delta specs, verify they exist in main specs
+- Show clear summary of what happened
+- If sync is requested, use /opsx:sync approach (agent-driven)`
+    };
+}
+//# sourceMappingURL=skill-templates.js.map