@juancr11/sibu 0.16.0 → 0.17.0

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

@@ -1,15 +1,15 @@
 ---
 name: deep-module-map-writer
-description: Create or update docs/deep-module-map.md as a map of deep, complexity-hiding implementation modules before feature brief work.
+description: Create or update docs/deep-module-map.md as a map of deep, complexity-hiding implementation modules after Product Vision, Business Domain Model, and Capabilities Map work.
 ---
 
 # Deep Module Map Writer
 
 ## Purpose
 
-Create or update `docs/deep-module-map.md`, a technical design map of deep implementation modules that downstream technical designs, feature briefs, and implementation plans use to decide where code work belongs.
+Create or update `docs/deep-module-map.md`, a technical design map of deep implementation modules that downstream technical designs and implementation plans use to decide where code work belongs.
 
-A Deep Module is primarily a technical design concept from software architecture: a module with a small, simple interface and a larger, more complex implementation hidden behind it. In this artifact, Deep Modules may align with product responsibilities, but their depth comes from technical abstraction and complexity hiding, not from being a product category, command, folder, service, or team boundary.
+A Deep Module is primarily a technical design concept from software architecture: a module with a small, simple interface and a larger, more complex implementation hidden behind it. In this artifact, Deep Modules are derived from product purpose, reviewed domain understanding, and capability coverage: domain concepts, relationships, lifecycles, business rules, workflows, domain events, boundaries, hard parts, and business/product abilities that need durable implementation boundaries. Their depth comes from technical abstraction and complexity hiding, not from being a product category, command, folder, service, or team boundary.
 
 This skill owns the Deep Module Map only. It does not own feature briefs, technical designs, user stories, implementation plans, production code, or the internal architecture used inside each module.
 
@@ -18,8 +18,10 @@ This skill owns the Deep Module Map only. It does not own feature briefs, techni
 ### What this skill needs
 
 - `docs/product-vision.md`.
+- `docs/business-domain-model.md`.
+- `docs/capabilities-map.md`.
 - Existing `docs/deep-module-map.md` when revising the map.
-- Enough user interview context to identify candidate technical modules, the simple interface each module should expose to the rest of the app, the complexity each module should hide, boundaries, scenarios, relationships, and cross-module rules.
+- Enough user interview context to identify candidate technical modules, the simple interface each module should expose to the rest of the app, the complexity each module should hide, boundaries, scenarios, relationships, and cross-module rules from the Product Vision, Business Domain Model, and Capabilities Map.
 
 ### What this skill writes
 
@@ -28,6 +30,8 @@ This skill owns the Deep Module Map only. It does not own feature briefs, techni
 ### When this skill stops
 
 - `docs/product-vision.md` is missing; tell the user to create it first with `product-vision-writer`.
+- `docs/business-domain-model.md` is missing; tell the user to create it first with `business-domain-model-writer`.
+- `docs/capabilities-map.md` is missing; tell the user to create it first with `capabilities-map-writer`.
 - The request belongs to another pipeline stage, such as feature brief, technical design, UX design, Scrum planning, implementation planning, or implementation execution.
 - User answers are still too vague to defend module depth, interfaces, hidden complexity, or boundaries; ask one focused question instead of drafting.
 
@@ -36,7 +40,9 @@ 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 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 invent Deep Modules without grounding them in the product vision, Business Domain Model, Capabilities Map, and user interview.
+- Do not inspect implementation code by default when creating or substantially revising the map.
+- Do not use existing code, folders, commands, screens, services, data objects, or technical layers as the source of truth for module boundaries.
 - 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.
 
@@ -96,13 +102,23 @@ Before doing any Deep Module Map work, read:
 
 ```txt
 docs/product-vision.md
+docs/business-domain-model.md
+docs/capabilities-map.md
 ```
 
 Use the product vision as the source of truth for purpose, audience, positioning, principles, boundaries, trust expectations, and success signals.
 
