using-system
diff --git a/‎README.md‎
Lines changed: 2 additions & 12 deletions b/‎README.md‎
Lines changed: 2 additions & 12 deletions
diff --git a/‎skills/github-complete-pr/SKILL.md‎
Lines changed: 177 additions & 0 deletions b/‎skills/github-complete-pr/SKILL.md‎
Lines changed: 177 additions & 0 deletions
diff --git a/‎skills/github-create-update-pr/SKILL.md‎
Lines changed: 168 additions & 0 deletions b/‎skills/github-create-update-pr/SKILL.md‎
Lines changed: 168 additions & 0 deletions
@@ -4,11 +4,7 @@ A curated collection of personal agent extensions, skills, and CLI hooks to enha
 
 ## Skills
 
-| Skill | Description |
-|-------|-------------|
-| `github-actions` | Enforces GitHub Actions best practices: pin actions to SHA, verify latest versions, add version comments |
-| `git-commit` | Enforces Conventional Commits specification for semantic versioning compatibility |
-| `github-pr` | Enforces Conventional Commits naming on PR titles for squash-merge and changelog generation |
+Each skill lives in its own directory under [skills/](skills/) with a `SKILL.md` describing when and how it applies. Browse that folder for the current catalogue — no listing is maintained here to avoid drift.
 
 ## Installation
 
