搜尋
搜尋結果
54 results for "prd"
breakdown-feature-prd
Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic.
githubprd
Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.
github
prd
Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out.
snarktank
writing-prds
Help users transform abstract ideas into actionable project specs that align engineering and design teams on the problem and success metrics.
refoundai
day6-prd-submit
PRD 초안을 작성하고 형식을 검증한 뒤 GitHub PR 제출을 안내한다. "PRD 작성", "PRD 검증", "Day 6", "6일차", "PR 제출", "prd submit" 요청에 사용.
ai-native-camp
product-capability
Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose.
affaan-mproduct-capability
Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose.
affaan-mbreakdown-feature-implementation
Prompt for creating detailed feature implementation plans, following Epoch monorepo structure.
githubbreakdown-epic-pm
Prompt for creating an Epic Product Requirements Document (PRD) for a new epic. This PRD will be used as input for generating a technical architecture specification.
github
product-skills
Use when coordinating product work across the 12 bundled product sub-skills (RICE, OKRs, UX research, design tokens, competitive teardown, analytics, experiments, discovery, roadmaps, spec-to-repo, landing pages, SaaS scaffolding) or the 4 standalone product-team plugins (user stories, Apple HIG, code-to-PRD, research summarizer). Triggers on 'help me prioritize', 'plan a product experiment', 'we ship features nobody uses', 'run the discovery loop', 'is our OST sound'. Forks context to route to one sub-skill via a deterministic signal router and returns a digest; can also drive a continuous-discovery loop (Torres cadence tracker + OST linter as machine gates) or a full goal→plan→execute→verify→close run through the repo-wide agent-harness. Distinct from project-management (how to deliver vs what to build), marketing/landing (from-scratch pages), and engineering/agent-harness (the generic loop engine this orchestrator plugs into).
alirezarezvani
feature-forge
Conducts structured requirements workshops to produce feature specifications, user stories, EARS-format functional requirements, acceptance criteria, and implementation checklists. Use when defining new features, gathering requirements, or writing specifications. Invoke for feature definition, requirements gathering, user stories, EARS format specs, PRDs, acceptance criteria, or requirement matrices.
jeffallan
problem-statement
Write a user-centered problem statement with who is blocked, what they are trying to do, why it matters, and how it feels. Use when framing discovery, prioritization, or a PRD.
deanpeters
experience-lds-data-requirements-generate
Use when a Lightning Web Component data need is described in ambiguous natural language — turn \"get contact info\" or \"show account data\" into a clear, PRD-ready data-requirements spec. TRIGGER when the user says \"define data requirements for this LWC\", \"turn this PRD data section into validated object/field names\", \"recommend GraphQL vs UIAPI for this data need\", \"validate these Salesforce API names\", or \"spec out the LDS adapter for this component\", or references LWC bundle files (`.js`, `.js-meta.xml`) whose data layer is not yet specified. DO NOT TRIGGER when the data layer is already fully specified, when authoring the actual query or adapter code from a known spec, or when implementing an LWC end-to-end (use experience-lwc-generate).
forcedotcom
product-planner
Vision intake conversation followed by generation of three product documents — `docs/product-vision.md` (strategy and brand), `docs/prd.md` (technical spec for coding agents), and `docs/product-roadmap.md` (phased build plan with task checkboxes). Also captures the founder's answers as `docs/VISION.md`. Use when the founder says "plan my product", "plan a product", "define my vision", "generate a PRD", "create a roadmap", "spec out my idea", "help me build something", or wants to convert an idea into shippable spec documents.
buildgreatproductsbuild-mvp
Use inside a product repository when the user wants the full MVP built from their BuilderOS spec documents. Triggers on phrases like "build my MVP", "build the app", "execute the roadmap", "start the build", "work through the whole roadmap", "build everything", or any request to implement the entire plan rather than a single task or phase. Requires `docs/prd.md` and `docs/product-roadmap.md` (plus `docs/product-vision.md` and `docs/design.md` for context). Works through every roadmap task in order — implementing, testing, and verifying each before moving on, marking checkboxes and updating the status line — and runs until all tasks are complete and the magic moment works end to end, then initializes git with an initial commit and offers to connect a remote repo.
buildgreatproducts
write-product-spec
Write a PRODUCT.md spec for a significant user-facing feature in Warp, focused on detailed behavior and validation. Use when the user asks for a product spec, desired behavior doc, or PRD, wants to define feature behavior before implementation, or when the feature is substantial or behaviorally ambiguous enough that a written spec would improve implementation or review.
warpdotdevday3-clarify
AI Native Camp Day 3 Clarify & GitHub. Clarify 플러그인으로 모호한 요구사항을 명확하게 만들고, 나만의 스킬을 만들고, PRD를 작성하여 GitHub에 첫 PR을 제출한다. "3일차", "Day 3", "clarify", "클래리파이", "PRD", "GitHub" 요청에 사용.
ai-native-camp
mcore-split-pr
Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.
nvidia
printing-press-amend
Amend a published CLI from one of two input sources: (1) dogfood mode mines the active Claude Code session transcript for friction (missing flags, hand- rolled API payloads, silent-null returns); (2) direct-input mode accepts user-supplied asks (rename a command, add commands or feeds, fix a named bug, optionally sniff the source site for new endpoints). Confirms scope with the user, plans + executes the fix autonomously, scrubs PII, and opens a PR against mvanhorn/printing-press-library. Two user-in-loop checkpoints: scope after capture, PR draft before open. Trigger phrases: "amend the CLI", "submit a patch", "fix what I just dogfooded", "open a PR for this CLI", "patch this CLI", "add features to my CLI", "rename this command", "add these feeds to <cli>", "sniff for new APIs in <cli>", "amend with these ideas", "use printing-press-amend", "run printing-press-amend".
mvanhorn
pr-review
Review PyTorch pull requests for code quality, test coverage, security, and backward compatibility. Use when reviewing PRs, when asked to review code changes, or when the user mentions "review PR", "code review", or "check this PR".
pytorch
domain-context
Progressive Domain Crystallization (PDC) — a skill for building and maintaining a living domain knowledge base for any custom business application. Use this skill whenever the user is developing a business application and wants the AI to accumulate understanding of internal terminology, entities, relationships, and business rules over time — especially when that knowledge is not fully defined upfront and grows across sessions. Trigger on any of: "remember how our system works", "learn our domain", "track business entities", "build domain knowledge", "understand our terminology", "grow AI context over time", "domain model", "business rules documentation", or whenever a user says the AI doesn't understand their business-specific language or data model. Also use at the start of any session where a .tasks/domain.md file exists in the project — always read it before doing any work.
customware-ai
pr-to-video
turn a GitHub pull request (a PR URL like github.com/<owner>/<repo>/pull/<N>, an <owner>/<repo>#<N> ref, or 'this PR' in a checked-out repo) into a code-change explainer video, up to ~3 min (sweet spot 30-90s) — changelog, feature reveal, fix, or refactor walkthrough, rendered from the diff / commits / files. The input is a CODE CHANGE read via the gh CLI; there is no website capture. Use this skill for a GitHub PR. Do not use it for a product launch/promo (use /product-launch-video), a tour of a real website (use /website-to-video), a topic explainer with no PR (use /faceless-explainer), captions on existing footage (use /embedded-captions), or a short unnarrated motion graphic (use /motion-graphics). If the intent is unclear, route through /hyperframes first.
heygen-compr-walkthrough
Generate a static interactive D3 walkthrough of a pull request. Use when the user wants a zoomable PR map, graph/canvas PR orientation, or alternate visualization of PR system components, data flow, code dependencies, and user actions.
warpdotdev
pr
Create a PR for the current branch (targets `canary` by default), including splitting one cross-layer branch into ordered stacked PRs so a lower layer (db / shared package / server TRPC) merges before its callers (desktop / CLI / UI). Use when the user asks to create / submit a PR, or to split a branch because clients call a server contract that isn't on the trunk yet. Triggers on 'pr', 'create pr', 'submit pr', 'open a PR', 'pull request', 'split this PR', 'stacked PR', 'backend should merge first', '提 PR', '提个 PR', '新建 PR', '拆 PR', '后端先合', '分层合并'.
lobehub