Menu
Applying Amazon's raise-the-bar principle to every code review. What reviewers look for — clarity, correctness, design, reuse, operational readiness. "Ship It" means the change raises or maintains the quality bar.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | Raising the Bar in Code Review |
| description | Applying Amazon's raise-the-bar principle to every code review. What reviewers look for — clarity, correctness, design, reuse, operational readiness. "Ship It" means the change raises or maintains the quality bar. |
| leadership_principles | ["Insist on the Highest Standards","Earn Trust","Learn and Be Curious"] |
Raising the Bar in Code Review applies Amazon's raise-the-bar principle to software changes. This is not a special role or a designated reviewer. It is the expected behavior of every engineer who reviews code: protect the current quality standard and look for opportunities to improve it.
No code should ship to production without at least one meaningful review ("Ship It"). This is not a formality — the reviewer actively evaluates code against five dimensions: clarity, correctness, design, reuse, and operational readiness. A reviewer who rubber-stamps code is lowering the bar.
The system works because it creates a forcing function: every engineer knows their code will be evaluated against the highest standards, so they write to that standard from the beginning.
Load agents/code-review-bar-raiser.md for code review. Use it to evaluate clarity, correctness, design quality, reuse, testing, and operational readiness before approving a change.
Amazon's raise-the-bar principle is simple: important decisions should improve the standard over time, not merely avoid obvious failure. The principle appears in multiple areas — hiring, documents, design, operations, and technical reviews.
This skill adapts that principle to code review by making the expected reviewer behavior explicit for agents and teams using this library.
The review exists to protect the codebase from gradual quality erosion. Delivery pressure must never become the measure of review quality. An approval that lowers the bar is a failure of the process.
Before marking a PR for review, the author must:
Reviewers evaluate every PR against these dimensions:
"Can a new team member understand this code without additional context?"
"Does this code do what it claims to do, in all cases?"
"Is the architecture appropriate for the problem and the system?"
"Does this leverage existing code and create reusable components?"
"Can we operate this code in production at 3 AM?"
Author submits PR
│
▼
Reviewer evaluates the change as a quality gate
│
▼
First pass: Architecture and design concerns
│
├── Major concerns? → Block with explanation, schedule discussion
│
└── No major concerns → Detailed review of all 5 dimensions
│
▼
Comments posted (categorized by severity)
│
▼
Author addresses feedback
│
▼
Reviewer re-reviews changes
│
├── Still has issues → Another round (max 2-3 rounds)
│
└── Satisfied → "Ship It" ✅
Reviewers categorize their feedback:
| Prefix | Meaning | Author Action |
|---|---|---|
[BLOCKING] | Must fix before merge. Correctness or operational issue. | Fix required. |
[IMPORTANT] | Should fix. Design or clarity issue. | Fix or explain why not. |
[NIT] | Minor style or preference. Nice to have. | Fix if easy, skip if not. |
[QUESTION] | Clarification needed. Might reveal an issue. | Answer in comment or code. |
[PRAISE] | Particularly good code. Worth calling out. | Enjoy. Keep doing this. |
┌─────────────────────────────────────────────────────────┐
│ "Ship It" means: │
│ │
│ ✅ I would be comfortable being paged at 3 AM │
│ for an issue in this code │
│ ✅ I can explain what this code does to someone who │
│ hasn't seen it │
│ ✅ The tests give me confidence the code is correct │
│ ✅ The operational instrumentation will detect problems │
│ ✅ This code raises (or at minimum maintains) our bar │
│ │
│ "Ship It" does NOT mean: │
│ │
│ ❌ This code is perfect │
│ ❌ I would have written it exactly this way │
│ ❌ There are zero possible improvements │
│ ❌ I understand every line in detail │
└─────────────────────────────────────────────────────────┘
| Mechanism | What It Enforces | How |
|---|---|---|
| Branch protection rules | No merge without meaningful review | GitHub/GitLab configured to require review approval |
| Reviewer calibration | Reviewers apply a consistent standard | Review past reviews, compare decisions, and align expectations |
| Review comment templates | Structured feedback | IDE/tool integration prompts for severity and category |
| Quarterly review calibration | Consistent standards across reviewers | Reviewers assess the same PR independently, then compare notes |
| Rationalization | Why It's Wrong | What To Do Instead |
|---|---|---|
| "It's a small change, it doesn't need a real review" | Small changes break production all the time. A one-line config change caused one of Amazon's largest outages. | Every change gets the same process. Small changes still deserve proper review. No shortcuts. |
| "I trust the author, just Ship It" | Trust is earned through evidence, not assumed. Even expert engineers make mistakes. The review protects them too. | Read the code. Check the tests. Verify the operational readiness. Trust and verify. |
| "We need to ship, let's merge and fix later" | "Fix later" means "never fix" in 80% of cases. The tech debt accumulates. The bar lowers for the next PR. | Split the PR if it's too large. Schedule a discussion if there's disagreement. Don't compromise the bar. |
| "The reviewer is being too picky, this is just style" | What looks like style is often clarity. Code is read 10x more than it's written. Readability is not a preference—it's an operational requirement. | If you disagree with a NIT, say so. But if the feedback is [IMPORTANT] or [BLOCKING], the reviewer has seen something you haven't. Listen. |
| "Only senior engineers can do this kind of review" | Treating quality as a specialist role creates bottlenecks and weakens ownership. Every reviewer is responsible for the bar. | Teach the review standard explicitly. Pair newer reviewers with experienced engineers. Calibrate on real PRs. |
After establishing the review process, verify:
After review findings are resolved, check whether any finding represents a recurring pattern (same finding appears across 2+ reviews, or the reviewer explicitly flags "this keeps happening"). If a recurring pattern is identified:
skills/implementation-memory/SKILL.md.docs/implementation-memory.md.If no recurring pattern is identified, skip this step silently. This keeps the memory focused on durable, cross-cutting lessons rather than one-off feedback.
Blameless post-incident analysis focused on timeline, 5 Whys, mechanisms over people, and concrete action items with owners.
Internal /build flow mechanism that maintains fixed-size procedural memory of durable implementation-quality lessons.
Review a technical design before specs or implementation. Evaluate problem clarity, requirements, alternatives, trade-offs, architecture, dependency behavior, security, operations, cost, testability, and simplicity.
Bridge between an approved Design Document and code. Decompose the system-level blueprint into N vertical specs (requirements → design → tasks), each independently deliverable. Fail fast by ordering hardest-first. Execute wave-by-wave with approval gates.
Stage 4 of Working Backwards: Write the PR/FAQ — a press release announcing the product as if it already exists, plus a comprehensive FAQ addressing hard questions. This is the core Amazon mechanism that forces clarity, customer-centric thinking, and rigorous pre-mortems before any code is written.
Reverse-engineer an existing project to produce a Design Doc, API contracts, and a Threat Model anchored in the real code, IaC, and observability. Run once per project. Output anchors all subsequent /spec and /build invocations.