@cubis/foundry 0.3.83 → 0.3.84

package/workflows/skills/requesting-code-review/evals/evals.json

@@ -1,71 +0,0 @@
-[
-  {
-    "name": "pr-description-quality",
-    "description": "Validate that the skill produces a well-structured PR description with context, testing details, and review guidance for a feature change.",
-    "input": "I just finished implementing a new caching layer for our API. It uses Redis to cache GET responses for 5 minutes. I changed the middleware pipeline, added cache invalidation on POST/PUT/DELETE, and updated the config to accept Redis connection strings. The changes touch the auth middleware because I had to reorder the pipeline. Help me write a PR description and prepare this for review.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "cache",
-        "description": "Must describe the caching feature being added, as this is the core change being reviewed."
-      },
-      {
-        "type": "contains",
-        "value": "Redis",
-        "description": "Must mention the specific technology (Redis) used for caching, as reviewers need to know the implementation approach."
-      },
-      {
-        "type": "contains",
-        "value": "auth",
-        "description": "Must highlight the auth middleware reordering as a risk area, since changes to auth pipeline require careful review."
-      },
-      {
-        "type": "contains",
-        "value": "invalidation",
-        "description": "Must address cache invalidation strategy, as stale cache is the most common caching bug."
-      },
-      {
-        "type": "contains",
-        "value": "test",
-        "description": "Must include a testing section describing how the caching behavior was verified."
-      },
-      {
-        "type": "contains",
-        "value": "review",
-        "description": "Must provide review guidance specifying what kind of feedback is needed and where reviewers should focus."
-      }
-    ]
-  },
-  {
-    "name": "reviewer-selection-and-timeline",
-    "description": "Validate that the skill recommends appropriate reviewers and manages review timeline for an urgent security fix.",
-    "input": "I found and fixed an XSS vulnerability in our user profile page. The fix sanitizes user-generated HTML in the bio field before rendering. It's a 30-line change in the frontend rendering layer plus 10 lines of tests. This needs to ship today because we got a report from a security researcher. We have these potential reviewers:\n- Alice: security team lead, currently in meetings until 3pm\n- Bob: frontend team lead, currently free, reviewed the original profile page code\n- Carol: full-stack developer, free, but new to the team (2 weeks)\n- Dave: backend developer, familiar with the sanitization library, in a different timezone (currently 11pm for him)\n\nHelp me prepare this review request.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "Bob",
-        "description": "Must recommend Bob as a primary reviewer since he has frontend expertise, is available, and reviewed the original code."
-      },
-      {
-        "type": "contains",
-        "value": "Alice",
-        "description": "Must recommend involving Alice (security lead) for security sign-off, even if delayed until after her meetings."
-      },
-      {
-        "type": "contains",
-        "value": "urgent",
-        "description": "Must communicate the urgency of the review given the active security vulnerability and same-day shipping requirement."
-      },
-      {
-        "type": "contains",
-        "value": "XSS",
-        "description": "Must identify the vulnerability type (XSS) clearly in the review request context."
-      },
-      {
-        "type": "contains",
-        "value": "sanitiz",
-        "description": "Must describe the sanitization approach so reviewers can evaluate the fix's completeness."
-      }
-    ]
-  }
-]

package/workflows/skills/requesting-code-review/examples/01-preparing-pr-for-review.md