+Use the Business Domain Model as the source of truth for business language, domain concepts, relationships, lifecycles, business rules, workflows, domain events, boundaries, and hard parts.
+
+Use the Capabilities Map as the source of truth for business/product abilities by subdomain. Capabilities inform which abilities need deep, complexity-hiding implementation boundaries; they are not modules, commands, services, files, APIs, database tables, or classes.
+
+Read existing `docs/deep-module-map.md` only when revising the map. An existing map can provide continuity and change context, but it never replaces the required Product Vision and Business Domain Model.
+
+Do not inspect implementation code by default. Existing code, folders, commands, screens, services, data objects, and technical layers are not the default source of truth for module boundaries. If the user explicitly asks for a code-alignment check, inspect code only after domain-driven module boundaries are drafted, and use that inspection only to identify alignment gaps, migration implications, and places where current code may not match the domain-driven map. Code alignment must not replace or override the Product Vision and Business Domain Model source requirements.
+
 ## Hard start rule
 
-Do not create or update a Deep Module Map if `docs/product-vision.md` is missing.
+Do not create or update a Deep Module Map if `docs/product-vision.md`, `docs/business-domain-model.md`, or `docs/capabilities-map.md` is missing.
 
 If the product vision is missing:
 
@@ -111,6 +127,20 @@ If the product vision is missing:
 3. Instruct the user to create the product vision first with `product-vision-writer`.
 4. Do not draft, infer, or save a module map until the product vision exists.
 
+If the Business Domain Model is missing:
+
+1. Stop.
+2. Tell the user that a Deep Module Map requires `docs/business-domain-model.md`.
+3. Instruct the user to create the Business Domain Model first with `business-domain-model-writer`.
+4. Do not draft, infer, or save a module map until the Business Domain Model exists.
+
+If the Capabilities Map is missing:
+
+1. Stop.
+2. Tell the user that a Deep Module Map requires `docs/capabilities-map.md`.
+3. Instruct the user to create the Capabilities Map first with `capabilities-map-writer`.
+4. Do not draft, infer, or save a module map until the Capabilities Map exists.
+
 ## Output location
 
 Write the map to:
@@ -125,17 +155,17 @@ 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.
+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 the Product Vision, Business Domain Model, and Capabilities Map as the primary source context; prior conversation and initial context can shape better questions, but they must not replace the interview. Implementation code is not inspected by default and must not become the 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.
 - 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.
+- If a question can be answered by reading the Product Vision, Business Domain Model, Capabilities Map, or existing Deep Module Map during revision, inspect those artifacts instead of asking. Do not inspect implementation code unless the user explicitly requested a later code-alignment check after domain-driven boundaries are drafted.
 - 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.
-- Extract modules by asking about caller intent, complexity that should be hidden, product jobs, decisions, promises, lifecycle moments, confusing boundaries, and where code should stay coherent over time.
+- Extract modules by asking about caller intent, complexity that should be hidden, product jobs, domain concepts, relationships, lifecycles, business rules, workflows, domain events, boundaries, hard parts, decisions, promises, lifecycle moments, confusing boundaries, and where code should stay coherent over time.
 - 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.
@@ -163,6 +193,8 @@ Do not ask the user to answer a large questionnaire all at once. Keep the interv
 Ask every question needed to remove material ambiguity, but only one at a time. Clarify:
 
 - what product or system capabilities the map must support
+- which Business Domain Model concepts, relationships, lifecycles, business rules, workflows, domain events, boundaries, or hard parts should drive module discovery
+- which Capabilities Map business/product abilities need deep implementation boundaries
 - what the rest of the app should be able to ask each area to do
 - what messy details callers should not need to know
 - which decisions or policies should change together
@@ -185,6 +217,7 @@ Prefer questions like:
 
 - "What should the rest of the app be able to ask this area to do in one simple phrase?"
 - "What messy details should callers not need to know?"
+- "Which domain concept, rule, lifecycle, workflow, event, boundary, or hard part makes this candidate module important?"
 - "If this were a good abstraction, what would its small public interface look like conceptually?"
 - "What steps, checks, edge cases, or policies would be hidden behind that interface?"
 - "Where are callers currently forced to know too much?"
