@juancr11/sibu 0.13.2 → 0.15.1

package/bin/modules/workflow-target-planning/catalog.js

@@ -71,6 +71,15 @@ export const MANDATORY_SKILLS = [
             windsurf: '.agents/skills/ai-implementation-plan-executor/SKILL.md',
         },
     },
+    {
+        templateRelativePath: 'skills/feature-idea-capture/SKILL.md',
+        targetRelativePathsByAgent: {
+            codex: '.agents/skills/feature-idea-capture/SKILL.md',
+            gemini: '.agents/skills/feature-idea-capture/SKILL.md',
+            claude: '.agents/skills/feature-idea-capture/SKILL.md',
+            windsurf: '.agents/skills/feature-idea-capture/SKILL.md',
+        },
+    },
 ];
 export const SELECTABLE_LANGUAGE_SKILLS = [
     {
@@ -211,7 +220,60 @@ export const SELECTABLE_WORKFLOW_SKILLS = [
             windsurf: '.agents/skills/ux-expert/SKILL.md',
         },
     },
+    {
+        id: 'export-to-github',
+        name: 'Export to GitHub',
+        description: "Install guidance for exporting a named feature's Epics and User Stories to GitHub using the configured GitHub MCP server",
+        routingInstruction: "For exporting a feature's Epics and User Stories to GitHub issues or sub-issues, use `export-to-github`.",
+        templateRelativePath: 'skills/export-to-github/SKILL.md',
+        targetRelativePathsByAgent: {
+            codex: '.agents/skills/export-to-github/SKILL.md',
+            gemini: '.agents/skills/export-to-github/SKILL.md',
+            claude: '.agents/skills/export-to-github/SKILL.md',
+            windsurf: '.agents/skills/export-to-github/SKILL.md',
+        },
+    },
+    {
+        id: 'export-to-notion',
+        name: 'Export to Notion',
+        description: "Install guidance for exporting a named feature's feature brief, UX design, and technical design to Notion using the configured Notion MCP server",
+        routingInstruction: "For exporting a feature's feature brief, UX design, or technical design to Notion, use `export-to-notion`.",
+        templateRelativePath: 'skills/export-to-notion/SKILL.md',
+        targetRelativePathsByAgent: {
+            codex: '.agents/skills/export-to-notion/SKILL.md',
+            gemini: '.agents/skills/export-to-notion/SKILL.md',
+            claude: '.agents/skills/export-to-notion/SKILL.md',
+            windsurf: '.agents/skills/export-to-notion/SKILL.md',
+        },
+    },
 ];
