dojo.md 0.1.0 → 0.2.1

package/courses/github-pr-review/scenarios/level-4/review-platform-architecture.yaml

@@ -0,0 +1,64 @@
+meta:
+  id: review-platform-architecture
+  level: 4
+  course: github-pr-review
+  type: output
+  description: "Architect a review platform — design the technical architecture for a company-wide review automation and analytics platform"
+  tags: [github, pr-review, architecture, platform, automation, expert]
+
+state: {}
+
+trigger: |
+  You're the Staff Engineer tasked with building an internal "Review
+  Platform" — a centralized system that orchestrates code review across
+  your 600-engineer organization. The platform replaces a patchwork of
+  scripts, bots, and manual processes.
+
+  Platform requirements:
+  1. Unified reviewer assignment across all repos and GitHub orgs
+  2. Risk-based review routing (auto-classify PRs by risk level and
+     route to appropriate reviewers)
+  3. Real-time review analytics dashboard
+  4. Compliance audit trail generator
+  5. Integration with GitHub, GitLab, Slack, Jira, PagerDuty
+  6. AI-assisted review suggestions (flag potential issues before human
+     review)
+  7. Custom review workflows (different flows for different teams/repos)
+
+  Scale requirements:
+  - 200+ repos across 3 GitHub orgs
+  - 1,500 PRs per week
+  - 50ms p99 latency for webhook processing
+  - 99.9% uptime (review platform down = all merges blocked)
+  - 30-day event replay for debugging
+  - Horizontal scalability for 3x growth
+
+  Technical constraints:
+  - Must run on existing Kubernetes cluster
+  - Must use existing PostgreSQL and Redis infrastructure
+  - GitHub API rate limits: 5,000/hour per installation
+  - Must handle GitHub webhook delivery guarantees (at-least-once)
+  - Must support gradual rollout (repo by repo)
+
+  Task: Design the platform architecture. Write: the system design
+  (components, data flow, storage, event processing), the API design
+  (internal APIs for team customization), the scalability strategy
+  (how to handle 1,500 PRs/week within rate limits, horizontal scaling
+  plan), the reliability design (what happens when the platform is down,
+  circuit breakers, graceful degradation), and the deployment strategy
+  (gradual rollout, feature flags, rollback plan). Include architecture
+  diagrams (text-based) and key technical decisions with trade-offs.
+
+assertions:
+  - type: llm_judge
+    criteria: "Architecture handles the scale — event-driven design with webhook receivers, job queues, and workers that handle 1,500 PRs/week within API rate limits. Includes rate limit pooling across 3 GitHub orgs and back-pressure mechanisms"
+    weight: 0.35
+    description: "Scale-handling architecture"
+  - type: llm_judge
+    criteria: "Reliability is enterprise-grade — graceful degradation when platform is down (PRs can still be merged manually), circuit breakers for external services, idempotent webhook processing (at-least-once handling), and 30-day event replay for debugging"
+    weight: 0.35
+    description: "Enterprise-grade reliability"
+  - type: llm_judge
+    criteria: "Deployment strategy is low-risk — gradual rollout repo by repo, feature flags for each capability, rollback plan that doesn't disrupt ongoing reviews, and the platform can be disabled per-repo without affecting others"
+    weight: 0.30
+    description: "Low-risk deployment strategy"

package/courses/github-pr-review/scenarios/level-4/review-training-program.yaml

