ubiquitous-language
What This Skill Does
Extract a DDD-style ubiquitous language glossary from a reviewed PRD and the codebase. Identify every domain term, flag ambiguities (same concept with different names, same name for different concepts), check how the codebase currently names things, and propose canonical terms with definitions.
This is the terminology alignment step in the planning pipeline (plan-feature → write-a-prd → review-prd → ubiquitous-language → design-feature → review-plan). The PRD established what to build. This skill answers: "What do we call things — and does everyone agree?"
Why This Step Exists
Domain terminology drifts. The PRD says "workspace," the database calls it "org," the UI shows "team," and the API uses "account." When design-feature runs without a canonical vocabulary, it bakes naming inconsistencies into data models, API endpoints, and code constructs. Fixing terminology after design is expensive. Fixing it after implementation is worse.
This step creates a shared vocabulary that design-feature uses as its naming source of truth.
Finding the PRD
Look for the PRD in this order:
- If the user names a specific file, read that file.
- Check
./plans/for PRD files (*-prd.md). If there's exactly one, use it. If there are several, ask which one. - If the PRD was produced earlier in this conversation (via write-a-prd), use the conversation context.
More from michaelmerrill/skills
design
Design specification interview → standalone spec.md (flows, screens, states, components, responsive, a11y). Triggers: 'design this,' 'what screens,' 'how should users interact,' post-product. Not for: technical design (engineering), requirements (product). Skip for API-only, CLI, backend, or infra features.
8plan
Decompose technical design into agent-sized implementation issues → numbered markdown files + standalone plan.md. Triggers: 'plan this,' 'break into issues,' 'create tasks,' 'ready to implement,' post-engineering. Not for: designs without file paths/phases (run engineering first).
7design-ux
MUST USE when a user wants to design user flows, interaction patterns, or screen-level UX for a feature that has defined requirements. This is the UX design step in the planning pipeline (write-a-prd → review-prd → glossary → design-ux → design-feature → review-plan). Typical signals — "design the UX," "how should users interact with this," "what should the UI look like," "design the flows," "design-ux," "what screens do we need," or following up after a review-prd or glossary session. Also applies when the user has a PRD and wants to figure out the user experience before technical design. Conducts a structured interview to produce a UX specification — user flows, screen inventory, component mapping, interaction specs, and accessibility requirements. Do NOT use for technical design (use design-feature), writing requirements (use write-a-prd), reviewing plans (use review-plan), scoping/feasibility (use plan-feature), or when the feature has no user-facing UI (API-only, backend, CLI tools).
6plan-feature
Scoping interview for new features -> scope doc with go/no-go. Triggers: user wants to add/build/implement any new capability. First pipeline step. Not for: bugs, PRDs (write-a-prd), design (design-feature), executing existing specs.
6define
Product requirements → living doc Requirements section + quality gate + domain glossary. Stateful: detects existing sections and resumes where needed. Triggers: 'define this,' 'write a PRD,' 'define requirements,' 'spec this out,' post-explore. Not for: scoping (explore), UX (design), technical design (architect).
5explore
Scope and assess new feature ideas → living doc with go/no-go. Elaborates vague ideas into clear concepts. First pipeline step. Triggers: user wants to add/build/implement any new capability. Not for: bugs (triage-issue), requirements (define), design (design/architect).
5