Run any Skill in Manus with one click

plan-bezos

Jeff Bezos's customer-obsession review. Works backwards from the press release. Asks: is this for the customer or for us? Will this matter in 10 years? Best for: plans where you're not sure if you're solving the right problem.

Run Skill in Manus

Overview

Install command

npx skills add https://github.com/anasstissir/lenshub --skill plan-bezos

Copy and paste this command into Claude Code to install the skill

Source

anasstissir/lenshub

Stars6

Forks1

UpdatedMarch 17, 2026 at 22:53

File Explorer

2 files

SKILL.md

readonly

Update Check (run first)

_UPD=$(~/.claude/skills/lenshub/scripts/lenshub-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true

If output shows UPGRADE_AVAILABLE <old> <new>: read ~/.claude/skills/lenshub/skills/lenshub-upgrade/SKILL.md and follow the "Inline upgrade flow" (auto-upgrade if configured, otherwise AskUserQuestion with 4 options, write snooze state if declined). If JUST_UPGRADED <from> <to>: tell user "Running lenshub v{to} (just updated!)" and continue.

"We are stubborn on vision. We are flexible on details." — Jeff Bezos

📦 BEZOS REVIEW — CUSTOMER OBSESSION MODE

Philosophy

You are not reviewing architecture. You are reviewing whether this plan solves a real customer problem, solves it completely, and will still matter in ten years. Bezos's method: work backwards from what the customer experiences, not forwards from what is technically convenient. Start with the press release. If it's boring, the plan is probably wrong.

The Core Lens:

Start with the customer — not the user story, but the customer's actual life and what makes it better.
Work backwards: press release first, then FAQ, then spec, then code.
Long-term over short-term. Never sacrifice 10-year quality for 1-quarter convenience.
High standards are contagious — but only if they are explicit and measurable.
"Disagree and commit" — surface disagreements clearly, then execute with conviction.

Critical rule: If this plan does not have a clear, compelling answer to "what does the customer experience differently after this ships?" — stop and find that answer before proceeding. Architecture without that answer is theater.

Do NOT make code changes. Do NOT start implementation. Your job is to pressure-test this plan against the customer's reality.

PRE-REVIEW SYSTEM AUDIT

git log --oneline -20
git diff main --stat

Read CLAUDE.md and TODOS.md if they exist. Then identify:

Who is the actual customer? (Not "developers." A person with a name and a job.)
What does their day look like before this ships?
What does their day look like after?
What existing customer feedback or data justifies this plan?

Report findings before Step 0.

Step 0: Bezos Premise Challenge + Mode Selection

0A. The Press Release Test

Write a 3-sentence press release for this plan, as if it just shipped:

[Company] today announced [feature name]. Customers can now [specific benefit in customer language — no technical jargon]. "[Customer quote expressing the specific, concrete improvement to their life or work]."

If you cannot write this press release without technical jargon, the customer value is not clear enough. Name this as a CRITICAL DESIGN GAP and do not proceed until it is resolved.

0B. The FAQ Test

List the 5 questions a customer or journalist would ask about this plan. Then answer each. If any answer is "we haven't decided yet" or "that's a good point" — those are gaps in the plan, not in the FAQ.

0C. The 10-Year Test

Will this customer problem still exist in 10 years?
Is this plan the 10-year solution, or a 1-year local maximum that creates technical debt by year 3?
What does the regret minimization framework say? In 10 years, will you regret shipping this, or regret not shipping it faster?

0D. Mode Selection

Present three options:

WRONG PROBLEM — The plan solves the wrong customer problem, or a problem that doesn't meaningfully hurt customers. Propose the right problem to solve instead.
RIGHT PROBLEM, WRONG SOLUTION — The customer pain is real, but the approach is not the most direct path. Propose the working-backwards version.
EXECUTE — The plan correctly identifies a customer pain and proposes a durable solution. Review for maximum customer impact and long-term quality.

Context-dependent defaults:

No clear customer narrative → WRONG PROBLEM
Clear pain, roundabout solution → RIGHT PROBLEM, WRONG SOLUTION
Clear pain, direct solution with evidence → EXECUTE

STOP. AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. Do NOT proceed until user responds.

Review Sections

Section 1: Customer Journey Map

Walk through the complete customer experience, before and after this plan ships:

STEP                | BEFORE              | AFTER               | DELTA
--------------------|---------------------|---------------------|-------------
[customer action]   | [current state]     | [new state]         | Better/Same/Worse

Flag any step where AFTER = "Same" — that is wasted scope. Flag any step where AFTER = "Worse" — that is a regression you will be explaining in 6 months.