@@ -0,0 +1,66 @@
+meta:
+  id: review-training-program
+  level: 4
+  course: github-pr-review
+  type: output
+  description: "Design reviewer training program — create a comprehensive curriculum for building review expertise across seniority levels"
+  tags: [github, pr-review, training, education, certification, expert]
+
+state: {}
+
+trigger: |
+  You're designing a company-wide code review training program for your
+  600-engineer organization. The program should transform review from a
+  chore into a valued skill with career impact.
+
+  Current problems the training must address:
+  - New hires take 3+ months before their reviews add value
+  - 30% of review comments are preferences, not issues
+  - Reviewers miss bugs because they focus on style
+  - Senior engineers' reviews are rubber-stamped ("too experienced to
+    question")
+  - No one teaches how to write good review comments
+  - Reviewers don't know when to approve vs request changes
+  - Cross-domain reviews (backend reviewer on frontend PR) are shallow
+
+  Target audience tiers:
+  1. New hires / juniors: First-time reviewers who need fundamentals
+  2. Mid-level engineers: Competent reviewers who need depth and breadth
+  3. Senior / staff engineers: Experienced reviewers who need to review
+     architecture and mentor through reviews
+  4. Engineering managers: Need to evaluate review quality and coach
+
+  Available formats:
+  - Self-paced online modules (budget: $50K to build)
+  - Live workshops (budget: $30K/year, monthly cadence)
+  - Shadow reviewing program (pair reviewing with a mentor)
+  - Review certification (gamification to incentivize learning)
+  - Practice exercises with curated PRs (real anonymized examples)
+
+  Constraints:
+  - Maximum 2 hours/month of training time per engineer
+  - Must show measurable improvement within 3 months
+  - Must not feel punitive (training shouldn't be "you review badly")
+  - Must work for remote-first company (75% remote)
+
+  Task: Design the complete training program. Write: the curriculum for
+  each tier (learning objectives, modules, exercises), the shadow
+  reviewing program design (matching, structure, graduation criteria),
+  the certification system (levels, requirements, incentives, badge
+  visibility), the measurement framework (how to prove training works),
+  and the rollout plan (who goes first, how to drive adoption without
+  mandating). Include sample exercise materials for each tier.
+
+assertions:
+  - type: llm_judge
+    criteria: "Curriculum is tier-appropriate — juniors learn fundamentals (comment types, approval criteria, etiquette), mid-level learn depth (security review, performance review, architecture), seniors learn strategic review and mentoring, and managers learn to evaluate and coach review quality"
+    weight: 0.35
+    description: "Tier-appropriate curriculum"
+  - type: llm_judge
+    criteria: "Shadow reviewing program is well-structured — includes matching criteria (expertise, personality, timezone), session structure (observe → co-review → independent with feedback), graduation criteria, and scales beyond 1:1 mentoring"
+    weight: 0.35
+    description: "Well-structured shadow program"
+  - type: llm_judge
+    criteria: "Measurement framework proves ROI — tracks leading indicators (comment quality scores, training completion) and lagging indicators (review-related incidents, merge time, developer satisfaction), with a control group or before/after comparison design"
+    weight: 0.30
+    description: "ROI-proving measurement framework"

package/courses/github-pr-review/scenarios/level-4/review-vendor-evaluation.yaml

@@ -0,0 +1,76 @@
+meta:
+  id: review-vendor-evaluation
+  level: 4
+  course: github-pr-review
+  type: output
+  description: "Evaluate review tool vendors — conduct a thorough evaluation of code review platforms, AI review tools, and analytics vendors"
+  tags: [github, pr-review, vendor-evaluation, procurement, tooling, expert]
+
+state: {}
+
+trigger: |
+  You're leading the vendor evaluation for code review tooling. The
+  company has budget for 1-2 tools and needs a recommendation within
+  30 days. Your 600-engineer organization currently uses GitHub's native
+  review features with some custom scripts.
+
+  Vendors to evaluate:
+
+  Vendor A — ReviewBot Pro ($15/user/month):
+  - AI-powered code review with custom model training
+  - Automated reviewer assignment based on expertise
+  - Review analytics dashboard
+  - Claims: "Reduces review time by 50%"
+  - Integration: GitHub, GitLab, Bitbucket
+  - Security: SOC 2 Type II certified, code never leaves your network
+  - Concerns: requires GitHub App with broad repo permissions, new
+    startup (2 years old, Series A)
+
+  Vendor B — CodeGuard Enterprise ($25/user/month):
+  - Security-focused review automation (SAST, dependency scanning)
+  - Compliance reporting (SOC 2, PCI, HIPAA)
+  - Custom policy engine (enforce review rules per repo)
+  - Claims: "Catches 70% of security issues before human review"
+  - Integration: GitHub only
+  - Security: FedRAMP authorized, self-hosted option available
+  - Concerns: expensive, long implementation timeline (3-6 months)
+
+  Vendor C — DevMetrics ($8/user/month):
+  - Review analytics and team performance dashboards
+  - Review SLA tracking and alerting
+  - Developer experience surveys integrated with review data
+  - Claims: "Teams using DevMetrics improve merge time by 35%"
+  - Integration: GitHub, Jira, Slack
+  - Security: SOC 2 Type I, cloud only
+  - Concerns: analytics only (no automation), uses anonymized data for
+    their own ML model training
+
+  Vendor D — Open source alternative (Danger.js + custom GitHub Actions):
+  - Free, fully customizable
+  - Active community
+  - No vendor lock-in
+  - Concerns: maintenance burden (estimated 0.5 FTE), limited analytics,
+    no AI capabilities, no support SLA
+
+  Task: Conduct the vendor evaluation. Write: the evaluation framework
+  (weighted criteria matrix), the detailed assessment of each vendor
+  (strengths, weaknesses, risks), the total cost of ownership analysis
+  (3-year TCO including implementation, maintenance, training), the
+  security and privacy assessment (data handling, permissions, vendor
+  risk), and the recommendation memo (which vendor(s) to choose, with
+  implementation plan and exit strategy). Include the pilot program
+  design to validate the choice.
+
+assertions:
+  - type: llm_judge
+    criteria: "Evaluation framework is rigorous — weighted criteria include functionality, security, cost, integration complexity, vendor viability (startup risk for Vendor A), scalability, and exit strategy. Weights reflect the organization's priorities"
+    weight: 0.35
+    description: "Rigorous evaluation framework"
+  - type: llm_judge
+    criteria: "TCO analysis is complete — includes license costs, implementation effort, ongoing maintenance, training, and hidden costs (productivity loss during migration, vendor lock-in costs). Compares 3-year TCO across all options including the open-source alternative"
+    weight: 0.35
+    description: "Complete TCO analysis"
+  - type: llm_judge
+    criteria: "Recommendation is well-reasoned — makes a specific recommendation (not 'it depends'), addresses security concerns (especially Vendor C's data usage), includes a pilot program to validate before full rollout, and has an exit strategy for each vendor"
+    weight: 0.30
+    description: "Well-reasoned recommendation"

package/courses/github-pr-review/scenarios/level-5/comprehensive-review-system.yaml

@@ -0,0 +1,68 @@
+meta:
+  id: comprehensive-review-system
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Design comprehensive review system — architect a 5-layer review system for a Fortune 500 technology company"
+  tags: [github, pr-review, comprehensive, enterprise, architecture, master]
+
+state: {}
+
+trigger: |
+  You're the CTO of a Fortune 500 technology company ($8B revenue, 3,000
+  engineers) designing a unified code review system. The company has 6
+  business units acquired over 10 years, each with different tooling,
+  processes, and cultures. The board has mandated unification after a
+  regulatory finding that change management controls were "inconsistent
+  and insufficient."
+
+  Current state by business unit:
+  - Cloud Platform (600 eng): GitHub Enterprise, mature review process
+  - Consumer Apps (500 eng): GitHub Cloud, fast-moving, minimal process
+  - Enterprise Software (400 eng): GitLab, heavyweight review gates
+  - Data & Analytics (300 eng): Mix of GitHub and Jupyter, informal
+  - IoT/Embedded (200 eng): Gerrit, hardware-focused review needs
+  - Recently acquired AI startup (200 eng): No formal process, pair
+    programming culture
+
+  Design the review system in 5 layers:
+
+  Layer 1 — Governance: Universal policies, compliance mapping (SOX,
+  SOC 2, PCI DSS, HIPAA, FedRAMP across different BUs), audit trail
+  Layer 2 — Platform: Unified tooling, migration from 4 VCS platforms
+  to GitHub Enterprise, custom automation
+  Layer 3 — Process: Review workflows per risk level, SLAs, escalation,
+  cross-BU reviews for shared code
+  Layer 4 — Intelligence: AI-powered review, analytics, predictive
+  quality, anomaly detection
+  Layer 5 — Culture: Training, certification, incentives, career paths,
+  developer experience
+
+  Constraints:
+  - $10M budget over 3 years
+  - Cannot disrupt any BU's shipping velocity during migration
+  - Must satisfy 6 different compliance frameworks simultaneously
+  - Must handle 5,000+ PRs per week across all BUs
+  - IoT/Embedded team has legitimate needs for Gerrit's change-based
+    review model
+  - Board expects quarterly progress reports
+
+  Task: Design all 5 layers. For each, write: the detailed design, the
+  migration/implementation plan, the interaction with other layers, and
+  the success metrics. Then write: the 3-year phased roadmap with
+  quarterly milestones, the $10M budget allocation, the organizational
+  model (who owns each layer), and the board presentation for approval.
+
+assertions:
+  - type: llm_judge
+    criteria: "5-layer design is coherent — each layer builds on the one below, there are clear interfaces between layers, and the design handles the complexity of 6 BUs without over-simplifying. The IoT/Gerrit exception is handled gracefully (bridge or adapter, not forced migration)"
+    weight: 0.35
+    description: "Coherent 5-layer design"
+  - type: llm_judge
+    criteria: "Migration plan is realistic — handles the 4-to-1 VCS consolidation without disrupting shipping, phases the migration BU by BU, has rollback plans for each phase, and the 3-year timeline with quarterly milestones is achievable"
+    weight: 0.35
+    description: "Realistic migration plan"
+  - type: llm_judge
+    criteria: "Budget allocation is justified — the $10M is distributed across layers and years with clear rationale, the build-vs-buy decisions are made for each component, and the ROI projection shows when the investment pays back through reduced incidents, compliance costs, and engineering productivity"
+    weight: 0.30
+    description: "Justified budget allocation"

