164 lines
5.5 KiB
Markdown
164 lines
5.5 KiB
Markdown
---
|
||
name: "OPSX: Apply"
|
||
description: Implement tasks from an OpenSpec change (Experimental)
|
||
category: Workflow
|
||
tags: [workflow, artifacts, experimental]
|
||
---
|
||
|
||
Implement tasks from an OpenSpec change.
|
||
|
||
**Input**: Optionally specify a change name (e.g., `/opsx:apply 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. **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: <name>" and how to override (e.g., `/opsx:apply <other>`).
|
||
|
||
2. **Check status to understand the schema**
|
||
```bash
|
||
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**
|
||
|
||
```bash
|
||
openspec instructions apply --change "<name>" --json
|
||
```
|
||
|
||
This returns:
|
||
- `contextFiles`: artifact ID -> array of concrete 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"`: congratulate, suggest archive
|
||
- Otherwise: proceed to implementation
|
||
|
||
4. **Read context files**
|
||
|
||
Read every file path listed under `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
|
||
|
||
<!-- CFDive 自訂區塊：由 `openspec update` 重新產生時會被覆蓋，更新後需重新加回（見 docs/analysis/2026-10-14-project-prompt-improvements.md S1） -->
|
||
4b. **測試對應檢查（實作前必做，CLAUDE.md 規定）**
|
||
|
||
依 spec 與 tasks 檢查：
|
||
- 列出每一個 `#### Scenario`（即 Acceptance Criteria），對應到 tasks.md 中至少一個 `[整合測試]` 或單元測試 task
|
||
- 若有 Scenario 沒有對應測試 task：**停止實作**，列出缺漏清單，詢問使用者是否補上 tasks，不可自行略過
|
||
- 若涉及權限行為，確認有跨角色（member / provider / admin / 未登入）的測試 task
|
||
- 若 design.md 觸及安全觸發條件（外部輸入、資料庫讀寫、身份驗證/授權、檔案上傳、外部 API）但缺「安全確認」段落，同樣停止並回報
|
||
|
||
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
|
||
- 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 → ask for clarification
|
||
- 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: suggest archive
|
||
- If paused: explain why and wait for guidance
|
||
|
||
**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! You can archive this change with `/opsx:archive`.
|
||
```
|
||
|
||
**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, pause and ask 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
|
||
- (CFDive) Never start implementing while any Scenario lacks a corresponding test task; see step 4b
|
||
- (CFDive) When all tasks are done, run the `verify-and-report` skill before suggesting archive
|
||
|
||
**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
|