@juancr11/sibu 0.9.2 → 0.9.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@juancr11/sibu",
-  "version": "0.9.2",
+  "version": "0.9.4",
   "description": "CLI for setting up a local AI-augmented development workflow.",
   "repository": {
     "type": "git",

package/templates/manifest.json

@@ -1,5 +1,5 @@
 {
-  "templateVersion": "76",
+  "templateVersion": "78",
   "templates": {
     "AGENTS.md": {
       "version": "25",
@@ -52,25 +52,24 @@
       ]
     },
     "skills/product-vision-writer/SKILL.md": {
-      "version": "7",
+      "version": "8",
       "description": "Mandatory product vision writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Updates downstream artifact wording to use Deep Module Map."
+        "Strengthens product vision interviews to resolve material strategy questions before drafting instead of leaving uncertainty in the artifact."
       ]
     },
     "skills/deep-module-map-writer/SKILL.md": {
-      "version": "2",
+      "version": "3",
       "description": "Mandatory Deep Module Map writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Clarifies that Deep Modules are primarily technical design boundaries that hide substantial implementation complexity behind simple interfaces.",
-        "Strengthens the interview flow so agents ask focused one-at-a-time questions until module interfaces, hidden complexity, and boundaries are defensible."
+        "Strengthens Deep Module Map interviews to ask as many one-at-a-time questions as needed and resolve material boundary questions before drafting."
       ]
     },
     "skills/feature-brief-writer/SKILL.md": {
-      "version": "8",
+      "version": "9",
       "description": "Mandatory feature brief writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Updates feature brief guidance to require Deep Modules from docs/deep-module-map.md."
+        "Removes Open Questions from the feature brief template and requires the interview to resolve material feature questions before drafting."
       ]
     },
     "skills/technical-design-writer/SKILL.md": {
@@ -145,12 +144,11 @@
       ]
     },
     "skills/ai-implementation-plan-executor/SKILL.md": {
-      "version": "16",
+      "version": "17",
       "description": "Mandatory AI implementation plan executor skill for implementing full story plans before story-level review and commit.",
       "changes": [
-        "Changes execution from per-step approval to full-story execution followed by one story-level review gate.",
-        "Marks all completed steps approved and commits once after the completed story is approved.",
-        "Continues Epics automatically by implementing the next planned story or planning the next unplanned story and waiting for plan approval."
+        "Prevents the executor from staging or committing Git-ignored story artifacts, including docs/features paths when ignored.",
+        "Clarifies that ignored approval marker changes remain local and commits include only eligible non-ignored story changes."
       ]
     },
     "skills/ai-prompt-engineer-master/SKILL.md": {

package/templates/skills/ai-implementation-plan-executor/SKILL.md

@@ -23,7 +23,7 @@ Execute one existing story implementation plan completely, one ordered step file
 
 - Code, docs, tests, or other repo changes required by all unapproved implementation steps in the story plan.
 - Step approval metadata in every completed step file only after explicit story-level user approval.
-- One focused commit for the approved story implementation.
+- One focused commit for the approved story implementation, excluding any paths ignored by Git.
 - When continuing an Epic and the next story has no plan, story-local implementation step files created by applying `ai-implementation-planner`.
 
 ### When this skill stops
@@ -160,7 +160,7 @@ When the user explicitly approves the completed story, update every step file co
 
 Before writing approval markers, 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 approval markers, commit only the changes produced by the approved story before continuing. The commit must include all step file approval markers and files intentionally changed while implementing the story. It must not include unrelated local edits or pre-existing worktree changes. Use the files tracked during story 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.
+After writing approval markers, commit only the non-ignored changes produced by the approved story before continuing. Do not attempt to stage or commit paths ignored by Git, including `docs/features/**` paths when the repository ignores them. The commit must include files intentionally changed while implementing the story that are eligible to be committed, and it must include step file approval markers only when those step files are not ignored. Ignored approval marker changes remain local and uncommitted; report that clearly. If every story change is ignored and there is nothing eligible to commit, skip the commit, report that no commit was created, and continue only according to the Epic continuation rules that do not depend on a commit hash. The commit must not include unrelated local edits or pre-existing worktree changes. Use the files tracked during story execution, `git check-ignore` when needed, 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.
 
 Use a Conventional Commits 1.0.0 message that describes the completed story. If the commit fails, stop and report the failure instead of continuing.
 
@@ -199,7 +199,8 @@ Do not:
 - add product scope absent from the story, Epic, feature brief, technical design, or step files
 - silently move work into unrelated or unapproved Deep Modules
 - continue past a failed validation without reporting it and asking how to proceed
-- leave approved story changes uncommitted before moving to the next story
+- leave committable approved story changes uncommitted before moving to the next story
+- attempt to stage or commit story files, approval markers, or other paths that are ignored by Git
 - execute a newly created next-story plan before the user approves that plan
 
 ## Final response behavior
@@ -211,10 +212,11 @@ After implementing all unapproved steps in one story, briefly report:
 - the steps completed
 - validations run and their results
 - notable risks or follow-up questions, if any
-- that you are waiting for story approval before marking all completed steps approved, committing, and continuing the Epic
+- that you are waiting for story approval before marking all completed steps approved, committing eligible non-ignored changes, and continuing the Epic
 
 After approving and committing a story implementation, briefly report the commit and the Epic continuation result:
 
+- commit hash when a commit was created, or a note that only ignored changes existed and no commit was created
 - next story is being implemented immediately because it already has a plan
 - next story was planned and is waiting for plan review and approval
 - or the Epic appears ready

package/templates/skills/deep-module-map-writer/SKILL.md

@@ -38,6 +38,7 @@ This skill owns the Deep Module Map only. It does not own feature briefs, techni
 - Do not ask for or require a final confirmation summary before writing once enough Deep Module Map information is available.
 - Do not invent Deep Modules without grounding them in the product vision, current system behavior, and user interview.
 - Do not treat a command, screen, helper, folder, data object, or technical layer as a Deep Module merely because it exists.
+- Do not leave material module-boundary questions unresolved in the final map; keep interviewing until the user answers, confirms an assumption, or explicitly excludes the boundary.
 
 ## What a Deep Module is
 
@@ -125,7 +126,10 @@ This file is user-owned product and implementation-boundary content created or u
 Be deliberately interrogative before writing.
 
 - Ask one focused question at a time.
-- Ask as many one-at-a-time questions as needed to understand the app well enough to defend the map.
+- Ask as many one-at-a-time questions as needed to understand the app well enough to defend the map; do not optimize for a short interview.
+- Walk down each module-boundary decision branch one by one, resolving dependencies between candidate modules before drafting.
+- When useful, provide your recommended answer or a concise default assumption with the question so the user can confirm, correct, or reject it quickly.
+- If a question can be answered by reading repository artifacts, inspect those artifacts instead of asking.
 - Do not rush to draft after a single answer unless the answer already makes interfaces, hidden complexity, boundaries, scenarios, and relationships clear.
 - Treat "enough context" as: candidate modules, suggested slugs, simple external interfaces, hidden implementation complexity, responsibilities, exclusions, scenarios, relationships, and cross-module rules are clear enough to defend.
 - Do not ask the user to name the Deep Modules up front. Most users do not know what the modules should be yet.
@@ -133,6 +137,7 @@ Be deliberately interrogative before writing.
 - Teach briefly as needed. If the user seems unsure, explain that a Deep Module hides a lot of implementation behind a simple interface, then ask the next question.
 - Do not create modules from vague labels without confirming what interface they expose and what complexity they hide.
 - If the conversation stalls, propose one concise assumption for the next unresolved point and ask the user to confirm or correct it.
+- Draft only when there are no material open questions about interfaces, hidden complexity, ownership, exclusions, relationships, or cross-module rules.
 
 ## Interview method
 

package/templates/skills/feature-brief-writer/SKILL.md

@@ -38,6 +38,7 @@ This skill owns the product/business shape of a feature. It does not own UI inte
 - Do not invent Deep Modules or use modules that are absent from `docs/deep-module-map.md`.
 - Do not require a final confirmation summary before writing once enough feature brief context is available.
 - Do not duplicate or rewrite the product vision; apply only the relevant implications to the feature.
+- Do not leave material product, scope, success, constraint, or Deep Module fit questions unresolved in the final brief; keep interviewing until the user answers, confirms an assumption, or explicitly excludes the topic.
 
 ## Required source of truth
 
@@ -99,7 +100,10 @@ Do not write the brief to technical design, UX, user story, implementation plan,
 Be deliberately interrogative before drafting. The feature brief should reflect the user's intent, not the assistant's assumptions.
 
 - Ask one focused question at a time.
-- Keep asking until you have complete practical understanding and explicit user alignment.
+- Keep asking until you have complete practical understanding and explicit user alignment; do not optimize for a short interview.
+- Walk down each feature decision branch one by one, resolving dependencies between product, scope, success, constraint, and module-fit decisions before drafting.
+- When useful, provide your recommended answer or a concise default assumption with the question so the user can confirm, correct, or reject it quickly.
+- If a question can be answered by reading repository artifacts, inspect those artifacts instead of asking.
 - Prefer follow-up questions over filling gaps with plausible invention.
 - Treat "100% understanding" as: feature intent, target user, scenario, user problem, business goal, MVP boundary, out-of-scope boundary, success signals, and known constraints are all clear enough to defend in the brief.
 - Treat "enough context" as: feature intent, target user/scenario, desired outcome, MVP boundary, out-of-scope boundary, success signals, constraints, and Deep Module fit are clear enough to defend in the brief.
@@ -165,9 +169,9 @@ Ask every question needed to remove material ambiguity, but only one at a time.
 - what outcome should improve
 - what must be included in the first version
 - what should stay out of scope
-- known constraints, risks, or open decisions
+- known constraints and risks
 
-Draft only once feature intent, target user/scenario, desired outcome, MVP boundary, out-of-scope boundary, success signals, constraints, and Deep Module fit are clear enough to avoid invention.
+Draft only once feature intent, target user/scenario, desired outcome, MVP boundary, out-of-scope boundary, success signals, constraints, and Deep Module fit are clear enough to avoid invention. Do not draft a brief with an `Open Questions` section.
 
 If the conversation stalls, offer a concise default assumption for the next unresolved point and ask the user to confirm or correct it before proceeding.
 
@@ -215,9 +219,6 @@ Recommended structure:
 
 ## Risks / Tradeoffs
 - <Important product, user, trust, operational, or positioning risks.>
-
-## Open Questions
-- <Decisions that still need user/product input.>
 ```
 
 Adapt the structure to the feature. Add, rename, merge, or omit sections when useful, but keep the result business-level and product-vision-aligned.
@@ -234,7 +235,7 @@ Do not include:
 - engineering task lists
 - UI wireframes or detailed interaction specs
 
-If technical or UX decisions come up, capture them as brief product-level constraints or open questions.
+If technical or UX decisions come up, either capture the resolved product-level implication as a constraint or ask follow-up questions before drafting. Do not add unresolved technical or UX decisions as open questions in the brief.
 
 ### 6. Save the document
 
@@ -267,6 +268,7 @@ Avoid:
 - drafting from vague feature labels without discovery
 - inventing new Deep Modules instead of stopping for a map update
 - inventing certainty where the product vision or user input is unresolved
+- including an Open Questions section instead of resolving the questions during the interview
 
 ## Decision rule
 

package/templates/skills/product-vision-writer/SKILL.md

@@ -34,13 +34,17 @@ Default output path: `docs/product-vision.md`.
 
 - Do not create Deep Module Maps, feature briefs, technical designs, UX specs, Epics, User Stories, implementation plans, or production code.
 - Do not require a final confirmation summary before writing once enough product vision context is available.
-- Do not pretend unresolved strategy questions are settled; ask a focused question or document a clear assumption.
+- Do not leave material strategy questions unresolved in the final document; keep interviewing until the user answers, confirms an assumption, or explicitly excludes the topic.
 
 ## Workflow
 
 ### 1. Start with discovery, not drafting
 
-Ask focused questions before writing unless the user already provided enough source material. Ask one question at a time and use the fewest questions that can produce a useful document. Cover these areas over the interview:
+Interview before writing unless the user already provided complete source material. Be deliberately interrogative: ask as many focused questions as needed to extract all material product vision decisions before drafting.
+
+Ask one question at a time. Walk down the product decision tree branch by branch, resolving dependencies between decisions before moving on. When useful, include a recommended answer or concise assumption so the user can confirm, correct, or reject it quickly. If a question can be answered from existing repository artifacts, inspect those artifacts instead of asking.
+
+Do not optimize for the fewest questions. Optimize for ending the interview with no material open product vision questions. Cover these areas over the interview:
 
 - **Product essence:** What is the product? What should it help people do, feel, or become?
 - **Current context:** Is this a new concept, an active project, or an existing product?
@@ -67,7 +71,7 @@ Before drafting, infer the product's through-line:
 - the product's opinion about the world
 - the decision-making principles that should survive future feature debates
 
-If the user's answers conflict, resolve the conflict explicitly in the draft by choosing the clearest product direction. Do not preserve every idea equally.
+If the user's answers conflict, ask follow-up questions until the conflict is resolved or the user confirms which direction should win. Do not preserve every idea equally.
 
 ### 3. Draft the product vision document
 
@@ -118,13 +122,13 @@ Avoid:
 - overexplaining
 - feature lists masquerading as vision
 - excessive frameworks
-- pretending unresolved strategy questions are settled
+- leaving unresolved strategy questions in the document
 
 Use the user's own language when it is vivid or revealing. Improve clarity without sanding off personality.
 
 ### 5. Handle incomplete inputs
 
-For rough ideas, produce a sharper first-pass vision with clear assumptions. For existing products, reflect what the product is today and what it must protect or change. If context is still insufficient, ask the smallest useful follow-up instead of inventing details.
+For rough ideas, keep interviewing until the user has confirmed enough assumptions to support a sharper first-pass vision. For existing products, reflect what the product is today and what it must protect or change. If context is still insufficient, ask the next most important follow-up instead of inventing details.
 
 ### 6. Save the document