🏗️ Simplify branch naming: verb-first descriptions + hotfix workflow

Type prefixes like feat/, fix/, docs/ are redundant - the branch name itself
tells you what it does. This change adopts verb-first descriptive names across
all work (add-oauth, fix-cache-bug, update-docs).

The only useful prefix is hotfix/ because it triggers different behavior:
expedited review focused on security and bugs, declining style suggestions,
one pass only. This gives workflow prefixes semantic weight instead of just
categorizing change types.

Updated address-pr-comments.md to detect hotfix branches and run streamlined
review: faster feedback on emergency fixes rather than the full polish cycle.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Author: Nick Sullivan

.claude/commands/address-pr-comments.md

@@ -29,6 +29,18 @@ Read @rules/code-review-standards.mdc for triage principles:
 Use provided PR number, or detect from current branch. Exit if no PR exists.
 </pr-detection>
 
+<hotfix-mode>
+If the branch name starts with `hotfix/`, switch to expedited review mode:
+
+- Only address security vulnerabilities and actual bugs
+- Decline ALL style, refactoring, and "improvement" suggestions
+- Skip theoretical concerns - focus on "will this break production?"
+- One pass only - don't wait for bot re-reviews after fixes
+- Speed over polish - this is an emergency
+
+Announce hotfix mode at start: "Hotfix branch detected - running expedited review.
+Addressing only security issues and bugs, declining all other feedback." </hotfix-mode>
+
 <comment-sources>
 Code review bots comment in different places. Fetch both:
 - PR comments (general feedback on the PR itself)

rules/git-interaction.mdc

@@ -294,48 +294,41 @@ Feature with context:
 
 ## Branch Naming Conventions
 
-Branch names should be clear, descriptive, and follow a consistent pattern that makes
-the type and purpose of work immediately obvious.
+Branch names should be verb-first and descriptive. Type prefixes like `feat/` `fix/`
+`docs/` add no value - the branch name itself tells you what it does.
 
 ### Format
 
 ```
-<type>/<short-description>
+verb-description
 ```
 
-### Types
+Start with a verb that describes the action: add, fix, update, refactor, remove.
 
-- `feature/` - New features or enhancements
-- `fix/` - Bug fixes
-- `refactor/` - Code restructuring without behavior changes
-- `docs/` - Documentation updates
-- `test/` - Adding or updating tests
-- `chore/` - Maintenance, dependencies, tooling
+### Examples
 
-### Guidelines
+- `add-oauth-authentication`
+- `fix-cache-race-condition`
+- `update-deployment-docs`
+- `refactor-payment-processing`
+- `remove-deprecated-api`
 
-- Use lowercase with hyphens for spaces
-- Keep descriptions short but meaningful (2-4 words)
-- Be specific enough to understand the work without context
-- Avoid ticket numbers alone - include description
+### Workflow Prefixes
 
-### Examples
+The only useful prefixes signal different workflows, not change types:
 
-Good:
+**`hotfix/`** - Emergency production fix. Triggers expedited review (fewer nitpicks,
+focus on correctness). Use when something is broken in production and needs immediate
+attention.
 
-- `feature/oauth-authentication`
-- `fix/mobile-upload-cors`
-- `refactor/payment-processing`
-- `docs/api-authentication-guide`
-- `test/user-registration-flow`
-- `chore/upgrade-dependencies`
+Example: `hotfix/fix-payment-timeout`
 
-Avoid:
+### Guidelines
 
-- `fix-bug` (too vague)
-- `TICKET-1234` (not descriptive)
-- `johns-branch` (not descriptive)
-- `update` (too generic)
+- Use lowercase with hyphens
+- Keep it short but meaningful (2-5 words)
+- Be specific enough to understand without context
+- The verb naturally categorizes the work
 
 ## Operating Philosophy