Domain-Driven Design patterns for TypeScript. Use when implementing ubiquitous language, value objects, entities, aggregates, domain events, domain services, or bounded contexts. Only applies to projects that explicitly use DDD. Do NOT use for simple CRUD or projects without domain modeling.
Deprecated compatibility alias for structure-codebase. Activate only for the exact legacy name folder-structure or an explicit $folder-structure invocation. Contains no independent architecture guidance and must delegate to the canonical sibling skill.
Hexagonal (ports and adapters) architecture patterns for TypeScript. Use when implementing ports, adapters, dependency inversion, or domain isolation. Only applies to projects that explicitly use hexagonal architecture. Do NOT use for projects without ports/adapters structure.
Design, audit, and evolve source and package structures that expose real architectural boundaries while keeping related behavior together. Use when creating or reviewing repository trees, deciding where files or packages belong, reducing flat folders, organizing by feature, route, screen, use case, bounded context, workflow or endpoint, structuring frontend state/data/UI ownership and design systems, making hexagonal inside/outside boundaries visible, locating ports, adapters and composition roots, structuring BFF routes, planning folder migrations, or enforcing package and import direction. Select first-class frontend, visible ports-and-adapters, and proportional feature-, framework-, workflow-, endpoint-, or shallow structures according to the architecture the project actually uses.
Get a rigorous second opinion on finished work, preferably from a *different* AI provider's CLI agent — codex, claude, gemini, or cursor-agent — then run a constructive back-and-forth until both agents genuinely agree. If no independent provider can be reached, fall back to a fresh same-provider agent with no inherited context and clearly label the reduced independence. Use when the user says "double check this", "verify my work", "get a second opinion", "have another model check", "cross-check with codex/gemini", "is this actually right?", or before merging or shipping high-stakes, complex, or security-sensitive work.
Writing developer-facing prose that can be skimmed first and trusted enough to finish — READMEs, guides, tutorials, reference docs, proposals, PR descriptions, release notes. Use when creating or editing any technical document, when a doc reads as a wall of text, when claims need receipts, or when docs must serve AI agents as well as humans. Covers reader-first structure, falsifiable claims, docs-as-behavior verification, and agent-readable reference shape. For diagram choice and syntax see diagrams; for API reference semantics see api-design; for CLI help text see cli-design.
Turn fuzzy intent into shared understanding and acceptance criteria — specification as a conversation, run one question at a time, before any story is split or planned. Use when an idea, feature request, or problem statement has no agreed rules or examples yet ("let's spec this out", "what should this actually do?", "we need acceptance criteria"). Produces an example map and acceptance criteria written back into the team's own story artifact, plus candidate glossary terms and parked questions. The agent-facilitated round is a first draft for a real conversation between humans — recommended, not optional. For decision trees with no artifact, see grill-me; for tightening an existing artifact, see find-gaps; for slicing agreed work, see story-splitting.
One ubiquitous language per bounded context — mechanically enforced, evolving only by decision. Per-context Contextive-format glossaries reconciled against code by lint; the five-step language protocol (detect, propose, decide, record, rename) for every new or changed domain term; glossary-driven identifier and test-title checking. Use when naming domain concepts, when a term is missing from or fights the glossary, when spotting synonyms or near-duplicates, when bootstrapping a glossary, or when renaming across a bounded context. For DDD building blocks see domain-driven-design; for acceptance-DSL vocabulary see acceptance-testing.