+const EXPORT_WORKFLOW_SKILL_MCP_REQUIREMENTS = {
+    'export-to-github': 'github',
+    'export-to-notion': 'notion',
+};
+export function getMcpServersRequiredByWorkflowSkills(workflowSkillIds) {
+    const requiredServerIds = new Set();
+    for (const workflowSkillId of workflowSkillIds) {
+        const requiredServerId = getRequiredMcpServerIdForWorkflowSkill(workflowSkillId);
+        if (requiredServerId) {
+            requiredServerIds.add(requiredServerId);
+        }
+    }
+    return SELECTABLE_MCP_SERVERS.filter((server) => requiredServerIds.has(server.id));
+}
+export function getWorkflowSkillsImpliedByMcpServers(mcpServerIds) {
+    const selectedServerIds = new Set(mcpServerIds);
+    const impliedSkillIds = Object.entries(EXPORT_WORKFLOW_SKILL_MCP_REQUIREMENTS)
+        .filter(([, requiredServerId]) => selectedServerIds.has(requiredServerId))
+        .map(([workflowSkillId]) => workflowSkillId);
+    return SELECTABLE_WORKFLOW_SKILLS.filter((skill) => impliedSkillIds.includes(skill.id));
+}
+function getRequiredMcpServerIdForWorkflowSkill(workflowSkillId) {
+    if (workflowSkillId === 'export-to-github' || workflowSkillId === 'export-to-notion') {
+        return EXPORT_WORKFLOW_SKILL_MCP_REQUIREMENTS[workflowSkillId];
+    }
+    return undefined;
+}
 export const SELECTABLE_MCP_SERVERS = [
     {
         id: 'github',

package/bin/modules/workflow-target-planning/index.js

@@ -1,2 +1,2 @@
-export { MANDATORY_SKILLS, SELECTABLE_ARCHITECTURE_SKILLS, SELECTABLE_DATABASE_SKILLS, SELECTABLE_FRAMEWORK_SKILLS, SELECTABLE_LANGUAGE_SKILLS, SELECTABLE_MCP_SERVERS, SELECTABLE_WORKFLOW_SKILLS, SUPPORTED_AGENTS, resolveSelectableMcpServerById, resolveSelectableSkillById, } from './catalog.js';
+export { MANDATORY_SKILLS, SELECTABLE_ARCHITECTURE_SKILLS, SELECTABLE_DATABASE_SKILLS, SELECTABLE_FRAMEWORK_SKILLS, SELECTABLE_LANGUAGE_SKILLS, SELECTABLE_MCP_SERVERS, SELECTABLE_WORKFLOW_SKILLS, SUPPORTED_AGENTS, getMcpServersRequiredByWorkflowSkills, getWorkflowSkillsImpliedByMcpServers, resolveSelectableMcpServerById, resolveSelectableSkillById, } from './catalog.js';
 export { getSelectedAgentsFromState, getSelectedArchitectureSkillFromState, getSelectedDatabaseSkillsFromState, getSelectedFrameworkSkillsFromState, getSelectedLanguageSkillsFromState, getSelectedMcpServersFromState, getSelectedMcpTargetsForAgents, getSelectedSkillTargetsForAgents, getSelectedWorkflowSkillsFromState, getWorkflowTargets, renderMissingWorkflowFiles, writeSibuState, } from './workflow-targets.js';

package/package.json

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

package/templates/AGENTS.md

@@ -47,6 +47,7 @@ For planned product/feature work, use this pipeline: product vision -> deep modu
 - For requests to create Epics, User Stories, Scrum planning artifacts, backlog slices, or delivery plans from an approved feature brief and technical design, use `scrum-master-planner`.
 - For explicit planning-only requests to turn a specific User Story into an implementation checklist, coding plan, step-by-step execution plan, or baby-step plan without implementation, use `ai-implementation-planner` and stop after writing the plan. Treat a request as planning-only only when the user explicitly says planning-only, "do not implement," or asks to create the plan without execution.
 - For requests to plan, implement, execute, continue, or work through a specific User Story under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.md`, an Epic, or an existing story implementation plan under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.impl_plan/`, use `ai-implementation-plan-executor`; when the story plan is missing, the executor must create it with `ai-implementation-planner` and immediately continue into implementation without a separate plan approval gate.
+- For requests to capture, save, jot down, or add rough future feature ideas, use `feature-idea-capture`.
 {{OPTIONAL_SKILL_ROUTING}}
 
 ## Sibu maintenance

package/templates/manifest.json

@@ -1,11 +1,11 @@
 {
-  "templateVersion": "98",
+  "templateVersion": "104",
   "templates": {
     "AGENTS.md": {
-      "version": "29",
+      "version": "30",
       "description": "Project-level agent instructions and Sibu maintenance guidance.",
       "changes": [
-        "Can render Layered Architecture routing when that architecture option is selected."
+        "Routes rough future idea capture requests to the mandatory feature-idea-capture skill."
       ]
     },
     ".codex/config.toml": {
@@ -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": "10",
+      "version": "14",
       "description": "Mandatory feature brief writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Adds optional Notion export guidance after local feature briefs are written while keeping Markdown as the canonical artifact."
+        "Makes feature brief interviews mandatory before drafting while keeping export workflows delegated to dedicated exporter skills."
       ]
     },
     "skills/technical-design-writer/SKILL.md": {
-      "version": "18",
+      "version": "20",
       "description": "Mandatory technical design writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Strengthens technical design interviews to resolve material implementation questions before drafting and replaces open questions with risks/tradeoffs."
+        "Makes technical design clarification mandatory before drafting while keeping export workflows delegated to dedicated exporter skills."
       ]
     },
     "skills/typescript/SKILL.md": {
@@ -128,10 +128,10 @@
       ]
     },
     "skills/scrum-master-planner/SKILL.md": {
-      "version": "11",
+      "version": "12",
       "description": "Mandatory Scrum planner skill for creating pragmatic Epics and User Stories from approved feature and technical design docs.",
       "changes": [
-        "Clarifies that User Stories should be deployable increments that can be merged safely on their own, even when gated or incomplete until the parent Epic is done."
+        "Keeps Scrum planning focused on local Epic and User Story artifacts and moves GitHub export workflow guidance to dedicated exporter skills."
       ]
     },
     "skills/ai-implementation-planner/SKILL.md": {
@@ -148,6 +148,13 @@
         "Clarifies that story and Epic planning requests are confirmation for executor implementation."
       ]
     },
