404-PF · 404-Page-Found · Sep 22, 2026 · Sep 21, 2026 · Sep 21, 2026 · Sep 21, 2026
@@ -2,6 +2,7 @@
 name: checkout-branch
 description: 'Create and switch to a new branch. Accepts a branch name or GitHub issue number. Derives branch name from issue title when an issue number is given. USE FOR: starting new work, branching from an issue, creating feature/bugfix branches. DO NOT USE FOR: committing, pushing, or managing PRs.'
 user-invocable: true
+disable-model-invocation: true
 argument-hint: '<branch-name-or-issue-number>'
 ---
 
@@ -29,39 +30,50 @@ Create a new Git branch and switch to it. Supports two input modes:
      - `enhancement`, `feature` → `feature/<number>-<slug>`
      - No matching label → `issue/<number>-<slug>`
    - Confirm the derived branch name with the user before proceeding
+   - After confirmation, record the confirmed name so it can be reused in Step 3.
 2. Go to Step 3
 
 ### 2b. Explicit Name Flow
 
-1. Use the provided name exactly
-2. Validate it is a valid Git branch name (no spaces, no `..`, no `~^:?*[\`, not `@{`, not `-`)
-3. If invalid, suggest a sanitized version and ask the user to confirm
-4. Go to Step 3
+1. Store the provided name as the confirmed `branch_name` value.
+2. Validate it by running `git check-ref-format --branch "$branch_name"`; exit status 0 means valid, non-zero means invalid.
+3. If invalid, suggest a sanitized version and ask the user to confirm.
+4. After confirmation, carry the confirmed branch name explicitly into Step 3; do not rely on shell variables persisting across separate tool invocations.
+5. Go to Step 3
 
 ### 3. Create and Switch
 
-Run the following steps:
+Resolve the GitHub remote before running the workflow:
 
-```bash
-# Fetch latest remote refs
-git fetch origin
-
-# Create branch from default branch (usually main or master)
-# Determine the default branch first:
-git remote show origin | grep "HEAD branch"
-```
-
-Then create and switch:
+1. Inspect configured remotes with `git remote -v`.
+2. Select the GitHub remote to use; if none exists, stop and ask for a GitHub remote. If multiple GitHub remotes exist, ask the user which one to use.
+3. After the branch name is confirmed and the remote is selected, run the following block as one shell invocation, passing the confirmed branch name and selected remote as positional arguments rather than interpolating either value into shell source. `$1` is the confirmed branch name and `$2` is the selected GitHub remote; do not rely on shell variables persisting across tool invocations.
 
 ```bash
-git checkout -b <branch-name> origin/<default-branch>
+branch_name="$1"
+github_remote="$2"
+git remote get-url "$github_remote"
+git fetch "$github_remote"
+if ! git remote set-head "$github_remote" --auto >/dev/null; then
+  echo "Could not determine a unique default branch for $github_remote." >&2
+  exit 1
+fi
+default_ref="$(git symbolic-ref --quiet "refs/remotes/$github_remote/HEAD" || true)"
+if [ -z "$default_ref" ]; then
+  echo "No default branch is available for $github_remote." >&2
+  exit 1
+fi
+default_branch="${default_ref#refs/remotes/$github_remote/}"
+git checkout -b "$branch_name" "$github_remote/$default_branch"
 ```
 
-If the branch already exists locally, ask the user whether to:
-- **Switch** to the existing branch (`git checkout <branch-name>`)
-- **Reset** it to the latest origin (`git checkout -B <branch-name> origin/<default-branch>`)
+If the branch already exists locally, ask the user whether to run one of these commands with the confirmed branch name as a quoted argument:
+- **Switch**: `git checkout "<confirmed-branch-name>"`
+- **Reset** it to the latest remote: `git checkout -B "<confirmed-branch-name>" "$github_remote/$default_branch"`
 - **Choose a different name**
 
+Do not interpolate a branch name directly into shell command text.
+
 ### 4. Verify
 
 After switching:

@@ -2,6 +2,7 @@
 name: commit
 description: "**WORKFLOW SKILL** — Stage changes, write clear commit messages, and commit following best practices. USE FOR: committing code changes; writing conventional commit messages; staging files before commits; amending previous commits; creating atomic commits; generating commit messages from diffs. DO NOT USE FOR: pushing to remote (use git push); resolving merge conflicts; branching or rebasing."
 user-invocable: true
+disable-model-invocation: true
 ---
 
 # Commit Workflow
@@ -77,12 +78,12 @@ Follow this structure:
 
 **Simple change**:
 ```
-fix(auth): prevent token refresh race condition
+fix(auth): Prevent token refresh race condition
 ```
 
 **Feature with context**:
 ```
-feat(api): add pagination to user list endpoint
+feat(api): Add pagination to user list endpoint
 
 Implement offset-based pagination with configurable page size.
 Default limit is 20 items per page. Includes cursor-based
@@ -93,7 +94,7 @@ Closes #234
 
 **Breaking change**:
 ```
-refactor(config)!: rename environment variables for consistency
+refactor(config)!: Rename environment variables for consistency
 
 BREAKING CHANGE: DATABASE_URL is now DB_CONNECTION_STRING
 ```

@@ -2,6 +2,7 @@
 name: create-issue
 description: 'Create a GitHub issue with proper structure and metadata. Use when the user asks to create an issue, open a ticket, report a bug, or request a feature. Supports labels, assignees, milestones, and templates.'
 user-invocable: true
+disable-model-invocation: true
 argument-hint: '[optional: issue title or description]'
 ---
 
@@ -130,11 +131,42 @@ Use **GitHub MCP tools** (`mcp_github_mcp_se_issue_write`) to create the issue:
 - `assignees`: Array of usernames
 - `milestone`: Milestone number (if provided)
 
-If MCP tools are unavailable, fall back to **`gh` CLI**:
+If MCP tools are unavailable, fall back to **`gh` CLI**. Pass generated values as data, not shell source. In the snippet, initialize the optional metadata arrays and populate them with the values confirmed in Step 4:
+
+- Start with `labels=()` and append each confirmed label with `labels+=("$label")`.
+- Start with `assignees=()` and append each confirmed assignee with `assignees+=("$assignee")`.
+- Set `milestone=""` when no milestone is confirmed; otherwise set it to the confirmed milestone value.
+
 ```bash
-gh issue create --title "<title>" --body "<body>" --label "<label1>,<label2>" --assignee "<user1>,<user2>"
+title="$GENERATED_TITLE"
+body="$GENERATED_BODY"
+labels=()
+assignees=()
+milestone=""
+body_file="$(mktemp)"
+trap 'rm -f "$body_file"' EXIT
+printf '%s\n' "$body" >"$body_file"
+
+# Append each confirmed value to labels/assignees and set milestone before building args.
+args=(issue create --title "$title" --body-file "$body_file")
+for label in "${labels[@]}"; do
+  args+=(--label "$label")
+done
+for assignee in "${assignees[@]}"; do
+  args+=(--assignee "$assignee")
+done
+if [ -n "$milestone" ]; then
+  args+=(--milestone "$milestone")
+fi
+
+if ! gh "${args[@]}"; then
+  echo "Failed to create the GitHub issue." >&2
+  exit 1
+fi
 ```
 
+Never interpolate the title or body directly into command text; quoted variable expansion and `--body-file` preserve the generated content as data.
+
 ### 6. Report Result
 - Display the created issue URL
 - Suggest next steps (e.g., add to project board, link to PR)

@@ -1,6 +1,6 @@
 ---
 name: create-pr
-description: 'Create a GitHub pull request from the current branch. Use when the user asks to create a PR, open a pull request, or submit a PR for review. Assumes branch is pushed. Auto-generates title and description from commit history.'
+description: 'Create a GitHub pull request from the current branch. Use when the user asks to create a PR, open a pull request, or submit a PR for review. Branch will be pushed if needed. Auto-generates title and description from commit history.'
 user-invocable: true
 argument-hint: 'Optional: base branch name (defaults to main)'
 ---
@@ -61,17 +61,28 @@ Before creating the PR, present:
 
 ### 5. Create the Pull Request
 
-Prefer **GitHub MCP tools** (`mcp_github_mcp_se_create_pull_request`) to create the PR. If MCP tools are unavailable or fail, fall back to **`gh` CLI** in the terminal:
+Prefer **GitHub MCP tools** (`mcp_github_mcp_se_create_pull_request`) to create the PR. If MCP tools are unavailable or fail, fall back to **`gh` CLI** in the terminal. Before running the snippet, expose the generated values to the shell as `GENERATED_TITLE`, `GENERATED_BODY`, `HEAD_BRANCH`, `BASE_BRANCH`, and `DRAFT` (where `DRAFT` is `true` or `false`).
+
 ```bash
-gh pr create --base <base> --head <head> --title "<title>" --body "<body>"
+title="$GENERATED_TITLE"
+body="$GENERATED_BODY"
+head="$HEAD_BRANCH"
+base="$BASE_BRANCH"
+body_file="$(mktemp)"
+trap 'rm -f "$body_file"' EXIT
+printf '%s\n' "$body" >"$body_file"
+
+draft_args=()
+if [ "${DRAFT:-false}" = "true" ]; then
+  draft_args+=(--draft)
+fi
+
+gh pr create --base "$base" --head "$head" --title "$title" --body-file "$body_file" "${draft_args[@]}"
 ```
 
-Set the following:
-- `title` → generated title
-- `body` → generated description
-- `head` → current branch
-- `base` → target branch
-- `draft` → based on user preference
+Set the shell variables above from the generated title/description, current branch, target branch, and user-selected draft state before invoking the snippet.
+
+Pass all generated metadata through quoted arguments or files; do not build shell command text from generated values. Preserve `--draft` whenever the user selected Draft.
 
 ### 6. Report Result
 - Display the created PR URL

@@ -16,11 +16,15 @@ user-invocable: true
 
 ### 1. Analyze Recent Commits
 
-Gather recent commits to determine the appropriate version bump:
+Gather recent commits to determine the appropriate version bump. Use the full history when the repository has no tags:
 
 ```bash
-# Get commits since last tag (or all commits if no tags exist)
-git log --oneline --no-merges $(git describe --tags --abbrev=0 2>/dev/null || echo "HEAD")..HEAD
+LATEST_TAG="$(git describe --tags --abbrev=0 2>/dev/null || true)"
+if [ -n "$LATEST_TAG" ]; then
+  git log --oneline --no-merges "$LATEST_TAG..HEAD"
+else
+  git log --oneline --no-merges HEAD
+fi
 ```
 
 **Version determination rules:**
@@ -31,10 +35,17 @@ git log --oneline --no-merges $(git describe --tags --abbrev=0 2>/dev/null || ec
 ### 2. Determine Next Version
 
 ```bash
-# Get current version from latest tag (strip leading 'v')
-LATEST_TAG=$(git describe --tags --abbrev=0 2>/dev/null | sed 's/^v//')
-# Default to 0.0.0 if no tags exist
-CURRENT_VERSION=${LATEST_TAG:-0.0.0}
+LATEST_TAG="$(git describe --tags --abbrev=0 2>/dev/null || true)"
+if [ -n "$LATEST_TAG" ]; then
+  CURRENT_VERSION="$(printf '%s' "$LATEST_TAG" | sed 's/^v//')"
+else
+  CURRENT_VERSION="$(node -p "require('./package.json').version")"
+fi
+
+if [ -z "$CURRENT_VERSION" ] || [ "$CURRENT_VERSION" = "undefined" ]; then
+  echo "No release baseline is available; provide the current version explicitly."
+  exit 1
+fi
 
 # Parse version components
 IFS='.' read -r MAJOR MINOR PATCH <<< "$CURRENT_VERSION"
@@ -43,13 +54,15 @@ IFS='.' read -r MAJOR MINOR PATCH <<< "$CURRENT_VERSION"
 # (Check for breaking changes, features, or fixes as described above)
 ```
 
+When no tag exists, use `package.json` as the version baseline; do not default to `0.0.0`. If `package.json` cannot be read, require the user to provide the current version explicitly.
+
 ### 3. Generate Changelog
 
-Use the [update-changelog](../update-changelog/SKILL.md) skill to generate the changelog entry for this release. Follow the procedure in that skill to:
+Use the [update-changelog](../update-changelog/SKILL.md) skill to generate the changelog entry for this release. Invoke it with `NEW_VERSION` as its version argument and follow its procedure to:
 
 1. Categorize commits into Keep a Changelog sections (Added, Changed, Fixed, etc.)
-2. Write the entry to `CHANGELOG.md`
-3. Show the diff and get user confirmation before saving
+2. Build and show the proposed diff
+3. After explicit user confirmation, write the entry to `CHANGELOG.md`
 
 ### 4. Create Git Tag
 
@@ -67,18 +80,26 @@ git push origin "v$NEW_VERSION"
 
 ### 6. Create GitHub Release
 
-Use the GitHub CLI to create the release:
+Use the GitHub CLI to create the release. Extract only the newly generated version section into a temporary notes file:
 
 ```bash
-# Create release with changelog body
+release_notes_file="$(mktemp)"
+awk -v section="## [$NEW_VERSION]" '
+  $0 == section || index($0, section " -") == 1 { in_section=1; next }
+  in_section && $0 ~ /^## / { exit }
+  in_section { print }
+' CHANGELOG.md >"$release_notes_file"
+test -s "$release_notes_file"
+
 gh release create "v$NEW_VERSION" \
   --title "Release v$NEW_VERSION" \
-  --notes-file CHANGELOG.tmp
+  --notes-file "$release_notes_file"
 
-# Clean up temporary file
-rm CHANGELOG.tmp
+rm -f "$release_notes_file"
 ```
 
+The temporary file is created from `CHANGELOG.md` after the changelog confirmation step; never point cleanup at `CHANGELOG.md` itself.
+
 ### 7. Verify Release
 
 ```bash

@@ -2,6 +2,7 @@
 name: patch-findings
 description: 'Generate fix patches from pre-identified findings. Use when: generating code fixes from PR review comments, producing patches from scan results, translating described problems into code changes. DO NOT USE FOR: resolving GitHub issues (use resolve-issue); creating PRs (use create-pr); managing branches.'
 argument-hint: 'describe the finding to patch'
+disable-model-invocation: true
 ---
 
 # Patch Findings

@@ -2,6 +2,7 @@
 name: resolve-issue
 description: "**WORKFLOW SKILL** — Systematically resolve GitHub issues from assignment through PR creation. USE FOR: working on assigned issues; following structured debugging workflows; implementing feature requests; fixing bugs reported in issues; creating focused PRs linked to issues. DO NOT USE FOR: creating new issues (use create-issue); reviewing PRs (use review-pr); general coding tasks without an issue context."
 user-invocable: true
+disable-model-invocation: true
 argument-hint: '[issue-number]'
 ---
 

@@ -2,7 +2,7 @@
 name: review-changes
 description: 'Review staged and unstaged changes before committing. Use for: code review, pre-commit checks, validating changes, checking diff quality, linting, test verification, security scan. Trigger phrases: review changes, review my changes, check changes, pre-commit review, review diff.'
 user-invocable: true
-argument-hint: '[optional: file path or branch to review]'
+argument-hint: '[optional: file path, branch, --staged, or --unstaged]'
 ---
 
 # Review Changes
@@ -17,11 +17,18 @@ Systematic pre-commit code review checklist for staged and unstaged changes.
 
 ## Procedure
 
-### 1. Identify Changes
-- Run `git diff --staged` to see staged changes
-- Run `git diff` to see unstaged changes
-- Run `git status` to see untracked files
-- Summarize the scope: which files changed, what the changes accomplish
+### 1. Identify Changes and Scope
+
+Honor the optional `argument-hint`:
+
+- **No argument**: review staged and unstaged changes plus all untracked files.
+- **`--staged`**: review only staged changes with `git diff --staged`.
+- **`--unstaged`**: review only unstaged changes with `git diff`.
+- **Existing path**: review only that path. Use path-limited diffs (`git diff --staged -- "$path"` and `git diff -- "$path"`) and `git status --short -- "$path"`. For an untracked path, read its contents directly before reviewing it; `git diff` does not include untracked content.
+- **Existing local branch**: review that branch's changes from its merge base with the current branch. Verify it with `git show-ref --verify --quiet "refs/heads/$branch"`, then use `base="$(git merge-base HEAD "$branch")"` and `git diff "$base..$branch"`.
+- **Anything else**: report that the scope argument is neither an existing path nor a local branch and stop rather than silently reviewing a different scope.
+
+Summarize the selected scope: which files changed and what the changes accomplish.
 
 ### 2. Correctness Check
 For each changed file, verify:

@@ -13,16 +13,19 @@ Comprehensive PR review that summarizes changes, identifies potential issues, an
 
 ### 1. Identify the PR
 
-- If the user provided a reference like `owner/repo#123`, parse it.
+- If the user provided a reference like `owner/repo#123`, parse it into a repository (`owner/repo`) and pull request number.
 - Otherwise, check for an active branch or recent PR in the workspace.
-- Use `mcp_github_mcp_se_search_pull_requests` to find the PR if needed.
+- Use the GitHub integration configured for the environment to find the PR when available; do not assume a connector-specific MCP tool name.
+- When no GitHub integration is available and the reference was left blank, derive the current PR's repository and number before Step 2 with `repo="$(gh repo view --json nameWithOwner -q .nameWithOwner)"` and `number="$(gh pr view --json number -q .number)"`.
+- When no GitHub integration is available, use the `gh` CLI fallback described below.
 
 ### 2. Gather PR Details
 
-Fetch the PR metadata and content:
-- Use `mcp_github_mcp_se_search_pull_requests` with the PR query to get title, description, author, state, and labels.
-- Use `mcp_github_mcp_se_list_branches` if branch info is needed.
-- Note the base and head branches to understand the diff scope.
+Fetch the PR metadata, changed-file list, unified diff, and file contents before reviewing code:
+
+- Use the configured GitHub integration when available to get the PR metadata, changed-file list, unified diff, and head revision.
+- Otherwise, use the `gh` CLI commands in Step 5: `gh pr view "$number" -R "$repo"`, `gh pr diff "$number" -R "$repo"`, and the GitHub API fallback for file contents.
+- Note the base and head branches and head revision to understand the diff scope.
 
 ### 3. Analyze Changes
 
@@ -80,4 +83,10 @@ One of:
 
 ### 5. Optional: Submit the Review
 
-If the user wants, use `mcp_github_mcp_se_pull_request_review_write` to submit the review directly on GitHub with the appropriate event (`APPROVE`, `REQUEST_CHANGES`, or `COMMENT`).
+If a configured GitHub integration is available, use it to submit the review with the requested event (`APPROVE`, `REQUEST_CHANGES`, or `COMMENT`). Otherwise use the `gh` CLI fallback below.
+
+If GitHub MCP tools are unavailable, use `gh` CLI. When the user supplied a reference, parse `owner/repo#123` into `repo="$owner/$repo_name"` and `number="123"`. When the PR was detected from the workspace instead, derive `repo="$(gh repo view --json nameWithOwner -q .nameWithOwner)"` and `number="$(gh pr view --json number -q .number)"`. Then run `gh pr view "$number" -R "$repo" --json title,body,state,labels,baseRefName,headRefName,headRefOid,files` for PR metadata and the changed-file list.
+- Use `gh pr diff "$number" -R "$repo"` for the unified diff.
+- Extract the head revision with `head_sha="$(gh pr view "$number" -R "$repo" --json headRefOid -q .headRefOid)"` before fetching changed files.
+- For each changed file with status other than `removed`, URL-encode each path segment before interpolation (spaces, `#`, `?`, and `%`). For example, set `encoded_path="$(python3 -c 'import sys; from urllib.parse import quote; print("/".join(quote(part, safe="") for part in sys.argv[1].split("/")))' "$path")"` and fetch it at the PR head with `gh api "repos/$repo/contents/$encoded_path?ref=$head_sha" -H "Accept: application/vnd.github.raw+json"`. A removed path is already represented by the diff and should be skipped. For a blob that exceeds the contents API size cap, use the Git Data blobs API with its blob SHA instead.
+- For review submission, write the review body to a temporary file and use `gh pr review "$number" -R "$repo" --approve --body-file "$review_file"`, `--request-changes`, or `--comment` as appropriate. Never interpolate review text into shell command source.