feat: add safe dependency version bump category to analysis prompt

Author: VdustR

prompts/analysis-prompt.md

@@ -4,7 +4,7 @@ You are an expert code reviewer analyzing GitHub pull request changes to determi
 
 ## Categories for Skip-Review
 
-All skip-review calls must fall cleanly into one of these five categories. If a PR blends eligible work with undefinable changes, default to “not eligible.”
+All skip-review calls must fall cleanly into one of these categories. If a PR blends eligible work with undefinable changes, default to “not eligible.”
 
 <!--- cSpell:disable - intentional typos as examples for the AI analyzer -->
 
@@ -281,6 +281,7 @@ const StyledButton = styled.button`
 - Removed code has no remaining references (e.g., flagged via type errors, linting, or is inside `if (false)`/feature-flag blocks that are never enabled)
 - Eliminates unused feature flags/controls along with their configuration, documentation, and rollout metadata
 - Removes environment variables, API endpoints, schemas, migrations, or DTOs that are provably obsolete with no callers
+- Deletes dependency declarations, configuration blocks, VS Code extension recommendations, or GitHub Actions workflow steps that are clearly unused or outdated
 - Deletes tests, mocks, or tooling that only validated the unused code paths
 - No behavior, routing, or data contract changes beyond removing definitively dead functionality
 - Removals are self-evident from context; no speculative “probably unused” code
@@ -308,12 +309,61 @@ const StyledButton = styled.button`
 - Deleting code that still has references or runtime callers (risking regressions)
 - Removing feature flags while also altering active flag paths or rollout logic
 - Eliminating environment variables that may be set outside the repo without proof of obsolescence
+- Removing dependencies/configuration entries/automation steps that might still be required by external tooling or environments
 - Removing APIs or schemas while introducing different replacements in the same PR (that is feature work)
 - Mixing large refactors or rewrites with dead-code cleanup
 - Any removal that is not blatantly obvious as safe from the diff alone
 
 ---
 
+### 6. Safe Dependency Version Bump
+
+**Definition**: Changes that only increase dependency versions in a non-breaking manner (e.g., patch or minor upgrades within the same major version) without modifying source code, configuration logic, or lockfile structure beyond what is required to reflect the new versions.
+
+**Characteristics to detect**:
+
+- Updates apply exclusively to dependency manifests (e.g., `package.json`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `requirements.txt`, GitHub Actions workflow `uses:` versions)
+- Version bumps stay within the same major version or follow an explicitly documented non-breaking range (e.g., `^1.2.3` → `^1.3.0`)
+- No new dependencies, dependency removals, or peer dependency adjustments
+- Lockfiles only change in ways consistent with the version bump (hashes, resolved URLs)
+- No source, test, build, or config files modified beyond mechanical version metadata updates
+- PR description or commit message clearly states the bump is non-breaking (optional but helpful)
+
+**Examples of valid dependency bumps**:
+
+```json
+// package.json
+{
+-  "lodash": "4.17.20"
++  "lodash": "4.17.21"
+}
+
+// package-lock.json (matching nodes updated automatically)
+```
+
+```toml
+# Cargo.toml
+-serde = "1.0.193"
++serde = "1.0.194"
+```
+
+```yaml
+# .github/workflows/ci.yml
+- uses: actions/checkout@v3
++ uses: actions/checkout@v3.1.0
+```
+
+**Anti-patterns (NOT safe dependency bumps)**:
+
+- Upgrading to a new major version (e.g., `1.x` → `2.x`) or changing version ranges from caret to specific versions without justification (including GitHub Action `uses:` references)
+- Adding, removing, or swapping dependencies (including sub-dependencies via overrides)
+- Making concurrent source-code changes, configuration tweaks, or script updates
+- Updating transitive dependencies manually without touching their parents in manifests
+- Bumping toolchain versions (Node, npm, TypeScript) that can alter build behavior
+- Multiple dependency bumps that collectively modify behavior (e.g., Babel + Webpack)
+
+---
+
 ## Analysis Instructions
 
 When analyzing a PR, follow these steps:
@@ -398,6 +448,7 @@ Not-eligible example:
 - **File types matter**: Changes to configuration files, build scripts, or CI/CD pipelines are typically NOT eligible
 - **Test changes**: Adding/modifying tests is NOT eligible (even if it's just formatting tests)
 - **Multiple categories**: Single-category PRs should receive the highest confidence. If a PR spans two or three categories (e.g., typo fixes + formatting), it can still be eligible but confidence must decrease as categories increase. More than three categories generally signals complexity—lean toward NOT eligible
+- **Dependency bumps**: Only clearly non-breaking (patch/minor) dependency version bumps with manifest/lockfile updates qualify; anything broader requires review
 - **Partial eligibility**: If 90% of changes are eligible but 10% involve logic, mark the entire PR as NOT eligible
 
 ## Edge Cases to Watch For
@@ -407,7 +458,7 @@ Not-eligible example:
 3. **Style changes affecting behavior**: Changing z-index, position, display properties might affect UX - review carefully
 4. **Formatting with logic changes**: If prettier formatted the file AND developer made logic changes - NOT eligible
 5. **Dead-code removals that aren't obvious**: If it's unclear whether code is unused (e.g., dynamic imports, reflection, indirect references), require review
-6. **Dependency updates**: Even if just version bumps in package.json - NOT eligible (needs testing)
+6. **Dependency updates beyond safe bumps**: Major-version upgrades, dependency additions/removals, or bumps that include source/config changes are NOT eligible
 
 ## Remember