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,55 +1,56 @@
|
|
|
1
|
+
import { commandFromSkill } from '../types.js';
|
|
1
2
|
export function getSynClarifySkillTemplate() {
|
|
2
3
|
return {
|
|
3
4
|
name: 'syn-clarify',
|
|
4
5
|
description: 'Ask up to 5 targeted questions about a change\'s proposal, specs, or design to improve clarity before implementation.',
|
|
5
|
-
instructions: `Ask targeted clarification questions about a change to improve its artifacts before implementation.
|
|
6
|
-
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
## Steps
|
|
10
|
-
|
|
11
|
-
1. **Identify the change**
|
|
12
|
-
- If the user specified a change name, use it
|
|
13
|
-
- Otherwise, run \`synarcx list --json\` to find active changes
|
|
14
|
-
- If multiple, ask which one to clarify
|
|
15
|
-
|
|
16
|
-
2. **Read the artifacts**
|
|
17
|
-
- \`synspec/changes/<name>/proposal.md\`
|
|
18
|
-
- \`synspec/changes/<name>/specs/**/*.md\` (if exist)
|
|
19
|
-
- \`synspec/changes/<name>/design.md\`
|
|
20
|
-
|
|
21
|
-
3. **Generate up to 5 targeted questions**
|
|
22
|
-
Focus on areas that are:
|
|
23
|
-
- Ambiguous or underspecified
|
|
24
|
-
- Missing edge cases
|
|
25
|
-
- Unclear scope boundaries
|
|
26
|
-
- Unstated assumptions
|
|
27
|
-
- Missing acceptance criteria
|
|
28
|
-
|
|
29
|
-
Question categories:
|
|
30
|
-
- **Scope**: What's in/out? Edge cases?
|
|
31
|
-
- **Requirements**: Acceptance criteria? Success metrics?
|
|
32
|
-
- **Design**: Trade-offs considered? Alternatives?
|
|
33
|
-
- **Implementation**: Dependencies? Migration path?
|
|
34
|
-
- **Testing**: How to verify?
|
|
35
|
-
|
|
36
|
-
4. **Ask questions interactively**
|
|
37
|
-
Use the **AskUserQuestion tool** (open-ended) to present each question.
|
|
38
|
-
Present questions one at a time. Wait for each answer before moving to the next.
|
|
39
|
-
Maximum 5 questions per session.
|
|
40
|
-
|
|
41
|
-
5. **Encode answers back into artifacts**
|
|
42
|
-
- Edit the relevant artifact in place (proposal.md, design.md, or specs)
|
|
43
|
-
- Do NOT create new files
|
|
44
|
-
- Show what was changed and why
|
|
45
|
-
|
|
46
|
-
---
|
|
47
|
-
|
|
48
|
-
## Output
|
|
49
|
-
|
|
50
|
-
After completing, summarize:
|
|
51
|
-
- What was clarified
|
|
52
|
-
- Which artifacts were updated
|
|
6
|
+
instructions: `Ask targeted clarification questions about a change to improve its artifacts before implementation.
|
|
7
|
+
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
## Steps
|
|
11
|
+
|
|
12
|
+
1. **Identify the change**
|
|
13
|
+
- If the user specified a change name, use it
|
|
14
|
+
- Otherwise, run \`synarcx list --json\` to find active changes
|
|
15
|
+
- If multiple, ask which one to clarify
|
|
16
|
+
|
|
17
|
+
2. **Read the artifacts**
|
|
18
|
+
- \`synspec/changes/<name>/proposal.md\`
|
|
19
|
+
- \`synspec/changes/<name>/specs/**/*.md\` (if exist)
|
|
20
|
+
- \`synspec/changes/<name>/design.md\`
|
|
21
|
+
|
|
22
|
+
3. **Generate up to 5 targeted questions**
|
|
23
|
+
Focus on areas that are:
|
|
24
|
+
- Ambiguous or underspecified
|
|
25
|
+
- Missing edge cases
|
|
26
|
+
- Unclear scope boundaries
|
|
27
|
+
- Unstated assumptions
|
|
28
|
+
- Missing acceptance criteria
|
|
29
|
+
|
|
30
|
+
Question categories:
|
|
31
|
+
- **Scope**: What's in/out? Edge cases?
|
|
32
|
+
- **Requirements**: Acceptance criteria? Success metrics?
|
|
33
|
+
- **Design**: Trade-offs considered? Alternatives?
|
|
34
|
+
- **Implementation**: Dependencies? Migration path?
|
|
35
|
+
- **Testing**: How to verify?
|
|
36
|
+
|
|
37
|
+
4. **Ask questions interactively**
|
|
38
|
+
Use the **AskUserQuestion tool** (open-ended) to present each question.
|
|
39
|
+
Present questions one at a time. Wait for each answer before moving to the next.
|
|
40
|
+
Maximum 5 questions per session.
|
|
41
|
+
|
|
42
|
+
5. **Encode answers back into artifacts**
|
|
43
|
+
- Edit the relevant artifact in place (proposal.md, design.md, or specs)
|
|
44
|
+
- Do NOT create new files
|
|
45
|
+
- Show what was changed and why
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
## Output
|
|
50
|
+
|
|
51
|
+
After completing, summarize:
|
|
52
|
+
- What was clarified
|
|
53
|
+
- Which artifacts were updated
|
|
53
54
|
- Next step: Run \`/syn:analyze\` to check consistency across artifacts`,
|
|
54
55
|
license: 'MIT',
|
|
55
56
|
compatibility: 'Requires synarcx CLI.',
|
|
@@ -57,52 +58,51 @@ After completing, summarize:
|
|
|
57
58
|
};
|
|
58
59
|
}
|
|
59
60
|
export function getSynClarifyCommandTemplate() {
|
|
60
|
-
return {
|
|
61
|
+
return commandFromSkill(getSynClarifySkillTemplate(), {
|
|
61
62
|
name: 'syn:clarify',
|
|
62
63
|
description: 'Ask up to 5 targeted questions to improve change artifacts',
|
|
63
|
-
category: 'Workflow',
|
|
64
64
|
tags: ['workflow', 'clarify'],
|
|
65
|
-
content: `Ask targeted clarification questions about a change to improve its artifacts before implementation.
|
|
66
|
-
|
|
67
|
-
---
|
|
68
|
-
|
|
69
|
-
## Steps
|
|
70
|
-
|
|
71
|
-
1. **Identify the change**
|
|
72
|
-
- If the user specified a change name, use it
|
|
73
|
-
- Otherwise, run \`synarcx list --json\` to find active changes
|
|
74
|
-
- If multiple, ask which one to clarify
|
|
75
|
-
|
|
76
|
-
2. **Read the artifacts**
|
|
77
|
-
- \`synspec/changes/<name>/proposal.md\`
|
|
78
|
-
- \`synspec/changes/<name>/specs/**/*.md\` (if exist)
|
|
79
|
-
- \`synspec/changes/<name>/design.md\`
|
|
80
|
-
|
|
81
|
-
3. **Generate up to 5 targeted questions**
|
|
82
|
-
Focus on areas that are:
|
|
83
|
-
- Ambiguous or underspecified
|
|
84
|
-
- Missing edge cases
|
|
85
|
-
- Unclear scope boundaries
|
|
86
|
-
- Unstated assumptions
|
|
87
|
-
- Missing acceptance criteria
|
|
88
|
-
|
|
89
|
-
4. **Ask questions interactively**
|
|
90
|
-
Present questions one at a time. Wait for each answer before moving to the next.
|
|
91
|
-
Maximum 5 questions per session.
|
|
92
|
-
|
|
93
|
-
5. **Encode answers back into artifacts**
|
|
94
|
-
- Edit the relevant artifact in place (proposal.md, design.md, or specs)
|
|
95
|
-
- Do NOT create new files
|
|
96
|
-
- Show what was changed and why
|
|
97
|
-
|
|
98
|
-
---
|
|
99
|
-
|
|
100
|
-
## Output
|
|
101
|
-
|
|
102
|
-
After completing, summarize:
|
|
103
|
-
- What was clarified
|
|
104
|
-
- Which artifacts were updated
|
|
65
|
+
content: `Ask targeted clarification questions about a change to improve its artifacts before implementation.
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## Steps
|
|
70
|
+
|
|
71
|
+
1. **Identify the change**
|
|
72
|
+
- If the user specified a change name, use it
|
|
73
|
+
- Otherwise, run \`synarcx list --json\` to find active changes
|
|
74
|
+
- If multiple, ask which one to clarify
|
|
75
|
+
|
|
76
|
+
2. **Read the artifacts**
|
|
77
|
+
- \`synspec/changes/<name>/proposal.md\`
|
|
78
|
+
- \`synspec/changes/<name>/specs/**/*.md\` (if exist)
|
|
79
|
+
- \`synspec/changes/<name>/design.md\`
|
|
80
|
+
|
|
81
|
+
3. **Generate up to 5 targeted questions**
|
|
82
|
+
Focus on areas that are:
|
|
83
|
+
- Ambiguous or underspecified
|
|
84
|
+
- Missing edge cases
|
|
85
|
+
- Unclear scope boundaries
|
|
86
|
+
- Unstated assumptions
|
|
87
|
+
- Missing acceptance criteria
|
|
88
|
+
|
|
89
|
+
4. **Ask questions interactively**
|
|
90
|
+
Present questions one at a time. Wait for each answer before moving to the next.
|
|
91
|
+
Maximum 5 questions per session.
|
|
92
|
+
|
|
93
|
+
5. **Encode answers back into artifacts**
|
|
94
|
+
- Edit the relevant artifact in place (proposal.md, design.md, or specs)
|
|
95
|
+
- Do NOT create new files
|
|
96
|
+
- Show what was changed and why
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
## Output
|
|
101
|
+
|
|
102
|
+
After completing, summarize:
|
|
103
|
+
- What was clarified
|
|
104
|
+
- Which artifacts were updated
|
|
105
105
|
- Next step: Run \`/syn:analyze\` to check consistency across artifacts`
|
|
106
|
-
};
|
|
106
|
+
});
|
|
107
107
|
}
|
|
108
108
|
//# sourceMappingURL=clarify.js.map
|
|
@@ -1,64 +1,65 @@
|
|
|
1
|
+
import { commandFromSkill } from '../types.js';
|
|
1
2
|
export function getSynDebugSkillTemplate() {
|
|
2
3
|
return {
|
|
3
4
|
name: 'syn-debug',
|
|
4
5
|
description: 'Investigate a known error or failure — root cause analysis, pattern recognition, and hypothesis formulation. Hands off explicitly to /syn:propose.',
|
|
5
|
-
instructions: `Investigate a known error or failure systematically in 3 phases. Produces a diagnosis and explicitly prompts the user to run \`/syn:propose\` — does NOT auto-create artifacts or auto-hand off.
|
|
6
|
-
|
|
7
|
-
**Input**: Error message, symptom, or failure description. If no input provided, ask what went wrong.
|
|
8
|
-
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
## Initial Context
|
|
12
|
-
|
|
13
|
-
If a change is active, read its artifacts first:
|
|
14
|
-
- \`synspec/changes/<name>/proposal.md\`
|
|
15
|
-
- \`synspec/changes/<name>/design.md\`
|
|
16
|
-
- \`synspec/changes/<name>/tasks.md\`
|
|
17
|
-
|
|
18
|
-
Use that context to understand what was intended vs. what went wrong.
|
|
19
|
-
|
|
20
|
-
---
|
|
21
|
-
|
|
22
|
-
## The 3 Phases
|
|
23
|
-
|
|
24
|
-
### Phase 1: Root Cause Analysis
|
|
25
|
-
- Reproduce the issue
|
|
26
|
-
- Gather context (error messages, logs, state)
|
|
27
|
-
- Follow the call stack backward
|
|
28
|
-
- Check input assumptions at each layer
|
|
29
|
-
- Identify the root cause (not symptoms)
|
|
30
|
-
- Document findings under \`### Root Cause\`
|
|
31
|
-
|
|
32
|
-
### Phase 2: Pattern Recognition
|
|
33
|
-
- Is this a known issue or novel?
|
|
34
|
-
- Have similar bugs been fixed before?
|
|
35
|
-
- Is this a class of issues?
|
|
36
|
-
- Check codebase for related patterns
|
|
37
|
-
- Document under \`### Pattern\`
|
|
38
|
-
|
|
39
|
-
### Phase 3: Hypothesis
|
|
40
|
-
- Formulate fix hypothesis
|
|
41
|
-
- Consider side effects of the fix
|
|
42
|
-
- Consider alternative approaches
|
|
43
|
-
- Determine minimal change needed
|
|
44
|
-
- Document under \`### Hypothesis\`
|
|
45
|
-
|
|
46
|
-
---
|
|
47
|
-
|
|
48
|
-
## Output
|
|
49
|
-
|
|
50
|
-
After completing the 3-phase investigation, present findings and prompt explicitly:
|
|
51
|
-
|
|
52
|
-
\`\`\`
|
|
53
|
-
### Diagnosis
|
|
54
|
-
|
|
55
|
-
**Root Cause**: <what was found>
|
|
56
|
-
**Pattern**: <similar issues or novel>
|
|
57
|
-
**Hypothesis**: <proposed fix approach>
|
|
58
|
-
|
|
59
|
-
**Ready to formalize?** Run \`/syn:propose\` to create a change with these findings.
|
|
60
|
-
\`\`\`
|
|
61
|
-
|
|
6
|
+
instructions: `Investigate a known error or failure systematically in 3 phases. Produces a diagnosis and explicitly prompts the user to run \`/syn:propose\` — does NOT auto-create artifacts or auto-hand off.
|
|
7
|
+
|
|
8
|
+
**Input**: Error message, symptom, or failure description. If no input provided, ask what went wrong.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Initial Context
|
|
13
|
+
|
|
14
|
+
If a change is active, read its artifacts first:
|
|
15
|
+
- \`synspec/changes/<name>/proposal.md\`
|
|
16
|
+
- \`synspec/changes/<name>/design.md\`
|
|
17
|
+
- \`synspec/changes/<name>/tasks.md\`
|
|
18
|
+
|
|
19
|
+
Use that context to understand what was intended vs. what went wrong.
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## The 3 Phases
|
|
24
|
+
|
|
25
|
+
### Phase 1: Root Cause Analysis
|
|
26
|
+
- Reproduce the issue
|
|
27
|
+
- Gather context (error messages, logs, state)
|
|
28
|
+
- Follow the call stack backward
|
|
29
|
+
- Check input assumptions at each layer
|
|
30
|
+
- Identify the root cause (not symptoms)
|
|
31
|
+
- Document findings under \`### Root Cause\`
|
|
32
|
+
|
|
33
|
+
### Phase 2: Pattern Recognition
|
|
34
|
+
- Is this a known issue or novel?
|
|
35
|
+
- Have similar bugs been fixed before?
|
|
36
|
+
- Is this a class of issues?
|
|
37
|
+
- Check codebase for related patterns
|
|
38
|
+
- Document under \`### Pattern\`
|
|
39
|
+
|
|
40
|
+
### Phase 3: Hypothesis
|
|
41
|
+
- Formulate fix hypothesis
|
|
42
|
+
- Consider side effects of the fix
|
|
43
|
+
- Consider alternative approaches
|
|
44
|
+
- Determine minimal change needed
|
|
45
|
+
- Document under \`### Hypothesis\`
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
## Output
|
|
50
|
+
|
|
51
|
+
After completing the 3-phase investigation, present findings and prompt explicitly:
|
|
52
|
+
|
|
53
|
+
\`\`\`
|
|
54
|
+
### Diagnosis
|
|
55
|
+
|
|
56
|
+
**Root Cause**: <what was found>
|
|
57
|
+
**Pattern**: <similar issues or novel>
|
|
58
|
+
**Hypothesis**: <proposed fix approach>
|
|
59
|
+
|
|
60
|
+
**Ready to formalize?** Run \`/syn:propose\` to create a change with these findings.
|
|
61
|
+
\`\`\`
|
|
62
|
+
|
|
62
63
|
Do NOT create any artifacts, do NOT start the pipeline automatically. The user must explicitly run \`/syn:propose\` to formalize.`,
|
|
63
64
|
license: 'MIT',
|
|
64
65
|
compatibility: 'Requires synarcx CLI.',
|
|
@@ -66,52 +67,51 @@ Do NOT create any artifacts, do NOT start the pipeline automatically. The user m
|
|
|
66
67
|
};
|
|
67
68
|
}
|
|
68
69
|
export function getSynDebugCommandTemplate() {
|
|
69
|
-
return {
|
|
70
|
+
return commandFromSkill(getSynDebugSkillTemplate(), {
|
|
70
71
|
name: 'syn:debug',
|
|
71
72
|
description: 'Investigate a known error — root cause analysis through hypothesis, explicitly prompts /syn:propose',
|
|
72
|
-
category: 'Workflow',
|
|
73
73
|
tags: ['workflow', 'debug', 'fix'],
|
|
74
|
-
content: `Investigate a known error or failure systematically in 3 phases. Produces a diagnosis and suggests \`/syn:propose\` for creating the fix change.
|
|
75
|
-
|
|
76
|
-
**Input**: Error message, symptom, or failure description. The argument after \`/syn:debug\` is what went wrong.
|
|
77
|
-
|
|
78
|
-
---
|
|
79
|
-
|
|
80
|
-
## Initial Context
|
|
81
|
-
|
|
82
|
-
If a change is active, read its artifacts first to understand what was intended vs. what went wrong.
|
|
83
|
-
|
|
84
|
-
---
|
|
85
|
-
|
|
86
|
-
## The 3 Phases
|
|
87
|
-
|
|
88
|
-
### Phase 1: Root Cause Analysis
|
|
89
|
-
- Reproduce the issue
|
|
90
|
-
- Gather context (error messages, logs, state)
|
|
91
|
-
- Follow the call stack backward
|
|
92
|
-
- Check input assumptions at each layer
|
|
93
|
-
- Identify the root cause (not symptoms)
|
|
94
|
-
- Document findings under \`### Root Cause\`
|
|
95
|
-
|
|
96
|
-
### Phase 2: Pattern Recognition
|
|
97
|
-
- Is this a known issue or novel?
|
|
98
|
-
- Have similar bugs been fixed before?
|
|
99
|
-
- Is this a class of issues?
|
|
100
|
-
- Check codebase for related patterns
|
|
101
|
-
- Document under \`### Pattern\`
|
|
102
|
-
|
|
103
|
-
### Phase 3: Hypothesis
|
|
104
|
-
- Formulate fix hypothesis
|
|
105
|
-
- Consider side effects of the fix
|
|
106
|
-
- Consider alternative approaches
|
|
107
|
-
- Determine minimal change needed
|
|
108
|
-
- Document under \`### Hypothesis\`
|
|
109
|
-
|
|
110
|
-
---
|
|
111
|
-
|
|
112
|
-
## Output
|
|
113
|
-
|
|
74
|
+
content: `Investigate a known error or failure systematically in 3 phases. Produces a diagnosis and suggests \`/syn:propose\` for creating the fix change.
|
|
75
|
+
|
|
76
|
+
**Input**: Error message, symptom, or failure description. The argument after \`/syn:debug\` is what went wrong.
|
|
77
|
+
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
## Initial Context
|
|
81
|
+
|
|
82
|
+
If a change is active, read its artifacts first to understand what was intended vs. what went wrong.
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## The 3 Phases
|
|
87
|
+
|
|
88
|
+
### Phase 1: Root Cause Analysis
|
|
89
|
+
- Reproduce the issue
|
|
90
|
+
- Gather context (error messages, logs, state)
|
|
91
|
+
- Follow the call stack backward
|
|
92
|
+
- Check input assumptions at each layer
|
|
93
|
+
- Identify the root cause (not symptoms)
|
|
94
|
+
- Document findings under \`### Root Cause\`
|
|
95
|
+
|
|
96
|
+
### Phase 2: Pattern Recognition
|
|
97
|
+
- Is this a known issue or novel?
|
|
98
|
+
- Have similar bugs been fixed before?
|
|
99
|
+
- Is this a class of issues?
|
|
100
|
+
- Check codebase for related patterns
|
|
101
|
+
- Document under \`### Pattern\`
|
|
102
|
+
|
|
103
|
+
### Phase 3: Hypothesis
|
|
104
|
+
- Formulate fix hypothesis
|
|
105
|
+
- Consider side effects of the fix
|
|
106
|
+
- Consider alternative approaches
|
|
107
|
+
- Determine minimal change needed
|
|
108
|
+
- Document under \`### Hypothesis\`
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
## Output
|
|
113
|
+
|
|
114
114
|
After completing, present the diagnosis and explicitly prompt the user to run \`/syn:propose\` to formalize the fix. Do NOT auto-create artifacts.`
|
|
115
|
-
};
|
|
115
|
+
});
|
|
116
116
|
}
|
|
117
117
|
//# sourceMappingURL=debug.js.map
|