domain-model

Review domain models using product, engineering, and design perspectives.

34|4|Updated Apr 20, 2026
One-click install
npx skills add https://github.com/redpanda-data/ui-harness --skill domain-model-redpanda-data
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-model
Source: https://github.com/redpanda-data/ui-harness/tree/main/domain-model
Command: npx skills add https://github.com/redpanda-data/ui-harness --skill domain-model-redpanda-data

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

This Skill aids in refining domain models through collaborative three-hat review, ensuring clarity and consistency in architectural decisions.

Core Features & Use Cases

  • Adversarial Review: Conducts parallel reviews by product, engineering, and design teams.
  • Documentation Integration: Seamlessly integrates with existing CONTEXT.md and ADR documents.
  • Use Case: Use this Skill to document a new architectural decision, ensuring all stakeholders agree on the terms and implications.

Quick Start

Run /domain-model to start the domain model grilling process.

Frequently Asked Questions about domain-model

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is an adversarial review process for domain modeling?

Adversarial review for domain modeling is a parallel evaluation process where product, engineering, and design perspectives critique a model to validate architectural decisions and ensure stakeholder clarity.

How do I document a new architectural decision while ensuring stakeholder alignment?

You document architectural decisions by running a three-hat domain model review that requires parallel input from product, engineering, and design teams to validate terms and implications.

Can I integrate existing context and decision records into the domain model review?

Yes, the domain model review process integrates existing domain-specific context from `CONTEXT.md` and decision records from ADR documents to inform and ground the validation process.

How do I validate domain models across different teams in software architecture?

You validate domain models by conducting a three-hat adversarial review that requires parallel input from product, engineering, and design perspectives to ensure consistency in architectural decisions.

What is the best way to review domain-specific terminology in a codebase?

The best way to review domain-specific terminology is using a collaborative three-hat review process that critiques existing context and decision records to refine domain model clarity.