@@ -232,7 +265,7 @@ Deep Modules should be:
 
 - complexity-hiding abstractions with simple external interfaces
 - deep enough that callers do not need to understand internal orchestration, edge cases, or policies
-- technical design boundaries first, with product alignment used only where it helps explain why code changes together
+- technical design boundaries first, derived from product purpose and reviewed domain understanding rather than accidental implementation structure
 - durable enough to absorb related technical and product changes over time
 - named in language useful across technical design, implementation planning, feature briefs, and code organization
 - flexible internally so different projects can use layered, DDD, Hexagonal, command-oriented, MVC, functional, or other architectures inside them
@@ -242,10 +275,13 @@ Avoid shallow modules based on one feature, screen, command, workflow step, data
 ## Workflow
 
 1. Read `docs/product-vision.md`.
-2. Read existing `docs/deep-module-map.md` if it exists.
-3. Ask one focused question at a time until the module direction is clear.
-4. Keep asking focused follow-up questions until the simple interface and hidden complexity of each candidate module are defensible.
-5. Write or update `docs/deep-module-map.md` once enough context is available.
+2. Read `docs/business-domain-model.md`.
+3. Read existing `docs/deep-module-map.md` only if revising the map.
+4. Draft domain-driven module boundaries from product purpose plus domain concepts, relationships, lifecycles, business rules, workflows, domain events, boundaries, and hard parts.
+5. Ask one focused question at a time until the module direction is clear.
+6. Keep asking focused follow-up questions until the simple interface and hidden complexity of each candidate module are defensible.
+7. If the user explicitly requested code alignment, inspect implementation code only after domain-driven boundaries are drafted and only to identify alignment gaps or migration implications.
+8. Write or update `docs/deep-module-map.md` once enough context is available.
 
 ## Recommended map structure
 

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

@@ -1,13 +1,13 @@
 ---
 name: feature-brief-writer
-description: Use this skill to define business-level feature briefs that stay loyal to docs/product-vision.md before UX, technical design, or implementation work.
+description: Use this skill to define business-level feature briefs that stay loyal to docs/product-vision.md, docs/business-domain-model.md, and docs/capabilities-map.md before UX, technical design, or implementation work.
 ---
 
 # Feature Brief Writer
 
 ## Purpose
 
-Create concise feature briefs that explain what a feature is, why it matters, who it serves, and how it follows `docs/product-vision.md`: purpose, audience, boundaries, and success signals.
+Create concise feature briefs that explain what a feature is, why it matters, who it serves, and how it follows `docs/product-vision.md`, `docs/business-domain-model.md`, and `docs/capabilities-map.md`: purpose, audience, business language, domain concepts, rules, workflows, boundaries, capability coverage, and success signals.
 
 This skill owns the product/business shape of a feature. It does not own UI interaction design, technical architecture, implementation plans, data models, APIs, or task breakdowns.
 
@@ -16,8 +16,9 @@ This skill owns the product/business shape of a feature. It does not own UI inte
 ### What this skill needs
 
 - `docs/product-vision.md`.
-- `docs/deep-module-map.md`.
-- Enough user-provided feature intent to define the feature problem, target user/scenario, business goal, MVP boundary, out-of-scope boundary, success signals, constraints, and Deep Module fit.
+- `docs/business-domain-model.md`.
+- `docs/capabilities-map.md`.
+- Enough user-provided feature intent to define the feature problem, target user/scenario, business goal, MVP boundary, out-of-scope boundary, success signals, constraints, Product Vision fit, Business Domain Model fit, and Capability Coverage.
 
 ### What this skill writes
 
@@ -27,18 +28,21 @@ This skill owns the product/business shape of a feature. It does not own UI inte
 ### When this skill stops
 
 - `docs/product-vision.md` is missing; tell the user to create it first with `product-vision-writer`.
