@juancr11/sibu 0.14.0 → 0.15.1

package/bin/admin/release.js

@@ -1,6 +1,6 @@
 #!/usr/bin/env node
 import { createInterface } from 'node:readline/promises';
-import { execFileSync } from 'node:child_process';
+import { execFileSync, spawnSync } from 'node:child_process';
 import fs from 'node:fs';
 import { fileURLToPath } from 'node:url';
 import { previewAndConfirmMaintainerRelease } from '../modules/maintainer-release-support/release-workflow/handler.js';
@@ -166,6 +166,20 @@ function createTerminalPorts() {
                 return commandFailure(error);
             }
         },
+        runInteractive(command, args) {
+            const result = spawnSync(command, args, {
+                stdio: 'inherit',
+            });
+            if (result.error) {
+                return {
+                    exitCode: 1,
+                    stderr: result.error.message,
+                };
+            }
+            return {
+                exitCode: result.status ?? 1,
+            };
+        },
     };
 }
 function printExecutionResult(result, ports) {

package/bin/modules/maintainer-release-support/release-workflow/handler.js

@@ -207,8 +207,9 @@ export async function executeConfirmedRelease(plan, ports) {
     }
     const npmPublishArgs = buildNpmPublishArgs(plan);
     const npmPublishLog = plan.hasOtp ? 'npm publish --access public --otp ******' : 'npm publish --access public';
-    printExecutionProgress(ports, `Publishing package to npm: ${npmPublishLog}...`);
-    const npmPublish = await ports.run('npm', npmPublishArgs);
+    const npmPublishMode = plan.hasOtp ? 'captured OTP publish' : 'interactive browser/2FA-capable publish';
+    printExecutionProgress(ports, `Publishing package to npm: ${npmPublishLog} (${npmPublishMode})...`);
+    const npmPublish = await runNpmPublish(ports, npmPublishArgs, plan);
     if (npmPublish.exitCode !== 0) {
         const failure = failExecution(completedSteps, 'publish-npm', 'Publishing to npm failed.', npmPublish);
         printExecutionFailure(ports, failure);
@@ -272,6 +273,12 @@ function buildNpmPublishArgs(plan) {
     }
     return args;
 }
+function runNpmPublish(ports, args, plan) {
+    if (plan.hasOtp || !ports.runInteractive) {
+        return ports.run('npm', args);
+    }
+    return ports.runInteractive('npm', args);
+}
 async function runStep(ports, completedSteps, stepName, startMessage, command, args, completedMessage) {
     printExecutionProgress(ports, startMessage);
     const result = await ports.run(command, args);

package/package.json

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

package/templates/manifest.json

@@ -1,5 +1,5 @@
 {
-  "templateVersion": "103",
+  "templateVersion": "104",
   "templates": {
     "AGENTS.md": {
       "version": "30",
@@ -51,31 +51,31 @@
       ]
     },
     "skills/product-vision-writer/SKILL.md": {
-      "version": "8",
+      "version": "9",
       "description": "Mandatory product vision writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Strengthens product vision interviews to resolve material strategy questions before drafting instead of leaving uncertainty in the artifact."
+        "Makes product vision discovery mandatory before drafting, even when existing context looks complete."
       ]
     },
     "skills/deep-module-map-writer/SKILL.md": {
-      "version": "4",
+      "version": "5",
       "description": "Mandatory Deep Module Map writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Adds explicit Deep Module Map discovery guidance so agents keep interviewing one question at a time until module interfaces, hidden complexity, ownership, exclusions, scenarios, relationships, and cross-module rules are clear enough to defend."
+        "Makes Deep Module Map interviews mandatory before drafting, even when repo code or existing docs look complete."
       ]
     },
     "skills/feature-brief-writer/SKILL.md": {
-      "version": "13",
+      "version": "14",
       "description": "Mandatory feature brief writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Keeps feature brief writing focused on local Markdown artifacts and moves Notion export workflow guidance to dedicated exporter skills."
+        "Makes feature brief interviews mandatory before drafting while keeping export workflows delegated to dedicated exporter skills."
       ]
     },
     "skills/technical-design-writer/SKILL.md": {
-      "version": "19",
+      "version": "20",
       "description": "Mandatory technical design writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Keeps technical design writing focused on local Markdown artifacts and moves Notion export workflow guidance to dedicated exporter skills."
+        "Makes technical design clarification mandatory before drafting while keeping export workflows delegated to dedicated exporter skills."
       ]
     },
     "skills/typescript/SKILL.md": {
@@ -163,10 +163,10 @@
       ]
     },
     "skills/ux-expert/SKILL.md": {
-      "version": "9",
+      "version": "10",
       "description": "Selectable UX expert skill for UI-changing features, responsive design, flows, states, accessibility, and binding mockups.",
       "changes": [
-        "Keeps UX design writing focused on local Markdown artifacts and moves Notion export workflow guidance to dedicated exporter skills."
+        "Makes UX clarification mandatory before drafting while keeping export workflows delegated to dedicated exporter skills."
       ]
     },
     "skills/architecture/layered-architecture/SKILL.md": {

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

@@ -35,7 +35,7 @@ This skill owns the Deep Module Map only. It does not own feature briefs, techni
 
 - Do not create feature briefs, technical designs, UX specs, Epics, User Stories, implementation plans, or production code.
 - Do not choose a specific internal architecture, service split, database model, framework, or team ownership structure.
-- Do not ask for or require a final confirmation summary before writing once enough Deep Module Map information is available.
+- Do not skip the interview or the final “I am clear; are you good?” check-in before writing. Once the user confirms there is nothing else to cover, write without requiring a recap, artifact approval, or separate summary confirmation.
 - 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.
@@ -125,6 +125,8 @@ This file is user-owned product and implementation-boundary content created or u
 
 Be deliberately interrogative before writing.
 
+This interview is mandatory and non-skippable. Even when the repository has substantial code, existing docs, an existing map, or extensive initial context, ask at least one explicit user-facing discovery question before drafting or writing the Deep Module Map. Treat code, repository artifacts, prior conversation, and initial context as useful but provisional: they can shape better questions, but they must not replace the interview or become the full source of truth for module boundaries, interfaces, hidden complexity, or ownership. Keep asking focused follow-up questions until the module decisions are clear enough to defend. Before drafting, always perform one final check-in in the spirit of: “I am clear on my end. Are you good, or is there anything else you want to cover before I proceed?” If the user adds context, incorporate or clarify it 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; do not optimize for a short interview.
 - Walk down each module-boundary decision branch one by one, resolving dependencies between candidate modules before drafting.

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

@@ -36,7 +36,7 @@ This skill owns the product/business shape of a feature. It does not own UI inte
 
 - Do not create or update Deep Module Maps, technical designs, UX specs, Epics, User Stories, implementation plans, or production code.
 - 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 skip the interview or the final “I am clear; are you good?” check-in before writing. Once the user confirms there is nothing else to cover, write without requiring a recap, artifact approval, or separate summary confirmation.
 - 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.
 
@@ -110,6 +110,8 @@ If the user asks for a feature brief from an idea in `docs/feature-ideas.md`, re
 
 Be deliberately interrogative before drafting. The feature brief should reflect the user's intent, not the assistant's assumptions.
 
+This interview is mandatory and non-skippable. Even when the user provides extensive initial context, existing docs, repo code, or a raw idea file, ask at least one explicit user-facing discovery question before drafting or writing the feature brief. Treat repository artifacts, prior conversation, existing product docs, and initial context as useful but provisional: they can shape better questions, but they must not replace the interview or become the full source of truth for feature intent, scope, success, constraints, or user value. Keep asking focused follow-up questions until the feature decisions are clear enough to defend. Before drafting, always perform one final check-in in the spirit of: “I am clear on my end. Are you good, or is there anything else you want to cover before I proceed?” If the user adds context, incorporate or clarify it before writing.
+
 - Ask one focused question at a time.
 - 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.

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

@@ -33,14 +33,16 @@ Default output path: `docs/product-vision.md`.
 ### What this skill must not do
 
 - 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 skip the interview or the final “I am clear; are you good?” check-in before writing. Once the user confirms there is nothing else to cover, write without requiring a recap, artifact approval, or separate summary confirmation.
 - 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
 
-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.
+Interview before writing. Be deliberately interrogative: ask as many focused questions as needed to extract all material product vision decisions before drafting.
+
+This interview is mandatory and non-skippable. Even when the user provides extensive initial context, existing documents, or a mature codebase, ask at least one explicit user-facing discovery question before drafting or writing the product vision. Treat repository artifacts, prior conversation, and initial context as useful but provisional: they can shape better questions, but they must not replace the interview or become the full source of truth for the user's product intent. Keep asking focused follow-up questions until the material product vision decisions are clear enough to defend. Before drafting, always perform one final check-in in the spirit of: “I am clear on my end. Are you good, or is there anything else you want to cover before I proceed?” If the user adds context, incorporate or clarify it before writing.
 
 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.
 

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

@@ -36,7 +36,7 @@ Write the smallest useful technical design doc for an approved feature: enough f
 - Do not invent new Deep Modules or move work into unselected modules.
 - Do not redesign binding UX mockups.
 - Do not duplicate architecture, language, framework, or clean-code skill guidance.
-- Do not require a final confirmation summary before writing once enough technical design context is available.
+- Do not skip the interview or the final “I am clear; are you good?” check-in before writing. Once the user confirms there is nothing else to cover, write without requiring a recap, artifact approval, or separate summary confirmation.
 
 ## Grounding
 
@@ -66,6 +66,8 @@ If the feature has UI impact, require `docs/features/<feature-slug>/ux.md`. If i
 
 Be deliberately interrogative before drafting. The technical design should reflect resolved implementation direction, not risky assistant assumptions.
 
+This interview is mandatory and non-skippable. Even when the approved artifacts, repo files, codebase, or prior conversation seem complete, ask at least one explicit user-facing technical clarification question before drafting or writing the technical design. Treat repository artifacts, source docs, prior conversation, and initial context as useful but provisional for current implementation intent: they can shape better questions, but they must not replace the interview or become the full source of truth for implementation direction, boundaries, risks, or validation choices. Keep asking focused follow-up questions until the technical decisions are clear enough to defend. Before drafting, always perform one final check-in in the spirit of: “I am clear on my end. Are you good, or is there anything else you want to cover before I proceed?” If the user adds context, incorporate or clarify it before writing.
+
 - 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.

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

@@ -33,7 +33,7 @@ Act as a senior UX/UI designer. Turn an approved product artifact into usable, e
 - Do not create or update product visions, Deep Module Maps, feature briefs, technical designs, Epics, User Stories, implementation plans, or production code.
 - Do not make architecture, framework, API, data model, or file-path decisions.
 - Do not treat UX work as optional for UI-changing features; concrete mockups are required.
-- Do not require a final confirmation summary before writing once enough UX context is available.
+- Do not skip the interview or the final “I am clear; are you good?” check-in before writing. Once the user confirms there is nothing else to cover, write without requiring a recap, artifact approval, or separate summary confirmation.
 
 ## Required grounding
 
@@ -45,6 +45,8 @@ Require a product artifact such as `docs/features/<feature-slug>/feature_brief.m
 
 Be deliberately interrogative before drafting. The UX spec should reflect resolved experience direction, not assistant-invented assumptions.
 
+This interview is mandatory and non-skippable. Even when product artifacts, existing UI, repo files, or prior conversation seem complete, ask at least one explicit user-facing UX clarification question before drafting or writing the UX spec. Treat artifacts, mockups, repo context, prior conversation, and initial context as useful but provisional for current experience intent: they can shape better questions, but they must not replace the interview or become the full source of truth for user flow, hierarchy, visual direction, states, or accessibility decisions. Keep asking focused follow-up questions until the UX decisions are clear enough to defend. Before drafting, always perform one final check-in in the spirit of: “I am clear on my end. Are you good, or is there anything else you want to cover before I proceed?” If the user adds context, incorporate or clarify it before writing.
+
 - 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.