package/courses/github-pr-review/scenarios/level-5/master-review-shift.yaml

@@ -0,0 +1,73 @@
+meta:
+  id: master-review-shift
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Master review shift — navigate existential threats to the review function while maintaining organizational trust and shipping velocity"
+  tags: [github, pr-review, shift-simulation, crisis, existential, master]
+
+state: {}
+
+trigger: |
+  You're the CTO facing a perfect storm of review-related challenges
+  that threaten the company's engineering capability, compliance
+  posture, and competitive position simultaneously.
+
+  Crisis 1 — Regulatory investigation:
+  The SEC is investigating your company's software change management
+  practices after a financial reporting error was traced to a code
+  change that bypassed review. They've subpoenaed 2 years of code
+  review records. Your legal team discovers that 12% of production
+  changes in the financial reporting codebase have incomplete review
+  trails. The SEC hearing is in 6 weeks.
+
+  Crisis 2 — Competitive disruption:
+  Your main competitor just announced "Zero-Review Deployment" — they
+  claim AI reviews 100% of their code and human review is optional.
+  Their merge time is 30 minutes vs your 2 days. Your board is asking
+  why you're "falling behind on AI adoption." Three VP-level candidates
+  withdrew from your hiring pipeline citing your "slow engineering
+  culture."
+
+  Crisis 3 — Platform outage:
+  Your GitHub Enterprise instance suffered a data corruption event.
+  The review history for 6 months of PRs is unrecoverable. This affects
+  your SOC 2 audit evidence, your review analytics baseline, and your
+  AI review model training data. GitHub's recovery ETA is "weeks."
+
+  Crisis 4 — Talent exodus:
+  Your top 3 review tooling engineers (out of 12) just gave notice —
+  they're joining the competitor from Crisis 2. They built the core
+  review automation platform and have institutional knowledge that's
+  not documented. Their last day is in 2 weeks.
+
+  Crisis 5 — Board pressure:
+  The board is meeting in 48 hours for an emergency session. They want
+  a unified briefing on all 4 crises above and a strategic response.
+  Two board members are pushing to "just adopt AI review like the
+  competitor." One board member (former regulator) is pushing to "freeze
+  all deployments until review gaps are fixed."
+
+  Task: Navigate all 5 crises. Write: the 48-hour action plan for the
+  board meeting, the SEC response strategy (what to present, what to
+  remediate, legal coordination), the competitive response (how to
+  address the AI review narrative without panic), the platform recovery
+  plan (data recovery, interim process, audit evidence reconstruction),
+  the talent retention and knowledge transfer plan, and the board
+  presentation that unifies all crises into a coherent strategic
+  response. Show how the crises interconnect and the risks of solving
+  one at the expense of others.
+
+assertions:
+  - type: llm_judge
+    criteria: "Board presentation unifies the crises — shows the interconnections (SEC investigation + data loss = compounded compliance risk, competitor + talent loss = capability risk), doesn't present 5 separate plans but a unified strategy, and addresses both board member extremes (AI adoption vs deployment freeze)"
+    weight: 0.35
+    description: "Unified crisis board presentation"
+  - type: llm_judge
+    criteria: "SEC response is legally sound — coordinates with legal counsel, presents a proactive remediation plan rather than defensive posture, addresses the 12% review gap with root cause analysis and corrective actions, and the audit evidence reconstruction plan is credible"
+    weight: 0.35
+    description: "Legally sound SEC response"
+  - type: llm_judge
+    criteria: "Competitive response is strategic not reactive — doesn't panic-adopt AI review to match competitor, analyzes the competitor's claim critically (is 'zero-review' actually safe for financial software?), proposes an AI adoption roadmap that's faster but responsible, and addresses the hiring pipeline impact"
+    weight: 0.30
+    description: "Strategic competitive response"