-- `docs/deep-module-map.md` is missing; tell the user to create it first with `deep-module-map-writer`.
-- The feature appears to require a new or changed Deep Module; direct the user back to `deep-module-map-writer`.
+- `docs/business-domain-model.md` is missing; tell the user to create it first with `business-domain-model-writer`.
+- `docs/capabilities-map.md` is missing; tell the user to create it first with `capabilities-map-writer`.
+- The feature appears to stretch or change the Product Vision; hard-stop with a ready prompt for `product-vision-writer`.
+- The feature introduces missing or changed domain concepts, rules, workflows, lifecycles, events, boundaries, or core/supporting subdomains; hard-stop with a ready prompt for `business-domain-model-writer`.
+- The feature fits an existing subdomain but needs missing capability coverage; hard-stop with a ready prompt for `capabilities-map-writer`.
 - The request belongs to another pipeline stage, such as technical design, UX design, Scrum planning, implementation planning, or implementation execution.
 - Current-stage feature intent is unclear; ask one focused question at a time until enough information is available.
 
 ### What this skill must not do
 
-- 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 create or update Product Vision, Business Domain Model, Capabilities Map, Deep Module Maps, technical designs, UX specs, Epics, User Stories, implementation plans, or production code.
+- Do not invent missing product direction, domain model coverage, subdomains, or capabilities in the final brief.
 - 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.
+- Do not leave material product, scope, success, constraint, domain fit, or capability coverage questions unresolved in the final brief; keep interviewing until the user answers, confirms an assumption, or explicitly excludes the topic.
 
 ## Required source of truth
 
@@ -46,18 +50,21 @@ Before doing any feature-brief work, read:
 
 ```txt
 docs/product-vision.md
-docs/deep-module-map.md
+docs/business-domain-model.md
+docs/capabilities-map.md
 ```
 
 Use the product vision as the source of truth for the product's purpose, audience, positioning, principles, voice, boundaries, trust expectations, and success signals.
 
-Use the Deep Module Map as the source of truth for where feature work belongs. Deep Modules answer “where does this work belong?” Do not invent Deep Modules in a feature brief.
+Use the Business Domain Model as the source of truth for business language, domain concepts, relationships, rules, states, workflows, events, and boundaries that shape business-level feature scope.
+
+Use the Capabilities Map as the source of truth for business/product capability coverage by subdomain. Capabilities answer “what existing business/product ability supports this feature?” Do not invent capabilities in a feature brief.
 
 Do not duplicate or rewrite the product vision inside the feature brief. Apply it to the specific feature being defined.
 
 ## Hard start rule
 
-Do not start a feature brief if `docs/product-vision.md` or `docs/deep-module-map.md` is missing.
+Do not start a feature brief if `docs/product-vision.md`, `docs/business-domain-model.md`, or `docs/capabilities-map.md` is missing.
 
 If the product vision is missing:
 
@@ -66,11 +73,18 @@ If the product vision is missing:
 3. Instruct the user to create the product vision first with the `product-vision-writer` skill.
 4. Do not draft, infer, or save a feature brief until the product vision exists.
 
-If the Deep Module Map is missing:
+If the Business Domain Model is missing:
 
 1. Stop.
-2. Tell the user that a feature brief requires `docs/deep-module-map.md`.
-3. Instruct the user to create the map first with the `deep-module-map-writer` skill.
+2. Tell the user that a feature brief requires `docs/business-domain-model.md`.
+3. Instruct the user to create the domain model first with the `business-domain-model-writer` skill.
+4. Do not draft, infer, or save a feature brief until the domain model exists.
+
+If the Capabilities Map is missing:
+
+1. Stop.
+2. Tell the user that a feature brief requires `docs/capabilities-map.md`.
+3. Instruct the user to create the map first with the `capabilities-map-writer` skill.
 4. Do not draft, infer, or save a feature brief until the map exists.
 
 ## Use this skill for
@@ -101,8 +115,8 @@ If the user asks for a feature brief from an idea in `docs/feature-ideas.md`, re
 
 - 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`.
+- 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, Business Domain Model fit, and Capability Coverage.
+- Preserve the hard-start requirements for `docs/product-vision.md`, `docs/business-domain-model.md`, and `docs/capabilities-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.
 
