build-like-amazon-agent-skills

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.

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.

Writing a technical design document that translates a Working Backwards output into a concrete, reviewable engineering plan with architecture, trade-offs, cost estimation, and operational concerns.

Meta-skill for navigating and applying the complete skills library. Routing flow chart, core operating behaviors, and skill discovery logic.

Writing code with built-in observability from day one. Structured logging (JSON), metrics emission (latency p50/p99, error rates), alarm-ready code, request tracing, graceful degradation.

Red-Green-Refactor cycle with Amazon's test pyramid (80% unit, 15% integration, 5% e2e). Coverage gates, DAMP over DRY in tests, canary tests in production.

Reviewing operational and business metrics for continuous improvement, trend analysis, and proactive issue detection.

Dashboards, alarms, and runbooks that make a service operable. Covers latency, error rate, availability, throughput, and severity-based alarming.

The ORR process — a self-assessment checklist covering monitoring, alarming, runbooks, on-call, scaling, security, deployment safety, cost, and dependencies. Must pass before launch.

CI/CD pipeline safety with automated gates, deployment blockers, alarm checks, and one-click rollback.

Deploy changes incrementally through expanding blast radius stages with bake time and automatic rollback on alarm.

Implementing features in thin vertical slices that each deliver value independently. Feature flags, safe defaults, rollback-friendly changes. Never a big-bang deployment.

CDK/CloudFormation design principles for immutable infrastructure, environment parity, least privilege, tagging strategy, and cost optimization. Infrastructure is code—it deserves the same rigor as application code.

Turning lessons learned into automated mechanisms that prevent recurrence of problems.

Designing APIs contract-first with backward compatibility guarantees, clear versioning strategy, error semantics, idempotency, and pagination. The API is a promise—never break existing clients.

Managing external dependencies safely with circuit breakers, timeouts, retries with exponential backoff, bulkhead pattern, graceful degradation, and dependency isolation.

Complete lifecycle of feature flags from creation through gradual rollout to cleanup, including kill switches and A/B testing.

Security threat modeling using STRIDE methodology adapted for cloud services. Covers data classification, IAM boundaries, encryption requirements, blast radius analysis, and systematic identification of attack vectors before code is written.

Stage 2 of Working Backwards: Articulate the customer's problem or opportunity with precision, using data to quantify impact and framing it in the customer's language — not engineering jargon.

Stage 3 of Working Backwards: Generate multiple solution approaches, classify decisions as one-way vs two-way doors, evaluate alternatives against customer benefit and feasibility, and select the recommended solution with clear rationale.

Stage 1 of Working Backwards: Identify who the customer is and gather deep insights about their current experience, pain points, and unmet needs through systematic observation and data collection.

Stage 5 of Working Backwards: Define how success will be measured using input and output metrics, set specific numeric targets, design experiments to validate assumptions, and plan iteration cycles based on data feedback.

Entry point for developing new products, features, or initiatives using Amazon's Working Backwards process. Orchestrates 5 stages from customer insight to measurable success, starting with the 5 Customer Questions as a lightweight on-ramp before committing to a full PR/FAQ.