@juancr11/sibu 0.12.1 → 0.12.2

package/package.json

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

package/templates/manifest.json

@@ -1,5 +1,5 @@
 {
-  "templateVersion": "93",
+  "templateVersion": "94",
   "templates": {
     "AGENTS.md": {
       "version": "28",
@@ -72,10 +72,10 @@
       ]
     },
     "skills/technical-design-writer/SKILL.md": {
-      "version": "17",
+      "version": "18",
       "description": "Mandatory technical design writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Adds optional Notion export guidance after local technical designs are written while keeping Markdown as the canonical artifact."
+        "Strengthens technical design interviews to resolve material implementation questions before drafting and replaces open questions with risks/tradeoffs."
       ]
     },
     "skills/typescript/SKILL.md": {
@@ -156,10 +156,10 @@
       ]
     },
     "skills/ux-expert/SKILL.md": {
-      "version": "7",
+      "version": "8",
       "description": "Selectable UX expert skill for UI-changing features, responsive design, flows, states, accessibility, and binding mockups.",
       "changes": [
-        "Adds optional Notion export guidance after local UX specs are written while keeping Markdown as the canonical artifact."
+        "Strengthens UX interviews to resolve material experience questions before drafting and replaces open UX questions with risks/tradeoffs."
       ]
     }
   }

package/templates/skills/technical-design-writer/SKILL.md

@@ -62,6 +62,20 @@ Require the feature brief to name one or more existing Deep Modules. Preserve th
 
 If the feature has UI impact, require `docs/features/<feature-slug>/ux.md`. If it is missing, stop and ask the user to create the UX spec with `ux-expert` first.
 
+## Interview posture
+
+Be deliberately interrogative before drafting. The technical design should reflect resolved implementation direction, not risky assistant assumptions.
+
+- Ask one focused question at a time when repository artifacts and source docs do not resolve a material technical ambiguity.
+- Ask as many questions as required to reach complete practical understanding; do not optimize for a short interview.
+- 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.
+- When useful, provide your recommended answer or a concise default assumption with the question so the user can confirm, correct, or reject it quickly.
+- Treat "enough context" as: selected Deep Modules, affected code paths, entrypoints, implementation boundaries, important state/data changes, validation approach, and meaningful risks are clear enough to defend in the design.
+- If the user gives a partial answer, acknowledge the useful part and ask the next most important unresolved question.
+- Do not ask a large questionnaire all at once.
+- Do not draft a technical design with an `Open Questions` section; resolve material questions during the interview, or record only known risks/tradeoffs after decisions are made.
+
 ## UX binding rule
 
 For UI-related features, `ux.md` is source context, not inspiration. If `ux.md` includes mockups, treat those mockups as binding UI goals for structure, hierarchy, visible content, dominant interactions, major visual emphasis, and breakpoint-specific layout. Do not redesign the mockups in the technical design. Translate them into implementation direction and call out only technical feasibility issues, missing states, or conflicts that require UX revision.
@@ -79,7 +93,7 @@ Prefer:
 - concise decisions over long explanation
 - concrete file/module impact over abstract architecture language
 - current codebase patterns over speculative redesigns
-- explicit open questions over risky assumptions
+- asking enough focused follow-up questions to resolve material ambiguity before drafting
 - delegation to the right skills instead of duplicating their guidance
 - preserving the feature brief's selected Deep Modules
 
@@ -108,8 +122,9 @@ Examples:
 1. Read the required grounding artifacts.
 2. Inspect the relevant existing code before proposing changes.
 3. Identify only the implementation decisions that matter.
-4. Write the doc at `docs/features/<feature-slug>/technical_design.md`.
-5. Keep it concise. Remove any section that does not help implementation.
+4. Ask one focused follow-up question at a time until material technical ambiguity is resolved.
+5. Write the doc at `docs/features/<feature-slug>/technical_design.md`.
+6. Keep it concise. Remove any section that does not help implementation.
 
 ## Output location
 
@@ -150,8 +165,8 @@ Use this structure as a starting point. Delete sections that do not add value.
 ## Validation
 <Focused test/build/manual checks.>
 
-## Risks / Open Questions
-- <Only unresolved decisions or meaningful risks.>
+## Risks / Tradeoffs
+- <Only meaningful risks or tradeoffs that remain after decisions are resolved.>
 ```
 
 ## Quality bar

package/templates/skills/ux-expert/SKILL.md

@@ -41,6 +41,20 @@ Read `docs/product-vision.md` and apply only relevant implications: target user,
 
 Require a product artifact such as `docs/features/<feature-slug>/feature_brief.md` that defines goal, scope, and acceptance criteria. If the user has only an idea, route to `feature-brief-writer` first. If the artifact says there is no UI impact, say so and do not invent UI work.
 
+## Interview posture
+
+Be deliberately interrogative before drafting. The UX spec should reflect resolved experience direction, not assistant-invented assumptions.
+
+- Ask one focused question at a time when product artifacts do not resolve a material UX ambiguity.
+- Ask as many questions as required to reach complete practical understanding; do not optimize for a short interview.
+- 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.
+- When useful, provide your recommended answer or a concise default assumption with the question so the user can confirm, correct, or reject it quickly.
+- Treat "enough context" as: affected surfaces, target user flow, content priority, primary actions, responsive behavior, critical states, accessibility constraints, visual direction, and meaningful UX risks are clear enough to defend in the spec and mockups.
+- If the user gives a partial answer, acknowledge the useful part and ask the next most important unresolved question.
+- Do not ask a large questionnaire all at once.
+- Do not draft a UX spec with an `Open Questions` section; resolve material questions during the interview, or record only known risks/tradeoffs after decisions are made.
+
 ## Mockup authority rule
 
 For UI-changing features, the UX artifact must include concrete mockups for affected screens, states, and breakpoints. Mockups are the source of truth for structure, hierarchy, visible content, dominant interactions, and major visual emphasis; downstream technical design, stories, implementation plans, and implementation must follow them unless this UX spec is revised. UX work is incomplete if a materially affected state/breakpoint lacks a mockup.
@@ -64,8 +78,9 @@ Design phone first, then re-evaluate tablet and desktop separately. Choose diffe
 3. Design phone-first flow, information architecture, and layout.
 4. Re-evaluate tablet and desktop independently.
 5. Define interaction states, failure/recovery behavior, accessibility requirements, and creative direction.
-6. Create concrete mockups for primary screens, affected breakpoints, and critical states.
-7. Write implementation-ready UX guidance only: flows, hierarchy, states, accessibility, visual direction.
+6. Ask one focused follow-up question at a time until material UX ambiguity is resolved.
+7. Create concrete mockups for primary screens, affected breakpoints, and critical states.
+8. Write implementation-ready UX guidance only: flows, hierarchy, states, accessibility, visual direction.
 
 ## Output location
 
@@ -112,8 +127,8 @@ Use only helpful sections from this shape:
 ## Visual Direction
 ## Creative Opportunities
 ## Implementation Notes
+## Risks / Tradeoffs
 ## UI Authority Rule
-## Open UX Questions
 ```
 
 The Binding Mockups section is authoritative for downstream work unless this UX spec is revised.