@@ -1,81 +0,0 @@
-# Example: Preparing a Feature PR for Review
-
-## Scenario
-
-A developer has completed a new search feature for an e-commerce application. The change touches the API layer, database queries, and frontend components. The developer needs to prepare a review request that gives reviewers full context and directs their attention effectively.
-
-## User Prompt
-
-> I just finished building product search for our e-commerce app. Here is what I changed:
->
-> - Added a `/api/products/search` endpoint that accepts query, category, price range, and sort parameters
-> - Created a PostgreSQL full-text search index on product name and description
-> - Added a search bar component in the header with autocomplete
-> - Added debounced API calls from the frontend (300ms)
-> - Changed the product list page to support search results view
->
-> Total: ~350 lines across 8 files. The autocomplete uses a new dependency (`downshift`). I am not sure if the full-text search index approach is the right long-term solution versus Elasticsearch, but it works for our current catalog size (5,000 products).
->
-> Help me prepare this for code review.
-
-## Expected Response
-
-### PR Title
-
-Add product search with full-text search and autocomplete
-
-### PR Description
-
-#### What
-
-Adds product search functionality with server-side full-text search and client-side autocomplete. Users can search by product name and description, filter by category and price range, and sort results by relevance, price, or date.
-
-#### Why
-
-Product search is the #1 requested feature from user feedback (Issue #89). Currently users must browse categories manually, which does not scale as the catalog grows.
-
-#### How
-
-- **Backend**: New `/api/products/search` endpoint using PostgreSQL `tsvector` full-text search with GIN index on `products.name` and `products.description`. Supports filtering by category and price range, with relevance-ranked results.
-- **Frontend**: Search bar component in the header using `downshift` for accessible autocomplete. API calls are debounced at 300ms to avoid excessive requests during typing.
-- **Database**: Migration adds a `search_vector` column and GIN index. Migration is backward-compatible (additive only).
-
-#### Testing
-
-- Unit tests for search query builder (edge cases: empty query, special characters, SQL injection attempts)
-- Integration test for the search endpoint with seeded test data
-- Manual testing of autocomplete UX in Chrome and Firefox
-- **Not tested**: Safari autocomplete behavior, search performance at scale beyond 5,000 products
-
-#### Known Limitations
-
-- Full-text search is PostgreSQL-specific. If we migrate databases, this will need rework.
-- The `tsvector` approach works for our current catalog size (~5,000 products) but may need to be replaced with Elasticsearch or Typesense as the catalog grows past 50,000.
-- Autocomplete does not yet support search history or popular searches.
-
-#### Risk Areas
-
-1. **Database migration** (medium risk) — adds a GIN index that may lock the products table during creation on large datasets. Current production table is small, so this should be fast.
-2. **New dependency: downshift** (low risk) — well-maintained React library for accessible autocomplete. 2MB gzipped, tree-shakeable.
-
-### Review Guidance
-
-- **Primary focus**: Please review the search query builder for correctness and SQL injection safety. I am using parameterized queries but want a second set of eyes.
-- **Secondary focus**: Is the `downshift` dependency justified, or should we build a simpler autocomplete without a library?
-- **Architecture question**: I chose PostgreSQL full-text search over Elasticsearch for simplicity. Does this trade-off make sense given our current scale?
-- **Depth**: Standard review. No auth or payment changes.
-
-### Reviewer Recommendation
-
-- **Primary**: Someone with PostgreSQL and backend API experience
-- **Secondary**: Someone with React component and accessibility experience
-- **Urgency**: Normal — no deadline pressure, but this unblocks the catalog team
-
-## Why This Response Works
-
-- The PR description follows a clear What/Why/How structure that gives reviewers full context before they read code.
-- Known limitations and the Elasticsearch trade-off are stated upfront, preventing reviewers from raising issues the author already considered.
-- The testing section explicitly states what was not tested, directing reviewer attention.
-- Risk areas are ranked and explained, so reviewers calibrate depth accordingly.
-- Review guidance specifies exactly what feedback the author needs, avoiding wasted effort on areas that are already settled.
-- The reviewer recommendation matches expertise to the areas that need review.

package/workflows/skills/requesting-code-review/examples/02-complex-refactor-review-request.md

