@juancr11/sibu 0.9.3 → 0.9.5

package/package.json

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

package/templates/AGENTS.md

@@ -45,7 +45,7 @@ For planned product/feature work, use this pipeline: product vision -> deep modu
 - For requests to create, revise, or clarify a technical design, implementation-oriented design doc, architecture approach, technical tradeoffs, technical risks, or implementation plan for an approved feature, use `technical-design-writer`.
 - 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 requests to turn a specific User Story into an implementation checklist, coding plan, step-by-step execution plan, or baby-step plan, use `ai-implementation-planner`.
-- For requests to implement, execute, continue, or work through a specific User Story under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.md` 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`; the executor must stop and direct the user to `ai-implementation-planner` when the story plan is missing.
+- For requests to implement, execute, continue, or work through a specific User Story under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.md` 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 should create it with `ai-implementation-planner` and immediately continue into implementation without a separate plan approval gate.
 {{OPTIONAL_SKILL_ROUTING}}
 
 ## Sibu maintenance

package/templates/manifest.json

@@ -1,11 +1,11 @@
 {
-  "templateVersion": "77",
+  "templateVersion": "82",
   "templates": {
     "AGENTS.md": {
-      "version": "25",
+      "version": "26",
       "description": "Project-level agent instructions and Sibu maintenance guidance.",
       "changes": [
-        "Clarifies Deep Module routing as complexity-hiding implementation module planning."
+        "Updates implementation routing so missing story plans are generated and executed immediately without a separate plan approval gate."
       ]
     },
     ".codex/config.toml": {
@@ -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": {
@@ -102,10 +101,10 @@
       ]
     },
     "skills/architecture/ddd-hexagonal/SKILL.md": {
-      "version": "4",
+      "version": "7",
       "description": "Selectable back-end architecture skill for DDD and Hexagonal Architecture.",
       "changes": [
-        "Clarifies that Deep Modules hide implementation complexity behind small interfaces and are not product categories by themselves."
+        "Adds anti-corruption adapter guidance for translating external models at infrastructure boundaries."
       ]
     },
     "skills/architecture/command-pattern/SKILL.md": {
@@ -137,19 +136,17 @@
       ]
     },
     "skills/ai-implementation-planner/SKILL.md": {
-      "version": "11",
+      "version": "12",
       "description": "Mandatory AI implementation planner skill for turning one approved User Story into small, story-local implementation step files.",
       "changes": [
-        "Adds a plan review gate so newly created implementation plans wait for user approval before execution.",
-        "Clarifies that next-story planning handoffs from the executor must stop after planning and wait for approval."
+        "Removes the implementation-plan approval gate and allows execution to continue immediately when implementation is requested."
       ]
     },
     "skills/ai-implementation-plan-executor/SKILL.md": {
-      "version": "17",
+      "version": "18",
       "description": "Mandatory AI implementation plan executor skill for implementing full story plans before story-level review and commit.",
       "changes": [
-        "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."
+        "Allows the executor to generate missing story plans and immediately implement them, preserving only the story-level review gate after implementation."
       ]
     },
     "skills/ai-prompt-engineer-master/SKILL.md": {

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

@@ -24,17 +24,15 @@ 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, 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 starting or continuing a story that has no plan, story-local implementation step files created by applying `ai-implementation-planner`, followed immediately by implementation.
 
 ### When this skill stops
 
 - The user does not provide or clearly identify exactly one User Story file or `.impl_plan/` folder.
-- The starting implementation plan is missing, empty, invalid, or has no ordered step files; direct the user to `ai-implementation-planner`.
 - Any required source artifact is missing, incomplete, or invalid in a way its owning stage should repair.
 - The story, any step, or feature has UI impact and `ux.md` is missing; direct the user to `ux-expert`.
 - Validation fails and the fix is ambiguous, risky, or would exceed the approved plan.
 - A step conflicts with the story, Epic, feature brief, technical design, UX spec, or approved Deep Module boundaries.
-- A newly planned next story is ready for plan review and approval before execution.
 
 ### What this skill must not do
 
@@ -43,7 +41,6 @@ Execute one existing story implementation plan completely, one ordered step file
 - Do not reread `docs/deep-module-map.md` by default; trust `technical_design.md` for Deep Module implementation boundaries.
 - Do not mark any step approved before explicit story-level user approval.
 - Do not commit story implementation changes before explicit story-level user approval.
-- Do not continue past a newly created implementation plan for the next story until the user approves that plan.
 
 ## Required source context
 
@@ -104,10 +101,10 @@ Reread broad source context only when scope changes, validation fails in a way t
 
 If the initial User Story has no matching `.impl_plan/`, or the initial `.impl_plan/` folder is missing, empty, or has no ordered `.md` step files:
 
-1. Stop.
-2. Tell the user the implementation plan is missing or invalid.
-3. Instruct the user to use `templates/skills/ai-implementation-planner/SKILL.md` to create or repair it first.
-4. Do not infer steps from the story or technical design.
+1. Apply `ai-implementation-planner` to create or repair the story-local implementation plan.
+2. Quality-check that the generated plan has ordered step files for exactly that story.
+3. Immediately begin executing the generated plan with this executor.
+4. Do not ask the user to approve the plan before implementation; the only required approval is the story-level review after implementation finishes.
 
 If required source context is missing:
 
@@ -120,7 +117,7 @@ If required source context is missing:
 
 Work through the full story plan in filename order, one step at a time, without asking for review or approval between steps.
 
-When a valid implementation plan exists, begin implementing the first unapproved step immediately. Do not ask for pre-implementation confirmation before changing code. This is an explicit exception to repository-level instructions that normally require confirmation before code changes: selecting this executor skill and providing a valid plan is the user's confirmation to implement the full story plan.
+When a valid implementation plan exists, begin implementing the first unapproved step immediately. If a plan was just generated by `ai-implementation-planner`, begin implementing it immediately. Do not ask for pre-implementation confirmation or plan approval before changing code. This is an explicit exception to repository-level instructions that normally require confirmation before code changes: selecting this executor skill, asking to implement or continue a story/Epic, or providing a valid plan is the user's confirmation to implement the full story plan.
 
 A step file is considered approved only when it contains this section:
 
@@ -172,9 +169,9 @@ After the approved story implementation is committed:
 2. Identify whether there is a next User Story after the completed story.
 3. If there is no next User Story in the Epic, tell the user the Epic appears ready and stop.
 4. If a next User Story exists and its `.impl_plan/` folder exists with ordered step files, immediately begin implementing that next story plan using this same story execution model.
-5. If a next User Story exists but its `.impl_plan/` folder is missing or empty, immediately create the implementation plan for that story by applying `ai-implementation-planner`, then stop and ask the user to review and approve the new plan before executing it.
+5. If a next User Story exists but its `.impl_plan/` folder is missing or empty, immediately create the implementation plan for that story by applying `ai-implementation-planner`, then immediately begin implementing the generated plan.
 
-This continuation behavior is an explicit exception to the normal hard-start rule only after a story has been approved and committed. It lets the executor keep an Epic moving while still preserving the required review gate before executing a newly created plan.
+This continuation behavior is an explicit exception to the normal hard-start rule only after a story has been approved and committed. It lets the executor keep an Epic moving while preserving only the story-level review gate after implementation.
 
 ## Implementation rules
 
@@ -201,7 +198,6 @@ Do not:
 - continue past a failed validation without reporting it and asking how to proceed
 - 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
 
@@ -218,5 +214,5 @@ After approving and committing a story implementation, briefly report the commit
 
 - 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
+- next story was planned and implementation started immediately
 - or the Epic appears ready

package/templates/skills/ai-implementation-planner/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: ai-implementation-planner
-description: Turn one approved User Story Markdown file into LLM-sized implementation step files, then request plan review before execution. Use when asked to create an implementation plan, coding checklist, step-by-step execution plan, or baby-step plan for completing a specific User Story from docs/features/<feature-slug>/epics/<epic-slug>/stories/.
+description: Turn one approved User Story Markdown file into LLM-sized implementation step files, then continue directly into execution when implementation is requested. Use when asked to create an implementation plan, coding checklist, step-by-step execution plan, or baby-step plan for completing a specific User Story from docs/features/<feature-slug>/epics/<epic-slug>/stories/.
 ---
 
 # AI Implementation Planner
 
 ## Purpose
 
-Turn one approved User Story into concrete Markdown step files an AI coding agent can execute safely and completely. This skill owns implementation planning for one story at a time, not product scope, technical design decisions, Scrum planning, or code implementation. After writing the plan, it asks for plan review and approval before any executor begins implementation.
+Turn one approved User Story into concrete Markdown step files an AI coding agent can execute safely and completely. This skill owns implementation planning for one story at a time, not product scope, technical design decisions, Scrum planning, or code implementation. After writing the plan, it does not require a separate plan approval gate; implementation may continue immediately through `ai-implementation-plan-executor` when the user requested execution or Epic continuation.
 
 ## Pipeline Contract
 
@@ -30,7 +30,6 @@ Turn one approved User Story into concrete Markdown step files an AI coding agen
 - Any required source artifact is missing, incomplete, or invalid in a way its owning stage should repair.
 - The story or feature has UI impact and `ux.md` is missing; direct the user to `ux-expert`.
 - The request is to write production code, execute an implementation plan, create stories, or perform another pipeline stage.
-- A newly created implementation plan is ready for user review and approval before execution.
 
 ### What this skill must not do
 
@@ -38,7 +37,7 @@ Turn one approved User Story into concrete Markdown step files an AI coding agen
 - Do not modify prior-stage artifacts.
 - Do not reread `docs/deep-module-map.md` by default; trust `technical_design.md` for Deep Module implementation boundaries.
 - Do not infer implementation scope from an Epic brief, feature brief, or technical design without exactly one User Story.
-- Do not execute the plan after creating it, even when invoked as the next-story planning handoff from `ai-implementation-plan-executor`.
+- Do not write production code directly from this planner; hand off to `ai-implementation-plan-executor` for implementation.
 
 ## Required input
 
@@ -241,18 +240,20 @@ Before finishing, verify:
 - the step files preserve approved Deep Module boundaries and stop before unrelated module movement
 - architecture and code-quality steps align with the relevant skills
 
-### 6. Request plan review
+### 6. Continue or report
 
-After writing and quality-checking the implementation step files, stop and ask the user to review and approve the plan before execution. Do not start implementation in the same turn.
+After writing and quality-checking the implementation step files, do not ask for plan approval before execution. If the user asked to implement, execute, continue, or work through the story or Epic, immediately hand off to `ai-implementation-plan-executor` for the newly created plan in the same turn. The user's execution request plus a valid generated plan is enough pre-implementation confirmation; the only required user approval is the story-level review after execution finishes.
 
-When this skill is invoked as the next-story planning handoff from `ai-implementation-plan-executor`, the same gate applies: create the plan, summarize it, and wait for explicit approval before the executor starts changing code for that story.
+If the user asked only to create a plan and did not ask for implementation, stop after creating the plan and report where it was written. Make clear that no plan approval is required before a later executor run.
 
-The final planning response must briefly include:
+When this skill is invoked as the next-story planning handoff from `ai-implementation-plan-executor`, create the plan and immediately return control to the executor so it can implement the next story without a plan-review gate.
+
+The final planning-only response must briefly include:
 
 - the source User Story path
 - the implementation plan folder path
 - the ordered step files created
-- any assumptions, risks, or validation commands worth reviewing
-- that execution should wait until the user approves the plan
+- any assumptions, risks, or validation commands worth noting
+- that no separate plan approval is required before execution
 
 Do not paste step-file bodies, excerpts, outlines, task text, done conditions, or section summaries. Only include generated step files when the user explicitly asks for inline review in the current request.

package/templates/skills/architecture/ddd-hexagonal/SKILL.md

@@ -138,6 +138,17 @@ Use this default mapping when the project does not already have a clearer conven
 /src/modules/<module-slug>/infra/**        # Technical implementations and external integrations
 ```
 
