You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update the OPSX application and proposal documentation, optimize the task implementation process, and emphasize the principles of stepwise verification and minimum self-consistent batches.
Copy file name to clipboardExpand all lines: .roo/commands/opsx-apply.md
+29-17Lines changed: 29 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -80,27 +80,40 @@ Implement tasks from an OpenSpec change.
80
80
- Remaining tasks overview
81
81
- Dynamic instruction from CLI
82
82
83
-
6.**Implement tasks (loop until done or blocked)**
83
+
6.**Implement exactly one rolling batch, then stop at a feedback gate**
84
84
85
-
For each pending task:
86
-
- Show which task is being worked on
87
-
- Make the code changes required
88
-
- Keep changes minimal and focused
89
-
- Mark task complete in the tasks file: `- [ ]` → `- [x]`
90
-
- Continue to next task
85
+
A batch is the smallest coherent change that can be reviewed, reverted, and validated independently. It is normally one pending implementation task, but split an oversized task in the tasks artifact before coding when it contains independently verifiable changes.
86
+
87
+
Before changing code:
88
+
- First reconcile any CI/device result supplied for the earliest unresolved validation gate
89
+
- If that result failed, select only the minimal repair for the current batch; do not advance to later implementation tasks
90
+
- Otherwise select the first pending implementation, repair, or validation task
91
+
- If the selected task is an external CI/device validation gate and no result is available, do not guess or edit code; stop and report the validation handoff
92
+
93
+
For the selected batch only:
94
+
- Show which batch is being worked on
95
+
- Make only the code, spec, and task-artifact changes required for that batch
96
+
- Run only locally available checks permitted by project context
97
+
- Mark an implementation task complete only when its specified implementation behavior is complete
98
+
- Mark a CI/device validation task complete only from actual reported evidence, never from local inference
99
+
- Stop after this batch or validation gate even if later tasks are clear; never begin a second code batch in the same invocation
91
100
92
101
**Pause if:**
93
102
- Task is unclear → ask for clarification
94
103
- Implementation reveals a design issue → suggest updating artifacts
95
104
- A task needs work beyond what the spec and tasks describe, or you are tempted to drop, narrow, defer, or accept exceptions to specified behavior to make it fit → surface the added scope and ask; do not absorb it silently
96
105
- Error or blocker encountered → report and wait for guidance
106
+
- The batch is ready for CI/device feedback → report the handoff and stop
97
107
- User interrupts
98
108
99
-
7.**On completion or pause, show status**
109
+
7.**On batch completion or pause, show status**
100
110
101
111
Display:
102
-
-Tasks completed this session
112
+
-The single batch handled this session
103
113
- Overall progress: "N/M tasks complete"
114
+
- Files changed and local checks actually run
115
+
- The exact next CI/device validation, expected result, and minimum evidence to return
116
+
- Whether later implementation is gated on that evidence
104
117
- If all done: suggest archive
105
118
- If paused: explain why and wait for guidance
106
119
@@ -109,13 +122,10 @@ Implement tasks from an OpenSpec change.
- Process exactly one smallest coherent implementation/repair batch per invocation, then stop for feedback
170
+
- Never accumulate a second code batch while the current batch lacks its required CI/device result
171
+
- On failed CI/device feedback, repair only the current batch before progressing
160
172
- Always read context files before starting (from the apply instructions output)
161
173
- If task is ambiguous, pause and ask before implementing
162
174
- If implementation reveals issues, pause and suggest artifact updates
163
175
- Keep code changes minimal and scoped to each task
164
-
- Update task checkbox immediately after completing each task
176
+
- Update an implementation checkbox immediately after its behavior is complete, but keep external validation checkboxes open until actual evidence is reported
165
177
- Pause on errors, blockers, or unclear requirements - don't guess
166
178
- When a task needs work beyond what the spec describes, surface the added scope and pause - never silently narrow, defer, or simplify away specified behavior
167
179
- Only mark a task `- [x]` when its specified behavior is fully implemented, not when it is partially done or deferred
Copy file name to clipboardExpand all lines: .roo/commands/opsx-propose.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -128,6 +128,9 @@ After completing all artifacts, summarize:
128
128
- The schema defines what each artifact should contain - follow it
129
129
- Read dependency artifacts for context before creating new ones
130
130
- Use `template` as the structure for your output file - fill in its sections
131
+
- For task artifacts, prefer a thin rolling sequence: one independently verifiable implementation batch, its immediate CI/device feedback gate, then the next batch
132
+
- Do not defer all CI/device validation to the end. Each gate must identify the applicable workflow/job or device scenario, expected result, and minimum evidence needed before later code work proceeds
133
+
- If a proposed task contains multiple independently verifiable behavior changes, split it before implementation rather than relying on the apply phase to hold the entire change in context
131
134
- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
132
135
- Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
133
136
- These guide what you write, but should never appear in the output
Copy file name to clipboardExpand all lines: .roo/skills/openspec-apply-change/SKILL.md
+29-17Lines changed: 29 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -88,27 +88,40 @@ Implement tasks from an OpenSpec change.
88
88
- Remaining tasks overview
89
89
- Dynamic instruction from CLI
90
90
91
-
6.**Implement tasks (loop until done or blocked)**
91
+
6.**Implement exactly one rolling batch, then stop at a feedback gate**
92
92
93
-
For each pending task:
94
-
- Show which task is being worked on
95
-
- Make the code changes required
96
-
- Keep changes minimal and focused
97
-
- Mark task complete in the tasks file: `- [ ]` → `- [x]`
98
-
- Continue to next task
93
+
A batch is the smallest coherent change that can be reviewed, reverted, and validated independently. It is normally one pending implementation task, but split an oversized task in the tasks artifact before coding when it contains independently verifiable changes.
94
+
95
+
Before changing code:
96
+
- First reconcile any CI/device result supplied for the earliest unresolved validation gate
97
+
- If that result failed, select only the minimal repair for the current batch; do not advance to later implementation tasks
98
+
- Otherwise select the first pending implementation, repair, or validation task
99
+
- If the selected task is an external CI/device validation gate and no result is available, do not guess or edit code; stop and report the validation handoff
100
+
101
+
For the selected batch only:
102
+
- Show which batch is being worked on
103
+
- Make only the code, spec, and task-artifact changes required for that batch
104
+
- Run only locally available checks permitted by project context
105
+
- Mark an implementation task complete only when its specified implementation behavior is complete
106
+
- Mark a CI/device validation task complete only from actual reported evidence, never from local inference
107
+
- Stop after this batch or validation gate even if later tasks are clear; never begin a second code batch in the same invocation
99
108
100
109
**Pause if:**
101
110
- Task is unclear → ask for clarification
102
111
- Implementation reveals a design issue → suggest updating artifacts
103
112
- A task needs work beyond what the spec and tasks describe, or you are tempted to drop, narrow, defer, or accept exceptions to specified behavior to make it fit → surface the added scope and ask; do not absorb it silently
104
113
- Error or blocker encountered → report and wait for guidance
114
+
- The batch is ready for CI/device feedback → report the handoff and stop
105
115
- User interrupts
106
116
107
-
7.**On completion or pause, show status**
117
+
7.**On batch completion or pause, show status**
108
118
109
119
Display:
110
-
-Tasks completed this session
120
+
-The single batch handled this session
111
121
- Overall progress: "N/M tasks complete"
122
+
- Files changed and local checks actually run
123
+
- The exact next CI/device validation, expected result, and minimum evidence to return
124
+
- Whether later implementation is gated on that evidence
112
125
- If all done: suggest archive
113
126
- If paused: explain why and wait for guidance
114
127
@@ -117,13 +130,10 @@ Implement tasks from an OpenSpec change.
- Process exactly one smallest coherent implementation/repair batch per invocation, then stop for feedback
178
+
- Never accumulate a second code batch while the current batch lacks its required CI/device result
179
+
- On failed CI/device feedback, repair only the current batch before progressing
168
180
- Always read context files before starting (from the apply instructions output)
169
181
- If task is ambiguous, pause and ask before implementing
170
182
- If implementation reveals issues, pause and suggest artifact updates
171
183
- Keep code changes minimal and scoped to each task
172
-
- Update task checkbox immediately after completing each task
184
+
- Update an implementation checkbox immediately after its behavior is complete, but keep external validation checkboxes open until actual evidence is reported
173
185
- Pause on errors, blockers, or unclear requirements - don't guess
174
186
- When a task needs work beyond what the spec describes, surface the added scope and pause - never silently narrow, defer, or simplify away specified behavior
175
187
- Only mark a task `- [x]` when its specified behavior is fully implemented, not when it is partially done or deferred
Copy file name to clipboardExpand all lines: .roo/skills/openspec-propose/SKILL.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -136,6 +136,9 @@ After completing all artifacts, summarize:
136
136
- The schema defines what each artifact should contain - follow it
137
137
- Read dependency artifacts for context before creating new ones
138
138
- Use `template` as the structure for your output file - fill in its sections
139
+
- For task artifacts, prefer a thin rolling sequence: one independently verifiable implementation batch, its immediate CI/device feedback gate, then the next batch
140
+
- Do not defer all CI/device validation to the end. Each gate must identify the applicable workflow/job or device scenario, expected result, and minimum evidence needed before later code work proceeds
141
+
- If a proposed task contains multiple independently verifiable behavior changes, split it before implementation rather than relying on the apply phase to hold the entire change in context
139
142
- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
140
143
- Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
141
144
- These guide what you write, but should never appear in the output
0 commit comments