@@ -1,131 +0,0 @@
-# Example: Complex Refactor Review Request
-
-## Scenario
-
-A senior developer has completed a large refactoring of the notification system, moving from a synchronous in-process model to an async event-driven architecture using a message queue. The change is 600 lines across 15 files and needs to be reviewed by multiple people with different expertise.
-
-## User Prompt
-
-> I just finished refactoring our notification system from synchronous to async. Here is the summary:
->
-> - Replaced direct function calls to `sendEmail()`, `sendSMS()`, `sendPush()` with events published to a RabbitMQ queue
-> - Added a notification worker service that consumes events and dispatches to the appropriate channel
-> - Added retry logic with exponential backoff (3 retries, max 30s delay)
-> - Added a dead letter queue for failed notifications
-> - Migrated 12 call sites across 6 services to use the new event-based API
-> - Added a `notifications` database table to track delivery status
->
-> Total: ~600 lines across 15 files. This is bigger than I wanted but the migration had to be atomic — we cannot have some call sites using the old pattern and some using the new one.
->
-> The team is:
-> - Elena: principal engineer, designed the original notification system, on PTO until Thursday
-> - Frank: backend lead, RabbitMQ expert, available now
-> - Grace: owns 3 of the 6 services that were migrated, available now
-> - Hassan: DevOps, manages the RabbitMQ cluster, available tomorrow
->
-> This is not urgent — no deadline. But I want thorough review because this touches a lot of surfaces. Help me prepare the review request.
-
-## Expected Response
-
-### PR Title
-
-Refactor notification system to async event-driven architecture
-
-### PR Description
-
-#### What
-
-Replaces the synchronous notification dispatch (`sendEmail()`, `sendSMS()`, `sendPush()`) with an async event-driven architecture using RabbitMQ. All 12 notification call sites across 6 services now publish events to a message queue, and a new worker service consumes and dispatches notifications.
-
-#### Why
-
-The synchronous approach causes three problems:
-1. **Latency**: Sending notifications inline blocks the request (email API calls take 200-500ms).
-2. **Reliability**: If the email provider is down, the entire request fails even though the core operation succeeded.
-3. **Scalability**: Notification volume during peak events (sales, password resets) creates cascading slowdowns across services.
-
-The async approach decouples notification dispatch from business logic, adds retry capability, and enables independent scaling of notification throughput. Related: Issue #156 (notification latency), Issue #201 (email provider outages).
-
-#### How
-
-**Architecture change**:
-```
-Before: Service -> sendEmail() -> Email API (synchronous, inline)
-After:  Service -> publish(NotificationEvent) -> RabbitMQ -> Worker -> Email API (async, decoupled)
-```
-
-**Key components**:
-- `NotificationEvent` schema: type, recipient, template, payload, metadata
-- `notification-worker`: new service that consumes events, dispatches via the appropriate channel, and tracks delivery status
-- Retry policy: exponential backoff (1s, 4s, 16s), max 3 attempts, then dead letter queue
-- `notifications` table: tracks event_id, status (queued/sent/failed/dead-lettered), attempts, timestamps
-
-**Migration approach**:
-- All 12 call sites migrated atomically in this PR to avoid split-brain behavior
-- Old `sendEmail/SMS/Push` functions replaced with `publishNotification()` wrapper
-- Backward-compatible: if RabbitMQ is unreachable, falls back to synchronous dispatch with a warning log
-
-#### Commit Structure
-
-Review commit-by-commit for the best experience:
-1. `Add NotificationEvent schema and RabbitMQ publisher` — the new event model and publishing layer
-2. `Add notification worker service with retry logic` — the consumer, dispatcher, and retry policy
-3. `Add notifications tracking table and migration` — database schema for delivery tracking
-4. `Migrate call sites to event-based notification API` — the 12 call site migrations across 6 services
-5. `Add integration tests for async notification flow` — end-to-end tests with RabbitMQ test container
-6. `Add dead letter queue handling and alerting` — DLQ consumer and PagerDuty alert integration
-
-#### Testing
-
-- Unit tests for NotificationEvent validation, retry logic, and backoff calculation
-- Integration tests using Testcontainers with a real RabbitMQ instance
-- End-to-end test: publish event, verify worker consumes and dispatches, verify delivery status recorded
-- Manual testing: killed RabbitMQ mid-dispatch to verify fallback behavior
-- Load test: 1,000 events/second sustained for 5 minutes, no message loss
-- **Not tested**: Behavior during RabbitMQ cluster failover (need Hassan's help to simulate)
-
-#### Known Limitations
-
-- The fallback to synchronous dispatch means a RabbitMQ outage degrades performance but does not prevent notifications. This is a conscious trade-off for the migration period. Post-migration, we should consider queuing to a local buffer instead.
-- The dead letter queue alert goes to PagerDuty but there is no self-service retry UI yet. Failed notifications must be replayed manually via `rabbitmqadmin`.
-- No rate limiting per recipient. A bug in a calling service could spam a user with notifications. Follow-up: Issue #234.
-
-#### Risk Areas
-
-1. **Call site migration correctness** (high risk) — 12 call sites across 6 services must all produce correctly-shaped events. A malformed event silently enters the DLQ.
-2. **Retry and backoff logic** (medium risk) — incorrect backoff could hammer the email provider or create infinite retry loops.
-3. **Database migration** (low risk) — additive only, new table, no existing schema changes.
-4. **RabbitMQ configuration** (medium risk) — queue declarations, exchange bindings, and DLQ routing must match between publisher and consumer.
-
-### Review Guidance
-
-- **Commit-by-commit review recommended**: Each commit builds on the previous one. Reviewing the squashed diff will be overwhelming at 600 lines.
-- **Focus areas by reviewer**:
-  - Frank: RabbitMQ patterns (exchange/queue topology, message durability, ack handling, retry logic)
-  - Grace: Call site migrations in the 3 services she owns (verify event payloads match the templates each service uses)
-  - Hassan: RabbitMQ configuration, deployment concerns, monitoring and alerting setup
-  - Elena: Overall architecture review when she returns from PTO (non-blocking)
-- **Architecture decision to validate**: The synchronous fallback when RabbitMQ is down. Is this the right trade-off, or should we fail fast and rely on the calling service to handle the error?
-- **Depth**: Deep review for the worker service and retry logic. Standard review for call site migrations. Quick review for the database migration.
-
-### Reviewer Recommendation
-
-| Reviewer | Focus Area | Priority | Timeline |
-|----------|-----------|----------|----------|
-| Frank | RabbitMQ architecture, retry logic, message durability | Primary | This week |
-| Grace | Call site migrations in her 3 services | Primary | This week |
-| Hassan | RabbitMQ config, deployment, monitoring | Secondary | When available tomorrow |
-| Elena | Overall architecture sign-off | Advisory | After PTO Thursday (non-blocking) |
-
-**Urgency**: Low — no deadline. Prefer thorough review over speed. Happy to wait for Elena's feedback before merging if the team prefers.
-
-## Why This Response Works
-
-- The PR description addresses the "why" before the "how," helping reviewers understand the motivation.
-- The architecture diagram (before/after) gives reviewers a mental model before diving into code.
-- The commit structure guide enables progressive review of a large change.
-- Each reviewer gets specific focus areas matching their expertise, reducing duplicated effort.
-- The risk areas are ranked so reviewers allocate attention proportionally.
-- Known limitations and follow-up issues demonstrate the author has thought about completeness.
-- The non-urgent timeline with an advisory review from Elena shows mature process awareness.
-- The architecture question (synchronous fallback) invites the kind of feedback that improves the design.

package/workflows/skills/requesting-code-review/references/pr-description-patterns.md

@@ -1,215 +0,0 @@
-# PR Description Patterns
-
-## Overview
-
-A well-written PR description is the single highest-leverage action for getting fast, high-quality reviews. Reviewers who understand the context, motivation, and risks of a change provide better feedback in fewer cycles. This reference provides templates and patterns for different change types.
-
-## Universal Structure
-
-Every PR description should contain these sections, regardless of change type:
-
-### Title
-
-- Imperative mood: "Add search endpoint" not "Added search endpoint"
-- Under 72 characters
-- Prefix with type if the project uses conventional commits: `feat:`, `fix:`, `refactor:`, `docs:`
-
-### What / Why / How
-
-- **What**: One sentence describing the change at a high level.
-- **Why**: The motivation — what problem this solves, what user need it addresses, what issue it closes.
-- **How**: The approach taken, key design decisions, and any alternatives considered.
-
-### Testing
-
-- What was tested (unit, integration, E2E, manual).
-- How it was tested (specific commands, test scenarios).
-- What was not tested and why.
-
-### Risk Assessment
-
-- Areas of highest risk or uncertainty.
-- Rollback strategy if something goes wrong.
-- Dependencies on other changes or deployments.
-
-## Pattern: Feature Addition
-
-```markdown
-## What
-Add [feature] to [area] for [user type].
-
-## Why
-[Problem statement]. Currently [current behavior]. Users need [desired behavior].
-Closes #[issue].
-
-## How
-- [Key implementation decision 1]
-- [Key implementation decision 2]
-- [New dependency, if any, and why]
-
-## Testing
-- Unit tests: [what is covered]
-- Integration tests: [what is covered]
-- Manual testing: [scenarios tested]
-- Not tested: [gaps and why]
-
-## Screenshots
-[Before/after for UI changes]
-
-## Review Focus
-- [Specific area needing attention]
-- [Architecture question, if any]
-```
-
-## Pattern: Bug Fix
-
-```markdown
-## What
-Fix [bug description] in [area].
-
-## Root Cause
-[Explanation of why the bug occurred — not just what the fix is, but what was wrong.]
-
-## Fix
-[Description of the fix and why this approach was chosen over alternatives.]
-
-## How to Reproduce (Before Fix)
-1. [Step 1]
-2. [Step 2]
-3. [Observe: incorrect behavior]
-
-## Verification (After Fix)
-1. [Step 1]
-2. [Step 2]
-3. [Observe: correct behavior]
-
-## Testing
-- [Regression test added to prevent recurrence]
-- [Related edge cases checked]
-
-## Risk
-- [Could this fix break other behavior?]
-- [Is this a symptom fix or root cause fix?]
-```
-
-## Pattern: Refactoring
-
-```markdown
-## What
-Refactor [area] from [old approach] to [new approach].
-
-## Why
-[Specific problems with the current approach: performance, maintainability, scalability.]
-No behavior change — this is a pure refactor.
-
-## Approach
-[How the refactoring was done, what the new structure looks like.]
-
-## Verification
-- All existing tests pass without modification (confirms no behavior change).
-- [Additional verification, if any.]
-
-## Commit Strategy
-Review commit-by-commit:
-1. [First commit: preparatory changes]
-2. [Second commit: core refactoring]
-3. [Third commit: cleanup and tests]
-
-## Risk
-- [Areas where behavior change might have been accidentally introduced]
-- [Performance implications, if any]
-```
-
-## Pattern: Database Migration
-
-```markdown
-## What
-[Migration description: add table, add column, change index, etc.]
-
-## Why
-[What feature or fix requires this schema change.]
-
-## Migration Details
-- **Backward compatible**: [Yes/No — can the old code run with the new schema?]
-- **Estimated runtime**: [For large tables, how long will the migration take?]
-- **Locking behavior**: [Does this lock tables? For how long?]
-- **Rollback migration**: [Does a down migration exist? Has it been tested?]
-
-## Deployment Order
-1. [Deploy migration]
-2. [Deploy application code]
-3. [Or: deploy code first, then migration — explain order dependency]
-
-## Testing
-- Migration tested on a copy of production data (size: [X] rows).
-- Rollback migration tested.
-
-## Risk
-- [Data loss scenarios]
-- [Performance impact during migration]
-```
-
-## Pattern: Security Fix
-
-```markdown
-## What
-Fix [vulnerability type] in [area].
-
-## Severity
-[Critical / High / Medium / Low] — [brief justification].
-
-## Vulnerability Details
-[Description of the vulnerability — enough for reviewers to understand the threat model, but be mindful of disclosure if the repo is public.]
-
-## Fix
-[What the fix does and why this approach was chosen.]
-
-## Verification
-- [How the fix was verified — including attempting the exploit after the fix]
-- [Regression test added]
-
-## Urgency
-[Ship timeline — same day, this sprint, etc.]
-[Disclosure timeline — is there an external reporter waiting?]
-
-## Review Focus
-- Security completeness: does the fix address the root cause or just one vector?
-- Regression risk: could the fix break existing functionality?
-```
-
-## Anti-Patterns to Avoid
-
-### The empty description
-
-> "Fixed stuff"
-
-This tells reviewers nothing. Even a one-line change deserves a one-sentence explanation.
-
-### The novel
-
-A 2,000-word description for a 10-line change. Match description length to change complexity.
-
-### The copy-paste Jira ticket
-
-Pasting the entire Jira description is not a PR description. The PR should describe the implementation, not repeat the requirements.
-
-### The missing "why"
-
-> "Changed the timeout from 30s to 60s"
-
-Why? Was there a timeout error? A specific user report? A load test result? The "why" is what makes the change reviewable.
-
-### The optimistic "no risk"
-
-Every change has risk. Claiming "no risk" signals that the author has not thought about failure modes.
-
-## Checklist Before Submitting
-
-- [ ] Title is concise, imperative mood, under 72 characters
-- [ ] Description explains what, why, and how
-- [ ] Related issues are linked with closing keywords
-- [ ] Testing approach is described, including gaps
-- [ ] Risk areas are identified and explained
-- [ ] Screenshots included for UI changes
-- [ ] Review guidance specifies focus areas and expected depth
-- [ ] Draft/ready-for-review status is set correctly

package/workflows/skills/requesting-code-review/references/reviewer-selection.md

@@ -1,162 +0,0 @@
-# Reviewer Selection
-
-## Overview
-
-Selecting the right reviewers is as important as writing good code. The wrong reviewer wastes time — theirs and yours. The right reviewer catches issues you cannot see, provides feedback you can act on, and approves with confidence. This reference covers how to choose reviewers based on change characteristics, team composition, and practical constraints.
-
-## Selection Criteria
-
-### Domain Expertise
-
-The most important factor. A reviewer who understands the domain can evaluate correctness, design, and edge cases that a generalist would miss.
-
-| Change Area              | Look for Reviewer With                        |
-|--------------------------|-----------------------------------------------|
-| Authentication / Auth    | Security expertise, auth protocol knowledge   |
-| Database / Migrations    | DBA knowledge, schema design experience       |
-| Payment / Billing        | Financial systems experience, compliance awareness |
-| Frontend / UI            | Component architecture, accessibility knowledge |
-| Infrastructure / DevOps  | Deployment, scaling, observability experience  |
-| API Design               | REST/GraphQL conventions, versioning experience|
-| Performance              | Profiling experience, system design knowledge  |
-
-### Recent Context
-
-A reviewer who recently worked on the affected code has a mental model that makes review faster and more thorough. Check `git log` for recent authors of the files you changed.
-
-**How to find context holders**:
-- `git log --format='%an' -- path/to/file | sort | uniq -c | sort -rn` — most frequent authors
-- `git log --since='3 months ago' --format='%an' -- path/to/file | head -5` — recent authors
-- CODEOWNERS file — designated owners per path
-
-### Availability and Workload
-
-A qualified reviewer who is overloaded will delay your review or give it less attention. Consider:
-
-- Current sprint workload and deadline pressure
-- Number of PRs already in their review queue
-- Time zone overlap for async review
-- PTO or meeting-heavy days
-
-**Practical rule**: If your first-choice reviewer has more than 3 pending reviews, assign someone else or explicitly negotiate timeline.
-
-### Author Experience Level
-
-Match reviewer seniority to the change risk:
-
-| Author Level  | Change Risk | Recommended Reviewer         |
-|---------------|-------------|------------------------------|
-| Junior        | High risk   | Senior + domain expert       |
-| Junior        | Low risk    | Mid-level peer               |
-| Mid-level     | High risk   | Senior or domain expert      |
-| Mid-level     | Low risk    | Any qualified peer           |
-| Senior        | High risk   | Another senior or principal  |
-| Senior        | Low risk    | Any qualified peer           |
-
-## How Many Reviewers
-
-### One reviewer (default)
-
-- Standard feature work, bug fixes, refactoring
-- The change is in a well-understood area
-- The author is experienced with the codebase
-
-### Two reviewers
-
-- The change spans multiple domains (backend + frontend, API + database)
-- The change touches security-sensitive areas
-- The change is high-risk and benefits from independent perspectives
-
-### Three or more reviewers (rare)
-
-- Architecture changes affecting the entire system
-- Public API changes with external consumers
-- Compliance-sensitive changes requiring multiple sign-offs
-
-**Warning**: More than 2 reviewers often causes diffusion of responsibility. Everyone assumes someone else will do the deep review. If you need 3+ reviewers, assign specific focus areas to each.
-
-## Assigning Focus Areas
-
-When using multiple reviewers, prevent duplicate effort by assigning focus areas:
-
-```
-@alice — Please review the database migration and query changes.
-         Focus on: index performance, backward compatibility, rollback safety.
-
-@bob   — Please review the API endpoint and request validation.
-         Focus on: input validation, error handling, API contract consistency.
-```
-
-This pattern:
-- Prevents reviewers from duplicating each other's effort
-- Ensures every area gets reviewed by the most qualified person
-- Makes the review request feel manageable rather than overwhelming
-
-## CODEOWNERS Integration
-
-If your repository uses a CODEOWNERS file, GitHub automatically suggests reviewers based on file paths. Use CODEOWNERS as a starting point, but override when:
-
-- The CODEOWNER is on PTO or overloaded
-- The change requires expertise the CODEOWNER does not have
-- The CODEOWNER is a team alias and you need a specific individual
-
-## When to Skip Review
-
-Some changes do not need full review:
-
-- **Automated dependency bumps** (Dependabot, Renovate) — review the changelog, not the lock file
-- **Generated code** (protobuf, OpenAPI, GraphQL codegen) — review the source schema, not the output
-- **Trivial fixes** — typo in a comment, fixing a broken link in docs
-
-Even skip-review changes should go through CI and get a quick approval from someone for audit trail purposes.
-
-## Communicating with Reviewers
-
-### When requesting
-
-- Tag the reviewer directly (not just assign in the UI)
-- State the urgency and desired timeline
-- Explain why you chose them specifically
-- Specify the focus area and review depth
-
-### Template for review request message
-
-```
-@reviewer I'd appreciate your review on this PR.
-
-Focus: [specific area or concern]
-Urgency: [blocking/normal/low priority]
-Depth: [quick sanity check / standard / deep review]
-Timeline: [ideally by when]
-
-Key context: [one sentence about what this change does and why]
-```
-
-### When your reviewer is slow
-
-1. Wait 24 hours (they may be busy)
-2. Send a polite ping: "Hey, just checking if you've had a chance to look at PR #X"
-3. If still no response after 48 hours, reassign with a note: "Reassigning to unblock — happy to add you back for a second pass"
-4. Never escalate to management without first trying steps 1-3
-
-## Anti-Patterns
-
-### The rubber stamp
-
-Assigning a reviewer who will approve without reading. This defeats the purpose of review.
-
-### The bottleneck
-
-Assigning the same senior engineer to every PR. They become a bottleneck and burn out.
-
-### The punishment reviewer
-
-Assigning the strictest reviewer to someone you are frustrated with. Reviews should improve code, not punish people.
-
-### The crowd
-
-Assigning 5 reviewers hoping someone will look at it. Assign 1-2 with clear expectations instead.
-
-### The surprise assignment
-
-Assigning someone without context or warning. Always communicate why you chose them and what you need.