@juancr11/sibu 0.9.4 → 0.9.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@juancr11/sibu",
-  "version": "0.9.4",
+  "version": "0.9.6",
   "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": "84",
   "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": "13",
       "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."
+        "Clarifies that executor handoffs can come from the next story or next Epic and still continue without plan approval."
       ]
     },
     "skills/ai-implementation-plan-executor/SKILL.md": {
-      "version": "17",
+      "version": "20",
       "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."
+        "Changes next-Epic continuation to choose the next logical Epic based on dependencies, readiness, risk, and value instead of filename order."
       ]
     },
     "skills/ai-prompt-engineer-master/SKILL.md": {

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

@@ -24,17 +24,16 @@ 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 an Epic is complete, the next Epic in the same feature is selected by inspecting the feature's `epics/` folder, then the first story in that Epic is planned and implemented immediately.
 
 ### 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 +42,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 +102,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 +118,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:
 
@@ -140,7 +138,7 @@ When starting or resuming a plan:
 6. Stop only for ambiguity, missing required files, conflicting scope, failed validation that cannot be safely fixed within the plan, or material risk.
 7. After the final unapproved step is implemented, report what changed, validation results, and any risks, then wait for explicit story-level approval.
 
-Do not mark steps approved, commit changes, or move to the next story until the user explicitly approves the completed story implementation.
+Do not mark steps approved, commit changes, move to the next story, or move to the next Epic until the user explicitly approves the completed story implementation.
 
 ## Story review gate
 
@@ -164,17 +162,19 @@ After writing approval markers, commit only the non-ignored changes produced by
 
 Use a Conventional Commits 1.0.0 message that describes the completed story. If the commit fails, stop and report the failure instead of continuing.
 
-## Epic continuation check
+## Feature continuation check
 
-After the approved story implementation is committed:
+After the approved story implementation is committed, continue through the current feature unless there is no next story or Epic to implement.
 
 1. Inspect the current Epic's `stories/` folder in filename order.
 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.
+3. 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.
+4. 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.
+5. If there is no next User Story in the current Epic, inspect the current feature's `epics/` folder and choose the next logical Epic to implement. Do not choose by filename alone. Base the choice on dependencies, prerequisite capabilities, technical sequencing, risk reduction, feature value, story readiness, and whether the Epic can be implemented without violating the feature brief or technical design. Briefly report the selected Epic and why it is the logical next step.
+6. If a next logical Epic exists, inspect its `stories/` folder, select the first logical unapproved User Story to implement, create its implementation plan if needed with `ai-implementation-planner`, and immediately begin implementing it. Prefer story order when it reflects dependencies; otherwise choose based on prerequisites, risk, and value sequence.
+7. If no logical next Epic exists or every Epic in the feature has all stories approved, tell the user the feature appears ready and stop.
 
-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 a feature moving across stories and Epics while preserving only the story-level review gate after each story implementation.
 
 ## Implementation rules
 
@@ -193,15 +193,14 @@ Do:
 
 Do not:
 
-- create a missing initial plan from scratch
+- invent a missing plan manually instead of applying `ai-implementation-planner`
 - mark any step approved before the user explicitly approves the completed story
 - commit story implementation changes before story approval
 - add product scope absent from the story, Epic, feature brief, technical design, or step files
 - silently move work into unrelated or unapproved Deep Modules
 - 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
+- leave committable approved story changes uncommitted before moving to the next story or Epic
 - 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
 
@@ -212,11 +211,12 @@ After implementing all unapproved steps in one story, briefly report:
 - the steps completed
 - validations run and their results
 - notable risks or follow-up questions, if any
-- that you are waiting for story approval before marking all completed steps approved, committing eligible non-ignored changes, and continuing the Epic
+- that you are waiting for story approval before marking all completed steps approved, committing eligible non-ignored changes, and continuing the feature
 
-After approving and committing a story implementation, briefly report the commit and the Epic continuation result:
+After approving and committing a story implementation, briefly report the commit and the feature continuation result:
 
 - 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
-- or the Epic appears ready
+- next story in the current Epic is being implemented immediately because it already has a plan
+- next story in the current Epic was planned and implementation started immediately
+- next Epic selected and its first unapproved story is being planned/implemented immediately
+- or the feature 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 or next-Epic planning handoff from `ai-implementation-plan-executor`, create the plan and immediately return control to the executor so it can implement that 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.