npx claudepluginhub dev10x-guru/dev10x-claude --plugin Dev10xThis skill uses the workspace's default tool permissions.
Guide users through structured domain exploration using DDD Event
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Guide users through structured domain exploration using DDD Event Storming, Software Archetypes, and architecture stress testing.
Trigger on:
Do NOT use for:
ticket-scope instead)write-adr prompt)This skill follows references/task-orchestration.md patterns.
Auto-advance: Complete each step, immediately start the next. Only pause when batching questions per the process rules.
REQUIRED: Create tasks before ANY work. After determining
the session type, execute TaskCreate calls for the applicable
steps. The task set varies by mode:
Continue / Stress-Test / Archetype mode:
TaskCreate(subject="Load context", activeForm="Loading domain context")TaskCreate(subject="Exploration", activeForm="Exploring domain")TaskCreate(subject="Stress testing", activeForm="Stress testing model")TaskCreate(subject="Decision capture", activeForm="Capturing decisions")TaskCreate(subject="Produce artifacts", activeForm="Producing artifacts")TaskCreate(subject="Quality checklist", activeForm="Verifying quality")New workshop mode:
TaskCreate(subject="Scaffold docs structure", activeForm="Scaffolding docs")TaskCreate(subject="Exploration", activeForm="Exploring domain")TaskCreate(subject="Stress testing", activeForm="Stress testing model")TaskCreate(subject="Decision capture", activeForm="Capturing decisions")TaskCreate(subject="Produce artifacts", activeForm="Producing artifacts")TaskCreate(subject="Quality checklist", activeForm="Verifying quality")Set sequential dependencies. Mark each step in_progress when
starting and completed when done. The quality checklist task
serves as the final verification gate.
Before starting, determine which mode applies:
| Mode | Trigger | Read before starting |
|---|---|---|
| New workshop | No docs/domain/ exists yet | references/document-structure.md |
| Continue workshop | docs/domain/model.md exists | All existing domain docs (Step 1) |
| Stress test | "What if we add X?" / "Does Y break?" | references/stress-test-protocol.md |
| Archetype application | "This feels bloated" / "Apply archetype" | references/archetypes-catalog.md |
Read these files in this order before proceeding:
docs/domain/model.md — current domain modeldocs/domain/decisions.md — all prior decisions (append-only)docs/domain/calculator.md — pricing pipeline and formulasdocs/domain/stress-tests.md — validated architectural seamsdocs/domain/glossary.md — ubiquitous languagedocs/domain/epics.md — tickets and prioritiesdocs/domain/workshops/ — previous sessionThen read implementation state:
8. apps/web/src/lib/domain/ — current TypeScript (if any)
9. CLAUDE.md — project conventions
Summarize what you understand in 3-5 sentences before proceeding.
For new workshops, skip to Step 2 and read
references/document-structure.md to scaffold the docs directory.
Read references/process-rules.md for the full set. Summary:
Go as long as possible without asking questions. Make reasonable assumptions, note alternatives, store unresolved choices. Only stop when the choice is genuinely arbitrary or high-stakes.
When you DO need input, batch ALL questions into a single structured decision menu with options. Never one question at a time.
Never re-derive or silently override decisions from decisions.md.
If new info contradicts a prior decision, propose a NEW decision
that explicitly supersedes it — state which, why, and what changes
downstream. Reference decisions by ID: [D-NNN].
Use reference materials (spreadsheets, specs) as behavioral models. Replace proprietary specifics with generic examples. The domain model must never leak client IP.
Read references/exploration-methodology.md for DDD techniques.
Read references/archetypes-catalog.md for the full pattern table.
At every stage, check: does this problem match a known archetype?
| If you see... | Apply... |
|---|---|
| Flat config with N named fields | Pricing (composable pipeline) |
Raw number for money or effort | Quantity (Money, Effort, Ratio) |
| Users, departments, vendors | Party (role-based) |
| "What resources does this need?" | Availability / assignment |
| Complex conditional logic | Rules (condition trees) |
| Items in a hierarchy | Product (composite tree) |
| "Is this available at time X?" | Availability (time-slotted) |
| Bloated entity with mixed semantics | Step back — which archetype decomposition? |
Applying an archetype is NOT premature abstraction. It's
recognizing that this problem has been solved before. The archetype
provides the vocabulary and structure; the domain provides the
specific rules. See references/archetypes-catalog.md for detailed
guidance on each.
These principles govern all proposals:
"Don't make me think" (Krug) — Prefer implicit automatic behavior (auto-grouping on child add) over manual workflows. But never auto-delete or auto-restructure — creation can be magic, destruction requires intent.
Configuration vs. Estimation — Keep pricing configuration cleanly separated from the estimation workspace. Users change rules without touching estimates, and vice versa.
Foundation-ready, not prematurely built — Bake hooks into the foundation (like i18n) so future capabilities are data extensions, not refactors. Rule of thumb: nullable field or open union now at zero runtime cost vs. data migration later → do it now. Actual code/abstractions not yet used → defer.
Plan but defer server dependencies — Features requiring servers (short URLs, cloud accounts) are scoped and designed but not built until the client-side foundation is solid.
Before committing to any model change, validate it. Read
references/stress-test-protocol.md for the full protocol.
stress-tests.md "Stable Core" section remain stable.decisions.md?Every choice gets recorded. Read
references/session-deliverables.md for the full format.
## D-NNN: [Short title]
- **Date:** YYYY-MM-DD
- **Status:** Active | Superseded by D-MMM
- **Workshop:** NNN
**Decision:** [What was chosen]
**Alternatives considered:**
1. [Option A] — [why not]
2. [Option B] — [why not]
**Rationale:** [Why this choice]
To supersede: add new decision with supersedes: D-NNN, update
old entry's status to Superseded by D-MMM.
Read references/session-deliverables.md for complete format and
references/document-structure.md for file responsibilities.
decisions.md — every choice, even "we
decided not to do X"workshops/NNN-topic.md — narrative,
decisions list, model changes, open questionsmodel.md (if types/pipeline/aggregates changed)calculator.md (if formulas/golden tests changed)epics.md (if tickets added/refined/completed)stress-tests.md (if stress test was run)glossary.md (if new terms introduced)docs/prompts/ (if feature area
is fully scoped and ready for implementation)Divide features into configuration tickets and estimation
tickets. Each ticket needs: JTBD Job Story, scope, acceptance
criteria, dependencies. See epics.md for established format.
When no docs/domain/ exists, create the full structure. Read
references/document-structure.md for the complete specification.
mkdir -p docs/domain/workshops docs/prompts
Create these files from the templates in
references/document-structure.md:
docs/domain/README.md — documentation architecture indexdocs/domain/model.md — domain model (initially empty scaffold)docs/domain/decisions.md — decision log (empty, with format guide)docs/domain/calculator.md — calculator spec (empty scaffold)docs/domain/glossary.md — ubiquitous language (empty table)docs/domain/stress-tests.md — stress tests (empty, with format)docs/domain/epics.md — epics and tickets (empty scaffold)docs/domain/workshops/TEMPLATE.md — workshop record templateThen proceed with exploration (Step 3).
Read these on demand — SKILL.md contains the workflow; references contain the depth.
| File | Read when |
|---|---|
references/process-rules.md | Starting any session |
references/exploration-methodology.md | Doing event storming or domain modeling |
references/archetypes-catalog.md | Recognizing or applying a Software Archetype |
references/stress-test-protocol.md | Validating a model change or extension |
references/session-deliverables.md | Producing artifacts at end of session |
references/document-structure.md | Scaffolding docs/ for a new project |
references/pricing-pipeline.md | Working on pricing, rates, or cost calculation |
Before ending a session, verify:
decisions.md with IDsstress-tests.mdworkshops/NNN-topic.md