@juancr11/sibu 0.5.0 → 0.5.2

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 CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@juancr11/sibu",
3
- "version": "0.5.0",
3
+ "version": "0.5.2",
4
4
  "description": "CLI for setting up a local AI-augmented development workflow.",
5
5
  "repository": {
6
6
  "type": "git",
@@ -36,7 +36,8 @@
36
36
  "validate:packed-runtime": "node ./scripts/validate-packed-cli-runtime.mjs",
37
37
  "validate:doctor-version-advisory": "pnpm build && node ./scripts/validate-doctor-version-advisory.mjs",
38
38
  "validate:post-update-doctor-drift": "pnpm build && node ./scripts/validate-post-update-doctor-drift.mjs",
39
- "validate:release": "pnpm verify && npm pack && pnpm run validate:packed-runtime && pnpm run validate:doctor-version-advisory && pnpm run validate:post-update-doctor-drift",
39
+ "validate:release-publish": "pnpm verify && npm pack && pnpm run validate:packed-runtime",
40
+ "validate:release": "pnpm run validate:release-publish && pnpm run validate:doctor-version-advisory && pnpm run validate:post-update-doctor-drift",
40
41
  "admin:release": "node ./bin/admin/release.js"
41
42
  },
42
43
  "keywords": [
@@ -19,6 +19,14 @@
19
19
  - Ask again only if the scope changes materially, the approach becomes materially more complex or risky, or the user explicitly asks to review before continuing.
20
20
  - Use Conventional Commits 1.0.0 for commit messages.
21
21
 
22
+ ## Context budget discipline
23
+
24
+ Treat context as a shared budget owned by the user. Prefer narrow, purposeful context before broad reads: search targeted paths, inspect snippets before full files, and avoid dependency, generated, build, cache, and lockfile content unless relevant.
25
+
26
+ Do not dump full files, full diffs, broad recursive scans, or uncapped command output unless needed for quality or explicitly requested. Summarize large diffs, logs, command output, and generated artifacts by default, with focused excerpts when they support a decision.
27
+
28
+ Keep responses concise by default, but spend the context needed for correctness, safety, validation, human control, or required context gathering. Warn or ask before optional expensive context operations.
29
+
22
30
  ## Communication style
23
31
 
24
32
  - Keep responses as short as practical while still being clear and useful.
@@ -1,11 +1,11 @@
1
1
  {
2
- "templateVersion": "49",
2
+ "templateVersion": "54",
3
3
  "templates": {
4
4
  "AGENTS.md": {
5
- "version": "21",
5
+ "version": "22",
6
6
  "description": "Project-level agent instructions and Sibu maintenance guidance.",
7
7
  "changes": [
8
- "Tightens Sibu maintenance outcome guidance while preserving startup health checks, safety, confirmation, routing, and workflow repair instructions."
8
+ "Adds concise context-budget discipline so agents prefer narrow reads, summarize large outputs, and preserve quality over token savings."
9
9
  ]
10
10
  },
11
11
  ".codex/config.toml": {
@@ -52,10 +52,10 @@
52
52
  ]
53
53
  },
54
54
  "skills/technical-design-writer/SKILL.md": {
55
- "version": "10",
55
+ "version": "11",
56
56
  "description": "Mandatory technical design writer skill installed once at the shared .agents/skills workspace path.",
57
57
  "changes": [
58
- "Compresses technical-design wording while preserving required grounding, UX binding, delegation boundaries, output location, and smallest-useful-design guidance."
58
+ "Tightens final responses so technical design updates report only the output path unless inline review is requested."
59
59
  ]
60
60
  },
61
61
  "skills/typescript/SKILL.md": {
@@ -115,10 +115,10 @@
115
115
  ]
116
116
  },
117
117
  "skills/ai-implementation-plan-executor/SKILL.md": {
118
- "version": "8",
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
- "Adds context reuse guidance so story implementation plans load broad context once, then continue step-by-step using cached context unless scope, validation, or file changes require rereading."
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": "2",
132
+ "version": "3",
133
133
  "description": "Selectable UX expert skill for UI-changing features, responsive design, flows, states, accessibility, and binding mockups.",
134
134
  "changes": [
135
- "Compresses UX guidance while preserving product grounding, no-code boundary, phone-first design, output location, concrete mockup requirements, and binding downstream mockup authority."
135
+ "Tightens final responses so UX spec updates report only the output path unless inline review is 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`. After writing the approval marker, commit all changes for the approved step before continuing. 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.
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
 
@@ -161,10 +165,10 @@ Do not:
161
165
 
162
166
  After implementing one step, briefly report:
163
167
 
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
164
170
  - current step file path
165
- - summary of changes made
166
- - validation run and result
167
- - any risks, blockers, or follow-up questions
171
+ - the next step file path, or that no next step remains
168
172
  - that you are waiting for user approval before marking the step approved, committing it, and continuing to the next step
169
173
 
170
174
  After approving and committing the final step in a story implementation plan, also briefly report the Epic continuation check result:
@@ -110,3 +110,7 @@ Use this structure as a starting point. Delete sections that do not add value.
110
110
  ## Quality bar
111
111
 
112
112
  A good technical design is short, specific, and useful. It should not try to be the product brief, architecture skill, clean-code skill, implementation plan, or ticket backlog.
113
+
114
+ ## Final response behavior
115
+
116
+ After writing the file, report only the path. Do not paste the full technical design unless the user asks to review it inline.
@@ -89,3 +89,7 @@ Use only helpful sections from this shape:
89
89
  ```
90
90
 
91
91
  The Binding Mockups section is authoritative for downstream work unless this UX spec is revised.
92
+
93
+ ## Final response behavior
94
+
95
+ After writing the file, report only the path. Do not paste the full UX spec unless the user asks to review it inline.