URL: https://nick-tune.me/blog/2026-03-01-workflow-dsl-domain-driven-claude-code-workflows/ Author: Nick Tune Date: March 1, 2026 Evaluated: 2026-03-16 Score: 3/5 — Pertinent, selective integration recommended
- Introduces a TypeScript DSL for defining Claude Code workflow states declaratively: each state specifies an emoji identifier, agent instruction file path, allowed state transitions, permitted operations, and transition guard functions.
- Three-module architecture:
workflow-engine(executes rules, domain-agnostic),workflow-dsl(language for defining steps),workflow-definition(aggregate root with actual workflow logic and invariants). - Type safety via TypeScript
as constunion types — invalid state transitions fail at compile time, not at runtime. - Domain-Driven Design framing: workflow as explicit aggregate root, adapter pattern decouples it from Claude Code infrastructure.
- Observability built-in: every operation appends to an internal event log (operation type, timestamp, contextual details). Enables replay and audit of workflow runs.
- "State ownership principle": each state validates its own preconditions rather than relying on defensive checks in the engine.
- Instruction re-injection on every state transition AND on command failure — distinct mechanism from context-compaction re-injection (compensates for runtime agent context loss, not compression).
- Black-box testing via public
Workflowclass methods; no internal state testing. - References GitHub repo
NTCoding/autonomous-claude-agent-teamfor full implementation. - Follow-up to: https://nick-tune.me/blog/2026-02-28-hook-driven-dev-workflows-with-claude-code/ (already evaluated separately).
| Score | Signification |
|---|---|
| 5 | Essentiel - Gap majeur dans le guide |
| 4 | Très pertinent - Amélioration significative |
| 3 | Pertinent - Complément utile |
| 2 | Marginal - Info secondaire |
| 1 | Hors scope - Non pertinent |
Score: 3/5
Justification: Conceptually interesting pattern (DSL + DDD for agent orchestration), but zero community adoption verified, three-module architecture adds real cognitive overhead for most users, and the guide's architecture section already correctly warns against complex state machines as a default. The value is in three extractable patterns — not in adopting the full architecture.
| Aspect | This Resource | Our Guide |
|---|---|---|
| TypeScript DSL for workflow states | ✅ Full implementation | ❌ Not covered |
| Compile-time state transition validation | ✅ Via union types | ❌ Not covered |
| Workflow as DDD aggregate root | ✅ Full pattern | ❌ Not covered |
| Event log observability for agent runs | ✅ Built-in design | ❌ Not covered |
| Instruction re-injection on failure | ✅ Explicit pattern | ❌ Not covered (only on compaction) |
| Hook-driven agent orchestration | Complementary | ✅ Covered (hooks section) |
| Complex state machine warnings | Not mentioned | ✅ Covered (architecture.md:1227) |
| Event-driven agent patterns | Partial overlap | ✅ Covered (event-driven-agents.md) |
Selective extraction — no new top-level file warranted until community adoption exists.
Three surgical integrations, in priority order:
Where: Hooks documentation or guide/workflows/event-driven-agents.md
What: The pattern of appending every agent operation to an internal event log (with type + timestamp + context) is a debugging and auditability technique the guide covers nowhere. Extract this as a standalone pattern, independent of the DDD framing.
Where: guide/workflows/event-driven-agents.md or hooks best practices
What: Re-injecting agent instructions on command failure (not just context compaction) addresses runtime context drift. Distinct from the existing compaction re-injection pattern — worth a paragraph with the distinction explicit.
Where: guide/core/architecture.md near line 1227 (state machines section)
What: The architecture guide warns against complex state machines. A callout acknowledging that TypeScript union types can make simple state transitions compile-safe is a useful nuance — without endorsing the full three-module pattern.
Core finding from the challenge: The evaluation was initially conflated with the previous Nick Tune article (2026-02-28, hook-driven workflows). These are two distinct posts, and this DSL article is architecturally different — the hook article is about wiring, this one is about state definition language.
Score assessment: 3/5 holds. The argument for 4/5 is that compile-time state validation via as const union types is genuinely novel. The argument against: zero community validation, real cognitive complexity in the three-module design, and DDD framing is academic overhead for most Claude Code users.
Key correction from challenge: The event log observability is underweighted in the initial read. It is the most actionable extraction, worth leading any integration pitch. The DDD framing is secondary.
Risk of not integrating: Low overall. The only real cost is missing the event log observability pattern. The full architecture can be safely skipped until adoption grows.
| Claim | Verified | Source |
|---|---|---|
| Author: Nick Tune | ✅ | Article byline |
| Published: March 1, 2026 | ✅ | Article metadata |
| Three-module architecture (engine/dsl/definition) | ✅ | Article content |
TypeScript as const for union types |
✅ | Article + code examples |
| GitHub repo: NTCoding/autonomous-claude-agent-team | ✅ | Article links |
| Reference to Yves Reynhout (Bluesky, event sourcing) | ✅ | Article attribution |
| No numerical benchmarks or percentages cited | ✅ | Article contains none |
| Follow-up to 2026-02-28 hook-driven article | ✅ | Article references it explicitly |
No hallucinated statistics. No unverifiable claims. Article is descriptive (architectural patterns) with no performance benchmarks.
- Score: 3/5
- Action: Integrate selectively (3 surgical extractions — event log, failure re-injection, state validation callout)
- Confidence: High
- Note: Do not create a new top-level
workflow-dsl.mdfile. Distribute the three patterns into existing sections where they add context without requiring readers to adopt the full DDD architecture.