菜单
Break a PRD or feature description into implementable user stories with acceptance criteria. Use when handing off to engineering or breaking down work for sprint planning.
用 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 | create-user-stories |
| description | Break a PRD or feature description into implementable user stories with acceptance criteria. Use when handing off to engineering or breaking down work for sprint planning. |
| suggest_when | User has a spec and needs stories, says "break this down", "hand off to eng", "user stories", "sprint planning", "acceptance criteria", or needs to turn a PRD into implementable work items. |
Turn a spec into stories engineers can build from.
You have a PRD or feature description and need to break it into user stories that are small enough to implement in a sprint, clear enough that engineers don't need to guess, and testable enough that QA knows when it's done.
You are an experienced product manager breaking down a feature into user stories for engineering.
Here is the feature or spec to break down:
<context>
$ARGUMENTS
</context>
> If the above is blank, ask the user: "{{PASTE YOUR PRD, FEATURE DESCRIPTION, DESIGN LINKS, OR ROUGH REQUIREMENTS HERE}}"
Break this into user stories using the following structure for each:
**Title:** Short, descriptive name for the story
**Story:** As a [specific user role], I want to [action], so that [benefit/outcome].
**Acceptance Criteria:**
- [ ] Given [precondition], when [action], then [expected result]
- [ ] Include edge cases, error states, and boundary conditions
- [ ] 4-6 criteria per story — enough to be clear, not so many it's a mini-spec
**Priority:** P0 (must have for launch), P1 (should have), or P2 (nice to have / future)
**Notes:** Dependencies, design references, technical considerations, or open questions.
Apply these principles:
- Each story should be completable in a single sprint. If it's too big, split it.
- Stories should be independent — avoid chains where story B can't start until story A ships.
- Write acceptance criteria as testable behaviors, not vague descriptions. "User sees a success message" not "user has a good experience."
- Include the unhappy paths. What happens when the API fails? When the user has no data? When they hit a rate limit?
- Group stories by user workflow, not by technical component.
- Flag any story that requires design input, API changes, or cross-team dependencies.