+    "skills/feature-idea-capture/SKILL.md": {
+      "version": "1",
+      "description": "Mandatory feature idea capture skill for storing rough future ideas in docs/feature-ideas.md only when the skill is used.",
+      "changes": [
+        "Adds a mandatory feature idea capture skill for quick, raw idea storage without backlog or planning ceremony."
+      ]
+    },
     "skills/ai-prompt-engineer-master/SKILL.md": {
       "version": "2",
       "description": "Selectable AI prompt engineering skill for prompt creation, optimization, compression, and evaluation.",
@@ -156,10 +163,10 @@
       ]
     },
     "skills/ux-expert/SKILL.md": {
-      "version": "8",
+      "version": "10",
       "description": "Selectable UX expert skill for UI-changing features, responsive design, flows, states, accessibility, and binding mockups.",
       "changes": [
-        "Strengthens UX interviews to resolve material experience questions before drafting and replaces open UX questions with risks/tradeoffs."
+        "Makes UX clarification mandatory before drafting while keeping export workflows delegated to dedicated exporter skills."
       ]
     },
     "skills/architecture/layered-architecture/SKILL.md": {
@@ -168,6 +175,20 @@
       "changes": [
         "Adds a Layered Architecture skill for smaller apps that need simple separation of concerns."
       ]
+    },
+    "skills/export-to-github/SKILL.md": {
+      "version": "1",
+      "description": "Selectable GitHub export skill for publishing a named feature's Epics and User Stories to GitHub issues and native sub-issues.",
+      "changes": [
+        "Adds a dedicated GitHub exporter skill paired with GitHub MCP selection."
+      ]
+    },
+    "skills/export-to-notion/SKILL.md": {
+      "version": "1",
+      "description": "Selectable Notion export skill for publishing a named feature's core documentation files to Notion.",
+      "changes": [
+        "Adds a dedicated Notion exporter skill paired with Notion MCP selection."
+      ]
     }
   }
 }

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/export-to-github/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: export-to-github
+description: Export a named feature's Epics and User Stories from local Markdown to GitHub issues and native sub-issues using configured GitHub MCP capabilities.
+---
+
+# Export to GitHub
+
+Use this skill when the user asks to export a feature's Epics and User Stories to GitHub.
+
+## Required input
+
+- A feature name or feature slug.
+- Local planning artifacts under `docs/features/<feature-slug>/epics/`.
+- Configured GitHub MCP capabilities for issue creation, issue ID access, and native sub-issue mutation.
+
+If the feature name is ambiguous, inspect `docs/features/` and ask one focused clarification question.
+
+## Workflow
+
+1. Resolve the feature slug from the user's feature name.
+2. Read the feature's Epic briefs and User Story Markdown files under `docs/features/<feature-slug>/epics/**`.
+3. Resolve the target repository from the current local repo's GitHub `origin` remote only. Do not ask for or use another repository.
+4. Verify GitHub MCP can create issues, return issue IDs, and attach native sub-issues.
+5. Ask one explicit opt-in question before any GitHub mutation.
+6. If the user accepts, create a fresh issue set every time:
+   - one issue per Epic, with no labels
+   - one issue per User Story, with no labels
+   - each User Story issue attached as a native sub-issue of its parent Epic issue
+7. Report created issue numbers or URLs.
+
+## Export rules
+
+- Keep issue bodies concise and source-grounded.
+- Include the source local doc path and relevant summary, scope, acceptance criteria, or validation notes.
+- Preserve each created User Story issue's GitHub issue `id`; native sub-issue APIs need the child issue ID, not only its issue number.
+- Do not search for duplicates or update existing issues.
+- Do not use labels, milestones, projects, assignees, status tracking, Markdown checklists, or loose links as a substitute for native sub-issues.
+- Do not modify local Markdown files with GitHub URLs.
+- If issue creation, issue ID access, or native sub-issue attachment is unavailable, fail clearly and do not fall back to another structure.