+Structure each application use case with files, not nested subfolders:
+
+```text
+/src/modules/<module-slug>/application/<usecase-slug>/input.*    # Input DTO/schema/command shape
+/src/modules/<module-slug>/application/<usecase-slug>/output.*   # Output DTO/result shape
+/src/modules/<module-slug>/application/<usecase-slug>/usecase.*  # Use case orchestration
+/src/modules/<module-slug>/application/<usecase-slug>/ports.*    # Ports required by this use case
+```
+
+Use the project language's normal extension, such as `.ts`, `.go`, or `.py`. Keep ports local to the use case by default. Extract shared application ports only when multiple use cases truly need the same abstraction. Do not create `input/`, `output/`, `usecase/`, or `ports/` folders unless an existing project convention already requires it.
+
 Entrypoints such as routes, jobs, or handlers should remain thin driving adapters that call application behavior inside the selected Deep Module.
 
 ## Ports and adapters
@@ -166,9 +177,40 @@ Typical driven adapters:
 
 Adapters should hide technical details rather than leak them inward.
 
-## Use cases
+### Anti-corruption adapters
+
+When integrating with an external API, SDK, database shape, file format, or third-party model, treat the infrastructure adapter as the anti-corruption layer. Translate external language and data shapes into application/domain concepts at the boundary.
+
+Place anti-corruption translation in infrastructure adapter files by default:
+
+```text
+/src/modules/<module-slug>/infra/<adapter-slug>.*        # Adapter and translation logic
+/src/modules/<module-slug>/infra/<adapter-slug>.types.*  # External DTOs/types when useful
+```
+
+Do not create a separate `acl/` folder by default. Split translation into extra infrastructure-local files only when the adapter becomes too large.
+
+External DTOs, SDK response types, database rows, and third-party vocabulary must not leak into `domain/**` or use case `input.*` / `output.*` unless the product language truly matches the external language. If changing an external API response would force changes in domain entities, value objects, or use case boundaries, the anti-corruption boundary is leaking.
+
+## Use cases, application services, and domain services
+
+### Use case
+
+A use case represents one externally meaningful backend capability triggered by a route, CLI command, job, handler, or other driving adapter.
+
+Place each use case at:
+
+```text
+/src/modules/<module-slug>/application/<usecase-slug>/usecase.*
+```
 
