@fission-ai/openspec
Version:
AI-native system for spec-driven development
232 lines (184 loc) • 10.5 kB
JavaScript
export function getContinueChangeSkillTemplate() {
return {
name: 'openspec-continue-change',
description: 'Continue working on an OpenSpec 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, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
**Steps**
1. **If no change name provided, prompt for selection**
Run \`openspec list --json\` to get available changes 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
openspec status --change "<name>" --json
\`\`\`
Parse the JSON to understand current state. The response includes:
- \`schemaName\`: The workflow schema being used (e.g., "spec-driven")
- \`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
openspec instructions <artifact-id> --change "<name>" --json
\`\`\`
- Parse the JSON. The key fields are:
- \`context\`: Project background (constraints for you - do NOT include in output)
- \`rules\`: Artifact-specific rules (constraints for you - do NOT include in output)
- \`template\`: The structure to use for your output file
- \`instruction\`: Schema-specific guidance
- \`outputPath\`: Where to write the artifact
- \`dependencies\`: Completed artifacts to read for context
- **Create the artifact file**:
- Read any completed dependency files for context
- Use \`template\` as the structure - fill in its sections
- Apply \`context\` and \`rules\` as constraints when writing - but do NOT copy them into the file
- 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
openspec 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/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
- **design.md**: Document technical decisions, architecture, and implementation approach.
- **tasks.md**: Break down implementation into checkboxed tasks.
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, ask the user before creating
- Verify the artifact file exists after writing before marking progress
- Use the schema's artifact sequence, don't assume specific artifact names
- **IMPORTANT**: \`context\` and \`rules\` are constraints for YOU, not content for the file
- Do NOT copy \`<context>\`, \`<rules>\`, \`<project_context>\` blocks into the artifact
- These guide what you write, but should never appear in the output`,
license: 'MIT',
compatibility: 'Requires openspec CLI.',
metadata: { author: 'openspec', version: '1.0' },
};
}
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 a change name after \`/opsx:continue\` (e.g., \`/opsx:continue add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
**Steps**
1. **If no change name provided, prompt for selection**
Run \`openspec list --json\` to get available changes 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
openspec status --change "<name>" --json
\`\`\`
Parse the JSON to understand current state. The response includes:
- \`schemaName\`: The workflow schema being used (e.g., "spec-driven")
- \`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 with \`/opsx:apply\` or archive it with \`/opsx:archive\`."
- 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
openspec instructions <artifact-id> --change "<name>" --json
\`\`\`
- Parse the JSON. The key fields are:
- \`context\`: Project background (constraints for you - do NOT include in output)
- \`rules\`: Artifact-specific rules (constraints for you - do NOT include in output)
- \`template\`: The structure to use for your output file
- \`instruction\`: Schema-specific guidance
- \`outputPath\`: Where to write the artifact
- \`dependencies\`: Completed artifacts to read for context
- **Create the artifact file**:
- Read any completed dependency files for context
- Use \`template\` as the structure - fill in its sections
- Apply \`context\` and \`rules\` as constraints when writing - but do NOT copy them into the file
- 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
openspec 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/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
- **design.md**: Document technical decisions, architecture, and implementation approach.
- **tasks.md**: Break down implementation into checkboxed tasks.
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, ask the user before creating
- Verify the artifact file exists after writing before marking progress
- Use the schema's artifact sequence, don't assume specific artifact names
- **IMPORTANT**: \`context\` and \`rules\` are constraints for YOU, not content for the file
- Do NOT copy \`<context>\`, \`<rules>\`, \`<project_context>\` blocks into the artifact
- These guide what you write, but should never appear in the output`
};
}
//# sourceMappingURL=continue-change.js.map