@juancr11/sibu 0.12.4 → 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.4",
+  "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": "95",
+  "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": {
@@ -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?