refactor(skills): remove create-branch and create-commit skills (#212)

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Author: ryzizub

.github/workflows/ci.yaml

@@ -44,7 +44,7 @@ jobs:
         run: |
           BASE=${{ github.event.pull_request.base.sha }}
           HEAD=${{ github.event.pull_request.head.sha }}
-          SKILLS=$(git diff --name-only $BASE $HEAD | \
+          SKILLS=$(git diff --name-only --diff-filter=d $BASE $HEAD | \
             { grep 'SKILL.md' || true; } | \
             xargs -I {} dirname {} | \
             sort -u | \

CLAUDE.md

@@ -35,8 +35,6 @@ Each phase persists its output to `docs/` so the next phase can discover it from
 Supporting skills:
 
 - `/create` (project creation — routes to companion plugins)
-- `/create-branch` (workspace setup)
-- `/create-commit` (propose and create conventional commit messages for staged changes)
 - `/create-pr` (generate a PR title and description from branch commits and optionally open it on GitHub or GitLab)
 - `/plan-technical-review` (validate plans)
 - `/refine-approach` (iterative document improvement)

README.md

@@ -98,9 +98,7 @@ Wingspan operates at a higher level, orchestrating agentic workflows across the
 | [**Build**](skills/build/SKILL.md) | `/build <plan file path>` | Execute a plan — write code and tests, run quality review, ship a PR |
 | [**Review**](skills/review/SKILL.md) | `/review [path]` | Run quality review agents on demand — assess code quality and identify issues |
 | [**Hotfix**](skills/hotfix/SKILL.md) | `/hotfix <bug description>` | Apply a minimal, targeted fix for emergency bugs — enforces review and testing without brainstorm or planning |
-| [**Create Branch**](skills/create-branch/SKILL.md) | `/create-branch` | Set up a workspace (branch or worktree) before writing artifacts |
 | [**Create**](skills/create/SKILL.md) | `/create <what to create>` | Scaffold a new project by routing to the right companion plugin |
-| [**Create Commit**](skills/create-commit/SKILL.md) | `/create-commit` | Stage and commit changes using conventional commit messages |
 | [**Create PR**](skills/create-pr/SKILL.md) | `/create-pr` | Validate (formatter, linter, tests, and CI checks), stage, commit, push, and open a pull request on the project's Git hosting platform — aborts on any failure |
 | [**Rebase**](skills/rebase/SKILL.md) | `/rebase` | Rebase the current feature branch onto the base branch to stay up-to-date |
 | [**Debrief**](skills/debrief/SKILL.md) | `/debrief <incident or context>` | Produce a structured post-incident analysis — timeline, root cause, and actionable follow-ups |

skills/brainstorm/SKILL.md

@@ -101,9 +101,9 @@ Use **AskUserQuestion tool** to ask which approach the user prefers.
 
 #### 1.4. Set up workspace
 
-Before writing any files, ensure the session is on a feature branch:
+Before writing any files, ensure the session is not on the base branch:
 
-- Call @create-branch to check and optionally create a working branch or worktree.
+- Run `git rev-parse --abbrev-ref HEAD`. If the current branch is a base branch (`main`, `master`, or `develop`), use **AskUserQuestion** to offer creating a feature branch — `git checkout -b <type>/<kebab-topic>`, name under 60 characters — before writing. If already on a feature branch, continue without prompting.
 
 ### 2. Capture the design document
 

skills/create-branch/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: create-pr
 description: Stage, commit, push, and open a pull request following project conventions and the Conventional Commits spec. Accepts optional skip-checks argument to bypass validation when called from /build.
-when_to_use: Use when user says "create a PR", "open a PR", "ship it", "submit a pull request", or "open a merge request".
+when_to_use: Use when user says "create a PR", "open a PR", "ship it", "submit a pull request", or "open a merge request", or when work on a branch is complete and ready to publish for review.
 argument-hint: "[optional: skip-checks | ticket/issue number e.g. VGV-123 | short description]"
 disable-model-invocation: true
 allowed-tools: Bash(git push *) Bash(git add *) Bash(git commit *) Bash(gh *) Bash(glab *)
@@ -27,14 +27,6 @@ Stage uncommitted changes, commit them, push the branch, and open a pull request
 - Do not push before the user confirms the commit.
 - Use the current branch as the source; target is `BASE_BRANCH` (determined in Step 2).
 
-## When to use
-
-Use this skill when:
-
-- The user asks to open or create a pull request.
-- The user asks to "create a PR", "open a PR", "submit a PR", or similar.
-- Work on a branch is complete and the user wants to publish it for review.
-
 ## Context
 
 <context>$ARGUMENTS</context>
@@ -86,7 +78,13 @@ Store as `BASE_BRANCH`.
 
 ## Step 3: Stage and commit
 
-Use the **create-commit** skill with the `single-commit` argument to stage files and produce a single conventional commit message.
+Produce a single conventional commit covering all changes.
+
+- **Never stage** secret files: `.env`, `*.key`, `*.pem`, `*secret*`, `*credential*`, `*.p12`, `*.jks`.
+- Stage the remaining changes with `git add`.
+- Propose one commit message following Conventional Commits (`type(scope): subject`). Consult `references/conventional-commits.md` for the full spec. Infer `type` from a plan file in `docs/plan/` if present; otherwise infer from the diff. Extract the ticket number from the branch name (e.g. `feat/VGV-59-...` → `VGV-59`) into a `Refs:` line.
+
+Use **AskUserQuestion** to confirm before committing (**Yes** / **No** / **Edit**). On confirm, commit with a HEREDOC to preserve formatting. Do not push yet.
 
 ## Step 4: Push
 

skills/create-branch/scripts/detect-base-branch.sh

@@ -74,9 +74,9 @@ Action items are recorded in the document only — they become separate tickets.
 
 ### 5. Set up workspace
 
-Before writing the debrief file, ensure the session is on a feature branch:
+Before writing the debrief file, ensure the session is not on the base branch:
 
-- Call @create-branch to check and optionally create a working branch or worktree.
+- Run `git rev-parse --abbrev-ref HEAD`. If the current branch is a base branch (`main`, `master`, or `develop`), use **AskUserQuestion** to offer creating a feature branch — `git checkout -b <type>/<kebab-topic>`, name under 60 characters — before writing. If already on a feature branch, continue without prompting.
 
 ### 6. Write the debrief document