package/courses/github-pr-review/scenarios/level-5/review-ai-future.yaml

@@ -0,0 +1,69 @@
+meta:
+  id: review-ai-future
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Design the future of AI-powered review — architect next-generation review systems where AI and humans collaborate on code quality"
+  tags: [github, pr-review, AI, future, ML-systems, architecture, master]
+
+state: {}
+
+trigger: |
+  You're the VP of AI/ML at a developer tools company building the
+  next generation of AI-powered code review. Your product serves 10,000
+  organizations and reviews 2M PRs per month. You need to design the
+  AI system that will define how code review works in 2027-2030.
+
+  Current capabilities (baseline):
+  - Style and formatting checks (commoditized, 95% accuracy)
+  - Common bug pattern detection (70% accuracy, 15% false positive rate)
+  - Automated review comment generation (50% helpfulness rating)
+  - PR risk scoring based on file types and historical data
+
+  Target capabilities (next 3 years):
+  1. Semantic code understanding: Understand what code does (not just
+     syntax), detect logical errors, and reason about business logic
+  2. Repository-aware review: Understand the full codebase context,
+     architectural patterns, and team conventions
+  3. Personalized review: Adapt review depth and style to the author's
+     experience level and team's preferences
+  4. Predictive review: Flag potential issues before they become bugs
+     based on historical patterns and similar code in other repos
+  5. Review orchestration: Dynamically assign human reviewers based on
+     what AI can vs cannot confidently review, optimizing human time
+
+  Constraints:
+  - Customer code must never leave their tenant (privacy-critical)
+  - False positives destroy trust — must be under 5%
+  - Must work with GitHub's review UI (not a separate tool)
+  - Must handle 2M PRs/month at current scale, 10M at target scale
+  - Enterprise customers require explainable AI decisions
+
+  Ethical considerations:
+  - AI review shouldn't replace the learning benefits of human review
+  - AI shouldn't create surveillance of developer performance
+  - AI decisions on code quality must be transparent and contestable
+  - AI training data must not leak code between customers
+
+  Task: Design the next-generation AI review system. Write: the product
+  vision (what review looks like in 2030), the technical architecture
+  (models, training, inference, privacy), the human-AI collaboration
+  model (when AI leads, when humans lead, how they interact), the
+  ethical framework (principles, guardrails, transparency mechanisms),
+  and the go-to-market roadmap (what to ship when, how to build trust
+  progressively). Include the key technical challenges and proposed
+  solutions.
+
+assertions:
+  - type: llm_judge
+    criteria: "Product vision is compelling and specific — paints a concrete picture of review in 2030 (not vague 'AI will review everything'), with specific scenarios showing human-AI collaboration, and acknowledges what AI will and won't be able to do"
+    weight: 0.35
+    description: "Compelling specific product vision"
+  - type: llm_judge
+    criteria: "Technical architecture handles constraints — solves the privacy problem (per-tenant models or federated learning), scales to 10M PRs/month, keeps false positives under 5% with confidence calibration, and integrates with GitHub's UI natively"
+    weight: 0.35
+    description: "Constraint-handling technical architecture"
+  - type: llm_judge
+    criteria: "Ethical framework is substantive — goes beyond platitudes to specific guardrails (e.g., AI review scores are never used in performance reviews, developers can always override AI, AI explanations are required for any blocking comment), with enforcement mechanisms"
+    weight: 0.30
+    description: "Substantive ethical framework"

