Menu
Meta-skill for navigating and applying the complete skills library. Routing flow chart, core operating behaviors, and skill discovery logic.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.
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.
| name | Using Amazon Skills |
| description | Meta-skill for navigating and applying the complete skills library. Routing flow chart, core operating behaviors, and skill discovery logic. |
| leadership_principles | ["Customer Obsession","Ownership","Insist on the Highest Standards","Bias for Action"] |
This is the meta-skill: it describes how to navigate, select, and combine the other skills in this library. Use this when you're unsure which skill applies, when you need to understand how skills interact, or when you want to establish core operating behaviors that underpin all other skills. Think of this as the operating system on which individual skills run.
Amazon doesn't have a single monolithic process—it has a collection of mechanisms, principles, and practices that compose together. The power comes from the composition: progressive deployment is effective because pipelines enforce safety gates, which work because alarms are set up correctly, which matter because the team operates the service they build. Remove one piece and the others weaken. This meta-skill helps you see the whole system.
Start → Working Backwards (define what customer needs)
→ Dependency Management (if external/system dependencies exist)
→ Feature Flag Lifecycle (if controlled exposure or kill switch is needed)
→ Operational Excellence (operational signals and runbooks)
→ Design Document (technical approach)
→ API Contract First (define interfaces)
→ Infrastructure as Code (define resources)
→ Operational Excellence (set up monitoring)
→ Progressive Deployment (ship safely)
Code change → Code Review Bar Raising (quality)
→ Test-Driven Development (coverage)
→ Pipeline Safety (automated gates)
→ Progressive Deployment (ship it)
Ready to deploy → Feature Flag Lifecycle (if a flag gates release)
→ Pipeline Safety (gates passing?)
→ Progressive Deployment (staged rollout)
→ Operational Excellence (monitoring ready?)
→ Operational Readiness Review (prepared to launch?)
Incident → Correction of Errors (learn from it)
→ Mechanism Creation (prevent recurrence)
→ Metrics Review (track improvement)
Improvement → Metrics Review (identify gaps and measure current state)
→ Mechanism Creation (automate improvements)
These behaviors underpin all skills and should be followed regardless of which specific skill you're applying:
Every decision starts with: "What's the customer impact?" Not "what's easiest for us" or "what's technically elegant." The customer's experience is the measure of success.
When someone says "I think..." ask "What does the data say?" Opinions are hypotheses. Data is evidence. Make decisions on evidence.
Most decisions are reversible (Type 2). Make them quickly. Use progressive deployment, feature flags, and rollback to make decisions reversible. Reserve extensive deliberation for irreversible decisions (Type 1).
Whenever you find yourself saying "we should..." or "we need to remember to...", stop and build a mechanism. Automate the safeguard. Remove the human from the critical path.
You own the entire experience, not just your component. If a customer problem crosses team boundaries, you own driving it to resolution even if the fix is in someone else's code. You can't say "that's not my team's service."
What you accept becomes the new normal. If you accept flaky tests, you'll get more flaky tests. If you accept missing alarms, you'll get more services without alarms. Hold the bar on everything.
The simplest solution that meets requirements is almost always the best. Complexity is not a sign of quality—it's a sign of insufficient thinking. Every line of code is a liability.
Write things down. Written documents force clarity that verbal discussions don't. Ambiguity hides in conversation but is exposed on paper.
Every customer-facing surface is an API. The API is the contract; everything behind it is private implementation. Design and ship the API before any of its clients.
A client is anything that consumes an API: a web UI, a mobile app, a CLI, an SDK, an MCP server, an AI agent, another internal service, a partner integration, a batch job. They are all clients of the same API and follow the same rules. The word "frontend" is too narrow — use "client" or "API consumer".
The API may be REST, GraphQL, gRPC, an async / event surface, a data contract, an MCP tool surface, an agent tool definition, a webhook, a CLI, or an SDK. The protocol does not change the rule: the contract is designed, frozen, and shipped before the clients that depend on it.
Pick the right standard for the protocol — OpenAPI is not the universal answer. Use OpenAPI for REST, GraphQL SDL for GraphQL, .proto for gRPC, AsyncAPI (with JSON Schema / Avro / Protobuf payloads) for async events, ODCS for data contracts, MCP manifest for MCP tools, provider-native tool spec for AI agents. See skills/api-contract-first/SKILL.md for the full mapping.
If a client needs behavior the API doesn't expose, evolve the API. Do not embed logic in the client to work around a missing API capability. Doing so leaks implementation details into the client and makes the API impossible to evolve later.
This rule is the direct descendant of Amazon's 2002 API Mandate: every team exposes its functionality only through APIs, and there is no other way to consume what another team built.
Alongside skills, this repository carries a catalog of architectural patterns in patterns/. Patterns are different in nature from skills:
A pattern, once adopted, changes how almost every skill is applied — partition keys leak into APIs, deploy strategy changes, observability changes, on-call changes. Each patterns/<name>/PATTERN.md declares its applicability in applies_when: and carries a Skill Impact Map listing exactly which skills change.
How patterns enter design (Amazon-style): patterns are not a separate mandatory checklist. They feed Alternatives Considered in the Design Doc. When generating alternatives, read patterns/INDEX.md (lightweight catalog) and identify any pattern whose applies_when criteria plausibly match the workload. Only then load the full patterns/<name>/PATTERN.md for matching patterns. That pattern becomes a real alternative, evaluated with data and trade-offs against the other options. If the user (or the WB output) is asking for a specific pattern (e.g., "implement cell-based"), the pattern is the chosen approach and alternatives are explored within it. Patterns that don't fit don't appear — quality of thought, not quantity of dismissals.
When a pattern is adopted, its Skill Impact Map becomes a constraint on the rest of the design and on the specs that follow.
The Build Like Amazon flow is designed for change of every size — from a one-line fix to a brand-new product. The full ceremony (/wb → /design → /spec → /build) is appropriate for a small fraction of changes; applying it everywhere is over-engineering and makes the agent feel slow.
The agent's job is to choose the right ceremony level automatically — never the user's job. The user describes the change; the agent classifies and proposes 2-3 concrete options when there is genuine ambiguity. The user picks an outcome (time, scope, traceability), not a process step.
| Change size | Examples | Recommended path | Artifacts produced |
|---|---|---|---|
| Trivial (< 2h, no customer impact) | Typo fix, dependency bump, comment cleanup, internal helper rename, dev-only logging tweak | Direct to code with Code Quality Bar from incremental-implementation. No spec, no Design Doc, no PR/FAQ. | Code + tests |
| Small (2h-1d, customer-facing but local) | Add a button, change copy, add a field to an existing API response (additive, backward-compatible), add an alarm, fix a known bug with clear root cause | Direct to code OR a single lightweight spec without a separate Design Doc. Apply TDD + operational-code + Code Quality Bar. | Code + tests, optionally specs/<slice>/tasks.md |
| Medium (1d-1wk, feature in existing product) | New endpoint with new logic, new screen with new interactions, integrating a new external dependency, adding a feature flag and rolling out a new behavior | /spec (anchored on existing code or a reverse-engineered design — see /onboard) → /build. No /wb; the customer is already known. Mini design section if architectural decisions arise. | Full spec trio + code + tests |
| Large (1wk+, feature changing architecture or new service) | New service, new public API surface, new pattern adoption (e.g., move to cell-based), schema migration, multi-region rollout, security model change | Full flow: /wb (or 5CQ if customer is known) → /design (Design Doc + API Contract + Threat Model + Review) → /spec per slice → /build | Full flow artifacts |
| New product (months, novel customer value) | A new product, a new business line, a major rewrite | Full /wb cycle: /listen → /define → /invent → /refine → /test-idea → /design → ... | Full flow artifacts |
docs/design/, docs/working-backwards/) or an unstructured project? Affects which path is available, not which is appropriate.The agent decides silently and proceeds when the right level is unambiguous. It asks only when:
/build invoked but no specs/ exists — see Step 0 in the command files)When asking, present 2-3 options framed by outcome, not by process: time, scope, traceability. Names like "Tier 1" or "Spec-Driven Implementation" do not appear in the question to the user.
/wb//listen//define//invent//refine//test-idea): the ladder above maps directly onto the canonical flow. Do not infer brownfield context from existing code./onboard first — it reverse-engineers a Design Doc, API Contracts, and Threat Model from the existing code so subsequent specs are anchored in reality. See skills/brownfield-discovery/SKILL.md.These two modes are mutually exclusive per invocation. The trigger (which command was invoked, which artifacts exist) decides which mode applies.
Before answering any of the questions below, check repo state:
/wb, /listen, /define, /invent, /refine, /test-idea → greenfield in progress. Do not infer brownfield context. Skip this rule./build and specs/ exists → execute as normal. Skip this rule.docs/design/, docs/working-backwards/):
/onboard./onboard as one of the options. Use AskUserQuestion:
[A] Run
/onboardfirst (~15-30min) to reverse-engineer the project. All subsequent specs use these as anchors. Recommended. [B] Skip onboarding and proceed without it. The agent will infer context per-change (slower, may miss constraints). [C] Cancel.
If /onboard was previously run (artifacts in docs/design/<service>/ with the REVERSE-ENGINEERED banner), do not re-run unless the project has drifted significantly. Use those artifacts as the anchor exactly like canonical Design Doc artifacts.
When facing a situation, ask yourself:
What phase am I in?
What's the risk?
patterns/INDEX.md while generating alternatives in the design doc; load full PATTERN.md for any whose criteria matchWhat's the scale?
Level 1 — Foundational: Monitoring exists, deployments are automated, on-call rotation works Level 2 — Practiced: Pipeline has safety gates, progressive deployment enforced, metrics are reviewed regularly Level 3 — Advanced: COE process produces mechanisms, metrics drive decisions, feature flags enable safe experimentation Level 4 — Excellent: All skills composing together seamlessly, team rarely gets paged, deployment velocity is high, learning is continuous
| Intention | Mechanism |
|---|---|
| "The team will follow the skills" | Skills referenced in design reviews, ORRs, and code reviews as checklists |
| "We'll remember to use the right skill" | IDE/tool integration that suggests relevant skills based on context |
| "New hires will learn the skills" | Onboarding checklist includes reading specific skills. Shadowing requirements enforced |
| "We'll maintain high standards" | Bar raisers in design review, code review, and operational review enforce standards |
| What They Say | Why It's Wrong | What To Do Instead |
|---|---|---|
| "We're too small for all this process" | Small teams have fewer people to catch mistakes. Process compensates for fewer eyeballs | Start with the highest-impact skills (Pipeline Safety, Operational Excellence) and add incrementally |
| "We're moving too fast to follow all these" | You're moving too fast to NOT follow these. Speed without safety leads to incidents that slow you down more | These skills enable speed by giving you confidence. Fast and safe, not fast or safe |
| "This is too Amazon-specific" | The principles are universal. Rename them if the terminology bothers you, but don't skip them | Adapt the language to your culture. Keep the mechanisms |
| "We'll adopt these later when we're bigger" | Habits set early compound. Bad habits set early also compound | Start simple, grow with your team. Perfect is the enemy of good |