package/templates/skills/export-to-notion/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: export-to-notion
+description: Export a named feature's local feature brief, UX design, and technical design Markdown files to Notion using configured Notion MCP capabilities.
+---
+
+# Export to Notion
+
+Use this skill when the user asks to export a feature's core documentation to Notion.
+
+## Required input
+
+- A feature name or feature slug.
+- Configured Notion MCP capabilities.
+- `.sibu/state.json` with `mcpServerConfigs.notion.docsParentPage` when available.
+
+If the feature name is ambiguous, inspect `docs/features/` and ask one focused clarification question.
+
+## Source files
+
+Export only these local Markdown files when present:
+
+```txt
+docs/features/<feature-slug>/feature_brief.md
+docs/features/<feature-slug>/ux.md
+docs/features/<feature-slug>/technical_design.md
+```
+
+Do not export Epics, User Stories, implementation plans, product vision, Deep Module Maps, or arbitrary docs with this skill.
+
+## Notion destination
+
+Use this organization under the configured Notion docs parent page:
+
+```txt
+<docsParentPage>
+└── <repo name>
+    └── Features
+        └── <feature name>
+            ├── Feature Brief
+            ├── UX Design
+            └── Technical Design
+```
+
+## Workflow
+
+1. Resolve the feature slug from the user's feature name.
+2. Read `.sibu/state.json` when available and use `mcpServerConfigs.notion.docsParentPage` as the destination parent.
+3. Confirm which of the allowed source files exist.
+4. Ask one explicit opt-in question before creating or modifying Notion pages.
+5. Create or reuse the repo, Features, and feature organization pages under the configured parent.
+6. Export each existing allowed artifact to its matching Notion page.
+7. Report export success or failure per artifact.
+
+## Export rules
+
+- Local Markdown remains canonical.
+- Do not write Notion URLs back into local Markdown.
+- Do not invent missing source artifacts.
+- Do not export files outside the allowed source list.
+- If Notion MCP capabilities or destination configuration are unavailable, fail clearly and explain what is missing.

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.
 
@@ -95,10 +95,23 @@ Use a short kebab-case feature slug that matches the feature name. Keep all arti
 
 Do not write the brief to technical design, UX, user story, implementation plan, or backlog files unless the user explicitly asks for a separate artifact after the feature brief exists.
 
+## Raw idea sources
+
+If the user asks for a feature brief from an idea in `docs/feature-ideas.md`, read the relevant idea and treat it as raw/vague input only.
+
+- Do not skip the normal interview flow because the idea exists in a file.
+- Use the idea as a seed for the first discovery question, not as complete feature intent.
+- Keep asking one focused question at a time until the usual required context is resolved: problem, target user/scenario, business goal, MVP boundary, out-of-scope boundary, success signals, constraints, and Deep Module fit.
+- Preserve the hard-start requirements for `docs/product-vision.md` and `docs/deep-module-map.md`.
+- After the local `docs/features/<feature-slug>/feature_brief.md` file is successfully written, remove the promoted idea from `docs/feature-ideas.md` while preserving the rest of the file.
+- Do not delete the idea before the feature brief file exists, and do not remove unrelated ideas or headings.
+
 ## Interview posture
 
 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.
@@ -283,31 +296,6 @@ When shaping a feature brief, prefer:
 7. measurable success signals
 8. non-technical acceptance criteria
 