package/courses/github-pr-review/scenarios/level-5/review-behavioral-science.yaml

@@ -0,0 +1,66 @@
+meta:
+  id: review-behavioral-science
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Apply behavioral science to code review — use psychology and behavioral economics to improve review quality, speed, and developer experience"
+  tags: [github, pr-review, behavioral-science, psychology, nudges, master]
+
+state: {}
+
+trigger: |
+  You're the Head of Developer Experience applying behavioral science
+  principles to code review. Despite having good tools, processes, and
+  training, review quality and speed haven't improved in 18 months.
+  You hypothesize that cognitive biases and behavioral patterns are the
+  root cause.
+
+  Observed behavioral patterns:
+  1. Authority bias: Senior engineers' PRs get approved 2x faster with
+     50% fewer comments than junior engineers' identical code changes
+     (tested with anonymized blind reviews)
+  2. Anchoring effect: The first reviewer's decision heavily influences
+     subsequent reviewers — if the first review is "LGTM," 85% of
+     second reviewers also approve without substantive feedback
+  3. Sunk cost fallacy: Large PRs that have been in review for days
+     get approved despite issues because "we've already invested so
+     much time reviewing this"
+  4. Status quo bias: Reviewers are 3x more likely to approve code that
+     follows existing patterns (even bad patterns) than code that
+     introduces better but unfamiliar patterns
+  5. Social loafing: PRs with 3+ required reviewers get less thorough
+     individual reviews than PRs with 1 required reviewer (diffusion
+     of responsibility)
+  6. Peak-end rule: Developers' overall satisfaction with review is
+     determined by their worst review experience and their most recent
+     experience, not the average
+
+  Available data:
+  - 2 years of review data (50,000 PRs) with timestamps, comments,
+    outcomes, and post-merge incident correlation
+  - Developer satisfaction surveys (quarterly, 600 respondents)
+  - Blind review experiment results (100 anonymized PRs)
+  - Focus group transcripts from 8 teams
+
+  Task: Design a behavioral intervention program. For each bias, write:
+  the evidence from your data, the behavioral intervention (nudge,
+  choice architecture, or environmental design), the implementation
+  plan (how to embed the intervention in the review workflow), and the
+  measurement approach (A/B test design to prove the intervention works).
+  Then write the unified "Behavioral Code Review" framework that ties
+  all interventions together, and the ethical considerations (when does
+  nudging become manipulation?).
+
+assertions:
+  - type: llm_judge
+    criteria: "Behavioral interventions are evidence-based — each intervention addresses a specific bias with a specific mechanism (e.g., randomized review order to reduce anchoring, blind review for authority bias, single-reviewer assignment to reduce social loafing), not generic 'educate people about biases'"
+    weight: 0.35
+    description: "Evidence-based interventions"
+  - type: llm_judge
+    criteria: "A/B test designs are rigorous — each intervention has a testable hypothesis, control group, sample size consideration, and success metric. The experiment design accounts for confounding variables and ethical review"
+    weight: 0.35
+    description: "Rigorous A/B test designs"
+  - type: llm_judge
+    criteria: "Ethical framework is thoughtful — distinguishes between nudging (preserving choice) and manipulation, addresses transparency (should developers know they're being nudged?), and sets limits on behavioral interventions in the workplace"
+    weight: 0.30
+    description: "Thoughtful ethical framework"

