@juancr11/sibu 0.6.0 → 0.8.0

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

@@ -12,8 +12,8 @@ Write the smallest useful technical design doc for an approved feature: enough f
 ### What this skill needs
 
 - A Markdown feature brief at `docs/features/<feature-slug>/feature_brief.md`.
-- `docs/product-context-map.md`.
-- The feature brief's `## Product Context` section naming one or more existing Product Contexts.
+- `docs/deep-module-map.md`.
+- The feature brief's `## Deep Module` section naming one or more existing Deep Modules.
 - 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.
@@ -25,15 +25,15 @@ Write the smallest useful technical design doc for an approved feature: enough f
 ### When this skill stops
 
 - The feature brief is missing or the user only has a vague feature idea; direct the user to `feature-brief-writer`.
-- `docs/product-context-map.md` is missing; direct the user to `product-context-map-writer`.
-- The feature brief does not name existing Product Contexts, or the selected contexts are missing, ambiguous, or inconsistent with the map.
+- `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 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, Product Context Maps, feature briefs, UX specs, Epics, User Stories, implementation plans, or production code.
-- Do not invent new Product Contexts or move work into unselected contexts.
+- 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 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.
@@ -43,8 +43,8 @@ Write the smallest useful technical design doc for an approved feature: enough f
 Before writing, read:
 
 1. `docs/product-vision.md`
-2. `docs/product-context-map.md`
-3. the feature brief, including its `## Product Context` section
+2. `docs/deep-module-map.md`
+3. the feature brief, including its `## Deep Module` section
 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
@@ -56,9 +56,9 @@ Apply those inputs. Do not summarize them back into the technical design unless
 
 Require a Markdown feature brief. If the user only has a vague idea, route to `feature-brief-writer` first.
 
-Require `docs/product-context-map.md`. If it is missing, stop and ask the user to create it with `product-context-map-writer` first. Do not infer or invent Product Contexts.
+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 Product Contexts. Preserve those selected contexts 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 Product Context Map first.
+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.
 
 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.
 
@@ -70,7 +70,7 @@ For UI-related features, `ux.md` is source context, not inspiration. If `ux.md`
 
 Translate product intent into implementation direction.
 
-Product Contexts answer “where does this work belong?” Architecture guidance answers “how is that context structured internally?” Translate the feature brief's selected Product Contexts 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 Product Context Map by default.
+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.
 
 Prefer:
 
@@ -79,7 +79,7 @@ Prefer:
 - current codebase patterns over speculative redesigns
 - explicit open questions over risky assumptions
 - delegation to the right skills instead of duplicating their guidance
-- preserving the feature brief's selected Product Contexts
+- preserving the feature brief's selected Deep Modules
 
 Avoid:
 
@@ -87,7 +87,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 Product Contexts or moving work into unselected contexts
+- inventing new Deep Modules or moving work into unselected modules
 - large template sections that say “none” without adding value
 
 ## Delegation rule
@@ -128,7 +128,7 @@ Use this structure as a starting point. Delete sections that do not add value.
 
 ## Inputs
 - Product vision: <path>
-- Product Context Map: <path>
+- Deep Module Map: <path>
 - Feature brief: <path>
 - Delegated skills: <skills later implementation should apply>
 
@@ -141,7 +141,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 Product Contexts translate into architecture, module, command, file, or implementation boundaries when that affects downstream work.>
+<Explain how the selected Deep Modules translate into architecture, module, command, file, or implementation boundaries when that affects downstream work.>
 
 ## Validation
 <Focused test/build/manual checks.>

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

@@ -30,7 +30,7 @@ Act as a senior UX/UI designer. Turn an approved product artifact into usable, e
 
 ### What this skill must not do
 
-- Do not create or update product visions, Product Context Maps, feature briefs, technical designs, Epics, User Stories, implementation plans, or production code.
+- 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.

package/bin/features/sync-project/preview.js

