cc-switch-web: Skill for Claude Code

Implement tasks from an OpenSpec change.

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. Select the change

   If a name is provided, use it. Otherwise:

   • Infer from conversation context if the user mentioned a change
   • Auto-select if only one active change exists
   • If ambiguous, run openspec list --json to get available changes and use the AskUserQuestion tool to let the user select

   Always announce: "Using change: " and how to override (e.g., /opsx:apply <other>).

2. Check status to understand the schema

   openspec status --change "<name>" --json
   

   Parse the JSON to understand:

   • schemaName: The workflow being used (e.g., "spec-driven")
   • Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)

3. Get apply instructions

   openspec 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 openspec-continue-change
   • If state: "needs_verify": skip back to Phase 1 and run canonical verification
   • If state: "needs_seal": skip implementation and continue with Phase 2/3
   • If state: "all_done": congratulate, suggest archive
   • Otherwise: proceed to implementation

4. Read context files

   Before reading other context files, check whether openspec/project.opsx.yaml exists.

• If it exists, read it first for domains → capabilities structure

• Check openspec/project.opsx.code-map.yaml for code location references

• Check openspec/specs/ for behavior documentation

• Treat it as navigation context, not as a replacement for change artifacts

  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
  • Other schemas: follow the contextFiles from CLI output
  • Build path.join(changeDir, '.verify-result.json') and check whether the previous verify result exists
  • Read .verify-result.json defensively: newer results may include an optimization object in addition to result, issues, and verificationContext
  • If the file exists and result === 'FAIL_NEEDS_REMEDIATION':
    • Read the persisted issues array
    • Keep only CRITICAL issues as mandatory remediation context
  • If optimization.status is DEGRADED or ABORTED_UNSAFE, treat it as advisory context only; do NOT let it override the canonical Phase 1 remediation signal
  • If tasks.md contains a ## Remediation section:
    • Parse each checkbox item
    • Track whether the item is tagged [code_fix] or [artifact_fix]
    • Treat unchecked remediation items as priority work

Document Language Contract:

• Treat openspec/config.yaml as the compact source of truth, but consume its compiled prompt projection rather than reinterpreting raw keys ad hoc
• If the compiled projection includes docLanguage, apply it only to natural-language prose you write in the artifact body
• Follow the existing template structure exactly; do not invent a different layout because the prose language changes
• Keep template headings, IDs, schema keys, relation types, BDD keywords, file paths, commands, and code identifiers in their canonical form
• If no docLanguage projection is present, keep the default writing behavior for prose

1. Show current progress

   Display:

   • Schema being used
   • Progress: "N/M tasks complete"
   • Remaining tasks overview
   • Summary of prior CRITICAL verify issues when .verify-result.json reports FAIL_NEEDS_REMEDIATION
   • Summary of open remediation items grouped by [code_fix] and [artifact_fix]
   • Dynamic instruction from CLI