package/courses/github-pr-review/scenarios/level-5/review-board-strategy.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: review-board-strategy
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Board-level review strategy — present code review as a strategic capability to the board of directors of a public company"
+  tags: [github, pr-review, board, strategy, governance, master]
+
+state: {}
+
+trigger: |
+  You're the CTO of a $3B public company presenting to the board of
+  directors. The board has 3 agenda items related to code review, driven
+  by recent events.
+
+  Agenda Item 1 — Risk governance after a competitor's review failure:
+  A competitor had a catastrophic production failure (48-hour outage,
+  $200M revenue impact) traced to a code change that bypassed review.
+  The board wants assurance that "it can't happen here." They want to
+  understand your change management controls and whether code review
+  is a governance strength or weakness.
+
+  Your data:
+  - 99.7% of production changes go through code review
+  - 0.3% are emergency changes with post-deployment review
+  - No review-related incidents exceeded $500K in the last 3 years
+  - SOC 2, PCI DSS, and SOX compliance are current
+  - Review process is audited quarterly
+
+  Agenda Item 2 — AI strategy for code review:
+  The board read about AI replacing code review in a McKinsey report.
+  They want to know: (a) Should the company invest in AI-powered review?
+  (b) What's the competitive advantage? (c) What are the risks of AI
+  reviewing code that handles $50B in annual transactions?
+
+  Agenda Item 3 — M&A due diligence:
+  The company is acquiring a 200-engineer startup. During due diligence,
+  you discovered the startup has no formal code review process — they
+  rely on pair programming and trust. The board wants to know the
+  integration risk and timeline to bring them to your review standards.
+
+  Task: Prepare the board presentation. For each agenda item, write:
+  the board-ready materials (1-page brief per item), the data
+  visualizations you would present (described in text), the Q&A
+  preparation (likely board questions and answers), and the governance
+  recommendations (what the board should approve or direct). End with
+  a unified strategic narrative connecting all 3 items to the company's
+  competitive position.
+
+assertions:
+  - type: llm_judge
+    criteria: "Risk governance answer is reassuring without being complacent — presents strong controls with data, acknowledges the competitor's failure couldn't 'absolutely never happen' but shows defense-in-depth, and proposes board-level oversight mechanisms (quarterly review health reports)"
+    weight: 0.35
+    description: "Reassuring risk governance"
+  - type: llm_judge
+    criteria: "AI strategy is pragmatic — doesn't over-promise AI capabilities, identifies specific use cases where AI review adds value ($50B transaction context requires human judgment for business logic), proposes a measured adoption approach, and addresses the risk question honestly"
+    weight: 0.35
+    description: "Pragmatic AI strategy"
+  - type: llm_judge
+    criteria: "M&A integration plan is realistic — acknowledges that pair programming has value (not just 'they're doing it wrong'), proposes a phased integration (not day-1 mandate), quantifies the risk timeline, and connects to the AI strategy (AI tools can accelerate integration)"
+    weight: 0.30
+    description: "Realistic M&A integration plan"

