@juancr11/sibu 0.9.1 → 0.9.3

package/package.json

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

package/templates/manifest.json

@@ -1,5 +1,5 @@
 {
-  "templateVersion": "75",
+  "templateVersion": "77",
   "templates": {
     "AGENTS.md": {
       "version": "25",
@@ -130,10 +130,10 @@
       ]
     },
     "skills/scrum-master-planner/SKILL.md": {
-      "version": "9",
+      "version": "10",
       "description": "Mandatory Scrum planner skill for creating pragmatic Epics and User Stories from approved feature and technical design docs.",
       "changes": [
-        "Makes the GitHub export gate mandatory after local Scrum planning, requiring agents to check available GitHub MCP capabilities and either ask for export, report skipped export, or report created issues."
+        "Removes label creation and label assignment from Scrum planning GitHub issue export while keeping the mandatory GitHub export gate and native sub-issue requirements."
       ]
     },
     "skills/ai-implementation-planner/SKILL.md": {
@@ -145,12 +145,11 @@
       ]
     },
     "skills/ai-implementation-plan-executor/SKILL.md": {
-      "version": "16",
+      "version": "17",
       "description": "Mandatory AI implementation plan executor skill for implementing full story plans before story-level review and commit.",
       "changes": [
-        "Changes execution from per-step approval to full-story execution followed by one story-level review gate.",
-        "Marks all completed steps approved and commits once after the completed story is approved.",
-        "Continues Epics automatically by implementing the next planned story or planning the next unplanned story and waiting for plan approval."
+        "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."
       ]
     },
     "skills/ai-prompt-engineer-master/SKILL.md": {

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

@@ -23,7 +23,7 @@ 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.
+- 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 this skill stops
@@ -160,7 +160,7 @@ When the user explicitly approves the completed story, update every step file co
 
 Before writing approval markers, identify the current Git user with `git config user.name`; if it is unavailable, use `git config user.email`. Use that value for `Approved by`.
 
-After writing approval markers, commit only the changes produced by the approved story before continuing. The commit must include all step file approval markers and files intentionally changed while implementing the story. It must not include unrelated local edits or pre-existing worktree changes. Use the files tracked during story execution and a focused `git status --short` check to stage the correct paths. Do not run broad `git diff` investigations or other "what changed?" archaeology unless it is required to avoid committing unrelated changes and the user has approved that extra inspection.
+After writing approval markers, commit only the non-ignored changes produced by the approved story before continuing. Do not attempt to stage or commit paths ignored by Git, including `docs/features/**` paths when the repository ignores them. The commit must include files intentionally changed while implementing the story that are eligible to be committed, and it must include step file approval markers only when those step files are not ignored. Ignored approval marker changes remain local and uncommitted; report that clearly. If every story change is ignored and there is nothing eligible to commit, skip the commit, report that no commit was created, and continue only according to the Epic continuation rules that do not depend on a commit hash. The commit must not include unrelated local edits or pre-existing worktree changes. Use the files tracked during story execution, `git check-ignore` when needed, and a focused `git status --short` check to stage the correct paths. Do not run broad `git diff` investigations or other "what changed?" archaeology unless it is required to avoid committing unrelated changes and the user has approved that extra inspection.
 
 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.
 
@@ -199,7 +199,8 @@ Do not:
 - 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 approved story changes uncommitted before moving to the next story
+- 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
@@ -211,10 +212,11 @@ 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, 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 Epic
 
 After approving and committing a story implementation, briefly report the commit and the Epic 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

package/templates/skills/scrum-master-planner/SKILL.md

@@ -214,7 +214,7 @@ Before finishing, verify:
 
 After all local Epic and User Story files are written, you must run the GitHub export gate before the final response. This gate is mandatory whenever Scrum planning creates or updates local Epic or User Story files.
 
-Do not skip the gate because the user did not mention GitHub. Do not assume GitHub MCP is unavailable. Explicitly check whether GitHub MCP tools are available for issue creation, label creation, issue ID access, and native sub-issue mutation.
+Do not skip the gate because the user did not mention GitHub. Do not assume GitHub MCP is unavailable. Explicitly check whether GitHub MCP tools are available for issue creation, issue ID access, and native sub-issue mutation.
 
 If any required GitHub MCP capability is unavailable, do not offer GitHub export. In the final response, include a single concise note that GitHub export was skipped because the required GitHub MCP capabilities were unavailable.
 
@@ -224,15 +224,14 @@ If the required GitHub MCP capabilities are available:
 2. Ask one explicit opt-in question before any GitHub mutation: "GitHub MCP is available. Create GitHub Issues for these Epics and User Stories in the current repo?"
 3. If the user declines, perform no GitHub mutation.
 4. If the user accepts, create a fresh issue set every time. Do not search for duplicates or update existing issues.
-5. Create missing labels before creating issues: `epic`, `user-story`, and `sibu-generated`.
-6. Create one issue per Epic with labels `epic` and `sibu-generated`.
-7. Create one issue per User Story with labels `user-story` and `sibu-generated`.
-8. Attach each User Story issue as a native GitHub sub-issue of its parent Epic issue.
-9. Report created issue numbers or URLs.
+5. Create one issue per Epic with no labels.
+6. Create one issue per User Story with no labels.
+7. Attach each User Story issue as a native GitHub sub-issue of its parent Epic issue.
+8. Report created issue numbers or URLs.
 
 Keep issue bodies concise and source-grounded. Include the source local doc path and relevant summary, scope, acceptance criteria, or validation notes. Do not modify local Markdown files with GitHub URLs.
 
-Native sub-issues are required for this export. Preserve each created User Story issue's GitHub issue `id` because native sub-issue APIs need the child issue ID, not only its issue number. If label creation, issue creation, issue ID access, or native sub-issue attachment fails or is unavailable, fail clearly and do not fall back to Markdown checklists, loose links, GitHub Projects, milestones, assignees, or status tracking.
+Native sub-issues are required for this export. Preserve each created User Story issue's GitHub issue `id` because native sub-issue APIs need the child issue ID, not only its issue number. If issue creation, issue ID access, or native sub-issue attachment fails or is unavailable, fail clearly and do not fall back to labels, Markdown checklists, loose links, GitHub Projects, milestones, assignees, or status tracking.
 
 Passing the gate means exactly one of these outcomes occurred: