菜单
Write a PR/FAQ for a product idea using Amazon's Working Backwards process. Start from the customer press release and work backward to what needs to be built. Use when validating whether an idea is worth building before committing to a spec.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Instruments a pull request with Amplitude analytics that conform to the project's existing taxonomy. Reads the tracking plan via the Amplitude MCP server (events, properties, naming conventions), analyzes the PR diff to find the few user actions genuinely worth tracking, detects the codebase's SDK and tracking patterns, and adds instrumentation that matches both. Optionally (opt-in) stages new events and properties on an Amplitude tracking-plan branch for data-governance review. Use when asked to "instrument this PR", "add analytics to this change", "add tracking", "add Amplitude events", "instrument this feature", or "what should I track here".
Diagnoses product health by cross-referencing Amplitude analytics (dashboards, charts, funnels, feedback, AI agent analytics), optionally Datadog (errors, latency, stack traces), and optionally Slack (qualitative feedback, bug reports, feature requests). Identifies what's broken, what's working, and what to do about it — with root causes, not just symptoms. Use when asked to "diagnose my product", "what's going on", "product health check", "what's broken", "where are users struggling", "give me a product diagnosis", or "what should I focus on".
Use this skill whenever a user wants to improve existing pages on their website to get cited more by AI models — whether they say "our pages aren't getting cited", "improve this page for AI visibility", "which of our pages should we update", "make this article more cite-worthy", "our competitors are getting cited instead of us", "update our content for AI search", or any variation where the goal is improving an existing asset rather than creating something new. This skill pulls owned pages from AI Visibility, identifies which ones have citation potential but are underperforming, compares them against the external pages that are winning citations on the same topics, and produces section-level rewrites or a full-page update — then pushes the revision to the CMS as a draft. Trigger even if the user just says "help me get cited more" or "why is [competitor] getting cited instead of us".
Use this skill whenever a user wants to win AI citations on prompts that competitors currently dominate — whether they say "competitors are getting cited instead of us", "we're losing on these prompts", "how do I outrank [competitor] in AI answers", "find prompts where we should be winning", "create content to beat [competitor]", or any variation where the goal is capturing AI share on prompts a competitor currently owns. This skill pulls competitor visibility data from AI Visibility, identifies the specific prompts where competitors win and Amplitude is absent, clusters them by intent, and produces targeted comparison pages, alternatives content, or rebuttal assets — then pushes drafts to CMS. Trigger on any mention of competitor, prompt hijack, outrank, or "why is [competitor] getting cited instead of us".
Use this skill whenever a user wants to turn AI Visibility data into published content — whether they say "find content gaps", "what should we write about", "which topics have low visibility", "help me get cited by AI models", "create a blog post from our AI Visibility gaps", "we're losing to competitors on these prompts", or any variation where they want to go from AI visibility weakness to a draft article, landing page, or FAQ. This skill connects directly to Amplitude AI Visibility data (topics, prompts, visibility scores, citations, competitor data, full LLM responses and sources) and produces a publish-ready content brief plus full article draft. If the user mentions CMS (WordPress, Webflow, Contentful, Sanity, HubSpot, Ghost, Shopify), also trigger this skill to push the draft directly. Trigger even if they just say something vague like "what content should we create?" in an AI Visibility context.
Use this skill whenever a user wants to test content variants before publishing to find which one will get cited most by AI models — whether they say "which version of this content will perform better", "test this article before we publish", "simulate how AI will respond to this content", "which angle should we use", "generate content variants and pick the winner", "run a simulation before publishing", or any variation where the goal is data-driven content selection rather than gut-feel publishing. This skill takes an identified content opportunity, generates 2–3 distinct variants with different angles or structures, scores them against actual AI model responses from AI Visibility, references the Simulate Changes feature for pre-publish validation, and produces a clear recommendation on which variant to publish — then pushes the winner to CMS. Trigger on any mention of "simulate", "test variants", "which performs better", "A/B content", or "before we publish".
| name | amazon-working-backwards |
| description | Write a PR/FAQ for a product idea using Amazon's Working Backwards process. Start from the customer press release and work backward to what needs to be built. Use when validating whether an idea is worth building before committing to a spec. |
| suggest_when | User has a product idea and wants to pressure-test it, says "PR/FAQ", "working backwards", "write the press release first", "is this worth building", or wants to crystallize a vague idea into a compelling customer narrative before speccing it out. |
Start from the customer. Write the press release before you write the code.
You have an idea — maybe a new product, a major feature, or a strategic bet. Before you invest in specs, designs, and engineering, this skill forces you to articulate what you're building, who it's for, and why it matters — all from the customer's perspective. If you can't write a compelling press release, the idea isn't ready.
You are an experienced product leader applying Amazon's Working Backwards process.
Here is the product idea, feature concept, or strategic bet:
<context>
$ARGUMENTS
</context>
> If the above is blank, ask the user: "{{PASTE YOUR IDEA — ROUGH NOTES, SLACK THREADS, BRAINSTORM OUTPUT, OR A ONE-LINER}}"
Write a PR/FAQ document using this structure:
### PRESS RELEASE
**Heading:** [Product name] — a clear, customer-facing name (not an internal codename).
**Subheading:** One sentence describing who the customer is and what benefit they get.
**Date & City:** [Plausible future launch date and location]
**Opening Paragraph:** Summarize the product and its benefit in 3-4 sentences. Lead with the customer problem, then the solution. Write as if this is a real press release going to the public — no internal jargon.
**Problem Paragraph:** Describe the customer's current pain in vivid, specific terms. What are they doing today? Why does it suck? Use concrete scenarios, not abstract statements. The reader should feel the pain.
**Solution Paragraph:** Describe how the product solves the problem. Focus on the customer experience, not the technology. What can they do now that they couldn't before? How does their life or workflow change?
**Quote from Company Leader:** A quote from a VP or CEO explaining why this matters strategically. This forces you to articulate the "why now" and the company's point of view.
**How It Works:** 3-5 sentences describing the customer experience. Walk through the happy path in simple terms. A customer should be able to read this and understand what they'd actually do.
**Quote from a Customer:** A fictional but realistic quote from a target customer describing the benefit in their own words. This forces you to think about what success sounds like from the outside.
**Call to Action:** How customers can get started. One sentence.
### FREQUENTLY ASKED QUESTIONS
**External FAQs** (customer-facing — 4-6 questions):
Answer the questions a customer would ask after reading the press release. Cover: pricing/availability, how it compares to alternatives, who it's for (and who it's NOT for), data/privacy, and the "yeah but..." objections.
**Internal FAQs** (team-facing — 4-6 questions):
Answer the hard questions your leadership team, engineers, and stakeholders would ask. Cover: market size and business case, technical feasibility and timeline, dependencies and risks, why now vs. later, what we're NOT building, and how we'll measure success.
### WORKING BACKWARDS ASSESSMENT
After writing the PR/FAQ, step back and evaluate:
1. **Clarity test** — Can a non-technical person read the press release and understand what the product does? If not, the idea is still fuzzy.
2. **Differentiation test** — Could a competitor's product fill in the blanks? If yes, the unique value isn't sharp enough.
3. **Customer test** — Would the fictional customer actually say that quote? If it sounds forced, the benefit isn't real enough.
4. **Internal FAQ test** — Are the internal answers convincing? Flag any where you're hand-waving — those are your biggest risks.
5. **Kill test** — Based on this PR/FAQ, should this idea move forward, be reworked, or be killed? Make a call.
Rules:
- Write the press release at a 6th-grade reading level. If you need jargon, the idea isn't clear enough.
- The problem paragraph is the most important section. If the pain isn't vivid and specific, everything downstream will be vague.
- Don't hedge. "This might help some users sometimes" is a sign the idea isn't ready. Commit to a strong claim and let the FAQs address the nuance.
- Internal FAQs should include at least one question you don't have a good answer to yet — that's the honest part.
- The assessment should be brutally honest. A PR/FAQ that reveals a weak idea is more valuable than one that papers over the cracks.