Amazon Leadership Principles

Apply Amazon's Leadership Principles to product building, feature development, code review, and architecture decisions. Use when building a new product or fe...

Security Scan

This is an instruction-only skill that provides Amazon Leadership Principles guidance and does not request credentials, install software, or perform actions outside its stated purpose.

Purpose & Capability

The name and description match the SKILL.md content: guidance for product/engineering decisions and reviews. No unrelated capabilities or resources are requested.

Instruction Scope

SKILL.md contains only prescriptive guidance, checklists, and templates. It does not instruct the agent to read files, access environment variables, call external endpoints, or execute commands.

Install Mechanism

No install spec and no code files — instruction-only. Nothing will be written to disk or downloaded during install.

Credentials

The skill declares no required environment variables, credentials, or config paths, which is proportional for a guidance-only skill.

Persistence & Privilege

Flags show default behavior (always: false, user-invocable: true). The skill does not request persistent or elevated privileges.

Assessment

This skill is a text-only checklist of Amazon Leadership Principles and appears internally consistent and low-risk. You can install and use it without exposing credentials or allowing disk/network access. As a precaution, review future versions for any added install steps, requested environment variables, or an "always: true" flag before updating, since those would change the security posture.

Amazon Leadership Principles — Product & Engineering

Apply these principles at every decision point. Not all apply to every situation — use judgment.

Pre-Build: Is This Worth Building?

Customer Obsession

• Who is the customer? Name them specifically.
• What is their pain? Quote real complaints, not assumptions.
• Work backwards: write the press release and FAQ BEFORE writing code.
• If you can't articulate why the customer cares in one sentence, stop.

Ownership

• Think long-term. Will this matter in 6 months?
• Don't build something just because it's interesting. Build what's needed.
• You own the outcome, not just the code. If it ships broken, that's on you.

Invent and Simplify

• What's the simplest version that solves the problem?
• Can you solve this with existing tools before building new ones?
• Complexity is a cost. Every abstraction must earn its place.

Are Right, A Lot

• What data supports this direction?
• What's the strongest argument AGAINST building this?
• Seek to disconfirm your hypothesis, not confirm it.

During Build: Execution Standards

Bias for Action

• Ship the smallest useful version first. Perfect is the enemy of shipped.
• Reversible decisions (two-way doors) → decide fast, move on.
• Irreversible decisions (one-way doors) → slow down, get data.

Dive Deep

• Don't hand-wave. Know the numbers: latency, error rates, user counts.
• When something looks wrong, investigate. Don't assume it's fine.
• "It works on my machine" is not a valid test.

Insist on the Highest Standards

• Code must have error handling, not just the happy path.
• Every feature needs: tests, documentation, monitoring.
• Ask: "Would I be comfortable if this was the only thing a customer saw?"

Frugality

• Do more with less. Fewer dependencies, smaller bundles, lower costs.
• Don't gold-plate. Ship the 80% solution, iterate on the 20%.
• Constraints breed resourcefulness. Treat them as features.

Think Big

• Is this a band-aid or a real solution?
• Will this approach scale to 10x the current load?
• What would the ambitious version look like? (Then ship the pragmatic one.)

Code & Architecture Review Checklist

Apply when reviewing code, PRs, or architecture decisions:

1. Customer Impact — Does this change make the customer's life better? How?
2. Simplicity — Is this the simplest solution? Can anything be removed?
3. Ownership — Does the author own the full lifecycle? Tests? Error handling? Monitoring?
4. Dive Deep — Are edge cases handled? What happens when it fails?
5. Highest Standards — Would you ship this to your most important customer today?
6. Bias for Action — Is this blocked by a perfect-is-the-enemy-of-good decision? Ship it.
7. Earn Trust — Is the code honest about its limitations? Are errors surfaced, not swallowed?

PRFAQ Template (Working Backwards)

Before building any significant feature or product, write this first:

PRESS RELEASE (1 paragraph)
- What is it? (one sentence)
- Who is it for?
- What problem does it solve?
- How does the customer benefit?
- Quote from a (hypothetical) customer

FAQ — Customer Questions
1. How does it work?
2. How much does it cost?
3. What if [common objection]?
4. How is this different from [competitor/alternative]?

FAQ — Internal/Technical Questions  
1. How will we measure success?
2. What are the biggest risks?
3. What's the simplest MVP?
4. What does v2 look like?

Anti-Patterns to Call Out

• Building without a customer — "We should build X because it's cool" → Who asked for it?
• Over-engineering — 3 layers of abstraction for a 50-line script → Simplify.
• Ignoring failure modes — "It'll probably work" → What happens when it doesn't?
• Scope creep — "While we're at it, let's also..." → Ship what you started first.
• Vanity metrics — "We have 1000 users!" → How many are active? How many pay?
• Premature scaling — Building for 1M users when you have 10 → Earn the complexity.

When to Apply Each Principle

Phase	Key Principles
Ideation	Customer Obsession, Think Big, Are Right A Lot
Planning	Ownership, Working Backwards (PRFAQ), Invent & Simplify
Building	Bias for Action, Dive Deep, Frugality, Highest Standards
Review	Highest Standards, Earn Trust, Dive Deep
Launch	Customer Obsession, Ownership, Bias for Action
Post-launch	Dive Deep (metrics), Learn and Be Curious, Ownership