@juancr11/sibu 0.5.1 → 0.5.3
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/package.json +1 -1
- package/templates/manifest.json +15 -15
- package/templates/skills/ai-implementation-plan-executor/SKILL.md +6 -1
- package/templates/skills/ai-implementation-planner/SKILL.md +2 -2
- package/templates/skills/feature-brief-writer/SKILL.md +2 -2
- package/templates/skills/product-vision-writer/SKILL.md +2 -2
- package/templates/skills/scrum-master-planner/SKILL.md +2 -2
- package/templates/skills/technical-design-writer/SKILL.md +3 -1
- package/templates/skills/ux-expert/SKILL.md +3 -1
package/package.json
CHANGED
package/templates/manifest.json
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"templateVersion": "
|
|
2
|
+
"templateVersion": "55",
|
|
3
3
|
"templates": {
|
|
4
4
|
"AGENTS.md": {
|
|
5
5
|
"version": "22",
|
|
@@ -38,24 +38,24 @@
|
|
|
38
38
|
]
|
|
39
39
|
},
|
|
40
40
|
"skills/product-vision-writer/SKILL.md": {
|
|
41
|
-
"version": "
|
|
41
|
+
"version": "5",
|
|
42
42
|
"description": "Mandatory product vision writer skill installed once at the shared .agents/skills workspace path.",
|
|
43
43
|
"changes": [
|
|
44
|
-
"
|
|
44
|
+
"Strengthens final response rules so saved product visions report only the path unless inline review is explicitly requested."
|
|
45
45
|
]
|
|
46
46
|
},
|
|
47
47
|
"skills/feature-brief-writer/SKILL.md": {
|
|
48
|
-
"version": "
|
|
48
|
+
"version": "4",
|
|
49
49
|
"description": "Mandatory feature brief writer skill installed once at the shared .agents/skills workspace path.",
|
|
50
50
|
"changes": [
|
|
51
|
-
"
|
|
51
|
+
"Strengthens final response rules so saved feature briefs report only the path unless inline review is explicitly requested."
|
|
52
52
|
]
|
|
53
53
|
},
|
|
54
54
|
"skills/technical-design-writer/SKILL.md": {
|
|
55
|
-
"version": "
|
|
55
|
+
"version": "12",
|
|
56
56
|
"description": "Mandatory technical design writer skill installed once at the shared .agents/skills workspace path.",
|
|
57
57
|
"changes": [
|
|
58
|
-
"
|
|
58
|
+
"Strengthens final response rules so saved technical designs report only the path and never include excerpts unless inline review is explicitly requested."
|
|
59
59
|
]
|
|
60
60
|
},
|
|
61
61
|
"skills/typescript/SKILL.md": {
|
|
@@ -101,24 +101,24 @@
|
|
|
101
101
|
]
|
|
102
102
|
},
|
|
103
103
|
"skills/scrum-master-planner/SKILL.md": {
|
|
104
|
-
"version": "
|
|
104
|
+
"version": "5",
|
|
105
105
|
"description": "Mandatory Scrum planner skill for creating pragmatic Epics and User Stories from approved feature and technical design docs.",
|
|
106
106
|
"changes": [
|
|
107
|
-
"
|
|
107
|
+
"Strengthens final response rules so generated Epics and Stories are summarized by paths and counts, not pasted inline unless explicitly requested."
|
|
108
108
|
]
|
|
109
109
|
},
|
|
110
110
|
"skills/ai-implementation-planner/SKILL.md": {
|
|
111
|
-
"version": "
|
|
111
|
+
"version": "7",
|
|
112
112
|
"description": "Mandatory AI implementation planner skill for turning one approved User Story into small, story-local implementation step files.",
|
|
113
113
|
"changes": [
|
|
114
|
-
"
|
|
114
|
+
"Strengthens final response rules so generated implementation step files are listed by path, not pasted inline unless explicitly requested."
|
|
115
115
|
]
|
|
116
116
|
},
|
|
117
117
|
"skills/ai-implementation-plan-executor/SKILL.md": {
|
|
118
|
-
"version": "
|
|
118
|
+
"version": "12",
|
|
119
119
|
"description": "Mandatory AI implementation plan executor skill for implementing existing story implementation plans one reviewed step at a time.",
|
|
120
120
|
"changes": [
|
|
121
|
-
"Clarifies
|
|
121
|
+
"Clarifies focused approved-step commits and validation-only step reporting."
|
|
122
122
|
]
|
|
123
123
|
},
|
|
124
124
|
"skills/ai-prompt-engineer-master/SKILL.md": {
|
|
@@ -129,10 +129,10 @@
|
|
|
129
129
|
]
|
|
130
130
|
},
|
|
131
131
|
"skills/ux-expert/SKILL.md": {
|
|
132
|
-
"version": "
|
|
132
|
+
"version": "4",
|
|
133
133
|
"description": "Selectable UX expert skill for UI-changing features, responsive design, flows, states, accessibility, and binding mockups.",
|
|
134
134
|
"changes": [
|
|
135
|
-
"
|
|
135
|
+
"Strengthens final response rules so saved UX specs report only the path and never include mockups or excerpts unless inline review is explicitly requested."
|
|
136
136
|
]
|
|
137
137
|
}
|
|
138
138
|
}
|
|
@@ -119,7 +119,11 @@ When the user explicitly approves the current step, update that step file by add
|
|
|
119
119
|
- Approved at: <ISO-8601 timestamp>
|
|
120
120
|
```
|
|
121
121
|
|
|
122
|
-
Before writing the approval marker, identify the current Git user with `git config user.name`; if it is unavailable, use `git config user.email`. Use that value for `Approved by`.
|
|
122
|
+
Before writing the approval marker, identify the current Git user with `git config user.name`; if it is unavailable, use `git config user.email`. Use that value for `Approved by`.
|
|
123
|
+
|
|
124
|
+
After writing the approval marker, commit only the changes produced by the approved step before continuing. The commit must include the step file approval marker and files intentionally changed while implementing that step. It must not include unrelated local edits, pre-existing worktree changes, or changes from other steps. Use the files tracked during step execution and a focused `git status --short` check to stage the correct paths. Do not run broad `git diff` investigations or other "what changed?" archaeology unless it is required to avoid committing unrelated changes and the user has approved that extra inspection.
|
|
125
|
+
|
|
126
|
+
Use a Conventional Commits 1.0.0 message that describes the completed step. If the commit fails, stop and report the failure instead of continuing.
|
|
123
127
|
|
|
124
128
|
Then continue with the next unapproved step immediately, without asking for another pre-implementation confirmation, only after the approval marker is written and the approved step changes are committed.
|
|
125
129
|
|
|
@@ -162,6 +166,7 @@ Do not:
|
|
|
162
166
|
After implementing one step, briefly report:
|
|
163
167
|
|
|
164
168
|
- that the step finished
|
|
169
|
+
- if the step was validation-only and produced no code changes, say that it was just a validation step and all validations passed
|
|
165
170
|
- current step file path
|
|
166
171
|
- the next step file path, or that no next step remains
|
|
167
172
|
- that you are waiting for user approval before marking the step approved, committing it, and continuing to the next step
|
|
@@ -204,11 +204,11 @@ Before finishing, verify:
|
|
|
204
204
|
|
|
205
205
|
## Final response behavior
|
|
206
206
|
|
|
207
|
-
After writing the files,
|
|
207
|
+
After writing the files, final-answer with only:
|
|
208
208
|
|
|
209
209
|
- the implementation plan folder path
|
|
210
210
|
- the step file paths created
|
|
211
211
|
- the source User Story path
|
|
212
212
|
- any risks or stop conditions captured in the step files
|
|
213
213
|
|
|
214
|
-
Do not paste
|
|
214
|
+
Do not paste step-file bodies, excerpts, outlines, task text, done conditions, or section summaries. Only include generated step files when the user explicitly asks for inline review in the current request.
|
|
@@ -210,6 +210,6 @@ When shaping a feature brief, prefer:
|
|
|
210
210
|
|
|
211
211
|
## Final response behavior
|
|
212
212
|
|
|
213
|
-
After writing the file,
|
|
213
|
+
After writing the file, final-answer with only the path created or updated. Do not paste the feature brief body, excerpt, outline, or section summaries.
|
|
214
214
|
|
|
215
|
-
If file writes are unavailable, provide the Markdown content and state that it is intended for `docs/features/<feature-slug>/feature_brief.md`.
|
|
215
|
+
Only include the full feature brief when the user explicitly asks for inline review in the current request. If file writes are unavailable, provide the Markdown content and state that it is intended for `docs/features/<feature-slug>/feature_brief.md`.
|
|
@@ -111,6 +111,6 @@ If the user explicitly requests a different path, use that path instead.
|
|
|
111
111
|
|
|
112
112
|
### 7. Final response behavior
|
|
113
113
|
|
|
114
|
-
After writing the file,
|
|
114
|
+
After writing the file, final-answer with only the path created or updated. Do not paste the document body, excerpt, outline, or section summaries.
|
|
115
115
|
|
|
116
|
-
If file writes are unavailable, provide the Markdown content and state that it is intended for `docs/product-vision.md`.
|
|
116
|
+
Only include the full document when the user explicitly asks for inline review in the current request. If file writes are unavailable, provide the Markdown content and state that it is intended for `docs/product-vision.md`.
|
|
@@ -183,10 +183,10 @@ Before finishing, verify:
|
|
|
183
183
|
|
|
184
184
|
## Final response behavior
|
|
185
185
|
|
|
186
|
-
After writing files,
|
|
186
|
+
After writing files, final-answer with only:
|
|
187
187
|
|
|
188
188
|
- the Epic directories created or updated
|
|
189
189
|
- the number of Epics and User Stories
|
|
190
190
|
- any source-scope items intentionally left unresolved or captured as risks
|
|
191
191
|
|
|
192
|
-
Do not paste
|
|
192
|
+
Do not paste artifact bodies, excerpts, outlines, story text, acceptance criteria, or section summaries. Only include generated artifacts when the user explicitly asks for inline review in the current request.
|
|
@@ -113,4 +113,6 @@ A good technical design is short, specific, and useful. It should not try to be
|
|
|
113
113
|
|
|
114
114
|
## Final response behavior
|
|
115
115
|
|
|
116
|
-
After writing the file,
|
|
116
|
+
After writing the file, final-answer with only the path created or updated. Do not paste the technical design body, excerpt, outline, or section summaries.
|
|
117
|
+
|
|
118
|
+
Only include the full technical design when the user explicitly asks for inline review in the current request.
|
|
@@ -92,4 +92,6 @@ The Binding Mockups section is authoritative for downstream work unless this UX
|
|
|
92
92
|
|
|
93
93
|
## Final response behavior
|
|
94
94
|
|
|
95
|
-
After writing the file,
|
|
95
|
+
After writing the file, final-answer with only the path created or updated. Do not paste the UX spec body, excerpt, outline, mockups, or section summaries.
|
|
96
|
+
|
|
97
|
+
Only include the full UX spec when the user explicitly asks for inline review in the current request.
|