che-ical-mcp: Skill for Claude Code

Create a complete Spectra change proposal — from requirement to validated artifacts — in a single workflow.

Input: The argument after $spectra-propose is the requirement description. Examples:

• $spectra-propose add dark mode
• $spectra-propose fix the login page crash
• $spectra-propose improve search performance

If no argument is provided, the workflow will extract requirements from conversation context or ask.

Prerequisites: This skill requires the spectra CLI. If any spectra command fails with "command not found" or similar, report the error and STOP.

Steps

1. Determine the requirement source

   a. Argument provided (e.g., "add dark mode") → use it as the requirement description, skip to deriving the change name below.

   b. Plan file available:

   • Check if the conversation context mentions a plan file path (plan mode system messages include the path like <name>.md)
   • If found, check if the file exists at ``
   • If a plan file is found, use the AskUserQuestion tool to ask:
     • Option 1: Use the plan file
     • Option 2: Use conversation context
   • If conversation context has no relevant discussion, mention this when presenting the choice
   • If the user picks the plan file → read it and extract:
     • plan_title (H1 heading) → use as requirement description
     • plan_context (Context section) → use as proposal Why/Motivation content
     • plan_stages (numbered implementation stages) → use for artifact creation
     • plan_files (all file paths mentioned) → use for Impact section
   • If the user picks conversation context → fall through to (c)

   c. Conversation context → attempt to extract requirements from conversation history

   • If context is insufficient, use the AskUserQuestion tool to ask what they want to build

   From the resolved description, derive a kebab-case change name (e.g., "add dark mode" → add-dark-mode).

   IMPORTANT: Do NOT proceed without understanding what the user wants to build.

2. Classify the change type

   Based on the requirement, classify the change into one of three types:

   Type	When to use
   Feature	New functionality, new capabilities
   Bug Fix	Fixing existing behavior, resolving errors
   Refactor	Architecture improvements, performance optimization, UI adjustments

   This determines the proposal template format in step 5.

3. Scan existing specs for relevance

   Before creating the change, check if any existing specs overlap:

   1. Use the Glob tool to list all files matching openspec/specs/*/spec.md
   2. Extract directory names as the spec identifier list
   3. Compare against the user's description to identify related specs (max 5 candidates)
   4. For each candidate (max 3), read the first 10 lines to retrieve the Purpose section
   5. If related specs are found, display them as an informational summary

   IMPORTANT:

   • If related specs are found, display them but do NOT stop or ask for confirmation — continue to the next step
   • If no related specs are found, silently proceed without mentioning the scan

4. Create the change directory

   spectra new change "<name>" --agent codex
   

   If a change with that name already exists, suggest continuing the existing change instead of creating a new one.

5. Write the proposal

   Get instructions:

   spectra instructions proposal --change "<name>" --json
   

   Write the proposal file using the template from instructions, with the following format based on change type:

   Feature

   ## Why
   
   <!-- Why this functionality is needed -->
   
   ## What Changes
   
   <!-- What will be different -->
   
   ## Non-Goals (optional)
   
   <!-- Scope exclusions and rejected approaches. Required when design.md is skipped. -->
   
   ## Capabilities
   
   ### New Capabilities
   
   - `<capability-name>`: <brief description>
   
   ### Modified Capabilities
   
   (none)
   
   ## Impact
   
   - Affected specs: <new or modified capabilities>
   - Affected code: <list of affected files>