Menu
Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.
Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/DanSnow/skill-manager --skill spectra-proposeLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Basé sur la classification professionnelle SOC
Affichage de SKILL.md
| name | spectra-propose |
| description | Create a change proposal with all required artifacts |
| license | MIT |
| compatibility | Requires spectra CLI. |
| metadata | {"author":"spectra","version":"1.0","generatedBy":"Spectra"} |
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 performanceIf 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
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:
~/.claude/plans/<name>.md)~/.claude/plans/plan_title (H1 heading) → use as requirement descriptionplan_context (Context section) → use as proposal Why/Motivation contentplan_stages (numbered implementation stages) → use for artifact creationplan_files (all file paths mentioned) → use for Impact sectionc. Conversation context → attempt to extract requirements from conversation history
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.
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.
Scan existing specs for relevance
Before creating the change, check if any existing specs overlap:
openspec/specs/*/spec.mdIMPORTANT:
Create the change directory
spectra new change "<name>" --agent claude
If a change with that name already exists, suggest continuing the existing change instead of creating a new one.
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:
## Why
<!-- Why this functionality is needed -->
## What Changes
<!-- What will be different -->
## Capabilities
### New Capabilities
- `<capability-name>`: <brief description>
### Modified Capabilities
(none)
## Impact
- Affected specs: <new or modified capabilities>
- Affected code: <list of affected files>
## Problem
<!-- Current broken behavior -->
## Root Cause
<!-- Why it happens -->
## Proposed Solution
<!-- How to fix -->
## Success Criteria
<!-- Expected behavior after fix, verifiable conditions -->
## Impact
- Affected code: <list of affected files>
## Summary
<!-- One sentence description -->
## Motivation
<!-- Why this is needed -->
## Proposed Solution
<!-- How to do it -->
## Alternatives Considered (optional)
<!-- Other approaches considered and why not -->
## Impact
- Affected specs: <affected capabilities>
- Affected code: <list of affected files>
Get the artifact build order
spectra status --change "<name>" --json
Parse the JSON to get:
applyRequires: array of artifact IDs needed before implementationartifacts: list of all artifacts with their status and dependenciesCreate remaining artifacts in sequence
Loop through artifacts in dependency order (skip proposal since it's already done):
a. For each artifact that is ready (dependencies satisfied):
spectra instructions <artifact-id> --change "<name>" --json
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 fileinstruction: Schema-specific guidanceoutputPath: Where to write the artifactdependencies: Completed artifacts to read for contextlocale: The language to write the artifact in (e.g., "Japanese (日本語)"). If present, you MUST write the artifact content in this language. Exception: spec files (specs/*/.md) MUST always be written in English regardless of locale, because they use normative language (SHALL/MUST).template as the structurecontext and rules as constraints - but do NOT copy them into the fileb. Continue until all applyRequires artifacts are complete
spectra status --change "<name>" --jsonapplyRequires has status: "done"applyRequires artifacts are donec. If an artifact requires user input (unclear context):
Analyze-Fix Loop (max 2 iterations)
spectra analyze <change-name> --jsonspectra analyze <change-name> --json
d. Repeat up to 2 total iterationsValidation
spectra validate "<name>"
If validation fails, fix errors and re-validate.
Show final status and end workflow
Show summary:
Use AskUserQuestion tool to ask what to do next. This ensures the workflow stops even when auto-accept is enabled. Provide exactly these options:
spectra park "<name>" to park the change, then inform the user they can run /spectra-apply <change-name> when ready (which will auto-unpark)./spectra-apply <change-name> to start implementation.If AskUserQuestion tool is not available, execute spectra park "<name>" and inform the user to run /spectra-apply <change-name> when ready. Then STOP — do not continue.
After the user responds, if they chose "Park", execute spectra park "<name>" and the workflow is OVER. If they chose "Apply", invoke /spectra-apply <change-name> to begin implementation.
Artifact Creation Guidelines
instruction field from spectra instructions for each artifact typetemplate as the structure for your output file - fill in its sectionscontext and rules are constraints for YOU, not content for the file
<context>, <rules>, <project_context> blocks into the artifact[P]): When creating the tasks artifact, first read openspec/config.yaml. If parallel_tasks: true is set, add [P] markers to tasks that can be executed in parallel. Format: - [ ] [P] Task description. A task qualifies for [P] if it targets different files from other pending tasks AND has no dependency on incomplete tasks in the same group. When parallel_tasks is not enabled, do NOT add [P] markers.Guardrails
/spectra-apply — this workflow ends after artifact creation. The user decides when to start implementation