@juancr11/sibu 0.12.4 → 0.13.1

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.4",
+  "version": "0.13.1",
   "description": "CLI for setting up a local AI-augmented development workflow.",
   "repository": {
     "type": "git",

package/templates/manifest.json

@@ -1,11 +1,11 @@
 {
-  "templateVersion": "95",
+  "templateVersion": "97",
   "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": {
@@ -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": {
@@ -128,10 +128,10 @@
       ]
     },
     "skills/scrum-master-planner/SKILL.md": {
-      "version": "10",
+      "version": "11",
       "description": "Mandatory Scrum planner skill for creating pragmatic Epics and User Stories from approved feature and technical design docs.",
       "changes": [
-        "Removes label creation and label assignment from Scrum planning GitHub issue export while keeping the mandatory GitHub export gate and native sub-issue requirements."
+        "Clarifies that User Stories should be deployable increments that can be merged safely on their own, even when gated or incomplete until the parent Epic is done."
       ]
     },
     "skills/ai-implementation-planner/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/scrum-master-planner/SKILL.md

@@ -164,7 +164,9 @@ Adapt headings only when it improves clarity. Keep the Epic brief short.
 
 Within each Epic, decide the order of execution before writing User Story files. Use the lowest practical sequence number for the first story that should be implemented, then increment only when later stories depend on earlier work. If two or more stories can be developed at the same time, give them the same order number.
 
-Each User Story should be independently understandable and reviewable.
+Each User Story should be independently understandable, reviewable, and deployable.
+
+A User Story represents a shippable increment that can move from backlog to Done and be merged safely on its own. It may be hidden behind feature flags, internal-only paths, disabled defaults, or incomplete parent-Epic workflows, but it must leave the product in a valid deployable state without requiring unmerged sibling Stories.
 
 Use this structure:
 
@@ -206,6 +208,7 @@ Before finishing, verify:
 - every Story belongs to exactly one Epic
 - every Story filename includes a two-digit execution order prefix
 - Stories with the same order number are actually parallelizable
+- every Story can be merged and deployed safely on its own, even if its user-facing value is gated or incomplete until the Epic is done
 - Story count is pragmatic, not inflated
 - no Story adds scope that is absent from the feature brief or technical design
 - acceptance criteria are testable enough for a reviewer