Prd Product Description
Draft the Product Description of a PRD by describing what the product is and how its parts fit together. Drives discovery through the one-liner, the user-facing surfaces, the major components, how they interact, and the boundaries of what the product is not. Writes to `.trogonai/project/{projectid}/prd/product-description.prd.md`. Use when the user wants to describe the product shape without divi…
Eventmodeling Optimizing Stream Design
Design event streams with proper stream identity to keep streams appropriately sized, avoid unnecessary snapshotting, and balance performance with simplicity. Use when concerned about stream length, planning performance, or validating stream design before implementation. Do not use for: designing the initial event model structure (use eventmodeling-designing-event-models) or general architectural…
Eventmodeling Designing Event Models
Designs event-sourced domain models. Maps business processes to immutable events and state projections. Events are the source of truth; state is derived from events for command validation. Use when designing event streaming architectures from domain analysis. Do not use for: brainstorming events from scratch (use eventmodeling-brainstorming-events), optimizing stream sizing or snapshotting (use e…
Eventmodeling Brainstorming Events
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…
Prd Business Problem
Draft the Business Problem of a PRD by framing the core problem the product addresses, the gaps in today's tools and processes, and why change is necessary now. Drives discovery through who experiences the pain, what fails today, and the cost of inaction. Writes to `.trogonai/project/{projectid}/prd/business-problem.prd.md`. Use when the user wants to write, refine, or audit the problem framing o…
Prd Custom Overview
Draft an additional Product Overview Document beyond the six defaults when a product-specific context area is needed. Keeps custom PRDs at product-level why/what, prevents duplicate default sections, and writes to `.trogonai/project/{projectid}/prd/{slug}.prd.md`. Use when the user needs a custom overview document rather than a feature requirement.
Frd Split
Split, merge, or nest Feature Requirements Documents (FRDs) using the parent-delivers-value rule where a parent feature must deliver value on its own and a child must be meaningless without the parent. Promotes parent files into directories, scaffolds child FRDs with appended prefixes, and rewrites the parent into an umbrella. Use when an FRD has grown too large or when multiple FRDs should be co…
Eventmodeling Validating Event Models Checklist
Validate event-sourced CQRS models against 16 architectural checks across 7 phases. Identifies anti-patterns and confirms compliance with event sourcing principles. Use when reviewing event models for production readiness or after completing event modeling steps. Do not use for: reviewing incomplete or in-progress models (use eventmodeling-validating-event-models), or for elaborating new scenario…
Diataxis Organize Docs
Reorganize documentation into the Diataxis framework structure. Splits existing docs into tutorials, how-to guides, reference, and explanation sections.
Prd Review
Review Product Overview Documents for completeness, clarity, source-of-truth conflicts, module-boundary drift, and likely downstream FRD / Blueprint / Work Order impact. Reads the default and custom files under `.trogonai/project/{projectid}/prd/` and writes a review. Use when the user asks to review, audit, critique, or sanity-check a PRD.
Gh Enrich Pr Description
Enrich GitHub PR descriptions with root-cause context, related issues/PRs, and CC mentions. Use when creating or editing a PR, when a PR has an empty or sparse description, or when the user asks to improve a PR description.
Requirements Operating Model
Apply the shared Requirements operating model across product-requirements skills: Requirements / Blueprints / Work Orders boundaries, single source-of-truth ownership, TrogonStack ask-question-compatible clarification, Product Overview / FRD scope, feature hierarchy, and downstream impact. Use alongside PRD or FRD writing, review, split, or getting-started work when cross-document consistency, am…
Prd Getting Started
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.
Eventmodeling Integrating Legacy Systems
Apply Event Modeling to legacy systems using side-car pattern. Freeze old system, extract events, build new features without rewriting. Use when modernizing legacy applications. Do not use for: greenfield systems without existing legacy constraints (use eventmodeling-orchestrating-event-modeling) or translating inbound events from external APIs (use eventmodeling-translating-external-events).
Eventmodeling Storyboarding Events
Step 3 of Event Modeling - Create UI storyboards/mockups showing what users see at each step. Capture all data fields needed from user perspective. Use after sequencing events. Do not use for: identifying commands or processor actions (use eventmodeling-identifying-inputs) or designing read models (use eventmodeling-identifying-outputs).
Eventmodeling Identifying Inputs
Step 4 of Event Modeling - Identify Commands/Inputs from UI and Processor actions. Map user actions to commands and data. Use after storyboarding UI. Do not use for: identifying read models or outputs (use eventmodeling-identifying-outputs) or elaborating behavior specifications (use eventmodeling-elaborating-scenarios).
Ask Question
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.
Scaffold Plugin
>-
Event Definition
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 consist…
Frd Write
Draft a Feature Requirements Document (FRD) using the Overview / Terminology / Requirements template, Product Overview context, source-of-truth checks, and REQ-[PREFIX]-NNN / AC-[PREFIX]-NNN.N acceptance criteria. Supports nested sub-features with appended prefixes. Use when the user wants to spec a feature for engineering to build.
Frd Getting Started
Produce the initial set of Feature Requirements Documents (FRDs) for a new project. Calibrates between an agile first pass (small set of must-have features only) and a waterfall first pass (comprehensive coverage). Asks how many features to draft, identifies them from the project's product overview, and scaffolds each via the FRD template. Use when the user is starting a project and there are no…
Eventmodeling Identifying Outputs
Step 5 of Event Modeling - Identify Outputs/Read Models from events. Show what data flows back to UI and Processors. Use after defining inputs. Do not use for: identifying commands or inputs (use eventmodeling-identifying-inputs) or verifying field completeness (use eventmodeling-checking-completeness).
Datadog Design Dashboard
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 be…
Eventmodeling Slicing Event Models
Break down complete event models into independently implementable feature slices, identify dependencies, and plan parallel implementation across teams. Use when planning team allocation, identifying MVP scope, or establishing implementation order after completing event modeling. Do not use for: organizational team structure based on Conway's Law (use eventmodeling-applying-conways-law) or plannin…
Eventmodeling Plotting Events
Step 2 of Event Modeling - Arrange events chronologically in logical narrative sequence. Create timeline showing event flow and dependencies. Use after brainstorming events. Do not use for: brainstorming new events (use eventmodeling-brainstorming-events) or designing command/read model architecture (use eventmodeling-designing-event-models).
Eventmodeling Elaborating Scenarios
Step 7 of Event Modeling - Elaborate scenarios using Given-When-Then format. Specify behavior of commands and views. Each spec tied to exactly one command or view. Use after defining systems and boundaries. Do not use for: architectural validation (use eventmodeling-validating-event-models) or verifying field completeness across the model (use eventmodeling-checking-completeness).
Eventmodeling Orchestrating Event Modeling
Orchestrates complete event modeling workflow from requirements to code generation. Models architecture as UI/Processor → Command → Event → Read Model. Use when modeling a domain end-to-end from requirements. Do not use for: executing a single step in isolation (invoke the named step skill directly, e.g., eventmodeling-brainstorming-events for Step 1 or eventmodeling-elaborating-scenarios for Ste…
Prd Current State
Draft the Current State of a PRD by documenting the status quo the product improves upon. Drives discovery through what users do today, the workarounds in use, the costs of the status quo, and the alternatives that already exist. Writes to `.trogonai/project/{projectid}/prd/current-state.prd.md`. Use when the user wants to document the baseline before proposing a change.
Eventmodeling Applying Conways Law
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).
Eventmodeling Validating Event Models
Step 9 of Event Modeling - Validate event-sourced models for completeness, consistency, and event sourcing principles. Ensures events are immutable facts, state projections are deterministic, and commands are pure. Identifies gaps and suggests improvements before code generation. Use when reviewing models before code generation. Do not use for: the structured 23-check production checklist (use ev…
Prd Personas
Draft the Personas of a PRD by defining the users, their goals, and what success looks like for them. Drives discovery through who the users are, the jobs they are trying to do, their constraints, and the per-persona definition of success. Writes to `.trogonai/project/{projectid}/prd/personas.prd.md`. Use when the user wants to define or sharpen who the product is for.
Frd Review
Review Feature Requirements Documents (FRDs) (single file or full tree) against the Overview / Terminology / Requirements template, source-of-truth rules, module boundaries, downstream impact, and the parent-delivers-value rule for sub-features. Writes a review file. Use when the user asks to review, audit, or sanity-check a feature spec.
Prd Technical Requirements
Draft the Technical Requirements of a PRD by capturing the technical constraints and requirements the product must meet. Drives discovery through performance, scale, reliability, security, privacy, compliance, integrations, platforms, accessibility, and localization. Writes to `.trogonai/project/{projectid}/prd/technical-requirements.prd.md`. Use when the user wants to capture the non-functional…
Diataxis Gen Readme
Generate a README introduction following the Diataxis 4-paragraph structure for product documentation.
Otel Name Metric
Review or create OpenTelemetry metric names following semantic conventions. Validates naming format, units, instrument selection, and attribute placement. Use when designing new metrics, reviewing existing instrumentation, or auditing metric naming consistency. Do not use for: (1) span or trace naming, (2) OTel collector configuration, (3) SDK installation or setup, (4) alerting or dashboard desi…
Otel Name Span
Review or create OpenTelemetry span names following semantic conventions. Validates naming, cardinality, attribute placement, and protocol-specific patterns. Use when designing new spans, reviewing existing instrumentation, or auditing span naming consistency. Do not use for: (1) metric naming, (2) OTel collector configuration, (3) SDK installation or setup, (4) alerting or dashboard design.
Prd Success Metrics
Draft the Success Metrics of a PRD by defining the key metrics used to measure success. Drives discovery through the primary outcome metric, leading indicators, guardrail metrics that must not regress, and the instrumentation source for each. Writes to `.trogonai/project/{projectid}/prd/success-metrics.prd.md`. Use when the user wants to define how success will be measured before building.
Nats Design Subject
Design NATS subject hierarchies for messaging patterns (pub/sub, request/reply, streaming). Apply naming conventions, segmentation strategies, and wildcard patterns to create scalable subject architectures. Use when designing NATS messaging systems, choosing account-vs-subject namespace boundaries for multi-tenant communication, designing export/import subjects, or auditing existing subject hiera…
Eventmodeling Translating External Events
Translate external system events (webhooks, APIs, IoT) into domain events. Map technical data to business concepts. Use when integrating with external systems that emit events your domain needs to react to. Do not use for: modernizing legacy systems using the side-car pattern (use eventmodeling-integrating-legacy-systems) or designing command handlers for the translated events (use eventmodeling-…
Eventmodeling Checking Completeness
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).