synarcx 0.2.0 → 0.2.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +233 -39
- package/dist/commands/config.js +7 -6
- package/dist/core/command-generation/adapters/bob.js +7 -20
- package/dist/core/command-generation/adapters/claude.js +9 -29
- package/dist/core/command-generation/adapters/cursor.js +9 -22
- package/dist/core/command-generation/adapters/pi.js +6 -19
- package/dist/core/command-generation/adapters/windsurf.js +9 -29
- package/dist/core/command-generation/yaml-utils.d.ts +3 -0
- package/dist/core/command-generation/yaml-utils.js +12 -0
- package/dist/core/completions/installers/bash-installer.d.ts +1 -0
- package/dist/core/completions/installers/bash-installer.js +14 -3
- package/dist/core/completions/installers/powershell-installer.d.ts +1 -0
- package/dist/core/completions/installers/powershell-installer.js +18 -10
- package/dist/core/config.js +0 -3
- package/dist/core/index.js +1 -1
- package/dist/core/init.d.ts +0 -2
- package/dist/core/init.js +27 -77
- package/dist/core/migration.js +1 -2
- package/dist/core/profile-sync-drift.d.ts +0 -7
- package/dist/core/profile-sync-drift.js +2 -17
- package/dist/core/profiles.d.ts +0 -11
- package/dist/core/profiles.js +1 -20
- package/dist/core/shared/artifact-cleanup.d.ts +5 -0
- package/dist/core/shared/artifact-cleanup.js +89 -0
- package/dist/core/shared/tool-detection.d.ts +4 -10
- package/dist/core/shared/tool-detection.js +3 -31
- package/dist/core/shared/workflow-registry.d.ts +40 -0
- package/dist/core/shared/workflow-registry.js +19 -0
- package/dist/core/templates/types.d.ts +7 -0
- package/dist/core/templates/types.js +9 -1
- package/dist/core/templates/workflows/analyze.js +84 -84
- package/dist/core/templates/workflows/apply-change.js +291 -291
- package/dist/core/templates/workflows/archive-change.js +254 -254
- package/dist/core/templates/workflows/clarify.js +91 -91
- package/dist/core/templates/workflows/debug.js +100 -100
- package/dist/core/templates/workflows/explore.js +462 -462
- package/dist/core/templates/workflows/propose.js +199 -199
- package/dist/core/templates/workflows/quick.js +112 -112
- package/dist/core/templates/workflows/refactor.js +109 -109
- package/dist/core/templates/workflows/sync.js +148 -148
- package/dist/core/update.d.ts +1 -21
- package/dist/core/update.js +18 -117
- package/dist/core/view.js +8 -8
- package/dist/core/workspace/open-surface.d.ts +2 -2
- package/dist/core/workspace/open-surface.js +13 -13
- package/package.json +84 -76
|
@@ -1,151 +1,152 @@
|
|
|
1
|
+
import { commandFromSkill } from '../types.js';
|
|
1
2
|
export function getSynApplySkillTemplate() {
|
|
2
3
|
return {
|
|
3
4
|
name: 'syn-apply',
|
|
4
5
|
description: 'Implement tasks from a synarcx change. Use when the user wants to start implementing, continue implementation, or work through tasks.',
|
|
5
|
-
instructions: `Implement tasks from a synarcx change.
|
|
6
|
-
|
|
7
|
-
**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.
|
|
8
|
-
|
|
9
|
-
**Steps**
|
|
10
|
-
|
|
11
|
-
1. **Select the change**
|
|
12
|
-
|
|
13
|
-
If a name is provided, use it. Otherwise:
|
|
14
|
-
- Infer from conversation context if the user mentioned a change
|
|
15
|
-
- Auto-select if only one active change exists
|
|
16
|
-
- If ambiguous, run \`synarcx list --json\` to get available changes and use the **AskUserQuestion tool** to let the user select
|
|
17
|
-
|
|
18
|
-
Always announce: "Using change: <name>" and how to override (e.g., \`/syn:apply <other>\`).
|
|
19
|
-
|
|
20
|
-
2. **Check status to understand the schema**
|
|
21
|
-
\`\`\`bash
|
|
22
|
-
synarcx status --change "<name>" --json
|
|
23
|
-
\`\`\`
|
|
24
|
-
Parse the JSON to understand:
|
|
25
|
-
- \`schemaName\`: The workflow being used (e.g., "synarcx")
|
|
26
|
-
- Which artifact contains the tasks (typically "tasks" for synarcx, check status for others)
|
|
27
|
-
|
|
28
|
-
3. **Get apply instructions**
|
|
29
|
-
|
|
30
|
-
\`\`\`bash
|
|
31
|
-
synarcx instructions apply --change "<name>" --json
|
|
32
|
-
\`\`\`
|
|
33
|
-
|
|
34
|
-
This returns:
|
|
35
|
-
- \`contextFiles\`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
|
|
36
|
-
- Progress (total, complete, remaining)
|
|
37
|
-
- Task list with status
|
|
38
|
-
- Dynamic instruction based on current state
|
|
39
|
-
|
|
40
|
-
**Handle states:**
|
|
41
|
-
- If \`state: "blocked"\` (missing artifacts): show message, suggest using syn:apply
|
|
42
|
-
- If \`state: "all_done"\`: congratulate, suggest archive
|
|
43
|
-
- Otherwise: proceed to implementation
|
|
44
|
-
|
|
45
|
-
4. **Read context files**
|
|
46
|
-
|
|
47
|
-
Read every file path listed under \`contextFiles\` from the apply instructions output.
|
|
48
|
-
The files depend on the schema being used:
|
|
49
|
-
- **synarcx**: proposal, specs, design, tasks
|
|
50
|
-
- Other schemas: follow the contextFiles from CLI output
|
|
51
|
-
|
|
52
|
-
5. **Show current progress**
|
|
53
|
-
|
|
54
|
-
Display:
|
|
55
|
-
- Schema being used
|
|
56
|
-
- Progress: "N/M tasks complete"
|
|
57
|
-
- Remaining tasks overview
|
|
58
|
-
- Dynamic instruction from CLI
|
|
59
|
-
|
|
60
|
-
6. **Implement tasks (loop until done or blocked)**
|
|
61
|
-
|
|
62
|
-
For each pending task:
|
|
63
|
-
- Show which task is being worked on
|
|
64
|
-
- Make the code changes required
|
|
65
|
-
- Keep changes minimal and focused
|
|
66
|
-
- Mark task complete in the tasks file: \`- [ ]\` → \`- [x]\`
|
|
67
|
-
- Continue to next task
|
|
68
|
-
|
|
69
|
-
**Pause if:**
|
|
70
|
-
- Task is unclear → ask for clarification
|
|
71
|
-
- Implementation reveals a design issue → suggest updating artifacts
|
|
72
|
-
- Error or blocker encountered → report and wait for guidance
|
|
73
|
-
- User interrupts
|
|
74
|
-
|
|
75
|
-
7. **On completion or pause, show status**
|
|
76
|
-
|
|
77
|
-
Display:
|
|
78
|
-
- Tasks completed this session
|
|
79
|
-
- Overall progress: "N/M tasks complete"
|
|
80
|
-
- If all done: suggest archive
|
|
81
|
-
- If paused: explain why and wait for guidance
|
|
82
|
-
|
|
83
|
-
**Output During Implementation**
|
|
84
|
-
|
|
85
|
-
\`\`\`
|
|
86
|
-
## Implementing: <change-name> (schema: <schema-name>)
|
|
87
|
-
|
|
88
|
-
Working on task 3/7: <task description>
|
|
89
|
-
[...implementation happening...]
|
|
90
|
-
✓ Task complete
|
|
91
|
-
|
|
92
|
-
Working on task 4/7: <task description>
|
|
93
|
-
[...implementation happening...]
|
|
94
|
-
✓ Task complete
|
|
95
|
-
\`\`\`
|
|
96
|
-
|
|
97
|
-
**Output On Completion**
|
|
98
|
-
|
|
99
|
-
\`\`\`
|
|
100
|
-
## Implementation Complete
|
|
101
|
-
|
|
102
|
-
**Change:** <change-name>
|
|
103
|
-
**Schema:** <schema-name>
|
|
104
|
-
**Progress:** 7/7 tasks complete ✓
|
|
105
|
-
|
|
106
|
-
### Completed This Session
|
|
107
|
-
- [x] Task 1
|
|
108
|
-
- [x] Task 2
|
|
109
|
-
...
|
|
110
|
-
|
|
111
|
-
All tasks complete! Ready to archive this change.
|
|
112
|
-
\`\`\`
|
|
113
|
-
|
|
114
|
-
**Output On Pause (Issue Encountered)**
|
|
115
|
-
|
|
116
|
-
\`\`\`
|
|
117
|
-
## Implementation Paused
|
|
118
|
-
|
|
119
|
-
**Change:** <change-name>
|
|
120
|
-
**Schema:** <schema-name>
|
|
121
|
-
**Progress:** 4/7 tasks complete
|
|
122
|
-
|
|
123
|
-
### Issue Encountered
|
|
124
|
-
<description of the issue>
|
|
125
|
-
|
|
126
|
-
**Options:**
|
|
127
|
-
1. <option 1>
|
|
128
|
-
2. <option 2>
|
|
129
|
-
3. Other approach
|
|
130
|
-
|
|
131
|
-
What would you like to do?
|
|
132
|
-
\`\`\`
|
|
133
|
-
|
|
134
|
-
**Guardrails**
|
|
135
|
-
- Keep going through tasks until done or blocked
|
|
136
|
-
- Always read context files before starting (from the apply instructions output)
|
|
137
|
-
- If task is ambiguous, pause and ask before implementing
|
|
138
|
-
- If implementation reveals issues, pause and suggest artifact updates
|
|
139
|
-
- Keep code changes minimal and scoped to each task
|
|
140
|
-
- Update task checkbox immediately after completing each task
|
|
141
|
-
- Pause on errors, blockers, or unclear requirements - don't guess
|
|
142
|
-
- Use contextFiles from CLI output, don't assume specific file names
|
|
143
|
-
|
|
144
|
-
**Fluid Workflow Integration**
|
|
145
|
-
|
|
146
|
-
This skill supports the "actions on a change" model:
|
|
147
|
-
|
|
148
|
-
- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
|
|
6
|
+
instructions: `Implement tasks from a synarcx change.
|
|
7
|
+
|
|
8
|
+
**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.
|
|
9
|
+
|
|
10
|
+
**Steps**
|
|
11
|
+
|
|
12
|
+
1. **Select the change**
|
|
13
|
+
|
|
14
|
+
If a name is provided, use it. Otherwise:
|
|
15
|
+
- Infer from conversation context if the user mentioned a change
|
|
16
|
+
- Auto-select if only one active change exists
|
|
17
|
+
- If ambiguous, run \`synarcx list --json\` to get available changes and use the **AskUserQuestion tool** to let the user select
|
|
18
|
+
|
|
19
|
+
Always announce: "Using change: <name>" and how to override (e.g., \`/syn:apply <other>\`).
|
|
20
|
+
|
|
21
|
+
2. **Check status to understand the schema**
|
|
22
|
+
\`\`\`bash
|
|
23
|
+
synarcx status --change "<name>" --json
|
|
24
|
+
\`\`\`
|
|
25
|
+
Parse the JSON to understand:
|
|
26
|
+
- \`schemaName\`: The workflow being used (e.g., "synarcx")
|
|
27
|
+
- Which artifact contains the tasks (typically "tasks" for synarcx, check status for others)
|
|
28
|
+
|
|
29
|
+
3. **Get apply instructions**
|
|
30
|
+
|
|
31
|
+
\`\`\`bash
|
|
32
|
+
synarcx instructions apply --change "<name>" --json
|
|
33
|
+
\`\`\`
|
|
34
|
+
|
|
35
|
+
This returns:
|
|
36
|
+
- \`contextFiles\`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
|
|
37
|
+
- Progress (total, complete, remaining)
|
|
38
|
+
- Task list with status
|
|
39
|
+
- Dynamic instruction based on current state
|
|
40
|
+
|
|
41
|
+
**Handle states:**
|
|
42
|
+
- If \`state: "blocked"\` (missing artifacts): show message, suggest using syn:apply
|
|
43
|
+
- If \`state: "all_done"\`: congratulate, suggest archive
|
|
44
|
+
- Otherwise: proceed to implementation
|
|
45
|
+
|
|
46
|
+
4. **Read context files**
|
|
47
|
+
|
|
48
|
+
Read every file path listed under \`contextFiles\` from the apply instructions output.
|
|
49
|
+
The files depend on the schema being used:
|
|
50
|
+
- **synarcx**: proposal, specs, design, tasks
|
|
51
|
+
- Other schemas: follow the contextFiles from CLI output
|
|
52
|
+
|
|
53
|
+
5. **Show current progress**
|
|
54
|
+
|
|
55
|
+
Display:
|
|
56
|
+
- Schema being used
|
|
57
|
+
- Progress: "N/M tasks complete"
|
|
58
|
+
- Remaining tasks overview
|
|
59
|
+
- Dynamic instruction from CLI
|
|
60
|
+
|
|
61
|
+
6. **Implement tasks (loop until done or blocked)**
|
|
62
|
+
|
|
63
|
+
For each pending task:
|
|
64
|
+
- Show which task is being worked on
|
|
65
|
+
- Make the code changes required
|
|
66
|
+
- Keep changes minimal and focused
|
|
67
|
+
- Mark task complete in the tasks file: \`- [ ]\` → \`- [x]\`
|
|
68
|
+
- Continue to next task
|
|
69
|
+
|
|
70
|
+
**Pause if:**
|
|
71
|
+
- Task is unclear → ask for clarification
|
|
72
|
+
- Implementation reveals a design issue → suggest updating artifacts
|
|
73
|
+
- Error or blocker encountered → report and wait for guidance
|
|
74
|
+
- User interrupts
|
|
75
|
+
|
|
76
|
+
7. **On completion or pause, show status**
|
|
77
|
+
|
|
78
|
+
Display:
|
|
79
|
+
- Tasks completed this session
|
|
80
|
+
- Overall progress: "N/M tasks complete"
|
|
81
|
+
- If all done: suggest archive
|
|
82
|
+
- If paused: explain why and wait for guidance
|
|
83
|
+
|
|
84
|
+
**Output During Implementation**
|
|
85
|
+
|
|
86
|
+
\`\`\`
|
|
87
|
+
## Implementing: <change-name> (schema: <schema-name>)
|
|
88
|
+
|
|
89
|
+
Working on task 3/7: <task description>
|
|
90
|
+
[...implementation happening...]
|
|
91
|
+
✓ Task complete
|
|
92
|
+
|
|
93
|
+
Working on task 4/7: <task description>
|
|
94
|
+
[...implementation happening...]
|
|
95
|
+
✓ Task complete
|
|
96
|
+
\`\`\`
|
|
97
|
+
|
|
98
|
+
**Output On Completion**
|
|
99
|
+
|
|
100
|
+
\`\`\`
|
|
101
|
+
## Implementation Complete
|
|
102
|
+
|
|
103
|
+
**Change:** <change-name>
|
|
104
|
+
**Schema:** <schema-name>
|
|
105
|
+
**Progress:** 7/7 tasks complete ✓
|
|
106
|
+
|
|
107
|
+
### Completed This Session
|
|
108
|
+
- [x] Task 1
|
|
109
|
+
- [x] Task 2
|
|
110
|
+
...
|
|
111
|
+
|
|
112
|
+
All tasks complete! Ready to archive this change.
|
|
113
|
+
\`\`\`
|
|
114
|
+
|
|
115
|
+
**Output On Pause (Issue Encountered)**
|
|
116
|
+
|
|
117
|
+
\`\`\`
|
|
118
|
+
## Implementation Paused
|
|
119
|
+
|
|
120
|
+
**Change:** <change-name>
|
|
121
|
+
**Schema:** <schema-name>
|
|
122
|
+
**Progress:** 4/7 tasks complete
|
|
123
|
+
|
|
124
|
+
### Issue Encountered
|
|
125
|
+
<description of the issue>
|
|
126
|
+
|
|
127
|
+
**Options:**
|
|
128
|
+
1. <option 1>
|
|
129
|
+
2. <option 2>
|
|
130
|
+
3. Other approach
|
|
131
|
+
|
|
132
|
+
What would you like to do?
|
|
133
|
+
\`\`\`
|
|
134
|
+
|
|
135
|
+
**Guardrails**
|
|
136
|
+
- Keep going through tasks until done or blocked
|
|
137
|
+
- Always read context files before starting (from the apply instructions output)
|
|
138
|
+
- If task is ambiguous, pause and ask before implementing
|
|
139
|
+
- If implementation reveals issues, pause and suggest artifact updates
|
|
140
|
+
- Keep code changes minimal and scoped to each task
|
|
141
|
+
- Update task checkbox immediately after completing each task
|
|
142
|
+
- Pause on errors, blockers, or unclear requirements - don't guess
|
|
143
|
+
- Use contextFiles from CLI output, don't assume specific file names
|
|
144
|
+
|
|
145
|
+
**Fluid Workflow Integration**
|
|
146
|
+
|
|
147
|
+
This skill supports the "actions on a change" model:
|
|
148
|
+
|
|
149
|
+
- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
|
|
149
150
|
- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly`,
|
|
150
151
|
license: 'MIT',
|
|
151
152
|
compatibility: 'Requires synarcx CLI.',
|
|
@@ -153,156 +154,155 @@ This skill supports the "actions on a change" model:
|
|
|
153
154
|
};
|
|
154
155
|
}
|
|
155
156
|
export function getSynApplyCommandTemplate() {
|
|
156
|
-
return {
|
|
157
|
+
return commandFromSkill(getSynApplySkillTemplate(), {
|
|
157
158
|
name: 'syn:apply',
|
|
158
159
|
description: 'Implement tasks from a synarcx change',
|
|
159
|
-
category: 'Workflow',
|
|
160
160
|
tags: ['workflow', 'artifacts'],
|
|
161
|
-
content: `Implement tasks from a synarcx change.
|
|
162
|
-
|
|
163
|
-
**Input**: Optionally specify a change name (e.g., \`/syn:apply add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
|
|
164
|
-
|
|
165
|
-
**Steps**
|
|
166
|
-
|
|
167
|
-
1. **Select the change**
|
|
168
|
-
|
|
169
|
-
If a name is provided, use it. Otherwise:
|
|
170
|
-
- Infer from conversation context if the user mentioned a change
|
|
171
|
-
- Auto-select if only one active change exists
|
|
172
|
-
- If ambiguous, run \`synarcx list --json\` to get available changes and use the **AskUserQuestion tool** to let the user select
|
|
173
|
-
|
|
174
|
-
Always announce: "Using change: <name>" and how to override (e.g., \`/syn:apply <other>\`).
|
|
175
|
-
|
|
176
|
-
2. **Check status to understand the schema**
|
|
177
|
-
\`\`\`bash
|
|
178
|
-
synarcx status --change "<name>" --json
|
|
179
|
-
\`\`\`
|
|
180
|
-
Parse the JSON to understand:
|
|
181
|
-
- \`schemaName\`: The workflow being used (e.g., "synarcx")
|
|
182
|
-
- Which artifact contains the tasks (typically "tasks" for synarcx, check status for others)
|
|
183
|
-
|
|
184
|
-
3. **Get apply instructions**
|
|
185
|
-
|
|
186
|
-
\`\`\`bash
|
|
187
|
-
synarcx instructions apply --change "<name>" --json
|
|
188
|
-
\`\`\`
|
|
189
|
-
|
|
190
|
-
This returns:
|
|
191
|
-
- \`contextFiles\`: artifact ID -> array of concrete file paths (varies by schema)
|
|
192
|
-
- Progress (total, complete, remaining)
|
|
193
|
-
- Task list with status
|
|
194
|
-
- Dynamic instruction based on current state
|
|
195
|
-
|
|
196
|
-
**Handle states:**
|
|
197
|
-
- If \`state: "blocked"\` (missing artifacts): show message, suggest using \`/syn:apply\`
|
|
198
|
-
- If \`state: "all_done"\`: congratulate, suggest archive
|
|
199
|
-
- Otherwise: proceed to implementation
|
|
200
|
-
|
|
201
|
-
4. **Read context files**
|
|
202
|
-
|
|
203
|
-
Read every file path listed under \`contextFiles\` from the apply instructions output.
|
|
204
|
-
The files depend on the schema being used:
|
|
205
|
-
- **synarcx**: proposal, specs, design, tasks
|
|
206
|
-
- Other schemas: follow the contextFiles from CLI output
|
|
207
|
-
|
|
208
|
-
5. **Show current progress**
|
|
209
|
-
|
|
210
|
-
Display:
|
|
211
|
-
- Schema being used
|
|
212
|
-
- Progress: "N/M tasks complete"
|
|
213
|
-
- Remaining tasks overview
|
|
214
|
-
- Dynamic instruction from CLI
|
|
215
|
-
|
|
216
|
-
6. **Implement tasks (loop until done or blocked)**
|
|
217
|
-
|
|
218
|
-
For each pending task:
|
|
219
|
-
- Show which task is being worked on
|
|
220
|
-
- Make the code changes required
|
|
221
|
-
- Keep changes minimal and focused
|
|
222
|
-
- Mark task complete in the tasks file: \`- [ ]\` → \`- [x]\`
|
|
223
|
-
- Continue to next task
|
|
224
|
-
|
|
225
|
-
**Pause if:**
|
|
226
|
-
- Task is unclear → ask for clarification
|
|
227
|
-
- Implementation reveals a design issue → suggest updating artifacts
|
|
228
|
-
- Error or blocker encountered → report and wait for guidance
|
|
229
|
-
- User interrupts
|
|
230
|
-
|
|
231
|
-
7. **On completion or pause, show status**
|
|
232
|
-
|
|
233
|
-
Display:
|
|
234
|
-
- Tasks completed this session
|
|
235
|
-
- Overall progress: "N/M tasks complete"
|
|
236
|
-
- If all done: suggest archive
|
|
237
|
-
- If paused: explain why and wait for guidance
|
|
238
|
-
|
|
239
|
-
**Output During Implementation**
|
|
240
|
-
|
|
241
|
-
\`\`\`
|
|
242
|
-
## Implementing: <change-name> (schema: <schema-name>)
|
|
243
|
-
|
|
244
|
-
Working on task 3/7: <task description>
|
|
245
|
-
[...implementation happening...]
|
|
246
|
-
✓ Task complete
|
|
247
|
-
|
|
248
|
-
Working on task 4/7: <task description>
|
|
249
|
-
[...implementation happening...]
|
|
250
|
-
✓ Task complete
|
|
251
|
-
\`\`\`
|
|
252
|
-
|
|
253
|
-
**Output On Completion**
|
|
254
|
-
|
|
255
|
-
\`\`\`
|
|
256
|
-
## Implementation Complete
|
|
257
|
-
|
|
258
|
-
**Change:** <change-name>
|
|
259
|
-
**Schema:** <schema-name>
|
|
260
|
-
**Progress:** 7/7 tasks complete ✓
|
|
261
|
-
|
|
262
|
-
### Completed This Session
|
|
263
|
-
- [x] Task 1
|
|
264
|
-
- [x] Task 2
|
|
265
|
-
...
|
|
266
|
-
|
|
267
|
-
All tasks complete! You can archive this change with \`/syn:archive\`.
|
|
268
|
-
\`\`\`
|
|
269
|
-
|
|
270
|
-
**Output On Pause (Issue Encountered)**
|
|
271
|
-
|
|
272
|
-
\`\`\`
|
|
273
|
-
## Implementation Paused
|
|
274
|
-
|
|
275
|
-
**Change:** <change-name>
|
|
276
|
-
**Schema:** <schema-name>
|
|
277
|
-
**Progress:** 4/7 tasks complete
|
|
278
|
-
|
|
279
|
-
### Issue Encountered
|
|
280
|
-
<description of the issue>
|
|
281
|
-
|
|
282
|
-
**Options:**
|
|
283
|
-
1. <option 1>
|
|
284
|
-
2. <option 2>
|
|
285
|
-
3. Other approach
|
|
286
|
-
|
|
287
|
-
What would you like to do?
|
|
288
|
-
\`\`\`
|
|
289
|
-
|
|
290
|
-
**Guardrails**
|
|
291
|
-
- Keep going through tasks until done or blocked
|
|
292
|
-
- Always read context files before starting (from the apply instructions output)
|
|
293
|
-
- If task is ambiguous, pause and ask before implementing
|
|
294
|
-
- If implementation reveals issues, pause and suggest artifact updates
|
|
295
|
-
- Keep code changes minimal and scoped to each task
|
|
296
|
-
- Update task checkbox immediately after completing each task
|
|
297
|
-
- Pause on errors, blockers, or unclear requirements - don't guess
|
|
298
|
-
- Use contextFiles from CLI output, don't assume specific file names
|
|
299
|
-
|
|
300
|
-
**Fluid Workflow Integration**
|
|
301
|
-
|
|
302
|
-
This skill supports the "actions on a change" model:
|
|
303
|
-
|
|
304
|
-
- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
|
|
161
|
+
content: `Implement tasks from a synarcx change.
|
|
162
|
+
|
|
163
|
+
**Input**: Optionally specify a change name (e.g., \`/syn:apply add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
|
|
164
|
+
|
|
165
|
+
**Steps**
|
|
166
|
+
|
|
167
|
+
1. **Select the change**
|
|
168
|
+
|
|
169
|
+
If a name is provided, use it. Otherwise:
|
|
170
|
+
- Infer from conversation context if the user mentioned a change
|
|
171
|
+
- Auto-select if only one active change exists
|
|
172
|
+
- If ambiguous, run \`synarcx list --json\` to get available changes and use the **AskUserQuestion tool** to let the user select
|
|
173
|
+
|
|
174
|
+
Always announce: "Using change: <name>" and how to override (e.g., \`/syn:apply <other>\`).
|
|
175
|
+
|
|
176
|
+
2. **Check status to understand the schema**
|
|
177
|
+
\`\`\`bash
|
|
178
|
+
synarcx status --change "<name>" --json
|
|
179
|
+
\`\`\`
|
|
180
|
+
Parse the JSON to understand:
|
|
181
|
+
- \`schemaName\`: The workflow being used (e.g., "synarcx")
|
|
182
|
+
- Which artifact contains the tasks (typically "tasks" for synarcx, check status for others)
|
|
183
|
+
|
|
184
|
+
3. **Get apply instructions**
|
|
185
|
+
|
|
186
|
+
\`\`\`bash
|
|
187
|
+
synarcx instructions apply --change "<name>" --json
|
|
188
|
+
\`\`\`
|
|
189
|
+
|
|
190
|
+
This returns:
|
|
191
|
+
- \`contextFiles\`: artifact ID -> array of concrete file paths (varies by schema)
|
|
192
|
+
- Progress (total, complete, remaining)
|
|
193
|
+
- Task list with status
|
|
194
|
+
- Dynamic instruction based on current state
|
|
195
|
+
|
|
196
|
+
**Handle states:**
|
|
197
|
+
- If \`state: "blocked"\` (missing artifacts): show message, suggest using \`/syn:apply\`
|
|
198
|
+
- If \`state: "all_done"\`: congratulate, suggest archive
|
|
199
|
+
- Otherwise: proceed to implementation
|
|
200
|
+
|
|
201
|
+
4. **Read context files**
|
|
202
|
+
|
|
203
|
+
Read every file path listed under \`contextFiles\` from the apply instructions output.
|
|
204
|
+
The files depend on the schema being used:
|
|
205
|
+
- **synarcx**: proposal, specs, design, tasks
|
|
206
|
+
- Other schemas: follow the contextFiles from CLI output
|
|
207
|
+
|
|
208
|
+
5. **Show current progress**
|
|
209
|
+
|
|
210
|
+
Display:
|
|
211
|
+
- Schema being used
|
|
212
|
+
- Progress: "N/M tasks complete"
|
|
213
|
+
- Remaining tasks overview
|
|
214
|
+
- Dynamic instruction from CLI
|
|
215
|
+
|
|
216
|
+
6. **Implement tasks (loop until done or blocked)**
|
|
217
|
+
|
|
218
|
+
For each pending task:
|
|
219
|
+
- Show which task is being worked on
|
|
220
|
+
- Make the code changes required
|
|
221
|
+
- Keep changes minimal and focused
|
|
222
|
+
- Mark task complete in the tasks file: \`- [ ]\` → \`- [x]\`
|
|
223
|
+
- Continue to next task
|
|
224
|
+
|
|
225
|
+
**Pause if:**
|
|
226
|
+
- Task is unclear → ask for clarification
|
|
227
|
+
- Implementation reveals a design issue → suggest updating artifacts
|
|
228
|
+
- Error or blocker encountered → report and wait for guidance
|
|
229
|
+
- User interrupts
|
|
230
|
+
|
|
231
|
+
7. **On completion or pause, show status**
|
|
232
|
+
|
|
233
|
+
Display:
|
|
234
|
+
- Tasks completed this session
|
|
235
|
+
- Overall progress: "N/M tasks complete"
|
|
236
|
+
- If all done: suggest archive
|
|
237
|
+
- If paused: explain why and wait for guidance
|
|
238
|
+
|
|
239
|
+
**Output During Implementation**
|
|
240
|
+
|
|
241
|
+
\`\`\`
|
|
242
|
+
## Implementing: <change-name> (schema: <schema-name>)
|
|
243
|
+
|
|
244
|
+
Working on task 3/7: <task description>
|
|
245
|
+
[...implementation happening...]
|
|
246
|
+
✓ Task complete
|
|
247
|
+
|
|
248
|
+
Working on task 4/7: <task description>
|
|
249
|
+
[...implementation happening...]
|
|
250
|
+
✓ Task complete
|
|
251
|
+
\`\`\`
|
|
252
|
+
|
|
253
|
+
**Output On Completion**
|
|
254
|
+
|
|
255
|
+
\`\`\`
|
|
256
|
+
## Implementation Complete
|
|
257
|
+
|
|
258
|
+
**Change:** <change-name>
|
|
259
|
+
**Schema:** <schema-name>
|
|
260
|
+
**Progress:** 7/7 tasks complete ✓
|
|
261
|
+
|
|
262
|
+
### Completed This Session
|
|
263
|
+
- [x] Task 1
|
|
264
|
+
- [x] Task 2
|
|
265
|
+
...
|
|
266
|
+
|
|
267
|
+
All tasks complete! You can archive this change with \`/syn:archive\`.
|
|
268
|
+
\`\`\`
|
|
269
|
+
|
|
270
|
+
**Output On Pause (Issue Encountered)**
|
|
271
|
+
|
|
272
|
+
\`\`\`
|
|
273
|
+
## Implementation Paused
|
|
274
|
+
|
|
275
|
+
**Change:** <change-name>
|
|
276
|
+
**Schema:** <schema-name>
|
|
277
|
+
**Progress:** 4/7 tasks complete
|
|
278
|
+
|
|
279
|
+
### Issue Encountered
|
|
280
|
+
<description of the issue>
|
|
281
|
+
|
|
282
|
+
**Options:**
|
|
283
|
+
1. <option 1>
|
|
284
|
+
2. <option 2>
|
|
285
|
+
3. Other approach
|
|
286
|
+
|
|
287
|
+
What would you like to do?
|
|
288
|
+
\`\`\`
|
|
289
|
+
|
|
290
|
+
**Guardrails**
|
|
291
|
+
- Keep going through tasks until done or blocked
|
|
292
|
+
- Always read context files before starting (from the apply instructions output)
|
|
293
|
+
- If task is ambiguous, pause and ask before implementing
|
|
294
|
+
- If implementation reveals issues, pause and suggest artifact updates
|
|
295
|
+
- Keep code changes minimal and scoped to each task
|
|
296
|
+
- Update task checkbox immediately after completing each task
|
|
297
|
+
- Pause on errors, blockers, or unclear requirements - don't guess
|
|
298
|
+
- Use contextFiles from CLI output, don't assume specific file names
|
|
299
|
+
|
|
300
|
+
**Fluid Workflow Integration**
|
|
301
|
+
|
|
302
|
+
This skill supports the "actions on a change" model:
|
|
303
|
+
|
|
304
|
+
- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
|
|
305
305
|
- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly`
|
|
306
|
-
};
|
|
306
|
+
});
|
|
307
307
|
}
|
|
308
308
|
//# sourceMappingURL=apply-change.js.map
|