package/courses/github-pr-review/scenarios/level-5/review-consulting-engagement.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: review-consulting-engagement
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Lead a review consulting engagement — diagnose and transform a client's broken code review process as an external consultant"
+  tags: [github, pr-review, consulting, transformation, engagement, master]
+
+state: {}
+
+trigger: |
+  You're a senior engineering consultant hired for a 16-week, $250K
+  engagement to transform code review at a 400-engineer fintech company.
+  They've had 5 production incidents in 6 months traced to review
+  failures, lost 2 enterprise customers due to compliance gaps, and
+  their Glassdoor reviews specifically mention "toxic code reviews."
+
+  Client diagnostic findings (Week 1):
+  - 12 teams, 3 GitHub organizations, no consistent review process
+  - Average merge time: 5.2 days (industry benchmark: 1.5 days)
+  - 28% of PRs are abandoned (never merged)
+  - Developer satisfaction with review: 32% (industry benchmark: 70%)
+  - Top reviewer does 40% of all reviews (single point of failure)
+  - No reviewer training program exists
+  - CODEOWNERS files exist but 60% are outdated (point to departed employees)
+  - Branch protection varies: some repos require 0 approvals, payment
+    repos require 4 approvals (both extremes are problematic)
+  - The security team does a "security review gate" that adds 2 weeks
+    to any PR touching auth/payment code
+  - 15% of review comments contain personal attacks or dismissive
+    language (analyzed via NLP on comment history)
+  - No review metrics are tracked or reported
+
+  Client stakeholders:
+  - CTO: "Fix this fast, we can't keep losing customers"
+  - VP Engineering: "My team leads don't see this as their problem"
+  - Head of Security: "If we relax security reviews, we'll get breached"
+  - Engineering Manager (vocal critic): "We tried improving review
+    before. Consultants don't understand our codebase."
+
+  Task: Design the complete consulting engagement. Write: the client
+  diagnostic report (executive summary, findings, risk assessment), the
+  16-week transformation roadmap (phased, with milestones and
+  deliverables each sprint), the quick wins for Week 2-4 (to build
+  credibility), the organizational change management plan (handling
+  resistance from the vocal critic and security team), and the handoff
+  package (what you leave behind so improvements stick after you leave).
+  Include the success metrics and the "after" state you're targeting.
+
+assertions:
+  - type: llm_judge
+    criteria: "Diagnostic is comprehensive and data-driven — quantifies every problem (merge time, satisfaction, abandonment rate), benchmarks against industry, identifies root causes (not just symptoms), and presents findings without blame. The risk assessment connects review failures to business impact ($)"
+    weight: 0.35
+    description: "Comprehensive data-driven diagnostic"
+  - type: llm_judge
+    criteria: "Transformation roadmap is realistic for 16 weeks — quick wins build credibility (Weeks 2-4: fix CODEOWNERS, add basic branch protection, address toxic comments), middle phase tackles process (Weeks 5-10: SLAs, automation, training), final phase embeds sustainability (Weeks 11-16: metrics, governance, handoff)"
+    weight: 0.35
+    description: "Realistic 16-week roadmap"
+  - type: llm_judge
+    criteria: "Change management handles real resistance — addresses the vocal critic by involving them (not overriding), negotiates with security team on risk-based reviews (not just faster reviews), builds team lead ownership, and the handoff package ensures improvements survive the consultant's departure"
+    weight: 0.30
+    description: "Resistance-handling change management"