@@ -1 +0,0 @@
-export { getSyncPreviews, isActionableSyncPreview, shouldAskForSyncAction } from '../../shared/sync-preview.js';

package/templates/skills/product-context-map-writer/SKILL.md

@@ -1,211 +0,0 @@
----
-name: product-context-map-writer
-description: Create or update docs/product-context-map.md as an architecture-agnostic map of durable product responsibility boundaries before feature brief work.
----
-
-# Product Context Map Writer
-
-## Purpose
-
-Create or update `docs/product-context-map.md`, the product-level map of responsibility areas that downstream feature briefs, technical designs, and implementation plans use to decide where work belongs.
-
-A Product Context is DDD-inspired but architecture-agnostic. It is not a folder structure, service boundary, layer, package, or requirement to use Domain-Driven Design.
-
-This skill owns the Product Context Map only. It does not own feature briefs, technical designs, user stories, implementation plans, code structure, or architecture selection.
-
-## Pipeline Contract
-
-### What this skill needs
-
-- `docs/product-vision.md`.
-- Existing `docs/product-context-map.md` when revising the map.
-- Enough user interview context to identify durable product responsibility boundaries, exclusions, scenarios, relationships, and cross-context rules.
-
-### What this skill writes
-
-- `docs/product-context-map.md`.
-
-### When this skill stops
-
-- `docs/product-vision.md` is missing; tell the user to create it first with `product-vision-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 Product Context boundaries; ask one focused question instead of drafting.
-
-### What this skill must not do
-
-- Do not create feature briefs, technical designs, UX specs, Epics, User Stories, implementation plans, or production code.
-- Do not choose application architecture, folders, services, packages, database tables, or team ownership.
-- Do not ask for or require a final confirmation summary before writing once enough context map information is available.
-- Do not invent Product Contexts without grounding them in the product vision and user interview.
-
-## What a Product Context is
-
-A Product Context is a durable area of product responsibility: a named part of the product that owns specific user-facing behaviors, rules, decisions, promises, and language.
-
-Use Product Contexts to answer:
-
-```txt
-When future work changes behavior, which part of the product is responsible for deciding how that behavior should work?
-```
-
-A Product Context is not:
-
-- a feature
-- a screen
-- a command
-- a workflow step
-- a code folder
-- a package, service, or database table
-- a technical layer
-- an org chart or team boundary
-
-Good Product Contexts are stable product jobs that will absorb multiple features over time. They should be broad enough to own meaningful behavior and narrow enough that ownership is defensible.
-
-Use these tests:
-
-- If it describes a stable product job or promise, it may be a context.
-- If it describes one command, page, database object, or implementation mechanism, it is probably too small or too technical.
-- If it only says "user control," "quality," "security," or another value that applies everywhere, it is probably a cross-context rule instead of a context.
-- If two candidates cannot explain what decisions they own differently, merge or rename them.
-- If future feature work would routinely ask "does this belong here or there?", keep clarifying the boundary.
-
-## Required source of truth
-
-Before doing any Product Context Map work, read:
-
-```txt
-docs/product-vision.md
-```
-
-Use the product vision as the source of truth for purpose, audience, positioning, principles, boundaries, trust expectations, and success signals.
-
-## Hard start rule
-
-Do not create or update a Product Context Map if `docs/product-vision.md` is missing.
-
-If the product vision is missing:
-
-1. Stop.
-2. Tell the user that a Product Context Map requires `docs/product-vision.md`.
-3. Instruct the user to create the product vision first with `product-vision-writer`.
-4. Do not draft, infer, or save a context map until the product vision exists.
-
-## Output location
-
-Write the map to:
-
-```txt
-docs/product-context-map.md
-```
-
-This file is user-owned product content created or updated by this skill. It is not a Sibu-managed workflow template.
-
-## Interview posture
-
-Be deliberately interrogative before writing.
-
-- Ask one focused question at a time.
-- Keep asking until you understand the product's major responsibility areas, boundaries, key scenarios, relationships, and naming.
-- Treat "100% understanding" as: contexts, responsibilities, exclusions, scenarios, relationships, and deep-module boundaries are clear enough to defend.
-- Treat "enough context" as: contexts, responsibilities, exclusions, scenarios, relationships, and deep-module boundaries are clear enough to defend in the map.
-- Do not ask the user to name the Product Contexts up front. Most users do not know what the contexts should be yet.
-- Extract contexts by asking about product jobs, decisions, promises, lifecycle moments, and confusing boundaries.
-- Teach briefly as needed. If the user seems unsure, explain Product Contexts in plain language before asking the next question.
-- Do not create contexts from vague labels without confirming what they own and do not own.
-- If the conversation stalls, propose one concise assumption for the next unresolved point and ask the user to confirm or correct it.
-
-## Interview method
-
-Derive candidate contexts from answers. Do not make the user design the map from scratch.
-
-Prefer questions like:
-
-- "What is the existing product/repo state before the product starts helping?"
-- "What durable job is the product doing for the user at this moment?"
-- "What decisions should this area own, and which decisions should it not own?"
-- "What should never be silently changed or overwritten?"
-- "After the first setup, what ongoing responsibilities does the product have?"
-- "What user scenarios would feel like the same responsibility area over time?"
-- "Where do you expect future features to create boundary confusion?"
-- "Is this a separate responsibility area, or a rule that applies across all areas?"
-- "If this behavior changed, what other parts of the product would need to know?"
-- "What language would a product manager, designer, engineer, and agent all understand?"
-
-Avoid questions like:
-
-- "What contexts do you want?"
-- "What bounded contexts should we use?"
-- "What services/packages/modules should exist?"
-- "What are your DDD boundaries?"
-
-When a user gives a feature, command, screen, template, or technical mechanism, translate it into the product responsibility it represents and ask the user to confirm or correct that responsibility.
-
-Example:
-
-```txt
-User: "sibu init scaffolds the AI files."
-Assistant: "That sounds like an AI workflow adoption/scaffolding responsibility, not general project onboarding. It owns how an existing repo adopts Sibu-managed AI workflow files. Is that right?"
-```
-
-Ask enough follow-up to fill these fields for each context:
-
-- Purpose
-- Owns
-- Does not own
-- Key scenarios
-- Related contexts
-- Boundary notes
-
-Also identify cross-context rules, especially product values that apply everywhere, such as user ownership, safety, transparency, local customization, or quality.
-
-## Context principles
-
-Product Contexts should be:
-
-- product responsibility boundaries, not implementation details
-- deep modules: simple from the outside, rich enough inside to own meaningful behavior
-- durable enough to guide multiple features over time
-- named in language useful across product planning, technical design, implementation planning, and code organization
-
-Avoid shallow contexts based on one feature, screen, command, workflow step, database table, folder, or technical layer.
-
-## Workflow
-
-1. Read `docs/product-vision.md`.
-2. Read existing `docs/product-context-map.md` if it exists.
-3. Ask one focused question at a time until the context direction is clear.
-4. Write or update `docs/product-context-map.md` once enough context is available.
-
-## Recommended map structure
-
-```md
-# Product Context Map
-
-## Purpose
-<How this map guides feature briefs, technical design, and implementation.>
-
-## Contexts
-
-### <Context Name>
-- Purpose:
-- Owns:
-- Does not own:
-- Key scenarios:
-- Related contexts:
-- Boundary notes:
-
-## Cross-Context Rules
-- <Rules for when work spans contexts or needs a new context.>
-```
-
-Adapt the structure when useful, but keep the map concise and product-level.
-
-## Final response behavior
-
-After writing the file, final-answer with only the path created or updated:
-
-```txt
-docs/product-context-map.md
-```
-
-Do not paste the map body, excerpt, outline, or section summaries unless the user explicitly asks for inline review in the current request.