-## Optional Notion export after local write
-
-After the local Markdown file is written successfully, optionally offer Notion export. Local Markdown remains the canonical pipeline artifact and Notion is only a convenience export destination.
-
-1. Do not check Notion export before the local file exists.
-2. After writing the local file, read `.sibu/state.json` if available.
-3. Offer export only when all are true:
-   - `selectedMcpServers` includes `notion`
-   - `mcpServerConfigs.notion.docsParentPage` is present
-   - Notion MCP tools are available in the current agent session
-4. If export is unavailable, do nothing else and finish with the normal local path response.
-5. If export is available, ask for explicit opt-in before creating or modifying any Notion page.
-6. If the user declines, do nothing else.
-7. If the user accepts, create or reuse Notion organization pages under the configured parent page:
-
-```txt
-<docsParentPage>
-└── <repo name>
-    └── Features
-        └── <feature name>
-            └── Feature Brief
-```
-
-Create a new document page for the just-written artifact content. Do not write Notion URLs back into local Markdown. Report Notion export success or a clear Notion export failure, while preserving the local file as the completed artifact either way.
-
 ## Final response behavior
 
 After writing the file, final-answer with only the path created or updated. Do not paste the feature brief body, excerpt, outline, or section summaries.

package/templates/skills/feature-idea-capture/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: feature-idea-capture
+description: Use when the user wants to capture, save, jot down, or add a rough future feature, product, workflow, or improvement idea without turning it into a backlog item, feature brief, or implementation task.
+---
+
+# Feature Idea Capture
+
+Capture rough future ideas quickly in `docs/feature-ideas.md`.
+
+## Behavior
+
+- Write the idea down directly. Do not interview the user before capture.
+- Keep the idea intentionally raw: a short heading and a few bullets are enough.
+- If `docs/feature-ideas.md` does not exist, create it on first use.
+- Append new ideas; do not classify, prioritize, groom, or turn them into backlog work.
+- Do not create feature briefs, epics, stories, implementation plans, or code from captured ideas unless the user separately asks for that later.
+- Do not migrate, rename, inspect, or reconcile pre-existing alternate idea files.
+
+## File shape
+
+Use this lightweight shape:
+
+```md
+# Feature Ideas
+
+## <Idea title>
+
+- <Short note>
+- <Short note>
+```
+
+If the file already exists, preserve its current content and append the new idea using the same simple style.

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/scrum-master-planner/SKILL.md

@@ -213,37 +213,6 @@ Before finishing, verify:
 - no Story adds scope that is absent from the feature brief or technical design
 - acceptance criteria are testable enough for a reviewer
 
-### 6. Mandatory GitHub export gate
-
-After all local Epic and User Story files are written, you must run the GitHub export gate before the final response. This gate is mandatory whenever Scrum planning creates or updates local Epic or User Story files.
-
-Do not skip the gate because the user did not mention GitHub. Do not assume GitHub MCP is unavailable. Explicitly check whether GitHub MCP tools are available for issue creation, issue ID access, and native sub-issue mutation.
-
-If any required GitHub MCP capability is unavailable, do not offer GitHub export. In the final response, include a single concise note that GitHub export was skipped because the required GitHub MCP capabilities were unavailable.
-
-If the required GitHub MCP capabilities are available:
-
-1. Resolve the target repository from the current local repo's GitHub `origin` remote only. Do not ask for or use another repository.
-2. Ask one explicit opt-in question before any GitHub mutation: "GitHub MCP is available. Create GitHub Issues for these Epics and User Stories in the current repo?"
-3. If the user declines, perform no GitHub mutation.
-4. If the user accepts, create a fresh issue set every time. Do not search for duplicates or update existing issues.
-5. Create one issue per Epic with no labels.
-6. Create one issue per User Story with no labels.
-7. Attach each User Story issue as a native GitHub sub-issue of its parent Epic issue.
-8. Report created issue numbers or URLs.
-
-Keep issue bodies concise and source-grounded. Include the source local doc path and relevant summary, scope, acceptance criteria, or validation notes. Do not modify local Markdown files with GitHub URLs.
-
-Native sub-issues are required for this export. Preserve each created User Story issue's GitHub issue `id` because native sub-issue APIs need the child issue ID, not only its issue number. If issue creation, issue ID access, or native sub-issue attachment fails or is unavailable, fail clearly and do not fall back to labels, Markdown checklists, loose links, GitHub Projects, milestones, assignees, or status tracking.
-
-Passing the gate means exactly one of these outcomes occurred:
-
-- GitHub MCP was unavailable or incomplete, and the final response says export was skipped for that reason.
-- GitHub MCP was available, the user declined export, and no GitHub mutation occurred.
-- GitHub MCP was available, the user accepted export, and the created issue numbers or URLs are reported.
-
-Never finish a Scrum planning run without one of these three GitHub export outcomes.
-
 ## Final response behavior
 
 After writing files, final-answer with only:
