@juancr11/sibu 0.9.4 → 0.9.5

package/package.json

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

package/templates/AGENTS.md

@@ -45,7 +45,7 @@ For planned product/feature work, use this pipeline: product vision -> deep modu
 - For requests to create, revise, or clarify a technical design, implementation-oriented design doc, architecture approach, technical tradeoffs, technical risks, or implementation plan for an approved feature, use `technical-design-writer`.
 - For requests to create Epics, User Stories, Scrum planning artifacts, backlog slices, or delivery plans from an approved feature brief and technical design, use `scrum-master-planner`.
 - For requests to turn a specific User Story into an implementation checklist, coding plan, step-by-step execution plan, or baby-step plan, use `ai-implementation-planner`.
-- For requests to implement, execute, continue, or work through a specific User Story under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.md` or an existing story implementation plan under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.impl_plan/`, use `ai-implementation-plan-executor`; the executor must stop and direct the user to `ai-implementation-planner` when the story plan is missing.
+- For requests to implement, execute, continue, or work through a specific User Story under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.md` or an existing story implementation plan under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.impl_plan/`, use `ai-implementation-plan-executor`; when the story plan is missing, the executor should create it with `ai-implementation-planner` and immediately continue into implementation without a separate plan approval gate.
 {{OPTIONAL_SKILL_ROUTING}}
 
 ## Sibu maintenance

package/templates/manifest.json

