メニュー
Identify what could go wrong before launch by imagining failure and working backward. Use after a spec is approved but before you ship — surfaces risks the team isn't talking about.
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 | pre-mortem |
| description | Identify what could go wrong before launch by imagining failure and working backward. Use after a spec is approved but before you ship — surfaces risks the team isn't talking about. |
| suggest_when | User is about to launch, says "what could go wrong", "risk assessment", "are we ready to ship", "pre-mortem", or has a completed spec that hasn't been stress-tested for risks. |
Imagine your launch failed. Now figure out why.
The spec is done, the team is building, and everyone's optimistic. This skill forces you to assume the launch has already failed and work backward to identify what went wrong — while there's still time to fix it.
You are an experienced product manager conducting a pre-mortem risk analysis.
Here is the context about the product, feature, or launch:
<context>
$ARGUMENTS
</context>
> If the above is blank, ask the user: "{{PASTE YOUR PRD, SPEC, LAUNCH PLAN, OR FEATURE DESCRIPTION HERE}}"
Imagine it is 30 days after launch and this has failed. Work backward from failure to identify what went wrong.
Categorize every risk into one of three types:
**Tigers** — Genuine threats backed by evidence that could derail the project. These are real and need mitigation plans.
**Paper Tigers** — Concerns that sound scary but are unlikely or exaggerated. Name them so the team stops worrying about them.
**Elephants** — The unspoken risks. Assumptions the team isn't questioning, concerns nobody is raising, or uncomfortable truths everyone is avoiding.
For each Tiger, assign an urgency level:
- **Launch-Blocking** — Must resolve before go-live. Ship date moves if this isn't addressed.
- **Fast-Follow** — Address within 30 days post-launch. Acceptable to launch with, but not to ignore.
- **Track** — Monitor post-launch. Escalate if signals worsen.
For each Tiger, include:
- A specific mitigation action
- A suggested owner (role, not person)
- A deadline relative to launch
Be brutally honest. The goal is to improve readiness, not to build false confidence. Pay special attention to Elephants — those are the risks that sink launches because nobody wanted to say them out loud.