agentskills

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).

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 eventmodeling-optimizing-stream-design), or translating external system events (use eventmodeling-translating-external-events).

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).

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).

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).

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).

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 validation (use eventmodeling-validating-event-models).

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 Step 7), validating an already-completed model (use eventmodeling-validating-event-models), or modernizing legacy systems (use eventmodeling-integrating-legacy-systems).

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).

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 planning before the event model is complete (complete the full model first using eventmodeling-orchestrating-event-modeling).

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).

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-designing-event-models).

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 scenarios (use eventmodeling-elaborating-scenarios).

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 eventmodeling-validating-event-models-checklist) or field-level completeness verification (use eventmodeling-checking-completeness).

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 hierarchies. Do not use for: (1) NATS server or account provisioning, (2) cluster setup, (3) client library implementation or connection code, (4) debugging connectivity or performance issues, (5) choosing between NATS and other messaging systems.

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 design.

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.

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, ambiguity, or module handoff matters.

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 FRDs yet.

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.

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 combined.

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.

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 of a product or feature.

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.

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.

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.

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.

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 diving into requirements.

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.

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.

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 and platform constraints engineering will design against.

Generate a README introduction following the Diataxis 4-paragraph structure for product documentation.

Reorganize documentation into the Diataxis framework structure. Splits existing docs into tutorials, how-to guides, reference, and explanation sections.

Scaffold a new plugin in this repository with all required wiring. Use when creating a new plugin from scratch. Do not use for adding skills to an existing plugin or for modifying plugin metadata.

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.