@@ -114,18 +128,18 @@ This interview is mandatory and non-skippable. Even when the user provides exten
 
 - 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.
+- Walk down each feature decision branch one by one, resolving dependencies between product, scope, success, constraint, domain-fit, and capability-coverage 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.
+- Treat "enough context" as: feature intent, target user/scenario, desired outcome, MVP boundary, out-of-scope boundary, success signals, constraints, Business Domain Model fit, and Capability Coverage are clear enough to defend in the brief.
 - 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.
 
 ## Workflow
 
-### 1. Read the product vision and Deep Module Map
+### 1. Read the product vision, Business Domain Model, and Capabilities Map
 
 Read `docs/product-vision.md` first and identify:
 
@@ -139,19 +153,41 @@ Read `docs/product-vision.md` first and identify:
 
 Use these as constraints for the feature brief.
 
-Then read `docs/deep-module-map.md` and identify which existing Deep Modules may own the requested feature. A feature brief must name one or more existing Deep Modules.
+Then read `docs/business-domain-model.md` and identify relevant business language, domain concepts, relationships, rules, states, workflows, events, and boundaries that should shape feature scope and wording.
+
+Then read `docs/capabilities-map.md` and identify which existing subdomain capabilities support the requested feature. A feature brief must explain the feature's Capability Coverage using existing Business Domain Model subdomains and existing capabilities.
+
+Before drafting, check for upstream gaps. Do not silently invent missing upstream foundations in the final brief.
+
+If the feature appears to stretch or change the Product Vision's direction, target users, boundaries, principles, trust expectations, or success signals:
+
+1. Stop before drafting.
+2. Tell the user the feature needs Product Vision clarification first.
+3. Provide this prompt, adapted to the user's feature:
+
+```txt
+Use product-vision-writer to revise docs/product-vision.md for this feature request: <feature summary>. Clarify whether the feature fits or changes the product direction, target users, boundaries, principles, trust expectations, and success signals. Include this context: <known user/scenario/problem/outcome/scope notes>. Do not write the feature brief until I confirm the Product Vision update.
+```
 
-If no existing Deep Module fits:
+If the feature introduces missing or changed domain concepts, rules, workflows, lifecycles, events, boundaries, or core/supporting subdomains:
 
 1. Stop before drafting.
-2. Tell the user the feature appears to require a Deep Module Map update.
-3. Provide this suggested prompt, adapted to the user's feature:
+2. Tell the user the Business Domain Model needs coverage first.
+3. Provide this prompt, adapted to the user's feature:
 
 ```txt
-Use deep-module-map-writer to update docs/deep-module-map.md for this feature: <feature summary>. Decide whether it belongs in an existing Deep Module or requires a new/changed module, then update the map only after confirming the responsibility boundary with me.
+Use business-domain-model-writer to revise docs/business-domain-model.md for this feature request: <feature summary>. Check whether it introduces or changes domain concepts, rules, workflows, lifecycles, events, boundaries, or core/supporting subdomains. Include this context: <known user/scenario/problem/outcome/scope notes>. Do not write the feature brief until I confirm the Business Domain Model update.
 ```
 
-4. Do not draft, infer, or save a feature brief until the map is updated.
+If the feature fits an existing Business Domain Model subdomain but depends on a missing capability:
+
+1. Stop before drafting.
+2. Tell the user the Capabilities Map needs coverage first.
+3. Provide this prompt, adapted to the user's feature:
+
+```txt
+Use capabilities-map-writer to revise docs/capabilities-map.md for this feature request: <feature summary>. Map it to the existing subdomain <subdomain name> and add or adjust only the business/product capability coverage needed to support it. Include this context: <known user/scenario/problem/outcome/scope notes>. Do not write the feature brief until I confirm the Capabilities Map update.
+```
 
 ### 2. Clarify feature intent before drafting
 
@@ -181,10 +217,11 @@ Ask every question needed to remove material ambiguity, but only one at a time.
 - when and why the target user would use it
 - what outcome should improve
 - what must be included in the first version
