dojo.md 0.1.0 → 0.2.1

package/courses/github-pr-review/scenarios/level-2/review-metrics-analysis.yaml

@@ -0,0 +1,63 @@
+meta:
+  id: review-metrics-analysis
+  level: 2
+  course: github-pr-review
+  type: output
+  description: "Analyze review metrics — interpret PR review data to identify bottlenecks, improve turnaround time, and balance reviewer load"
+  tags: [github, pr-review, metrics, analytics, turnaround-time, intermediate]
+
+state: {}
+
+trigger: |
+  You're a team lead analyzing 3 months of PR review data for your
+  12-person engineering team. Management is concerned about shipping
+  velocity. Here's the data:
+
+  Overall metrics:
+  - Average time to first review: 18 hours
+  - Average time to merge: 4.2 days
+  - Average review rounds: 2.8
+  - PRs merged per week: 23
+  - PRs abandoned/closed without merge: 8 per week
+
+  Per-reviewer breakdown:
+  | Reviewer | Reviews/week | Avg first review (hrs) | Avg comments | Approval rate |
+  |----------|-------------|----------------------|--------------|---------------|
+  | Alice    | 14          | 4                    | 8.2          | 35%           |
+  | Bob      | 12          | 6                    | 3.1          | 72%           |
+  | Carol    | 3           | 48                   | 1.5          | 90%           |
+  | David    | 8           | 12                   | 5.4          | 55%           |
+  | Eve      | 2           | 72                   | 0.8          | 95%           |
+  | Frank    | 6           | 24                   | 4.7          | 60%           |
+
+  PR size distribution:
+  - Under 100 lines: 30% (avg 1.2 days to merge)
+  - 100-400 lines: 45% (avg 3.8 days to merge)
+  - 400+ lines: 25% (avg 8.5 days to merge)
+
+  Common review comment categories:
+  - Style/formatting: 35%
+  - Logic errors: 20%
+  - Missing tests: 18%
+  - Architecture concerns: 15%
+  - Documentation: 12%
+
+  Task: Analyze the data and write: the key findings (what's working,
+  what's not), the root causes behind slow merge times, specific
+  recommendations for each bottleneck (reviewer load balancing, PR size
+  policy, automation opportunities), an action plan with expected impact,
+  and the dashboard design for ongoing monitoring.
+
+assertions:
+  - type: llm_judge
+    criteria: "Key bottlenecks are identified — Alice is a bottleneck (too many reviews, too critical), Carol and Eve are under-reviewing, 35% of comments are style issues that should be automated, large PRs take disproportionately long, and the abandonment rate is high"
+    weight: 0.35
+    description: "Bottleneck identification"
+  - type: llm_judge
+    criteria: "Recommendations are specific and actionable — includes reviewer load rebalancing (cap Alice, increase Carol/Eve), automating style checks to eliminate 35% of comments, enforcing PR size limits, and reducing review rounds through better PR descriptions"
+    weight: 0.35
+    description: "Specific recommendations"
+  - type: llm_judge
+    criteria: "Action plan includes expected impact — quantifies improvements (e.g., automating style saves X hours/week, rebalancing reduces first-review time by Y hours), prioritizes actions by impact, and the dashboard tracks leading indicators not just lagging metrics"
+    weight: 0.30
+    description: "Quantified action plan"

package/courses/github-pr-review/scenarios/level-2/review-turnaround-sla.yaml

@@ -0,0 +1,54 @@
+meta:
+  id: review-turnaround-sla
+  level: 2
+  course: github-pr-review
+  type: output
+  description: "Design review SLAs — create turnaround time agreements that balance speed with quality and handle escalations"
+  tags: [github, pr-review, SLA, turnaround-time, process, intermediate]
+
+state: {}
+
+trigger: |
+  Your engineering org (40 developers, 4 teams) has no formal review
+  SLAs. The result: some PRs get reviewed in minutes (if the author
+  pings on Slack), others sit for days (if the author is quiet). This
+  creates frustration and slows delivery unpredictably.
+
+  Current pain points:
+  - Average first-review time varies wildly: 1 hour to 5 days
+  - Hotfixes sometimes wait behind feature PRs
+  - Junior engineers' PRs wait longer than senior engineers' PRs
+  - Cross-team reviews are the slowest (2x longer than within-team)
+  - No escalation path when a review is stuck
+  - Some reviewers batch all reviews to Friday afternoon
+  - No distinction between "quick look" reviews and deep reviews
+
+  Team composition:
+  - Platform team (8 devs): infrastructure, shared libraries
+  - Product team A (12 devs): user-facing features
+  - Product team B (10 devs): merchant-facing features
+  - Data team (10 devs): pipelines, analytics, ML
+
+  Task: Design the review SLA framework. Write: the SLA tiers (by PR
+  type, size, and urgency — with specific time targets for first review
+  and final decision), the escalation process (what happens when SLA is
+  missed — auto-assign, manager notification, etc.), the cross-team
+  review protocol (how to handle reviews that need expertise from another
+  team), the GitHub automation to track and enforce SLAs (labels, bots,
+  notifications), and the fairness mechanisms (ensuring junior engineers
+  get timely reviews, preventing reviewer burnout). Include the rollout
+  communication plan.
+
+assertions:
+  - type: llm_judge
+    criteria: "SLA tiers are well-designed — differentiates by urgency (hotfix < 2 hrs, normal < 1 business day, large/architectural < 2 days), by size (small PRs get faster targets), and includes separate targets for first review vs final decision"
+    weight: 0.35
+    description: "Well-designed SLA tiers"
+  - type: llm_judge
+    criteria: "Escalation and automation are practical — includes graduated escalation (reminder → reassign → manager), GitHub Actions or bot configuration for SLA tracking, label-based routing, and doesn't create notification fatigue"
+    weight: 0.35
+    description: "Practical escalation and automation"
+  - type: llm_judge
+    criteria: "Fairness and sustainability are addressed — prevents reviewer burnout (review load caps, rotation), ensures junior engineers' PRs don't get deprioritized, handles cross-team reviews with designated liaisons, and the communication plan gets buy-in"
+    weight: 0.30
+    description: "Fair and sustainable framework"

package/courses/github-pr-review/scenarios/level-2/stacked-pr-review.yaml

@@ -0,0 +1,65 @@
+meta:
+  id: stacked-pr-review
+  level: 2
+  course: github-pr-review
+  type: output
+  description: "Review stacked PRs — handle dependent PR chains, manage merge order, and review incremental changes effectively"
+  tags: [github, pr-review, stacked-prs, dependencies, workflow, intermediate]
+
+state: {}
+
+trigger: |
+  A senior engineer has submitted a stack of 4 dependent PRs for a
+  payment processing feature. They've asked you to review the full
+  stack. The PRs must be merged in order.
+
+  PR #301 (base: main) — "Add Payment model and database migration"
+  - 120 lines: new Payment table, migration, model with validations
+  - Status: CI green, no other reviews yet
+  - The migration adds columns: amount, currency, status, stripe_id,
+    created_at, updated_at
+  - You notice: no index on stripe_id, status enum uses strings instead
+    of an integer enum, no soft delete support
+
+  PR #302 (base: PR #301) — "Add payment processing service"
+  - 200 lines: PaymentService class, Stripe integration, error handling
+  - Status: CI green (includes #301's changes)
+  - Handles: create, capture, refund, webhook processing
+  - You notice: good error handling, but the refund method doesn't
+    check if the payment was already refunded, and the webhook handler
+    doesn't validate the Stripe signature
+
+  PR #303 (base: PR #302) — "Add payment API endpoints"
+  - 150 lines: REST endpoints, request validation, authentication
+  - Status: CI green
+  - You notice: endpoints look good, but there's no rate limiting on
+    the create-payment endpoint, and error responses leak internal
+    error messages to the client
+
+  PR #304 (base: PR #303) — "Add payment UI components"
+  - 180 lines: React components, form validation, loading states
+  - Status: CI green
+  - You notice: good UX, but the payment form doesn't disable the
+    submit button after click (double-charge risk), and there's no
+    idempotency key sent with the request
+
+  Task: Review the full stack. Write: the review strategy (how to
+  approach reviewing dependent PRs — top-down vs bottom-up, what to
+  focus on at each layer), the review for each PR (noting which issues
+  block the entire stack vs just that PR), the guidance on which issues
+  to fix before merging vs address in follow-ups, and the merge plan
+  (order, timing, what to verify between merges).
+
+assertions:
+  - type: llm_judge
+    criteria: "Review strategy is sound — reviews bottom-up (data layer first), identifies which issues are stack-blocking (migration issues in #301 block everything) vs local (UI issues in #304 only affect that PR), and reviews each PR in the context of the full feature"
+    weight: 0.35
+    description: "Sound stacked PR review strategy"
+  - type: llm_judge
+    criteria: "Issues are correctly categorized — missing stripe_id index and webhook signature validation are blocking issues, double-submit in UI is important but could be a follow-up, and the review recognizes that some issues span PRs (idempotency needs both API and UI changes)"
+    weight: 0.35
+    description: "Correct issue categorization"
+  - type: llm_judge
+    criteria: "Merge plan is practical — addresses the risks of merging a stack (what happens if #301 merges but #302 needs changes), suggests rebasing strategy, and handles the case where a middle PR needs significant changes"
+    weight: 0.30
+    description: "Practical merge plan"

package/courses/github-pr-review/scenarios/level-3/advanced-review-shift.yaml

@@ -0,0 +1,65 @@
+meta:
+  id: advanced-review-shift
+  level: 3
+  course: github-pr-review
+  type: output
+  description: "Advanced review shift — handle cross-functional reviews, compliance requirements, and process improvements simultaneously"
+  tags: [github, pr-review, shift-simulation, cross-functional, compliance, advanced]
+
+state: {}
+
+trigger: |
+  You're the review lead for the week. Your shift involves complex
+  reviews that span organizational boundaries and require process-level
+  decisions.
+
+  Situation 1 — Compliance-critical PR:
+  PR #601: "Add PCI DSS logging to payment endpoints" (180 lines)
+  The PR adds audit logging but the implementation logs full credit card
+  numbers in the "debug" log level. The author says debug logs are "only
+  for development" but you know they're enabled in staging which shares
+  infrastructure with production logs. This PR is blocking a PCI audit
+  next week.
+  Two reviewers have already approved it.
+
+  Situation 2 — Cross-team architecture dispute:
+  PR #602: "Shared authentication library v2" (450 lines)
+  The platform team submitted a breaking change to the auth library.
+  Three consuming teams have pushed back in the PR comments — 87
+  comments over 5 days with no resolution. The backend team wants OAuth,
+  the mobile team wants JWT, and the frontend team wants session-based.
+  The platform team is frustrated and threatening to merge without
+  consensus.
+
+  Situation 3 — Review process failure:
+  A production incident occurred because a PR was merged with a stale
+  approval — the code changed significantly after the approval, but
+  GitHub didn't require re-review. The CTO wants a fix before end of
+  week.
+
+  Situation 4 — Culture challenge:
+  A junior engineer comes to you privately saying a senior reviewer has
+  been leaving dismissive comments like "this is obviously wrong" and
+  "any competent developer would know this." The junior wants to change
+  teams. You check the PR history and confirm the pattern — 15 PRs with
+  similar comments in the last month.
+
+  Task: Handle all 4 situations. For each, write: the immediate action
+  (what to do right now), the resolution (how to resolve the core issue),
+  the process improvement (how to prevent recurrence), and the
+  communication (what to say and to whom). Include a weekly review lead
+  summary for the engineering leadership.
+
+assertions:
+  - type: llm_judge
+    criteria: "Compliance situation is handled correctly — the PCI logging issue is flagged as a blocker despite 2 existing approvals, the approval is dismissed/review requested, and the fix addresses the credit card logging in all environments, not just production"
+    weight: 0.35
+    description: "Correct compliance handling"
+  - type: llm_judge
+    criteria: "Architecture dispute is resolved constructively — doesn't pick a side in the PR, escalates to an architectural decision record (ADR) or RFC process, proposes an in-person/sync discussion, and addresses the platform team's frustration with a timeline commitment"
+    weight: 0.35
+    description: "Constructive dispute resolution"
+  - type: llm_judge
+    criteria: "Culture issue is addressed seriously — the senior reviewer's behavior is addressed through management (not publicly in PRs), the junior engineer is supported, and the systemic fix includes reviewer conduct expectations and a feedback mechanism"
+    weight: 0.30
+    description: "Serious culture issue handling"

package/courses/github-pr-review/scenarios/level-3/ai-powered-review.yaml

@@ -0,0 +1,58 @@
+meta:
+  id: ai-powered-review
+  level: 3
+  course: github-pr-review
+  type: output
+  description: "Implement AI-powered code review — evaluate and integrate AI review tools, define human-AI review boundaries, and measure effectiveness"
+  tags: [github, pr-review, AI, automation, LLM, code-analysis, advanced]
+
+state: {}
+
+trigger: |
+  Your CTO wants to adopt AI-powered code review to reduce review
+  bottlenecks. You've been tasked with evaluating the approach and
+  designing the integration. Your team has 80 engineers across 25 repos.
+
+  Tools to evaluate:
+  1. GitHub Copilot code review (built-in, understands repo context)
+  2. CodeRabbit (AI review bot, posts inline comments)
+  3. Sourcery (automated refactoring suggestions)
+  4. Custom solution using Claude/GPT API with GitHub webhooks
+
+  Current review data:
+  - 120 PRs per week, average 4 review comments each
+  - Comment breakdown: 40% style/formatting, 25% bug/logic, 20%
+    performance, 15% architecture
+  - Average reviewer time per PR: 25 minutes
+  - 60% of first-round comments are issues AI could catch
+
+  Concerns from the team:
+  - "AI reviews will be noisy and developers will start ignoring all
+    automated feedback"
+  - "We'll lose the learning aspect of human review"
+  - "Who's responsible when AI misses a bug that a human would catch?"
+  - "AI can't understand our business domain and conventions"
+  - "Junior engineers will stop learning if AI does the reviewing"
+
+  Task: Design the AI review integration. Write: the tool evaluation
+  matrix (features, accuracy, cost, integration complexity for each),
+  the human-AI boundary definition (what AI reviews vs what humans
+  review), the integration architecture (GitHub Actions workflow, comment
+  formatting, noise reduction), the measurement framework (how to track
+  AI review accuracy, false positive rate, developer satisfaction), and
+  the change management plan (addressing team concerns, pilot program,
+  rollout). Include cost-benefit analysis.
+
+assertions:
+  - type: llm_judge
+    criteria: "Tool evaluation is thorough — compares all 4 options on accuracy, cost, integration effort, and noise level, with a clear recommendation and reasoning. Considers the custom solution's flexibility vs maintenance burden"
+    weight: 0.35
+    description: "Thorough tool evaluation"
+  - type: llm_judge
+    criteria: "Human-AI boundaries are well-defined — AI handles style/formatting (40% of comments), flags potential bugs for human verification, and humans focus on architecture/design/domain logic. Addresses the learning concern by keeping educational review interactions human"
+    weight: 0.35
+    description: "Well-defined human-AI boundaries"
+  - type: llm_judge
+    criteria: "Change management addresses real concerns — the pilot program starts small and measures before scaling, noise reduction strategy prevents alert fatigue, the cost-benefit analysis quantifies saved reviewer hours vs tool cost, and the plan includes an exit strategy"
+    weight: 0.30
+    description: "Realistic change management"

package/courses/github-pr-review/scenarios/level-3/compliance-review-process.yaml

@@ -0,0 +1,64 @@
+meta:
+  id: compliance-review-process
+  level: 3
+  course: github-pr-review
+  type: output
+  description: "Design compliance-aware review — build review processes that satisfy SOX, SOC 2, HIPAA, and PCI DSS audit requirements"
+  tags: [github, pr-review, compliance, SOX, SOC2, audit, advanced]
+
+state: {}
+
+trigger: |
+  Your fintech company is preparing for SOC 2 Type II and PCI DSS
+  audits. The auditors will examine your code review process as part
+  of change management controls. Currently your process has gaps that
+  would fail the audit.
+
+  Audit requirements:
+  1. SOC 2 — Change Management (CC8.1):
+     - All production changes must be reviewed by someone other than
+       the author
+     - Reviews must be documented and traceable
+     - Emergency changes must have post-deployment review within 24 hrs
+     - Separation of duties: developer cannot approve and deploy
+
+  2. PCI DSS — Requirement 6.5:
+     - Code reviews must check for OWASP Top 10 vulnerabilities
+     - Security-focused review must be documented
+     - All custom code changes in the cardholder data environment must
+       be reviewed before deployment
+
+  3. SOX (if applicable to financial reporting code):
+     - Changes to financial calculation code require dual approval
+     - Complete audit trail of who reviewed, when, and what was decided
+
+  Current gaps:
+  - 15% of PRs are merged by the author (self-merge after auto-approve
+    from CI)
+  - No documented security review checklist
+  - Emergency hotfixes bypass review entirely
+  - No separation between code approval and deployment
+  - Review comments are sometimes deleted or edited after merge
+  - No way to prove a human reviewed the code (vs rubber stamp)
+
+  Task: Design the compliance-aware review process. Write: the branch
+  protection rules that enforce separation of duties, the security
+  review checklist (OWASP-focused, documented per PR), the emergency
+  change process (fast but auditable), the audit trail requirements
+  (what to log, how to preserve, how to present to auditors), and the
+  GitHub configuration (rulesets, required reviews, CODEOWNERS for
+  sensitive code paths). Include sample audit evidence you would present.
+
+assertions:
+  - type: llm_judge
+    criteria: "Compliance controls are complete — prevents self-merge (branch protection), requires documented security review for PCI-scoped code, enforces dual approval for SOX-scope financial code, and creates an immutable audit trail"
+    weight: 0.35
+    description: "Complete compliance controls"
+  - type: llm_judge
+    criteria: "Emergency process balances speed with compliance — allows expedited merges with reduced (but not zero) review requirements, mandates post-deployment review within 24 hours, and creates an audit trail even for emergency changes"
+    weight: 0.35
+    description: "Balanced emergency process"
+  - type: llm_judge
+    criteria: "Audit evidence is convincing — includes sample reports, GitHub configurations that create tamper-proof trails, and the process for presenting review history to auditors. Addresses the gap of edited/deleted review comments"
+    weight: 0.30
+    description: "Convincing audit evidence"

package/courses/github-pr-review/scenarios/level-3/cross-functional-review.yaml

@@ -0,0 +1,60 @@
+meta:
+  id: cross-functional-review
+  level: 3
+  course: github-pr-review
+  type: output
+  description: "Cross-functional PR review — coordinate reviews involving design, security, legal, and product stakeholders beyond engineering"
+  tags: [github, pr-review, cross-functional, design-review, security-review, advanced]
+
+state: {}
+
+trigger: |
+  You're leading the review process for a major feature PR that requires
+  input from multiple non-engineering stakeholders. The PR implements
+  GDPR consent management and data deletion for EU users.
+
+  The PR ("Implement GDPR consent and right-to-erasure"):
+  - 600 lines across 15 files
+  - Changes: consent UI, data collection APIs, deletion pipeline, audit
+    logging, cookie management, privacy policy integration
+
+  Required reviewers and their concerns:
+  1. Engineering (2 reviewers): Code quality, architecture, test coverage
+  2. Security team: Data handling, encryption at rest, access controls,
+     deletion completeness
+  3. Legal/Privacy: Consent language accuracy, deletion scope compliance
+     with Article 17, data retention exceptions
+  4. Design: Consent banner UX, accessibility, user flow clarity
+  5. Product: Feature completeness against GDPR requirements spec,
+     analytics impact (what tracking stops)
+
+  Challenges:
+  - Legal doesn't use GitHub — they review via email/Confluence
+  - Design reviews in Figma, not in code
+  - Security wants to run their own penetration test before approval
+  - Product wants to verify in a staging environment
+  - Each stakeholder has different availability (legal is 2 weeks out)
+  - The PR is too large for a single review session
+
+  Task: Design the cross-functional review process. Write: the review
+  coordination plan (who reviews what, in what order, with timeline),
+  the PR splitting strategy (if the 600-line PR should be broken up for
+  different reviewers), the tooling integration (how to bring GitHub,
+  Figma, Confluence, and email reviews into a single audit trail), the
+  sign-off process (how each stakeholder formally approves), and the
+  template for cross-functional PRs. Address the legal reviewer's 2-week
+  availability constraint.
+
+assertions:
+  - type: llm_judge
+    criteria: "Review coordination is realistic — sequences reviews logically (legal/design first since they have longest lead time, security pen test in parallel with code review, product verification last in staging), and the timeline accounts for the legal 2-week constraint"
+    weight: 0.35
+    description: "Realistic review coordination"
+  - type: llm_judge
+    criteria: "Tooling integration creates a single audit trail — brings email/Confluence legal feedback, Figma design comments, and GitHub code review into a traceable record, handles stakeholders who don't use GitHub"
+    weight: 0.35
+    description: "Unified audit trail"
+  - type: llm_judge
+    criteria: "The process is repeatable — the template and sign-off process could be reused for future cross-functional features, balances thoroughness with velocity, and doesn't create a 6-week review bottleneck"
+    weight: 0.30
+    description: "Repeatable cross-functional process"

package/courses/github-pr-review/scenarios/level-3/incident-driven-review.yaml

@@ -0,0 +1,63 @@
+meta:
+  id: incident-driven-review
+  level: 3
+  course: github-pr-review
+  type: output
+  description: "Incident-driven review improvement — analyze post-incident review failures and redesign processes to catch similar issues"
+  tags: [github, pr-review, incidents, post-mortem, process-improvement, advanced]
+
+state: {}
+
+trigger: |
+  Three production incidents in the last quarter were traced back to
+  code review failures — issues that should have been caught in review
+  but weren't. You've been tasked with analyzing the failures and
+  improving the review process.
+
+  Incident 1 — Data loss (Severity: Critical):
+  A migration PR dropped a column that was still used by a background
+  job. The PR had 2 approvals and CI was green. Neither reviewer checked
+  the background job code. The column name appeared in 3 files that
+  weren't part of the PR diff.
+  Impact: 48 hours of data loss for 12,000 users
+  Review gap: Reviewers only looked at files in the diff, not at callers
+  of the changed code
+
+  Incident 2 — Security breach (Severity: Critical):
+  A PR added a debug endpoint that returned user data without
+  authentication. It was merged as part of a 1,200-line "feature
+  complete" PR. The endpoint was on line 847 of a 900-line file.
+  Impact: 500 user records exposed for 3 days
+  Review gap: The PR was too large to review effectively, the debug
+  endpoint was buried in a massive diff, and the reviewer admitted
+  to "skimming" the last 400 lines
+
+  Incident 3 — Financial miscalculation (Severity: High):
+  A PR changed a currency conversion formula. The unit test used the
+  same incorrect formula as the implementation (copy-pasted), so tests
+  passed. The reviewer approved based on "tests pass."
+  Impact: $47,000 in incorrect charges over 2 weeks
+  Review gap: Tests validated consistency, not correctness. No
+  independent verification of the business logic
+
+  Task: For each incident, write: the root cause analysis of the review
+  failure (why the review process didn't catch it), the specific process
+  change that would prevent recurrence, the detection mechanism (how to
+  know if the process change is working), and the review checklist
+  addition. Then write a synthesis: the systemic patterns across all 3
+  incidents, the comprehensive review process improvements, and the
+  training program to address the skill gaps revealed by these incidents.
+
+assertions:
+  - type: llm_judge
+    criteria: "Root causes go beyond blaming reviewers — identifies systemic issues: #1 reveals that reviews don't check callers/dependencies, #2 reveals that large PRs can't be reviewed effectively, #3 reveals that test-pass ≠ correctness and independent verification is needed"
+    weight: 0.35
+    description: "Systemic root cause analysis"
+  - type: llm_judge
+    criteria: "Process changes are specific and preventive — #1 adds dependency/caller analysis to reviews (or automated tooling), #2 enforces PR size limits and adds security-specific review for auth-related code, #3 requires independent test verification for business-critical calculations"
+    weight: 0.35
+    description: "Specific preventive process changes"
+  - type: llm_judge
+    criteria: "Synthesis identifies patterns — connects all 3 incidents to broader themes (over-reliance on CI, review depth vs PR size, domain-specific review expertise), and the training program addresses the revealed skill gaps without creating blame"
+    weight: 0.30
+    description: "Pattern-connecting synthesis"

package/courses/github-pr-review/scenarios/level-3/large-scale-review-operations.yaml

@@ -0,0 +1,55 @@
+meta:
+  id: large-scale-review-operations
+  level: 3
+  course: github-pr-review
+  type: output
+  description: "Design large-scale review operations — create review processes for 100+ developer organizations with multiple teams and repositories"
+  tags: [github, pr-review, operations, scaling, organization, advanced]
+
+state: {}
+
+trigger: |
+  You're the Director of Engineering at a company scaling from 30 to
+  150 engineers over the next year. The current review process (informal,
+  team-based) is already breaking down at 30 engineers. You need to
+  design a review system that scales.
+
+  Current problems:
+  - 15 repositories with no consistent review process
+  - Some repos require 1 approval, others require 3
+  - No cross-repo review standards (code style varies wildly)
+  - Average merge time: 3 days (target: 1 day)
+  - Knowledge silos: only 2 people can review the payment code
+  - New hires take 3 months before they can review code confidently
+  - No review quality metrics — quantity is tracked but not quality
+  - Occasional "LGTM" rubber-stamp approvals on critical code
+
+  Planned growth:
+  - 5 new teams being formed (total: 10 teams)
+  - 3 new repos being created (total: 18 repos)
+  - Acquiring a company with 20 engineers and their own repo/processes
+  - Moving to a monorepo for shared libraries (under discussion)
+
+  Task: Design the review operations framework. Write: the review
+  standards document (minimum requirements for all repos, with team-
+  specific extensions), the reviewer assignment system (CODEOWNERS
+  strategy, rotation, knowledge distribution), the quality assurance
+  mechanisms (preventing rubber stamps, ensuring review depth), the
+  onboarding program for new reviewers (shadow reviewing, graduated
+  autonomy), and the metrics framework (what to measure, targets,
+  dashboards). Include the migration plan for existing repos and the
+  acquired company's integration.
+
+assertions:
+  - type: llm_judge
+    criteria: "Standards are scalable — creates a base standard that applies to all 18 repos with team-specific extensions, handles the monorepo question, and includes the acquired company integration with a gradual alignment plan rather than forcing immediate compliance"
+    weight: 0.35
+    description: "Scalable review standards"
+  - type: llm_judge
+    criteria: "Knowledge distribution is addressed — CODEOWNERS strategy prevents knowledge silos (rotation, mandatory cross-training), reviewer onboarding program reduces the 3-month ramp-up time, and the system handles the 2-person payment code bottleneck"
+    weight: 0.35
+    description: "Knowledge distribution strategy"
+  - type: llm_judge
+    criteria: "Quality assurance prevents gaming — mechanisms to detect rubber-stamp reviews (review depth metrics, comment quality), graduated approval requirements (critical code vs routine changes), and the metrics framework measures quality not just speed"
+    weight: 0.30
+    description: "Anti-gaming quality assurance"

package/courses/github-pr-review/scenarios/level-3/monorepo-review-process.yaml

@@ -0,0 +1,68 @@
+meta:
+  id: monorepo-review-process
+  level: 3
+  course: github-pr-review
+  type: output
+  description: "Design monorepo review process — handle review routing, ownership, and CI for PRs that touch multiple packages in a monorepo"
+  tags: [github, pr-review, monorepo, CODEOWNERS, CI, routing, advanced]
+
+state: {}
+
+trigger: |
+  Your company just migrated 12 microservice repos into a single
+  monorepo using Turborepo. The review process that worked for individual
+  repos is now broken. Key problems:
+
+  Monorepo structure:
+  ```
+  /
+  ├── apps/
+  │   ├── web/           (Frontend team, 8 devs)
+  │   ├── api/           (Backend team, 10 devs)
+  │   ├── mobile/        (Mobile team, 6 devs)
+  │   └── admin/         (Platform team, 4 devs)
+  ├── packages/
+  │   ├── ui/            (Design system — shared)
+  │   ├── auth/          (Auth library — shared)
+  │   ├── database/      (DB client — backend + platform)
+  │   ├── config/        (Shared config — everyone)
+  │   └── types/         (Shared types — everyone)
+  ├── infra/             (DevOps, 3 devs)
+  └── tools/             (DX team, 2 devs)
+  ```
+
+  Current problems:
+  - A PR touching `packages/types` requests review from ALL 33 engineers
+  - CI runs all tests for every PR (45 minutes), even single-line changes
+  - CODEOWNERS from individual repos were concatenated — conflicts and
+    overlaps everywhere
+  - Cross-package PRs (e.g., API change + type update + web update) have
+    no clear review strategy
+  - Shared packages have no clear ownership — everyone and no one
+
+  A recent incident: A change to `packages/auth` broke mobile login but
+  the mobile team wasn't requested as reviewers. It took 2 days to
+  discover the break.
+
+  Task: Design the monorepo review process. Write: the CODEOWNERS
+  strategy (ownership model for shared packages, cross-team routing),
+  the CI optimization (affected-package detection, selective test runs),
+  the cross-package PR guidelines (when to split PRs, when one PR is
+  fine, who reviews what), the shared package governance model (who
+  owns shared code, how changes are reviewed), and the incident
+  prevention strategy (ensuring breaking changes are caught by affected
+  teams). Include the CODEOWNERS file and a sample CI workflow.
+
+assertions:
+  - type: llm_judge
+    criteria: "CODEOWNERS handles the monorepo correctly — shared packages have designated owners plus affected-team routing (not all 33 engineers), apps have team ownership, and cross-package PRs are handled with both source and consumer team reviews"
+    weight: 0.35
+    description: "Correct monorepo CODEOWNERS"
+  - type: llm_judge
+    criteria: "CI optimization is practical — uses affected-package detection (Turborepo's --filter or similar), runs only relevant tests, but still runs shared-package tests when shared code changes. Reduces 45-minute CI to relevant-only runs"
+    weight: 0.35
+    description: "Practical CI optimization"
+  - type: llm_judge
+    criteria: "Incident prevention is addressed — the auth-breaking-mobile scenario is prevented through consumer-team notification on shared package changes, integration test requirements for cross-package changes, and a shared package change RFC process"
+    weight: 0.30
+    description: "Cross-package incident prevention"