@@ -251,6 +220,5 @@ After writing files, final-answer with only:
 - the Epic directories created or updated
 - the number of Epics and User Stories
 - any source-scope items intentionally left unresolved or captured as risks
-- the GitHub export gate outcome
 
 Do not paste artifact bodies, excerpts, outlines, story text, acceptance criteria, or section summaries. Only include generated artifacts when the user explicitly asks for inline review in the current request.

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.
@@ -173,31 +175,6 @@ Use this structure as a starting point. Delete sections that do not add value.
 
 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.
 
-## Optional Notion export after local write
-
-After the local Markdown file is written successfully, optionally offer Notion export. Local Markdown remains the canonical pipeline artifact and Notion is only a convenience export destination.
-
-1. Do not check Notion export before the local file exists.
-2. After writing the local file, read `.sibu/state.json` if available.
-3. Offer export only when all are true:
-   - `selectedMcpServers` includes `notion`
-   - `mcpServerConfigs.notion.docsParentPage` is present
-   - Notion MCP tools are available in the current agent session
-4. If export is unavailable, do nothing else and finish with the normal local path response.
-5. If export is available, ask for explicit opt-in before creating or modifying any Notion page.
-6. If the user declines, do nothing else.
-7. If the user accepts, create or reuse Notion organization pages under the configured parent page:
-
-```txt
-<docsParentPage>
-└── <repo name>
-    └── Features
-        └── <feature name>
-            └── Technical Design
-```
-
-Create a new document page for the just-written artifact content. Do not write Notion URLs back into local Markdown. Report Notion export success or a clear Notion export failure, while preserving the local file as the completed artifact either way.
-
 ## Final response behavior
 
 After writing the file, final-answer with only the path created or updated. Do not paste the technical design body, excerpt, outline, or section summaries.

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.
@@ -133,31 +135,6 @@ Use only helpful sections from this shape:
 
 The Binding Mockups section is authoritative for downstream work unless this UX spec is revised.
 
-## Optional Notion export after local write
-
-After the local Markdown file is written successfully, optionally offer Notion export. Local Markdown remains the canonical pipeline artifact and Notion is only a convenience export destination.
-
-1. Do not check Notion export before the local file exists.
-2. After writing the local file, read `.sibu/state.json` if available.
-3. Offer export only when all are true:
-   - `selectedMcpServers` includes `notion`
-   - `mcpServerConfigs.notion.docsParentPage` is present
-   - Notion MCP tools are available in the current agent session
-4. If export is unavailable, do nothing else and finish with the normal local path response.
-5. If export is available, ask for explicit opt-in before creating or modifying any Notion page.
-6. If the user declines, do nothing else.
-7. If the user accepts, create or reuse Notion organization pages under the configured parent page:
-
-```txt
-<docsParentPage>
-└── <repo name>
-    └── Features
-        └── <feature name>
-            └── UX Design
-```
-
-Create a new document page for the just-written artifact content. Do not write Notion URLs back into local Markdown. Report Notion export success or a clear Notion export failure, while preserving the local file as the completed artifact either way.
-
 ## Final response behavior
 
 After writing the file, final-answer with only the path created or updated. Do not paste the UX spec body, excerpt, outline, mockups, or section summaries.