+- which Business Domain Model concepts, rules, states, workflows, or boundaries materially shape the scope
 - what should stay out of scope
 - 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. Do not draft a brief with an `Open Questions` section.
+Draft only once feature intent, target user/scenario, desired outcome, MVP boundary, out-of-scope boundary, success signals, constraints, Business Domain Model fit, and Capability Coverage 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.
 
@@ -203,8 +240,11 @@ Recommended structure:
 ## Product Vision Fit
 <How this feature supports the product vision, principles, audience, or positioning.>
 
-## Deep Module
-<One or more existing Deep Modules from docs/deep-module-map.md that own this feature, with a brief fit rationale.>
+## Business Domain Model Fit
+<Relevant domain language, concepts, rules, states, workflows, or boundaries from docs/business-domain-model.md that shape this feature.>
+
+## Capability Coverage
+<Existing subdomain capabilities from docs/capabilities-map.md that support this feature, with a business/product fit rationale.>
 
 ## User / Customer Problem
 <The user need, pain, desire, or opportunity this feature addresses.>
@@ -265,7 +305,7 @@ If the file already exists, read it first. Treat the request as a revision when
 Aim for writing that is:
 
 - loyal to the required product vision
-- explicit about which existing Deep Modules own the feature
+- explicit about which existing subdomain capabilities support the feature
 - specific to the user's feature
 - grounded in the product vision
 - concise
@@ -279,7 +319,7 @@ Avoid:
 - vague benefits without user or business grounding
 - feature lists without rationale
 - drafting from vague feature labels without discovery
-- inventing new Deep Modules instead of stopping for a map update
+- inventing new capabilities or subdomains instead of stopping for the right upstream 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
 
@@ -288,7 +328,7 @@ Avoid:
 When shaping a feature brief, prefer:
 
 1. alignment with `docs/product-vision.md`
-2. fit with existing Deep Modules from `docs/deep-module-map.md`
+2. fit with existing capabilities from `docs/capabilities-map.md`
 3. clear user value
 4. clear business or product outcome
 5. simple MVP scope

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

@@ -13,7 +13,7 @@ Write the smallest useful technical design doc for an approved feature: enough f
 
 - A Markdown feature brief at `docs/features/<feature-slug>/feature_brief.md`.
 - `docs/deep-module-map.md`.
-- The feature brief's `## Deep Module` section naming one or more existing Deep Modules.
+- Enough feature and module context to map the feature brief to one or more existing Deep Modules during technical design.
 - Relevant existing repo files and flows needed to make implementation direction concrete.
 - `docs/features/<feature-slug>/ux.md` only when the feature has UI impact.
 - Relevant implementation guidance skills such as `clean-code`, selected architecture skills, language skills, or framework skills.
@@ -26,14 +26,14 @@ Write the smallest useful technical design doc for an approved feature: enough f
 
 - The feature brief is missing or the user only has a vague feature idea; direct the user to `feature-brief-writer`.
 - `docs/deep-module-map.md` is missing; direct the user to `deep-module-map-writer`.
-- The feature brief does not name existing Deep Modules, or the selected modules are missing, ambiguous, or inconsistent with the map.
+- The feature brief and Deep Module Map cannot be reconciled to existing Deep Modules after focused clarification, or the selected modules are missing, ambiguous, or inconsistent with the map.
 - The feature has UI impact and `docs/features/<feature-slug>/ux.md` is missing; direct the user to `ux-expert`.
 - The request belongs to another pipeline stage, such as feature definition, UX design, Scrum planning, implementation planning, or implementation execution.
 
 ### What this skill must not do
 
 - Do not create or update product visions, Deep Module Maps, feature briefs, UX specs, Epics, User Stories, implementation plans, or production code.
-- Do not invent new Deep Modules or move work into unselected modules.
+- Do not invent new Deep Modules or move work into modules that cannot be justified from the Feature Brief and Deep Module Map.
 - Do not redesign binding UX mockups.
 - Do not duplicate architecture, language, framework, or clean-code skill guidance.
 - 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.
