@juancr11/sibu 0.12.3 → 0.13.0

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

@@ -147,7 +147,7 @@ export const SELECTABLE_ARCHITECTURE_SKILLS = [
     {
         id: 'ddd-hexagonal',
         name: 'DDD + Hexagonal Architecture',
-        description: 'Install back-end architecture guidance for DDD, ports/adapters, and inward dependencies',
+        description: 'Choose for complex back-end domains that need DDD, ports/adapters, and strict inward dependencies',
         routingInstruction: 'For backend features, refactors, bug fixes, persistence, external integrations, application/service boundaries, domain modeling, or architectural tradeoffs, use `ddd-hexagonal`.',
         templateRelativePath: 'skills/architecture/ddd-hexagonal/SKILL.md',
         targetRelativePathsByAgent: {
@@ -160,7 +160,7 @@ export const SELECTABLE_ARCHITECTURE_SKILLS = [
     {
         id: 'command-pattern',
         name: 'Command Pattern',
-        description: 'Install architecture guidance for structuring executable operations as commands and handlers',
+        description: 'Choose for workflow-heavy apps that need executable operations structured as commands and handlers',
         routingInstruction: 'For work that structures actions, workflows, command handlers, operation dispatch, request processing, or executable tasks, use `command-pattern`.',
         templateRelativePath: 'skills/architecture/command-pattern/SKILL.md',
         targetRelativePathsByAgent: {
@@ -170,6 +170,19 @@ export const SELECTABLE_ARCHITECTURE_SKILLS = [
             windsurf: '.agents/skills/command-pattern/SKILL.md',
         },
     },
+    {
+        id: 'layered-architecture',
+        name: 'Layered Architecture',
+        description: 'Choose for smaller apps that need lightweight separation with controllers, services, models, and repositories',
+        routingInstruction: 'For smaller apps that need lightweight separation of concerns with controllers, services, models, and repositories, use `layered-architecture`.',
+        templateRelativePath: 'skills/architecture/layered-architecture/SKILL.md',
+        targetRelativePathsByAgent: {
+            codex: '.agents/skills/layered-architecture/SKILL.md',
+            gemini: '.agents/skills/layered-architecture/SKILL.md',
+            claude: '.agents/skills/layered-architecture/SKILL.md',
+            windsurf: '.agents/skills/layered-architecture/SKILL.md',
+        },
+    },
 ];
 export const SELECTABLE_WORKFLOW_SKILLS = [
     {

package/package.json

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

package/templates/manifest.json

@@ -1,11 +1,11 @@
 {
-  "templateVersion": "94",
+  "templateVersion": "96",
   "templates": {
     "AGENTS.md": {
-      "version": "28",
+      "version": "29",
       "description": "Project-level agent instructions and Sibu maintenance guidance.",
       "changes": [
-        "Routes story and Epic planning requests to the executor by default so generated plans are implemented immediately unless planning-only is explicit."
+        "Can render Layered Architecture routing when that architecture option is selected."
       ]
     },
     ".codex/config.toml": {
@@ -58,10 +58,10 @@
       ]
     },
     "skills/deep-module-map-writer/SKILL.md": {
-      "version": "3",
+      "version": "4",
       "description": "Mandatory Deep Module Map writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Strengthens Deep Module Map interviews to ask as many one-at-a-time questions as needed and resolve material boundary questions before drafting."
+        "Adds explicit Deep Module Map discovery guidance so agents keep interviewing one question at a time until module interfaces, hidden complexity, ownership, exclusions, scenarios, relationships, and cross-module rules are clear enough to defend."
       ]
     },
     "skills/feature-brief-writer/SKILL.md": {
@@ -89,7 +89,7 @@
       "version": "1",
       "description": "Selectable Go skill installed when Go language support is selected.",
       "changes": [
-        "Adds an optional Go skill with concise, Effective Go\u2013style guidance for .go files, package APIs, interfaces, errors, receivers, concurrency, and tests."
+        "Adds an optional Go skill with concise, Effective Go–style guidance for .go files, package APIs, interfaces, errors, receivers, concurrency, and tests."
       ]
     },
     "skills/postgresql-expert/SKILL.md": {
@@ -161,6 +161,13 @@
       "changes": [
         "Strengthens UX interviews to resolve material experience questions before drafting and replaces open UX questions with risks/tradeoffs."
       ]
+    },
+    "skills/architecture/layered-architecture/SKILL.md": {
+      "version": "1",
+      "description": "Selectable lightweight architecture skill for pragmatic controllers, services, models, and repositories guidance.",
+      "changes": [
+        "Adds a Layered Architecture skill for smaller apps that need simple separation of concerns."
+      ]
     }
   }
 }

package/templates/skills/architecture/layered-architecture/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: layered-architecture
+description: Use this skill for smaller apps that need lightweight separation of concerns with controllers, services, models, and repositories.
+---
+
+# layered-architecture
+
+Use this skill for smaller apps that need basic separation of concerns.
+
+This is Sibu's pragmatic layered architecture guidance. It is not the only valid meaning of “Layered Architecture”; it is the lightweight shape Sibu recommends when a project needs clearer boundaries but not a full domain-architecture framework.
+
+## Main rule
+
+> **Controllers adapt input, services coordinate behavior, models represent core concepts, and repositories hide persistence details.**
+
+Keep the layers useful, not ceremonial. If splitting a small function across layers makes the code harder to understand, prefer the simpler code.
+
+## Layer responsibilities
+
+### Controllers
+
+Controllers are entrypoints. They adapt the outside world into application calls.
+
+Controllers may:
+
+- parse request, CLI, job, or UI-facing input
+- call services
+- translate service results into response, CLI, or UI-facing output
+- handle transport-specific validation and formatting
+
+Controllers should not:
+
+- own business rules
+- talk directly to persistence
+- coordinate multi-step business behavior that belongs in a service
+- leak framework-specific objects into services
+
+### Services
+
+Services coordinate application behavior and business rules.
+
+Services may:
+
+- run use-case or workflow logic
+- validate business conditions
+- coordinate models and repositories
+- return plain results that controllers can adapt
+
+Services should not:
+
+- depend on framework request/response objects
+- embed SQL, ORM, SDK, or filesystem details directly
+- become generic “miscellaneous helper” bags
+
+### Models
+
+Models represent core data shapes or business concepts.
+
+Models may:
+
+- define meaningful application data structures
+- contain simple validation or derived behavior when it clarifies the concept
+- make important states and invariants explicit
+
+Models should not:
+
+- mirror persistence tables blindly when that hides business meaning
+- know about controllers, framework concerns, or repository implementations
+- become over-modeled when a plain type or object is enough
+
+### Repositories
+
+Repositories hide persistence and data-access details.
+
+Repositories may:
+
+- load and save models or data shapes
+- translate between storage records and application-facing data
+- contain SQL, ORM, filesystem, or external data-access details
+
+Repositories should not:
+
+- own business workflows
+- expose low-level persistence details to services
+- import controllers or transport-layer code
+
+## Dependency direction
+
+Use this default flow:
+
+```txt
+controller -> service -> repository
+service -> model
+repository -> model or storage mapping
+```
+
+Avoid these flows:
+
+```txt
+controller -> repository
+service -> controller
+model -> controller
+repository -> service
+```
+
+## Practical project mapping
+
+Use the project's existing folders when they are already clear. If no convention exists, this simple shape is enough:
+
+```text
+src/controllers/**    # entrypoints and adapters
+src/services/**       # application behavior and business rules
+src/models/**         # core data shapes and business concepts
+src/repositories/**   # persistence and data access
+```
+
+For modular projects, place those layers inside the owning module instead:
+
+```text
+src/modules/<module-slug>/controllers/**
+src/modules/<module-slug>/services/**
+src/modules/<module-slug>/models/**
+src/modules/<module-slug>/repositories/**
+```
+
+## Review checklist
+
+- Does each controller stay thin and call services instead of persistence?
+- Does each service coordinate behavior without depending on framework objects?
+- Do repositories hide data-access details from services?
+- Are models meaningful without unnecessary ceremony?
+- Is the layer split making the app easier to understand?

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

@@ -139,6 +139,42 @@ Be deliberately interrogative before writing.
 - 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.
 
+## Clarify module intent before drafting
+
+Do not draft a Deep Module Map from a vague product idea, feature label, command name, screen, folder, or implementation mechanism alone. The map must reflect the user's actual system responsibilities and the complexity boundaries that should stay stable over time.
+
+A request is too vague when the user gives only a broad area such as "onboarding," "analytics," "sync," "workflow," "AI features," "the CLI," or "the database" without enough detail to know what capability the rest of the system should rely on or what implementation complexity should be hidden.
+
+When module intent is vague or incomplete:
+
+1. Stop before drafting.
+2. Explain briefly that a responsible Deep Module Map requires more boundary context.
+3. Ask one focused discovery question.
+4. Wait for the user's answer.
+5. Continue asking one question at a time until there is enough context to defend the map.
+6. Draft only after the module candidates, interfaces, hidden complexity, ownership, exclusions, scenarios, relationships, and cross-module rules are clear enough to avoid invention.
+
+Do not ask the user to answer a large questionnaire all at once. Keep the interview conversational and focused.
+
+## Gather the minimum required module context
+
+Ask every question needed to remove material ambiguity, but only one at a time. Clarify:
+
+- what product or system capabilities the map must support
+- 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
+- which responsibilities each candidate module owns
+- which responsibilities each candidate module explicitly does not own
+- key scenarios that prove the module boundary is useful
+- relationships and dependencies between candidate modules
+- cross-module rules such as user ownership, safety, validation, local customization, or read-only vs mutating behavior
+- where future implementation work is likely to create boundary confusion
+
+Treat "enough context" as: candidate modules, suggested slugs, simple external interfaces, hidden implementation complexity, responsibilities, exclusions, scenarios, relationships, and cross-module rules are all clear enough to defend. Do not draft a map with an `Open Questions` section. Resolve material questions during the interview, or record only known risks/tradeoffs after decisions are made.
+
+If the conversation stalls, offer one concise default assumption for the next unresolved boundary and ask the user to confirm, correct, or reject it before proceeding.
+
 ## Interview method
 
 Derive candidate modules from answers. Do not make the user design the map from scratch.