@@ -1,11 +1,11 @@
 {
-  "templateVersion": "78",
+  "templateVersion": "82",
   "templates": {
     "AGENTS.md": {
-      "version": "25",
+      "version": "26",
       "description": "Project-level agent instructions and Sibu maintenance guidance.",
       "changes": [
-        "Clarifies Deep Module routing as complexity-hiding implementation module planning."
+        "Updates implementation routing so missing story plans are generated and executed immediately without a separate plan approval gate."
       ]
     },
     ".codex/config.toml": {
@@ -101,10 +101,10 @@
       ]
     },
     "skills/architecture/ddd-hexagonal/SKILL.md": {
-      "version": "4",
+      "version": "7",
       "description": "Selectable back-end architecture skill for DDD and Hexagonal Architecture.",
       "changes": [
-        "Clarifies that Deep Modules hide implementation complexity behind small interfaces and are not product categories by themselves."
+        "Adds anti-corruption adapter guidance for translating external models at infrastructure boundaries."
       ]
     },
     "skills/architecture/command-pattern/SKILL.md": {
@@ -136,19 +136,17 @@
       ]
     },
     "skills/ai-implementation-planner/SKILL.md": {
-      "version": "11",
+      "version": "12",
       "description": "Mandatory AI implementation planner skill for turning one approved User Story into small, story-local implementation step files.",
       "changes": [
-        "Adds a plan review gate so newly created implementation plans wait for user approval before execution.",
-        "Clarifies that next-story planning handoffs from the executor must stop after planning and wait for approval."
+        "Removes the implementation-plan approval gate and allows execution to continue immediately when implementation is requested."
       ]
     },
     "skills/ai-implementation-plan-executor/SKILL.md": {
-      "version": "17",
+      "version": "18",
       "description": "Mandatory AI implementation plan executor skill for implementing full story plans before story-level review and commit.",
       "changes": [
-        "Prevents the executor from staging or committing Git-ignored story artifacts, including docs/features paths when ignored.",
-        "Clarifies that ignored approval marker changes remain local and commits include only eligible non-ignored story changes."
+        "Allows the executor to generate missing story plans and immediately implement them, preserving only the story-level review gate after implementation."
       ]
     },
     "skills/ai-prompt-engineer-master/SKILL.md": {

package/templates/skills/ai-implementation-plan-executor/SKILL.md

@@ -24,17 +24,15 @@ Execute one existing story implementation plan completely, one ordered step file
 - Code, docs, tests, or other repo changes required by all unapproved implementation steps in the story plan.
 - Step approval metadata in every completed step file only after explicit story-level user approval.
 - One focused commit for the approved story implementation, excluding any paths ignored by Git.
-- When continuing an Epic and the next story has no plan, story-local implementation step files created by applying `ai-implementation-planner`.
+- When starting or continuing a story that has no plan, story-local implementation step files created by applying `ai-implementation-planner`, followed immediately by implementation.
 
 ### When this skill stops
 
 - The user does not provide or clearly identify exactly one User Story file or `.impl_plan/` folder.
-- The starting implementation plan is missing, empty, invalid, or has no ordered step files; direct the user to `ai-implementation-planner`.
 - Any required source artifact is missing, incomplete, or invalid in a way its owning stage should repair.
 - The story, any step, or feature has UI impact and `ux.md` is missing; direct the user to `ux-expert`.
 - Validation fails and the fix is ambiguous, risky, or would exceed the approved plan.
 - A step conflicts with the story, Epic, feature brief, technical design, UX spec, or approved Deep Module boundaries.
-- A newly planned next story is ready for plan review and approval before execution.
 
 ### What this skill must not do
 
@@ -43,7 +41,6 @@ Execute one existing story implementation plan completely, one ordered step file
 - Do not reread `docs/deep-module-map.md` by default; trust `technical_design.md` for Deep Module implementation boundaries.
 - Do not mark any step approved before explicit story-level user approval.
 - Do not commit story implementation changes before explicit story-level user approval.
-- Do not continue past a newly created implementation plan for the next story until the user approves that plan.
 
 ## Required source context
 
@@ -104,10 +101,10 @@ Reread broad source context only when scope changes, validation fails in a way t
 
 If the initial User Story has no matching `.impl_plan/`, or the initial `.impl_plan/` folder is missing, empty, or has no ordered `.md` step files:
 
-1. Stop.
-2. Tell the user the implementation plan is missing or invalid.
-3. Instruct the user to use `templates/skills/ai-implementation-planner/SKILL.md` to create or repair it first.
-4. Do not infer steps from the story or technical design.
+1. Apply `ai-implementation-planner` to create or repair the story-local implementation plan.
+2. Quality-check that the generated plan has ordered step files for exactly that story.
+3. Immediately begin executing the generated plan with this executor.
+4. Do not ask the user to approve the plan before implementation; the only required approval is the story-level review after implementation finishes.
 
 If required source context is missing:
 
@@ -120,7 +117,7 @@ If required source context is missing:
 
 Work through the full story plan in filename order, one step at a time, without asking for review or approval between steps.
 
-When a valid implementation plan exists, begin implementing the first unapproved step immediately. Do not ask for pre-implementation confirmation before changing code. This is an explicit exception to repository-level instructions that normally require confirmation before code changes: selecting this executor skill and providing a valid plan is the user's confirmation to implement the full story plan.
+When a valid implementation plan exists, begin implementing the first unapproved step immediately. If a plan was just generated by `ai-implementation-planner`, begin implementing it immediately. Do not ask for pre-implementation confirmation or plan approval before changing code. This is an explicit exception to repository-level instructions that normally require confirmation before code changes: selecting this executor skill, asking to implement or continue a story/Epic, or providing a valid plan is the user's confirmation to implement the full story plan.
 
 A step file is considered approved only when it contains this section:
 
@@ -172,9 +169,9 @@ After the approved story implementation is committed:
 2. Identify whether there is a next User Story after the completed story.
 3. If there is no next User Story in the Epic, tell the user the Epic appears ready and stop.
 4. If a next User Story exists and its `.impl_plan/` folder exists with ordered step files, immediately begin implementing that next story plan using this same story execution model.
-5. If a next User Story exists but its `.impl_plan/` folder is missing or empty, immediately create the implementation plan for that story by applying `ai-implementation-planner`, then stop and ask the user to review and approve the new plan before executing it.
+5. If a next User Story exists but its `.impl_plan/` folder is missing or empty, immediately create the implementation plan for that story by applying `ai-implementation-planner`, then immediately begin implementing the generated plan.
 
-This continuation behavior is an explicit exception to the normal hard-start rule only after a story has been approved and committed. It lets the executor keep an Epic moving while still preserving the required review gate before executing a newly created plan.
+This continuation behavior is an explicit exception to the normal hard-start rule only after a story has been approved and committed. It lets the executor keep an Epic moving while preserving only the story-level review gate after implementation.
 
 ## Implementation rules
 
@@ -201,7 +198,6 @@ Do not:
 - continue past a failed validation without reporting it and asking how to proceed
 - leave committable approved story changes uncommitted before moving to the next story
 - attempt to stage or commit story files, approval markers, or other paths that are ignored by Git
-- execute a newly created next-story plan before the user approves that plan
 
 ## Final response behavior
 
@@ -218,5 +214,5 @@ After approving and committing a story implementation, briefly report the commit
 
 - commit hash when a commit was created, or a note that only ignored changes existed and no commit was created
 - next story is being implemented immediately because it already has a plan
-- next story was planned and is waiting for plan review and approval
+- next story was planned and implementation started immediately
 - or the Epic appears ready

package/templates/skills/ai-implementation-planner/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: ai-implementation-planner
-description: Turn one approved User Story Markdown file into LLM-sized implementation step files, then request plan review before execution. Use when asked to create an implementation plan, coding checklist, step-by-step execution plan, or baby-step plan for completing a specific User Story from docs/features/<feature-slug>/epics/<epic-slug>/stories/.
+description: Turn one approved User Story Markdown file into LLM-sized implementation step files, then continue directly into execution when implementation is requested. Use when asked to create an implementation plan, coding checklist, step-by-step execution plan, or baby-step plan for completing a specific User Story from docs/features/<feature-slug>/epics/<epic-slug>/stories/.
 ---
 
 # AI Implementation Planner
 
 ## Purpose
 
-Turn one approved User Story into concrete Markdown step files an AI coding agent can execute safely and completely. This skill owns implementation planning for one story at a time, not product scope, technical design decisions, Scrum planning, or code implementation. After writing the plan, it asks for plan review and approval before any executor begins implementation.
+Turn one approved User Story into concrete Markdown step files an AI coding agent can execute safely and completely. This skill owns implementation planning for one story at a time, not product scope, technical design decisions, Scrum planning, or code implementation. After writing the plan, it does not require a separate plan approval gate; implementation may continue immediately through `ai-implementation-plan-executor` when the user requested execution or Epic continuation.
 
 ## Pipeline Contract
 
@@ -30,7 +30,6 @@ Turn one approved User Story into concrete Markdown step files an AI coding agen
 - Any required source artifact is missing, incomplete, or invalid in a way its owning stage should repair.
 - The story or feature has UI impact and `ux.md` is missing; direct the user to `ux-expert`.
 - The request is to write production code, execute an implementation plan, create stories, or perform another pipeline stage.
-- A newly created implementation plan is ready for user review and approval before execution.
 
 ### What this skill must not do
 
@@ -38,7 +37,7 @@ Turn one approved User Story into concrete Markdown step files an AI coding agen
 - Do not modify prior-stage artifacts.
 - Do not reread `docs/deep-module-map.md` by default; trust `technical_design.md` for Deep Module implementation boundaries.
 - Do not infer implementation scope from an Epic brief, feature brief, or technical design without exactly one User Story.
-- Do not execute the plan after creating it, even when invoked as the next-story planning handoff from `ai-implementation-plan-executor`.
+- Do not write production code directly from this planner; hand off to `ai-implementation-plan-executor` for implementation.
 
 ## Required input
 
@@ -241,18 +240,20 @@ Before finishing, verify:
 - the step files preserve approved Deep Module boundaries and stop before unrelated module movement
 - architecture and code-quality steps align with the relevant skills
 
-### 6. Request plan review
+### 6. Continue or report
 
-After writing and quality-checking the implementation step files, stop and ask the user to review and approve the plan before execution. Do not start implementation in the same turn.
+After writing and quality-checking the implementation step files, do not ask for plan approval before execution. If the user asked to implement, execute, continue, or work through the story or Epic, immediately hand off to `ai-implementation-plan-executor` for the newly created plan in the same turn. The user's execution request plus a valid generated plan is enough pre-implementation confirmation; the only required user approval is the story-level review after execution finishes.
 
-When this skill is invoked as the next-story planning handoff from `ai-implementation-plan-executor`, the same gate applies: create the plan, summarize it, and wait for explicit approval before the executor starts changing code for that story.
+If the user asked only to create a plan and did not ask for implementation, stop after creating the plan and report where it was written. Make clear that no plan approval is required before a later executor run.
 
-The final planning response must briefly include:
+When this skill is invoked as the next-story planning handoff from `ai-implementation-plan-executor`, create the plan and immediately return control to the executor so it can implement the next story without a plan-review gate.
+
+The final planning-only response must briefly include:
 
 - the source User Story path
 - the implementation plan folder path
 - the ordered step files created
-- any assumptions, risks, or validation commands worth reviewing
-- that execution should wait until the user approves the plan
+- any assumptions, risks, or validation commands worth noting
+- that no separate plan approval is required before execution
 
 Do not paste step-file bodies, excerpts, outlines, task text, done conditions, or section summaries. Only include generated step files when the user explicitly asks for inline review in the current request.

package/templates/skills/architecture/ddd-hexagonal/SKILL.md

@@ -138,6 +138,17 @@ Use this default mapping when the project does not already have a clearer conven
 /src/modules/<module-slug>/infra/**        # Technical implementations and external integrations
 ```
 
+Structure each application use case with files, not nested subfolders:
+
+```text
+/src/modules/<module-slug>/application/<usecase-slug>/input.*    # Input DTO/schema/command shape
+/src/modules/<module-slug>/application/<usecase-slug>/output.*   # Output DTO/result shape
+/src/modules/<module-slug>/application/<usecase-slug>/usecase.*  # Use case orchestration
+/src/modules/<module-slug>/application/<usecase-slug>/ports.*    # Ports required by this use case
+```
+
+Use the project language's normal extension, such as `.ts`, `.go`, or `.py`. Keep ports local to the use case by default. Extract shared application ports only when multiple use cases truly need the same abstraction. Do not create `input/`, `output/`, `usecase/`, or `ports/` folders unless an existing project convention already requires it.
+
 Entrypoints such as routes, jobs, or handlers should remain thin driving adapters that call application behavior inside the selected Deep Module.
 
 ## Ports and adapters
@@ -166,9 +177,40 @@ Typical driven adapters:
 
 Adapters should hide technical details rather than leak them inward.
 
-## Use cases
+### Anti-corruption adapters
+
+When integrating with an external API, SDK, database shape, file format, or third-party model, treat the infrastructure adapter as the anti-corruption layer. Translate external language and data shapes into application/domain concepts at the boundary.
+
+Place anti-corruption translation in infrastructure adapter files by default:
+
+```text
+/src/modules/<module-slug>/infra/<adapter-slug>.*        # Adapter and translation logic
+/src/modules/<module-slug>/infra/<adapter-slug>.types.*  # External DTOs/types when useful
+```
+
+Do not create a separate `acl/` folder by default. Split translation into extra infrastructure-local files only when the adapter becomes too large.
+
+External DTOs, SDK response types, database rows, and third-party vocabulary must not leak into `domain/**` or use case `input.*` / `output.*` unless the product language truly matches the external language. If changing an external API response would force changes in domain entities, value objects, or use case boundaries, the anti-corruption boundary is leaking.
+
+## Use cases, application services, and domain services
+
+### Use case
+
+A use case represents one externally meaningful backend capability triggered by a route, CLI command, job, handler, or other driving adapter.
+
+Place each use case at:
+
+```text
+/src/modules/<module-slug>/application/<usecase-slug>/usecase.*
+```
 
-A use case should represent one meaningful backend capability.
+Its sibling files should define its boundary:
+
+```text
+/src/modules/<module-slug>/application/<usecase-slug>/input.*
+/src/modules/<module-slug>/application/<usecase-slug>/output.*
+/src/modules/<module-slug>/application/<usecase-slug>/ports.*
+```
 
 A use case should:
 - orchestrate domain logic and required ports explicitly
@@ -180,6 +222,35 @@ A use case should not:
 - hide infrastructure details inline
 - absorb framework behavior that belongs in adapters
 
+### Application service
+
+An application service is reusable application-layer orchestration shared by multiple use cases. Use it only when multiple use cases truly need the same orchestration, transaction coordination, or port coordination. Do not create application services just to shorten one use case; prefer private helpers first.
+
+Place application services under:
+
+```text
+/src/modules/<module-slug>/application/services/<service-slug>.*
+```
+
+Application services may depend on domain concepts and application ports, but must not depend on infrastructure implementations, SDK clients, database clients, or framework request/response objects.
+
+### Domain service
+
+A domain service contains pure business behavior that does not naturally belong on one entity or value object. Use it when the rule is domain language, needs multiple domain concepts, and has no dependency on ports, databases, SDKs, frameworks, or technical time/randomness unless those are passed in as values.
+
+Place domain services under:
+
+```text
+/src/modules/<module-slug>/domain/services/<service-slug>.*
+```
+
+Domain services must stay pure and should not orchestrate use cases or external capabilities.
+
+Rule of thumb:
+- Use case: “Do this application action.”
+- Application service: “Reuse this application orchestration.”
+- Domain service: “Evaluate or perform this pure domain rule.”
+
 ## Simplicity rule
 
 - Use the fewest layers that preserve clear boundaries.