Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 13 additions & 75 deletions .codex/skills/openspec-apply-change/SKILL.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
name: openspec-apply-change
description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
description: "Implement tasks from an OpenSpec change by reading task definitions, generating code changes, marking tasks complete, and tracking progress. Use when the user wants to start or resume implementation, work through spec tasks, check the task list, or apply the next pending change."
license: MIT
compatibility: Requires openspec CLI.
metadata:
Expand All @@ -9,9 +9,9 @@ metadata:
generatedBy: "1.2.0"
---

Implement tasks from an OpenSpec change.
Implement tasks from an OpenSpec change β€” read task definitions, generate focused code changes, update task status, and report progress.

**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.
**Input**: Optionally specify a change name (e.g., `apply add-auth`). If omitted, infer from conversation context. If vague or ambiguous, MUST prompt for available changes.

**Steps**

Expand All @@ -38,23 +38,16 @@ Implement tasks from an OpenSpec change.
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
This returns context file paths, progress (total/complete/remaining), task list with status, and a dynamic instruction.

**Handle states:**
- If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
- If `state: "all_done"`: congratulate, suggest archive
- `state: "blocked"` (missing artifacts): show message, suggest openspec-continue-change
- `state: "all_done"`: congratulate, suggest archive
- Otherwise: proceed to implementation

4. **Read context files**

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
Read all files listed in `contextFiles` from the apply instructions output. File sets vary by schema (e.g., spec-driven uses proposal/specs/design/tasks).

5. **Show current progress**

Expand Down Expand Up @@ -87,70 +80,15 @@ Implement tasks from an OpenSpec change.
- 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! Ready to archive this change.
```

**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?
```
**Output format**: Always show `## Implementing: <change-name> (schema: <schema-name>)` as a header, then for each task: `Working on task N/M: <description>` followed by `βœ“ Task complete`. On completion, show final progress (`N/N tasks complete βœ“`) and suggest archiving. On pause, show the issue encountered with numbered options for the user.

**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
- Always read context files (from apply instructions output) before starting β€” use `contextFiles` from CLI output, don't assume file names
- 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
- Update task checkbox (`- [ ]` β†’ `- [x]`) immediately after completing each task
- Pause and ask before proceeding when: task is ambiguous, implementation reveals a design issue (suggest artifact updates), error or blocker encountered, or user interrupts β€” never guess
- Keep going through tasks until done or blocked

**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
This skill can be invoked anytime β€” before all artifacts are done (if tasks exist), after partial implementation, or interleaved with other actions. If implementation reveals design issues, suggest updating artifacts rather than blocking.
88 changes: 13 additions & 75 deletions .github/skills/openspec-apply-change/SKILL.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
name: openspec-apply-change
description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
description: "Implement tasks from an OpenSpec change by reading task definitions, generating code changes, marking tasks complete, and tracking progress. Use when the user wants to start or resume implementation, work through spec tasks, check the task list, or apply the next pending change."
license: MIT
compatibility: Requires openspec CLI.
metadata:
Expand All @@ -9,9 +9,9 @@ metadata:
generatedBy: "1.2.0"
---

Implement tasks from an OpenSpec change.
Implement tasks from an OpenSpec change β€” read task definitions, generate focused code changes, update task status, and report progress.

**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.
**Input**: Optionally specify a change name (e.g., `apply add-auth`). If omitted, infer from conversation context. If vague or ambiguous, MUST prompt for available changes.

**Steps**

Expand All @@ -38,23 +38,16 @@ Implement tasks from an OpenSpec change.
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
This returns context file paths, progress (total/complete/remaining), task list with status, and a dynamic instruction.

**Handle states:**
- If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
- If `state: "all_done"`: congratulate, suggest archive
- `state: "blocked"` (missing artifacts): show message, suggest openspec-continue-change
- `state: "all_done"`: congratulate, suggest archive
- Otherwise: proceed to implementation

4. **Read context files**

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
Read all files listed in `contextFiles` from the apply instructions output. File sets vary by schema (e.g., spec-driven uses proposal/specs/design/tasks).

5. **Show current progress**

Expand Down Expand Up @@ -87,70 +80,15 @@ Implement tasks from an OpenSpec change.
- 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! Ready to archive this change.
```

**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?
```
**Output format**: Always show `## Implementing: <change-name> (schema: <schema-name>)` as a header, then for each task: `Working on task N/M: <description>` followed by `βœ“ Task complete`. On completion, show final progress (`N/N tasks complete βœ“`) and suggest archiving. On pause, show the issue encountered with numbered options for the user.

**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
- Always read context files (from apply instructions output) before starting β€” use `contextFiles` from CLI output, don't assume file names
- 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
- Update task checkbox (`- [ ]` β†’ `- [x]`) immediately after completing each task
- Pause and ask before proceeding when: task is ambiguous, implementation reveals a design issue (suggest artifact updates), error or blocker encountered, or user interrupts β€” never guess
- Keep going through tasks until done or blocked

**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
This skill can be invoked anytime β€” before all artifacts are done (if tasks exist), after partial implementation, or interleaved with other actions. If implementation reveals design issues, suggest updating artifacts rather than blocking.