domain-driven

Plugin domain-driven from marketplace mtrense-skills in mtrense/skills. Commands read from the repo's manifest — today.

Skills (12)

• architecture-foundation

  Facilitate a Socratic session that defines a project's architectural foundation — the boundaries and guidelines every later task is built against — once vision.md, domain-model.md, and context-map.md exist. Opens the agenda with the domain model's still-open hotspots — the last gate where each must

• context-mapping

  Draw the project's bounded contexts and the relationships between them, working from the aggregate clusters in domain-model.md — and place the domain model's external systems on the same map as external contexts (upstream models you don't own, where Conformist/ACL/Published Language earn their keep)

• domain-model

  Run a big-picture EventStorming session over the project vision and produce a single `domain-model.md` at the project root: a chronological domain-event timeline, the commands/actors that trigger them, policies and external systems, the aggregates that own consistency, and a hotspots list of unresol

• dossier

  Build or extend a dossier — the project's fact file on one subject: everything discoverable that is relevant to the job to be done, distilled into confidence-tagged, source-cited claims under dossiers/. The fact twin of an ADR (an ADR records a decision, an exemplar shows it in bytes, a dossier reco

• exemplar

  Brainstorm or ingest a concrete exemplar — a sample config file, dataset, API payload, CLI transcript, UI mock, or similar artifact that pins a piece of the spec down in actual bytes. Trigger whenever the user wants to sketch, draft, brainstorm, or pin down a concrete example artifact — e.g. "let's

• grounding

  Facilitate a Socratic vision session for a new project (or a major new direction) and produce a single tight `vision.md` at the project root. Asks one question at a time, reflects back what it heard, and drives toward shared understanding of purpose, users, the problem, what success looks like, and

• showcase

  Assess the domain-driven project's current progress and report what the human can already test or present — as demoable capabilities tied to vision outcomes, each with a concrete step-by-step walk-through. Read-only: synthesizes the `## Closing → ### Manual testing` records the landed (`done`) tasks

• task-append

  Capture one or more tasks into the domain-driven backlog as new `draft`s from human input of ANY quality — a polished spec or a half-formed brain-dump both welcome. Trigger whenever the user wants to record, capture, add, jot down, or "note for later" a task, idea, feature, or piece of work into the

• task-cycle

  Drive ready `todo` tasks to `done`. Reads the dependency-respecting ready-set from the tasks.sh helper, claims each task (todo -> in progress), and delegates implementation to a task-worker subagent (strict TDD, verify, commit) — dispatched on the model tier the task's `complexity` frontmatter maps

• task-refine

  Refine a draft task into a ready `todo`: assess it for spec completeness, domain-compliance (against its bounded context's ubiquitous language and relationships), implementation size, and complexity (an abstract low/medium/high reasoning-difficulty estimate persisted in frontmatter for later routing

• task-status

  Read-only progress report for the domain-driven backlog. Runs the bundled tasks.sh helper to print a board — counts per status, the ready-set (todo tasks whose dependencies are all done), and what is blocked on what — derived live from the task files' frontmatter, never by scanning their bodies. The

• whats-next

  Assess the project's vision, domain model, and context map against the current backlog state, surface the coverage gaps, and propose a prioritized list of next tasks to work on. Reads the domain artifacts directly and the backlog through the tasks.sh helper (frontmatter only — never scanning task bo

Subagents (9)

• architecture-proposer

  Read-only seed worker for the architecture-foundation skill. Given the paths to a project's vision.md, domain-model.md, and context-map.md, proposes a FIRST-PASS architecture agenda: first the domain model's still-open hotspots (each cross-checked against the decision index so settled ones are dropp

• boundary-proposer

  Read-only seed worker for the context-mapping skill. Given the paths to a project's domain-model.md and vision.md, proposes a FIRST-PASS bounded-context map: candidate contexts (each a cluster of aggregates/events with a one-line responsibility and its core ubiquitous-language terms), candidate EXTE

• domain-seed-extractor

  Read-only seed worker for the domain-model skill. Given the path to a project's vision.md, reads it and returns a FIRST-PASS big-picture EventStorming proposal: candidate past-tense domain events, the commands/actors that plausibly trigger them, obvious external systems, candidate aggregates (consis

• dossier-scout

  Read-only sweep worker for the dossier skill. Given a subject, a human-confirmed relevance frame, and an approved source list (research-KB paths, repo-local files such as captures/specs/PDFs/vendor docs, and — only when the list sanctions it — the web), sweeps those sources and returns the distillat

• exemplar-drafter

  Read-only seed worker for the exemplar skill. Given an intent (what artifact to exemplify, pinning what) and the project root, reads the relevant strategic artifacts — vision.md, domain-model.md, the target bounded context's file, the on-point architecture topic summaries / ADRs, and the existing ex

• exemplar-scribe

  Write-side worker for the exemplar skill's intake mode. Given the exemplar directory (the artifact already landed on disk) and the list of corrections the interview settled — each with an anchor (heading, element id/selector, quoted text, or file name) and the agreed new value — applies them to the

• integrator

  Integration worker for the task-cycle skill's parallel (multi-worker) mode. Given a base branch and a list of completed task branches (each built in its own git worktree by a task-worker), merges them onto the base ONE AT A TIME. On a clean merge the task is integrated; on a conflict it aborts that

• task-analyzer

  Read-only assessment worker for the task-refine skill. Given one draft task file and the project root, reads the task plus its bounded context (bounded-contexts/), the domain-model.md, and the ADR index, and returns a structured assessment: spec completeness gaps, domain-compliance (does it fit a co

• task-worker

  Implementation worker for the task-cycle skill. Given one task file (already claimed `in progress` by the orchestrator) and a working directory (the current checkout, or a dedicated git worktree), implements exactly that task using strict TDD where the change has testable behavior, verifies it, and

Similar plugins