@juancr11/sibu 0.9.3 → 0.9.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@juancr11/sibu",
-  "version": "0.9.3",
+  "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": "77",
+  "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": {

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