@@ -71,13 +67,7 @@ gemini extensions install https://github.com/using-system/ai-dev-extensions
 
 ```
 ai-dev-extensions/
-├── skills/                    # Skills (one directory per skill)
-│   ├── github-actions/        # GitHub Actions best practices
-│   │   └── SKILL.md
-│   ├── git-commit/            # Conventional Commits for git
-│   │   └── SKILL.md
-│   └── github-pr/             # Conventional Commits for PR titles
-│       └── SKILL.md
+├── skills/                    # Skills (one directory per skill, each with a SKILL.md)
 ├── hooks/                     # Hooks for CLI agents and git
 │   ├── session-start          # Session start hook (multi-platform)
 │   ├── commit-msg             # Git hook: validates Conventional Commits
 
@@ -0,0 +1,177 @@
+---
+name: github-complete-pr
+description: "Use when a GitHub pull request has just been merged or closed - switches back to the repository default branch, syncs it, and deletes the now-obsolete feature branch both locally and on the remote if it still exists"
+---
+
+# GitHub Complete PR
+
+## Overview
+
+Once a pull request is merged or closed, the feature branch is no longer needed. Leaving it around clutters the local repo and the remote, creates stale references, and confuses future `git branch` / PR listings. This skill defines the cleanup steps to run immediately after PR completion.
+
+## When to Use
+
+- A pull request has just been merged (squash, rebase, or merge commit)
+- A pull request has been closed without merging and the branch will not be reused
+- The user says things like "PR is merged", "done with that PR", "close it out", "clean up the branch"
+
+## Do NOT Use When
+
+- The PR is still open or in draft
+- The branch is shared with other collaborators who still have in-flight work on it
+- The branch is a long-lived branch (e.g. `develop`, `release/*`, `main`) — never delete these
+
+## Rules
+
+### 1. Confirm the PR is actually merged or closed
+
+Before deleting anything, verify the PR state via `gh`:
+
+```bash
+gh pr view <number-or-branch> --json state,mergedAt,headRefName,baseRefName
+```
+
+Only proceed when `state` is `MERGED` or `CLOSED`. If the PR is still `OPEN`, stop and tell the user.
+
+### 2. Identify the repository default branch
+
+Do not assume `main`. Query it:
+
+```bash
+gh repo view --json defaultBranchRef --jq .defaultBranchRef.name
+```
+
+Use whatever it returns (`main`, `master`, `trunk`, etc.) as the checkout target.
+
+### 3. Switch back to the default branch and sync
+
+```bash
+git checkout <default-branch>
+git pull --ff-only origin <default-branch>
+```
+
+Use `--ff-only` to avoid accidental merge commits if the local default branch has drifted.
+
+### 4. Delete the local feature branch
+
+```bash
+git branch -d <feature-branch>
+```
+
+Use `-d` (safe delete) first. Git will refuse when the branch is not fully merged into the default branch — this is common and expected when the PR was squash-merged or rebase-merged (the tip commit of the feature branch is not an ancestor of `main`).
+
+Force-delete with `-D` is acceptable **only** when one of the following is true, confirmed via `gh pr view`:
+
+- `state` is `MERGED` — the changes exist on the default branch under a new commit hash; the original commits are redundant.
+- `state` is `CLOSED` **and** the branch was intentionally abandoned (the user confirms the work will not be reused).
+
+```bash
+git branch -D <feature-branch>
+```
+
+**Data-loss warning.** For a `CLOSED` (unmerged) PR, `-D` permanently discards any commits on that branch that live nowhere else — there is no remote copy to recover from once the remote branch is also deleted in step 5. Confirm with the user before force-deleting a closed-unmerged branch.
+
+Never use `-D` without first confirming PR state via `gh pr view`.
+
+### 5. Delete the remote branch if it still exists
+
+Many PR workflows auto-delete the remote branch on merge, but not all. Check and clean up:
+
+```bash
+git fetch --prune origin
+if git ls-remote --exit-code --heads origin <feature-branch> >/dev/null 2>&1; then
+  git push origin --delete <feature-branch>
+else
+  echo "Remote branch already deleted"
+fi
+```
+
+`--prune` removes stale remote-tracking refs. The `ls-remote` check avoids a noisy error when the remote branch is already gone. The explicit `if/else` (instead of `A && B || C`) ensures a real `git push --delete` failure surfaces as an error rather than being swallowed by the "already deleted" message.
+
+### 6. Confirm cleanup
+
+Finish by showing the user the state so they can verify:
+
+```bash
+git branch            # local branches
+git branch -r         # remote-tracking branches
+```
+
+The feature branch must be absent from both.
+
+## Full Recipe
+
+The recipe below enforces Rule §1 (abort when `state` is `OPEN`) and Rule §4 (only force-delete after state validation), and derives `FEATURE_BRANCH` from the PR itself so a mistyped argument cannot cause the wrong branch to be deleted.
+
+```bash
+PR=<branch-or-number>
+
+# 1. Verify PR state and capture the exact head branch from the PR
+PR_STATE=$(gh pr view "$PR" --json state --jq .state)
+FEATURE_BRANCH=$(gh pr view "$PR" --json headRefName --jq .headRefName)
+
+if [ -z "$PR_STATE" ] || [ -z "$FEATURE_BRANCH" ]; then
+  echo "Could not determine PR state or head branch; aborting."
+  exit 1
+fi
+
+if [ "$PR_STATE" = "OPEN" ]; then
+  echo "PR is still OPEN; refusing to delete anything."
+  exit 1
+fi
+
+# 2. Find default branch and refuse protected branches
+DEFAULT=$(gh repo view --json defaultBranchRef --jq .defaultBranchRef.name)
+
+if [ -z "$DEFAULT" ]; then
+  echo "Could not determine default branch (gh auth/config issue, or not a git repo); aborting."
+  exit 1
+fi
+
+if [ "$FEATURE_BRANCH" = "$DEFAULT" ] \
+    || [ "$FEATURE_BRANCH" = "main" ] \
+    || [ "$FEATURE_BRANCH" = "master" ] \
+    || [ "$FEATURE_BRANCH" = "develop" ] \
+    || [[ "$FEATURE_BRANCH" == release/* ]]; then
+  echo "Refusing to delete protected or default branch: $FEATURE_BRANCH"
+  exit 1
+fi
+
+# 3. Switch + sync
+git checkout "$DEFAULT"
+git pull --ff-only origin "$DEFAULT"
+
+# 4. Delete local branch — safe delete first; auto-force-delete only for MERGED PRs.
+#    For CLOSED (unmerged) PRs, abort and require the user to explicitly confirm data loss.
+if ! git branch -d "$FEATURE_BRANCH"; then
+  if [ "$PR_STATE" = "MERGED" ]; then
+    echo "Safe delete failed (squash/rebase merge rewrote history). Force-deleting merged branch: $FEATURE_BRANCH"
+    git branch -D "$FEATURE_BRANCH"
+  else
+    echo "Safe delete failed because the branch is not fully merged."
+    echo "PR state is $PR_STATE (not MERGED). Refusing to force-delete without explicit confirmation that the work is abandoned."
+    echo "If you have confirmed the branch can be discarded, rerun manually:"
+    echo "  git branch -D \"$FEATURE_BRANCH\""
+    exit 1
+  fi
+fi
+
+# 5. Prune + delete remote branch if still present
+git fetch --prune origin
+if git ls-remote --exit-code --heads origin "$FEATURE_BRANCH" >/dev/null 2>&1; then
+  git push origin --delete "$FEATURE_BRANCH"
+else
+  echo "Remote branch already deleted"
+fi
+
+# 6. Verify
+git branch
+git branch -r
+```
+
+## Red Flags — STOP
+
+- PR state is `OPEN` → do not delete anything
+- Current branch has uncommitted changes → stash or commit before switching
+- Feature branch name matches the default branch or a protected pattern (`main`, `master`, `develop`, `release/*`) → never delete
+- Force-delete (`-D`) is needed but PR merge state is unverified → verify first
@@ -0,0 +1,168 @@
+---
+name: github-create-update-pr
+description: "Use when creating or updating GitHub pull requests - enforces Conventional Commits naming convention on PR titles for semantic versioning and squash-merge compatibility, and verifies that CI workflows (if any) complete successfully before handing the PR back to the user"
+---
+
+# GitHub Create/Update PR Convention
+
+## Overview
+
+All GitHub pull request titles MUST follow the [Conventional Commits](https://www.conventionalcommits.org/) specification. When a repo uses squash-merge, the PR title becomes the commit message, so it must be a valid conventional commit to enable automatic semantic versioning and changelog generation.
+
+## When to Use
+
+- Creating a new pull request
+- Updating an existing PR title or body
+- When a user asks about PR naming conventions
+
+## Format
+
+PR title follows the same format as a conventional commit:
+
+```
+<type>(<scope>): <description>
+```
+
+### Types
+
+| Type | Description | SemVer Impact |
+|------|-------------|---------------|
+| `feat` | New feature | MINOR |
+| `fix` | Bug fix | PATCH |
+| `docs` | Documentation only | - |
+| `style` | Formatting, no code change | - |
+| `refactor` | Code restructuring, no behavior change | - |
+| `perf` | Performance improvement | PATCH |
+| `test` | Adding or correcting tests | - |
+| `build` | Build system or dependency changes | - |
+| `ci` | CI configuration changes | - |
+| `chore` | Maintenance, no src/test change | - |
+| `revert` | Reverts a previous change | - |
+
+### Breaking Changes
+
+Indicate breaking changes with `!` after the type/scope:
+
+```
+feat(api)!: remove deprecated v1 endpoints
+```
+
+## Rules
+
+### 1. PR title must be a valid conventional commit
+
+```
+# BAD
+Add login page
+Feature: login page
+[FEAT] Add login page
+
+# GOOD
+feat: add login page
+feat(auth): add login page
+```
+
+### 2. Same rules as git-commit for the title line
+
+- Lowercase description
+- Imperative mood ("add" not "added" or "adds")
+- No period at the end
+- Type is mandatory, scope is optional but encouraged
+
+### 3. PR body should complement the title
+
+The PR body is free-form but should include:
+- **What**: summary of changes
+- **Why**: motivation and context
+- **How to test**: steps for reviewers
+
+### 4. One logical change per PR
+
+A PR should map to a single conventional commit type. If a PR contains both a feature and a refactor, the dominant change defines the type.
+
+### 5. Branch name should align with PR title
+
+```
+# PR title: feat(auth): add OAuth2 login flow
+# Branch name:
+feat/auth-oauth2-login-flow
+
+# PR title: fix(api): handle null payment response  
+# Branch name:
+fix/api-null-payment-response
+```
+
+### 6. Verify CI workflows after creating or updating the PR
+
+After every `gh pr create` or push that updates an open PR, check whether the repository has CI workflows that run on `pull_request` (or equivalent) and confirm they pass before handing control back to the user. Do not declare the PR ready if checks are red or still running.
+
+#### Detect whether the repo has CI
+
+```bash
+# Any workflows defined?
+ls .github/workflows 2>/dev/null
+
+# What checks are expected on this PR?
+gh pr checks <pr-number-or-branch>
+```
+
+If `.github/workflows/` is absent or empty **and** `gh pr checks` reports no checks, skip the rest of this rule — there is nothing to verify.
+
+#### Wait for checks to complete
+
+```bash
+gh pr checks <pr-number-or-branch> --watch --fail-fast
+```
+
+`--watch` streams status until every check reaches a terminal state; `--fail-fast` returns a non-zero exit code as soon as one check fails so you can react immediately.
+
+#### If checks pass
+
+Report success to the user with the PR URL. Done.
+
+#### If checks fail
+
+1. Identify the failing job(s):
+
+   ```bash
+   gh pr checks <pr-number-or-branch>
+   gh run list --branch <branch> --limit 5
+   ```
+
+2. Fetch the failing logs:
+
+   ```bash
+   gh run view <run-id> --log-failed
+   ```
+
+3. Diagnose the root cause before reacting. Do **not** blindly add retries, `continue-on-error`, or workflow edits just to make the red turn green — that hides real defects. Common categories:
+
+   - **Code defect in the PR** → fix the code, commit, push, re-verify.
+   - **Broken workflow (misconfigured action, missing secret, wrong version pin)** → fix the workflow per the `github-actions` skill, commit, push, re-verify.
+   - **Pre-existing failure unrelated to this PR** → stop, surface it to the user with the log evidence, and let them decide whether to fix here or in a separate PR.
+   - **Flake** → rerun once via `gh run rerun <run-id>`. If it fails again, treat as a real defect.
+
+4. After any fix, push and re-run `gh pr checks --watch --fail-fast` to confirm green.
+
+#### Never merge around red CI
+
+If the user asks you to merge while checks are failing, refuse and explain the failing checks. Merging past red CI is a destructive action — require explicit, informed authorization.
+
+## Examples
+
+```
+# Feature
+feat(dashboard): add real-time metrics widget
+
+# Bug fix
+fix(auth): prevent token refresh race condition
+
+# Documentation
+docs(readme): add installation guide
+
+# CI improvement
+ci(workflows): pin GitHub Actions to SHA
+
+# Breaking change
+feat(api)!: migrate from REST to GraphQL
+```