-A use case should represent one meaningful backend capability.
+Its sibling files should define its boundary:
+
+```text
+/src/modules/<module-slug>/application/<usecase-slug>/input.*
+/src/modules/<module-slug>/application/<usecase-slug>/output.*
+/src/modules/<module-slug>/application/<usecase-slug>/ports.*
+```
 
 A use case should:
 - orchestrate domain logic and required ports explicitly
@@ -180,6 +222,35 @@ A use case should not:
 - hide infrastructure details inline
 - absorb framework behavior that belongs in adapters
 
+### Application service
+
+An application service is reusable application-layer orchestration shared by multiple use cases. Use it only when multiple use cases truly need the same orchestration, transaction coordination, or port coordination. Do not create application services just to shorten one use case; prefer private helpers first.
+
+Place application services under:
+
+```text
+/src/modules/<module-slug>/application/services/<service-slug>.*
+```
+
+Application services may depend on domain concepts and application ports, but must not depend on infrastructure implementations, SDK clients, database clients, or framework request/response objects.
+
+### Domain service
+
+A domain service contains pure business behavior that does not naturally belong on one entity or value object. Use it when the rule is domain language, needs multiple domain concepts, and has no dependency on ports, databases, SDKs, frameworks, or technical time/randomness unless those are passed in as values.
+
+Place domain services under:
+
+```text
+/src/modules/<module-slug>/domain/services/<service-slug>.*
+```
+
+Domain services must stay pure and should not orchestrate use cases or external capabilities.
+
+Rule of thumb:
+- Use case: “Do this application action.”
+- Application service: “Reuse this application orchestration.”
+- Domain service: “Evaluate or perform this pure domain rule.”
+
 ## Simplicity rule
 
 - Use the fewest layers that preserve clear boundaries.

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