@@ -44,7 +44,7 @@ Before writing, read:
 
 1. `docs/product-vision.md`
 2. `docs/deep-module-map.md`
-3. the feature brief, including its `## Deep Module` section
+3. the feature brief
 4. `docs/features/<feature-slug>/ux.md` when the feature has UI impact
 5. `clean-code`
 6. any selected architecture, language, or framework skills that apply
@@ -58,7 +58,7 @@ Require a Markdown feature brief. If the user only has a vague idea, route to `f
 
 Require `docs/deep-module-map.md`. If it is missing, stop and ask the user to create it with `deep-module-map-writer` first. Do not infer or invent Deep Modules.
 
-Require the feature brief to name one or more existing Deep Modules. Preserve those selected modules in the technical design; if they appear missing, ambiguous, or inconsistent with the map, stop and ask the user to update the feature brief or Deep Module Map first.
+Treat the Feature Brief and Deep Module Map as sibling upstream inputs. Older feature briefs may name selected Deep Modules directly; newer feature briefs may omit that section. If the brief names modules, preserve them when they match the map. If it does not, use the approved feature scope plus `docs/deep-module-map.md` to identify the existing modules during technical clarification. If the feature cannot be mapped to existing modules, or the selected modules are missing, ambiguous, or inconsistent with the map, stop and ask the user to update the Feature Brief or Deep Module Map first.
 
 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.
 
@@ -73,7 +73,7 @@ This interview is mandatory and non-skippable. Even when the approved artifacts,
 - 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.
+- Treat "enough context" as: existing Deep Modules selected or mapped during technical design, 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.
@@ -86,7 +86,7 @@ For UI-related features, `ux.md` is source context, not inspiration. If `ux.md`
 
 Translate product intent into implementation direction.
 
-Deep Modules answer “where does this implementation work belong?” Architecture guidance answers “how is that module structured internally?” Translate the feature brief's selected Deep Modules into implementation boundaries appropriate for the selected architecture. Capture those boundaries in the technical design so downstream Scrum planning, implementation planning, and execution can trust the technical design instead of rereading the Deep Module Map by default.
+Deep Modules answer “where does this implementation work belong?” Architecture guidance answers “how is that module structured internally?” Translate the existing Deep Modules selected or mapped from the Feature Brief plus Deep Module Map into implementation boundaries appropriate for the selected architecture. Capture those boundaries in the technical design so downstream Scrum planning, implementation planning, and execution can trust the technical design instead of rereading the Deep Module Map by default.
 
 When a feature crosses a framework or delivery boundary, include the allowed orchestration/application entrypoint and the forbidden lower-level dependencies. Keep this framework-agnostic: name roles like framework adapter, application/orchestration boundary, domain, port, and infrastructure, then add concrete project paths only where useful.
 
@@ -97,7 +97,7 @@ Prefer:
 - current codebase patterns over speculative redesigns
 - 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
+- preserving named Deep Modules when present and otherwise mapping the Feature Brief to existing Deep Modules during technical design
 
 Avoid:
 
@@ -105,7 +105,7 @@ Avoid:
 - product scope expansion
 - user stories, tickets, or delivery plans
 - invented CLI/database/API concepts that the feature brief did not ask for
-- inventing new Deep Modules or moving work into unselected modules
+- inventing new Deep Modules or moving work into modules that cannot be justified from the Feature Brief and Deep Module Map
 - large template sections that say “none” without adding value
 
 ## Delegation rule
@@ -160,7 +160,7 @@ Use this structure as a starting point. Delete sections that do not add value.
 ## Proposed Design
 <Concrete implementation decisions. Include command flows, file/module impact, state changes, and integration boundaries when relevant.>
 
-<Explain how the selected Deep Modules translate into architecture, module, command, file, or implementation boundaries when that affects downstream work.>
+<Explain how the existing Deep Modules selected or mapped during technical design translate into architecture, module, command, file, or implementation boundaries when that affects downstream work.>
 
 <For framework/delivery entrypoints, state the application/orchestration API they may call and the lower-level layers, modules, or paths they must not call directly.>