菜单
Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Deeply explore a live app feature or a single mapped sub-feature and capture grounded evidence for downstream planning in `docs/qa/exploration-report.md` or a scoped file under `docs/qa/exploration/`. Use after the requested scope is already known, especially after `map-feature-scope` has identified bounded sub-features for a large feature. This skill owns observed product evidence and blockers for the scoped area; it does not perform feature decomposition, frame exploratory charters, prioritize risks, or write coverage plans.
Quickly map a broad product feature into concrete sub-features before deep exploration begins. Use when a requested feature may span multiple routes, tabs, overlays, roles, or primary interactive surfaces and the agent needs to identify bounded exploration units, shared state, and blockers before spawning parallel browser subagents. This skill owns `docs/qa/feature-map.md`; it does not produce the final deep exploration evidence, coverage plan, or test specs.
Define an exploratory testing charter: frame what to investigate, why it matters, and which risk hypotheses to test before or alongside the shared testing workflow. Triggers include "exploratory testing for...", "what should I investigate in this app", "help me think about what could go wrong", "risk hypotheses for...", "testing charter for...", "where should I probe deeper", or any request that needs structured thinking about test intent before coverage planning begins. This skill owns exploratory intent, risk framing, investigation order, and concrete follow-up asks for missing evidence; it does NOT own exploration evidence (capture-feature-evidence), final coverage prioritization (plan-test-coverage), or test case specs (generate-test-cases).
THE DEFAULT ENTRY POINT for the Playwright execution layer in the split testing suite. Use to add, create, or set up Playwright end-to-end tests for a feature, page, or application. It orchestrates the full Playwright workflow after shared exploration and planning: analyze the Playwright codebase, consume `docs/qa/feature-map.md`, `docs/qa/exploration-report.md`, `docs/qa/coverage-plan.md`, and `docs/qa/test-cases/*.md`, write production-grade test code, review it, and verify it with real execution. Delegates to `analyze-test-codebase`, `write-test-code`, `review-test-code`, and `fix-flaky-tests`, while relying on shared `map-feature-scope`, `capture-feature-evidence`, `plan-test-coverage`, `generate-test-cases`, and `review-test-cases`.
Scans and reports on an existing Playwright test codebase. This skill should be used to inspect the current Playwright setup before writing, reviewing, or fixing tests, and should be loaded early when working in a new project to understand existing patterns. Covers: Playwright config, page objects, fixtures, helpers, auth/globalSetup patterns, test conventions, and directory structure. Triggers: "understand", "check", "show me", "inspect", or "analyze" the current test setup, config, infrastructure, patterns, or conventions. In the full add-tests workflow, this skill serves as an early read-only analysis sub-step before planning detailed coverage or writing code. This skill examines existing files and outputs a structured report. It does NOT write or fix tests, install Playwright, or explore live websites — for live-site exploration, use `capture-feature-evidence` so evidence is captured in `docs/qa/exploration-report.md`.
Quality review of Playwright test code before final execution signoff. This skill should be used when implementation review of executable Playwright tests is needed, not for diagnosis of runtime flakiness. Triggers: "review test code", "review Playwright tests", "check test quality", "audit test implementation", "review my tests before merging", "check test code for issues", "review e2e tests", "code review Playwright", "are my tests stable", "check for brittle selectors", "review before running tests". Quality gate after write-test-code — catches brittle selectors, force:true misuse, networkidle overuse, Tailwind utility class selectors, exact numeric assertions, missing teardown, parallel-unsafe mutations, hardcoded data, missing assertions, test coupling, and convention divergence. Review-only — does NOT rewrite tests, does NOT run tests. Use fix-flaky-tests for fixing, write-test-code for rewriting.
| name | to-prd |
| description | Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context. |
This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.
The issue tracker and triage label vocabulary should have been provided to you — run /setup-engineering-workflow if not.
Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can.
Check with the user that these seams match their expectations.
ready-for-agent triage label - no need for additional triage.The problem that the user is facing, from the user's perspective.
The solution to the problem, from the user's perspective.
A LONG, numbered list of user stories. Each user story should be in the format of:
This list of user stories should be extremely extensive and cover all aspects of the feature.
A list of implementation decisions that were made. This can include:
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
A list of testing decisions that were made. Include:
A description of the things that are out of scope for this PRD.
Any further notes about the feature.