菜单
Initialize a new project with the six default Product Overview Documents (business problem, current state, personas, product description, success metrics, technical requirements). Scaffolds stubs and walks the user through running each section skill in priority order. Use when the user is starting a project and there are no PRD files yet.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Ask structured questions one at a time to gather requirements, context, or clarification. Each question includes the intention behind it and current assumptions. Use when the user wants to be interviewed about a topic, gather requirements, or needs help thinking through a problem step by step.
Design new Datadog dashboards, redesign existing ones, or audit dashboards for operational readiness. Covers widget selection, layout organization, template variables, group structure, tab organization, alert threshold validation, and zero-knowledge readability. Uses pup CLI for inspecting dashboards and validating designs. Use when designing new dashboards, redesigning existing ones, auditing before on-call handoff, or reviewing after dashboard changes. Do not use for: (1) Datadog agent installation or configuration, (2) monitor/alert rule design, (3) APM instrumentation or tracing setup, (4) log pipeline configuration.
Review or create event definitions for event-driven architecture. Covers event names, payload field names, event_type identity, stream naming boundaries, and record metadata/context/payload placement for both domain events (event-sourcing) and integration events (cross-service). Use when designing a new event definition, reviewing an existing event definition, or auditing event definition consistency across a catalog. Do not use for full event modeling workflows (use trogonstack-eventmodeling skills), event schema evolution or migration strategy, or event store implementation design.
Step 6 of Event Modeling - Apply Conway's Law with swimlanes. Organize events into autonomous system parts that different teams can independently own. Use after defining inputs/outputs. Do not use for: planning feature slice implementation order (use eventmodeling-slicing-event-models) or defining command/read model boundaries (use eventmodeling-designing-event-models).
Step 1 of Event Modeling - Brainstorm all domain events from requirements. Extract every state-changing event the system could have. Use when starting event modeling from requirements or a new domain. Do not use for: arranging events in sequence (use eventmodeling-plotting-events), designing commands or read models (use eventmodeling-designing-event-models), or when a complete event list already exists.
Step 8 of Event Modeling - Completeness Check. Verify every field has origin and destination. Ensure complete event model before code generation. Use after all scenarios defined. Do not use for: architectural validation against event sourcing principles (use eventmodeling-validating-event-models) or elaborating Given-When-Then specs (use eventmodeling-elaborating-scenarios).
| name | prd-getting-started |
| description | Initialize a new project with the six default Product Overview Documents (business problem, current state, personas, product description, success metrics, technical requirements). Scaffolds stubs and walks the user through running each section skill in priority order. Use when the user is starting a project and there are no PRD files yet. |
| allowed-tools | ["AskUserQuestion","Read","Write","Glob"] |
Every project starts with the same six Product Overview Documents. This skill creates them once, in priority order, so the user has a complete baseline they can fill in section by section.
This is the PRD counterpart to frd-getting-started.
Use requirements-operating-model when the task involves clarification, existing product context, custom overview ownership, feature handoff, or downstream Blueprint / Work Order impact. Use its clarification pattern instead of creating a separate local questioning workflow.
.trogonai/project/{projectid}/prd/ is emptyprojectid (ask if not supplied; offer choices via Glob of .trogonai/project/*/).Glob .trogonai/project/{projectid}/prd/*.prd.md: if any default files already exist, ask whether to skip existing and only scaffold what's missing, or stop (this skill is for getting started, not for re-initialization). Suggest the individual prd-* skills for refining existing files.Ask the user which style fits this project:
prd-* skills for the user to fill in at their own pace. Best when the user wants to see the shape first and fill in over time.If unclear, default to Quick scaffold: it is reversible.
The six default PODs in recommended discovery order (later docs reference earlier ones):
prd-business-problem: why this exists at allprd-current-state: what is being improvedprd-personas: who it serves (referenced by every later doc)prd-product-description: what the product isprd-success-metrics: how success is measured (references personas)prd-technical-requirements: what the build must satisfyFor each of the six PODs that does not already exist, write a stub file at .trogonai/project/{projectid}/prd/{filename} with the headings present but the bodies marked for completion.
# <Section Title>
- **Project:** {projectid}
- **Status:** Stub
- **Last updated:** <YYYY-MM-DD>
> This is a stub. Run the corresponding skill (`<skill-name>`) to author the full content.
<headings from the section's template, each with a placeholder body>
Use the exact section template defined by the matching prd-* skill (don't invent new headings). Stubs preserve the headings so later edits don't have to recreate them.
| File | Skill | Section Title |
|---|---|---|
business-problem.prd.md | prd-business-problem | Business Problem |
current-state.prd.md | prd-current-state | Current State |
personas.prd.md | prd-personas | Personas |
product-description.prd.md | prd-product-description | Product Description |
success-metrics.prd.md | prd-success-metrics | Success Metrics |
technical-requirements.prd.md | prd-technical-requirements | Technical Requirements |
After scaffolding, write .trogonai/project/{projectid}/prd/_getting-started.md:
# Getting Started: Initial Product Overview Set
- **Project:** {projectid}
- **Date:** <YYYY-MM-DD>
- **Style:** <Quick scaffold / Guided pass>
## Scaffolded
- [business-problem.prd.md](./business-problem.prd.md): author with `prd-business-problem`
- [current-state.prd.md](./current-state.prd.md): author with `prd-current-state`
- [personas.prd.md](./personas.prd.md): author with `prd-personas`
- [product-description.prd.md](./product-description.prd.md): author with `prd-product-description`
- [success-metrics.prd.md](./success-metrics.prd.md): author with `prd-success-metrics`
- [technical-requirements.prd.md](./technical-requirements.prd.md): author with `prd-technical-requirements`
## Next Steps
1. Run the six skills in priority order. Personas (3) should be authored before Success Metrics (5).
2. Run `prd-review` once a meaningful chunk is authored.
3. Move on to `frd-getting-started` to scaffold the initial Feature Requirements set.
4. Use `prd-custom-overview` only if the project needs a product-level context document beyond the six defaults.
If the user picked Guided pass, after writing the summary, recommend running prd-business-problem next and stop. The user (or the agent on the next turn) can invoke each subsequent skill.
The initialization is complete when:
prd-* skill is responsible for its own quality bar.prd-* skills instead.prd-custom-overview when the product needs a separate custom Product Overview Document.prd-business-problem, prd-current-state, prd-personas, prd-product-description, prd-success-metrics, prd-technical-requirements: author each sectionprd-review: audit once authoring is meaningfulprd-custom-overview: author additional Product Overview Documents beyond the six defaultsfrd-getting-started: translate the overview into the initial Feature Requirements setprojectid and the working style