@lenardangeloolajay/len-toolkit 1.1.0

package/templates/skills/domain-driven-design/domain-driven-design.mini.md

@@ -0,0 +1,48 @@
+# OBEY Domain-Driven Design by Eric Evans
+
+## When to use
+
+Use when business complexity, model language, lifecycle rules, or cross-team/system boundaries shape the design more than generic technical organization.
+
+## Primary bias to correct
+
+Keep domain behavior, code, tests, documents, and team language aligned inside explicit Bounded Contexts. Do not let persistence, UI, frameworks, integration formats, or DDD vocabulary replace an implementation-driving model.
+
+## Decision rules
+
+- Use a model only when it organizes domain knowledge, clarifies communication, and can be expressed in implementation; iterate through code, expert conversation, scenarios, and refactoring toward deeper insight.
+- Maintain one Ubiquitous Language per Bounded Context across names, tests, documents, diagrams, planning, and feature discussion; keep explanatory models separate from the implementation model.
+- Put business logic in the domain layer. Keep UI, application coordination, infrastructure, persistence, messaging, and framework constraints outside the model or behind adapters.
+- Use tactical patterns for model meaning: Entities for stable identity, Value Objects for immutable descriptive value, Services for important operations with no natural object home, and Modules for conceptual cohesion.
+- Manage lifecycle through Aggregates, Factories, and Repositories: expose only Aggregate roots, enforce invariants inside the boundary, hide complex creation and persistence, and prevent partially formed objects from escaping.
+- Design domain objects for the model first and persistence second; preserve identity, Aggregate boundaries, Value Object semantics, and domain query criteria instead of exposing database structure.
+- Refactor toward deeper domain insight, not only mechanical cleanliness. Make constraints, policies, processes, calculations, allocations, and generation rules explicit when they carry domain meaning.
+- Design for model users: name operations by domain purpose, separate side-effect-free functions from state-changing commands, make assertions explicit, and shape boundaries around conceptual contours.
+- Define every Bounded Context explicitly. Do not assume a term has the same meaning elsewhere; use context maps, tests, and active communication to protect model integrity.
+- Choose context relationships deliberately: Shared Kernel, Customer/Supplier, Conformist, Anticorruption Layer, Separate Ways, Open Host Service, Published Language, or incremental legacy replacement.
+- Distill and protect the Core Domain by strategic value. Keep generic subdomains, infrastructure, reusable mechanisms, and supporting details from consuming core-domain attention.
+- Add large-scale structure only when individual objects no longer make a large model understandable; keep structures domain-specific, evolvable, and valid only inside compatible contexts.
+- Use analysis patterns, design patterns, specifications, industry formalisms, and prior art only when they clarify the current model and preserve domain language.
+- Test the model in the Ubiquitous Language: prioritize domain tests for invariants, allowed and forbidden transitions, valid construction, specifications, application orchestration, and boundary translation before generic infrastructure checks.
+- Make major strategic moves with people who understand both the implementation and the domain; architecture and framework guidance must serve application teams and domain goals.
+
+## Trigger rules
+
+- When terminology is awkward, ambiguous, inconsistent, or repeatedly translated, refine the Ubiquitous Language and rename code before adding more behavior.
+- When controllers, services, scripts, SQL, jobs, or serializers carry business decisions, move rules into domain objects, domain services, specifications, or explicit domain concepts.
+- When UI, persistence, messaging, APIs, or frameworks start shaping domain concepts, isolate them with layers, adapters, translation, or an Anticorruption Layer.
+- When a change crosses unrelated modules, many objects, or multiple roots, reassess Module cohesion, Aggregate ownership, consistency timing, and context boundaries.
+- When clients know creation, lifecycle, persistence, identity generation, or internal mutation details, repair Factories, Repositories, roots, and encapsulation.
+- When new behavior is hard to explain, test, or extend, search for a deeper model, missing implicit concept, or breakthrough refactoring instead of adding procedural branches.
+- When integrating with another model, choose the relationship, translation strategy, published language or protocol, and boundary tests before writing boundary code.
+- When changing invariants, lifecycle transitions, specifications, orchestration, or context translation, add domain-language tests that prove valid behavior and block invalid states.
+- When generic mechanisms, reusable frameworks, or supporting subdomains obscure distinctive value, distill the Core Domain or separate the mechanism.
+
+## Final checklist
+
+- Is domain behavior explicit in the model rather than hidden in delivery, persistence, or integration code?
+- Do code, tests, documents, and conversations use one language inside each Bounded Context?
+- Do tactical patterns protect identity, value semantics, lifecycle, invariants, and responsibility instead of adding ceremony?
+- Does every cross-context integration have an explicit relationship, translation strategy, and boundary test?
+- Do tests read like executable examples of the model and cover invalid transitions or construction?
+- Is the Core Domain visible and protected from supporting complexity, generic mechanisms, infrastructure, and frameworks?

package/templates/skills/domain-driven-design/domain-driven-design.nano.md

@@ -0,0 +1,39 @@
+# OBEY Domain-Driven Design by Eric Evans
+
+## When to use
+
+Use as always-on DDD guidance when domain language, invariants, lifecycle, or integration boundaries affect implementation choices.
+
+## Primary bias to correct
+
+Generic plumbing and DDD terminology are not a domain model.
+
+## Decision rules
+
+- Keep model, code, tests, documents, and team language aligned inside each Bounded Context.
+- Make business behavior explicit in model code, not hidden in controllers, persistence, jobs, scripts, or framework glue.
+- Refine Ubiquitous Language when terms are fuzzy, and use only models that solve the problem and can be implemented.
+- Use tactical patterns for domain meaning: Entities for identity, Value Objects for value, Services for homeless operations, and Modules for conceptual cohesion.
+- Treat Aggregates as consistency and lifecycle boundaries; expose roots only and protect invariants inside the boundary.
+- Hide complex creation and persistence behind Factories and Repositories; design for the model first and storage second.
+- Define context boundaries and relationships explicitly before sharing terms, data, or behavior across systems.
+- Protect the Core Domain from generic subdomains, reusable mechanisms, infrastructure, framework pressure, and foreign models.
+- Refactor toward deeper insight: make important constraints, policies, processes, and calculations explicit domain concepts.
+- Test invariants, invalid construction, lifecycle transitions, and boundary translations in the Ubiquitous Language.
+
+## Trigger rules
+
+- Fuzzy or inconsistent terms trigger language refinement and code renaming.
+- Procedural business rules in orchestration, SQL, jobs, or serializers trigger moving behavior into the model.
+- Sprawling transactions or cross-module changes trigger Aggregate and context-boundary review.
+- Foreign model, schema, API, or legacy pressure triggers translation or an explicit Conformist choice.
+- Supporting mechanisms obscuring distinctive value trigger Core Domain distillation.
+
+## Final checklist
+
+- Domain behavior in the model?
+- One language per context?
+- Invariants protected by roots and values?
+- Integration relationship explicit?
+- Domain tests cover invalid states and translations?
+- Core Domain still visible?

package/templates/skills/domain-driven-design-distilled/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: domain-driven-design-distilled
+description: Apply Vaughn Vernon-inspired lightweight DDD rules when using bounded contexts, subdomains, context maps, and tactical modeling without excess ceremony.
+license: MIT
+---
+
+# Domain-Driven Design Distilled Skill
+
+Use this skill when a task needs practical DDD guidance for subdomains, bounded contexts, context mapping, aggregates, domain events, or tactical modeling with restrained ceremony.
+
+Before making design or code decisions, read and apply [domain-driven-design-distilled.mini.md](domain-driven-design-distilled.mini.md). Use [domain-driven-design-distilled.md](domain-driven-design-distilled.md) only as a deeper reference when the mini rules are not enough for the current DDD tradeoff.

package/templates/skills/domain-driven-design-distilled/domain-driven-design-distilled.md

@@ -0,0 +1,317 @@
+# OBEY Domain-Driven Design Distilled by Vaughn Vernon
+
+## Purpose
+
+This repository follows **Domain-Driven Design Distilled**:
+use the smallest effective set of DDD practices to model the business meaning clearly and deliver results quickly.
+
+All code generation, edits, and reviews must optimize for:
+- clear business language
+- explicit bounded contexts
+- focus on core domain complexity
+- selective use of tactical DDD patterns
+- practical implementation over ceremony
+- collaboration between model and software design
+
+This file is a binding engineering policy: `MUST` is binding, `SHOULD` is a strong default, and `MUST NOT` is forbidden.
+
+---
+
+## Primary Directive
+
+Use DDD where it clarifies complex business software.
+Do not turn DDD into ritual.
+
+When uncertain:
+1. identify the business capability or subdomain
+2. decide whether it is core, supporting, or generic
+3. define the bounded context
+4. use the local ubiquitous language
+5. apply only the tactical patterns that actually earn their cost
+
+Reject both extremes:
+- no modeling when the domain is complex
+- full-blown DDD ceremony when the problem is simple
+
+---
+
+## Adoption Fit and Modeling Investment
+
+1. Use DDD when domain complexity, language ambiguity, business differentiation, or integration risk justify the modeling effort.
+2. Do not apply full tactical DDD to simple CRUD, generic subdomains, or problems whose complexity is mainly technical.
+3. Let business drivers decide where modeling effort goes.
+4. Reassess the model when the core business concern drifts, terms stop matching code, or supporting complexity hides the core.
+5. Use scenarios and acceptance tests to validate that the model expresses real business behavior.
+
+---
+
+## Strategic Rules
+
+### Start with Subdomains
+Classify major areas as:
+- core domain
+- supporting subdomain
+- generic subdomain
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+1. Invest the most design effort in the core domain.
+2. Keep supporting and generic subdomains simpler unless complexity proves otherwise.
+3. Do not waste the best modeling effort on commodity concerns.
+
+### Define Bounded Contexts Early
+1. Every meaningful model lives inside a bounded context.
+2. A bounded context owns its language, rules, and model semantics.
+3. The same term may mean different things in different contexts.
+4. Code structure must reflect context boundaries.
+
+### Use Context Mapping
+1. Make context relationships explicit.
+2. Translate where meanings differ.
+3. Own integration contracts deliberately.
+4. Protect the local model from foreign language.
+
+Anti-patterns (MUST NOT):
+- one model reused across billing, identity, catalog, fulfillment, and support
+- shared domain classes with subtly different meanings
+- context boundaries documented but ignored in code
+
+---
+
+## Context Relationship Rules
+
+Choose context relationships deliberately:
+
+- USE Partnership only when teams can coordinate closely and share planning burden.
+- USE Shared Kernel only for a small stable overlap with joint ownership and tests.
+- USE Customer/Supplier when the upstream team can plan for downstream needs.
+- USE Conformist when adopting the upstream model is cheaper and safer than translation.
+- USE Anticorruption Layer when a foreign model would corrupt the local language.
+- USE Open Host Service when many clients need a stable protocol into one context.
+- USE Published Language when multiple systems need a documented interchange model.
+- USE Separate Ways when integration cost is higher than shared capability value.
+- TREAT Big Ball of Mud as a context to contain and translate around, not as a model to spread.
+
+Anti-patterns (MUST NOT):
+- claiming independent modeling while conforming silently
+- using Shared Kernel without governance
+- calling integration an anticorruption layer when no translation exists
+
+---
+
+## Integration Style Rules
+
+1. Use RPC only when request/response coupling, latency, versioning, and failure semantics are acceptable.
+2. Use REST resources as application-facing representations, not as leaked aggregate internals.
+3. Use messaging when asynchronous coordination fits the business process and consumers can handle lag, duplicates, and ordering limits.
+4. Decide whether domain events should carry enough information for consumers or require query-back.
+5. Keep integration contracts separate from internal models.
+6. Test translations at context boundaries.
+
+---
+
+## Ubiquitous Language Rules
+
+1. Use domain terms from the current bounded context in code, tests, commands, events, and conversations.
+2. One concept gets one term.
+3. One term must not carry multiple meanings inside one context.
+4. Rename code when understanding improves.
+5. Prefer domain names over technical placeholders.
+
+Avoid:
+- technical placeholders that conceal a business concept
+- names imported from another bounded context without translation
+- generic helper or utility names that end up carrying domain decisions
+
+---
+
+## Tactical Pattern Rules
+
+### Entities
+Use entities when identity and lifecycle matter.
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+1. Entities must have explicit identity.
+2. Entities must protect meaningful state transitions.
+3. Do not expose unrestricted state changes by default.
+
+### Value Objects
+Use value objects aggressively when a primitive hides meaning.
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+1. Value objects are immutable by default.
+2. They validate themselves.
+3. They make code read in domain language.
+
+### Aggregates
+Use aggregates only where invariants require a consistency boundary.
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+1. Keep aggregates small.
+2. Protect invariants through the aggregate root.
+3. Reference other aggregates by identity.
+4. Avoid loading large object graphs.
+
+### Domain Events
+Use domain events for meaningful facts.
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+1. Name events in the past tense.
+2. Use events when they clarify collaboration or integration.
+3. Do not publish trivial noise for every field change.
+
+## Aggregate Minimalism Rules
+
+1. Do not create large aggregates to make navigation convenient.
+2. Default to smaller boundaries.
+3. Default to eventual consistency across aggregates.
+4. Use IDs for references across aggregate boundaries.
+5. One transaction should usually change one aggregate.
+
+Anti-patterns (MUST NOT):
+- aggregate designed around a screen
+- one request loading and mutating a whole graph
+- aggregate roots exposing mutable children directly
+
+---
+
+## Application Service Rules
+
+1. Application services coordinate use cases.
+2. They load aggregates, call domain behavior, save results, and trigger integration work.
+3. They must not become the real domain model.
+4. They should stay thin enough that the model still carries meaning.
+
+Anti-patterns (MUST NOT):
+- all business decisions in application services
+- controllers duplicating application orchestration
+- application services shaped only by transport
+
+---
+
+## Architecture and Infrastructure Rules
+
+1. Infrastructure is a detail.
+2. Keep frameworks, persistence mechanics, REST resources, transport formats, and other technology concerns out of the domain model.
+3. Persist aggregates without letting persistence define the model.
+4. Translate transport and integration data at the boundary.
+
+Anti-patterns (MUST NOT):
+- persistence-first modeling
+- reusing transport objects as domain objects
+- domain methods depending on framework types
+
+---
+
+## Collaboration Rules
+
+1. Keep names close to real business terms.
+2. Prefer code that teaches the model to a reader.
+3. Make domain assumptions explicit in names, tests, and events.
+4. Where a concept is fuzzy, do not hide the ambiguity behind technical abstractions.
+
+Anti-patterns (MUST NOT):
+- generic code that could belong to any business
+- unexplained status codes and flags with domain meaning
+- enums and booleans where a richer concept is needed
+
+---
+
+## Practicality Rules
+
+1. Use the least expensive pattern that honestly models the problem.
+2. Simple domains may use simple services and data structures.
+3. Once invariants, lifecycle, and language complexity rise, strengthen the model.
+4. Prefer incremental improvement over massive design overhauls.
+
+Anti-patterns (MUST NOT):
+- dismissing DDD because not every module needs it
+- over-modeling a generic subsystem
+- introducing aggregates and events before knowing why
+
+---
+
+## Accelerated Modeling and Project Rules
+
+1. Use event storming or similar collaborative modeling when workflow, events, commands, policies, or team language are unclear.
+2. Timebox modeling work so it improves implementation instead of becoming detached analysis.
+3. Use modeling spikes to reduce uncertainty before committing to a model shape.
+4. Track modeling debt when code and language are known to be imperfect but intentionally deferred.
+5. Involve domain experts in scenario walkthroughs, terminology decisions, and acceptance criteria.
+6. Estimate DDD work by modeling uncertainty, integration risk, and implementation cost, not only by feature count.
+7. Treat team skill and access to domain experts as constraints on how much DDD ceremony the project can sustain.
+
+---
+
+## Code Generation Rules
+
+When generating code, use this default order:
+1. identify the subdomain
+2. identify the bounded context
+3. write names in the local ubiquitous language
+4. decide whether a concept is entity, value object, aggregate, service, repository, or event
+5. choose the smallest tactical pattern that fits
+6. isolate infrastructure at boundaries
+7. keep context translation explicit
+
+Default avoidance:
+- giant shared domain packages
+- service-centric fake DDD
+- technical names replacing domain language
+- full tactical DDD in trivial modules
+
+---
+
+## Review Rules
+
+When reviewing code, actively look for:
+- missing subdomain classification
+- missing bounded context ownership
+- context bleeding
+- no context translation where meanings differ
+- primitive obsession
+- anemic entities
+- no value objects where concepts repeat
+- aggregates too large
+- services containing all behavior
+- excessive ceremony in simple modules
+- no modeling at all in complex modules
+
+---
+
+## Testing Rules
+
+1. Domain tests must read in the ubiquitous language.
+2. Test value objects for validation and behavior.
+3. Test entities and aggregates for valid and invalid transitions.
+4. Test application services for orchestration, not for all domain rules.
+5. Test context translation where external or foreign models exist.
+
+---
+
+## Review Checklist
+
+Before finalizing any change, verify:
+- Is the subdomain/core importance understood?
+- Is the bounded context explicit?
+- Is the ubiquitous language visible in the code?
+- Did we use only the tactical patterns that genuinely help?
+- Are aggregates small and focused on invariants?
+- Are value objects used where they clarify meaning?
+- Are application services coordinating rather than owning all domain logic?
+- Did we keep infrastructure out of the model?
+- Did we avoid DDD theater and over-modeling?
+
+If any answer is no, revise before shipping.
+
+---
+
+## Final Instruction
+
+When uncertain, choose the option that:
+1. sharpens the business language
+2. clarifies the bounded context
+3. models real complexity honestly
+4. avoids unnecessary ceremony
+5. keeps the design practical enough to deliver
+
+Use DDD selectively, but seriously.

package/templates/skills/domain-driven-design-distilled/domain-driven-design-distilled.mini.md

@@ -0,0 +1,56 @@
+# OBEY Domain-Driven Design Distilled by Vaughn Vernon
+
+## When to use
+
+Use when business software has enough domain complexity, language ambiguity, strategic differentiation, or integration risk that modeling changes implementation decisions, but the project still needs the smallest effective DDD practice rather than ceremony.
+
+## Primary bias to correct
+
+Use DDD selectively, but seriously. Start from business capability, subdomain importance, bounded context, and local language before tactical patterns, frameworks, persistence, APIs, or class shapes.
+
+## Decision rules
+
+- Before designing code, identify the business capability, classify the subdomain as Core, Supporting, or Generic, define the Bounded Context, use its Ubiquitous Language, and choose only tactical patterns that earn their cost.
+- Put the most modeling effort into the Core Domain. Keep Supporting and Generic Subdomains simpler unless their own complexity proves otherwise.
+- Do not apply full tactical DDD to simple CRUD, generic subsystems, or mainly technical problems; strengthen the model only when invariants, lifecycle, language complexity, or integration risk justify it.
+- Give every meaningful model one explicit Bounded Context. The context owns its language, rules, semantics, code structure, tests, and integration contracts.
+- Treat the same word in different contexts as potentially different concepts. Translate at context boundaries instead of sharing domain classes or leaking foreign language into the local model.
+- Choose context relationships deliberately: Partnership, Shared Kernel, Customer/Supplier, Conformist, Anticorruption Layer, Open Host Service, Published Language, Separate Ways, or Big Ball of Mud containment all imply different ownership and translation duties.
+- Select integration style from business coupling and failure semantics: RPC requires acceptable request/response coupling; REST resources must not expose Aggregate internals; messaging must tolerate lag, duplicates, and ordering limits.
+- Keep integration contracts separate from internal models and test translations wherever meanings cross a boundary.
+- Use local domain terms in code, tests, Commands, Domain Events, APIs, and conversations. One concept gets one term, one term does not carry multiple meanings inside a context, and code is renamed when understanding improves.
+- Use Entities when identity and lifecycle matter; make identity explicit and protect meaningful state transitions rather than exposing unrestricted setters.
+- Use immutable, self-validating Value Objects when primitives hide domain meaning.
+- Use Aggregates only as invariant and transactional consistency boundaries. Keep them small, modify through the root, reference other Aggregates by identity, avoid large object graphs, and usually change one Aggregate per transaction.
+- Use Domain Events for meaningful past-tense business facts that clarify collaboration or integration; do not publish noisy field-change events.
+- Application Services coordinate use cases by loading Aggregates, invoking domain behavior, saving results, and triggering integration work. They must not become the real domain model.
+- Keep frameworks, persistence mechanics, transport formats, REST representations, and infrastructure types out of the domain model. Translate external data at the boundary and persist Aggregates without letting storage define the model.
+- Prefer code that teaches the model: make domain assumptions explicit in names, tests, and events; expose richer concepts instead of hiding meaning behind flags, status codes, booleans, enums, helpers, or utilities.
+- Use Event Storming, scenarios, acceptance tests, modeling spikes, and domain-expert walkthroughs when workflow, terminology, policies, or acceptance criteria are unclear. Timebox modeling and track modeling debt instead of drifting into detached analysis.
+- Estimate and plan DDD work from modeling uncertainty, integration risk, implementation cost, team skill, and access to domain experts, not only from feature count.
+
+## Trigger rules
+
+- When language is fuzzy, generic, overloaded, or imported from another context, pause coding and sharpen the local Ubiquitous Language.
+- When the core concern drifts, terms stop matching code, or supporting complexity hides the core, reassess subdomains, boundaries, and modeling investment.
+- When one model spreads across billing, identity, catalog, fulfillment, support, permissions, or other separate concerns, split or translate instead of reusing shared domain classes.
+- When an upstream model, schema, UI, framework, API payload, transport object, or database shape starts defining the domain model, restore boundary translation.
+- When using Shared Kernel, require small stable overlap, joint ownership, and tests; without governance, choose another relationship.
+- When calling something an Anticorruption Layer, verify that real translation exists.
+- When a request wants to load and mutate a large graph or several Aggregate roots, revisit the invariant boundary and ask whether eventual consistency is acceptable.
+- When controllers, helpers, services, or transport-shaped application services contain business decisions, move behavior into the domain model or name the missing concept.
+- When a Domain Event is command-like, vague, trivial, or emitted for every field change, redesign it as a specific business fact or remove it.
+- When a concept is represented as a primitive, flag, status code, enum, or boolean but carries domain rules, promote it to a richer concept or Value Object.
+- When delivery pressure tempts the team to skip design, use a short modeling spike, scenario, or acceptance test and record known modeling debt.
+
+## Final checklist
+
+- Correct subdomain and Core Domain investment?
+- Explicit Bounded Context and relationship to neighboring contexts?
+- Ubiquitous Language visible in code, tests, Commands, Events, APIs, and conversations?
+- Translation tested where external or foreign meanings cross boundaries?
+- Tactical patterns used only where they clarify meaning or protect invariants?
+- Aggregates small, root-protected, identity-referenced, and not graph-shaped?
+- Application Services coordinating rather than owning business logic?
+- Infrastructure, persistence, REST, and transport details kept out of the domain model?
+- Modeling discoveries, acceptance tests, expert input, and modeling debt captured before shipping?

package/templates/skills/domain-driven-design-distilled/domain-driven-design-distilled.nano.md

@@ -0,0 +1,41 @@
+# OBEY Domain-Driven Design Distilled by Vaughn Vernon
+
+## When to use
+
+Use as compact DDD guidance when business language, context ownership, invariants, or integration meaning can affect the code.
+
+## Primary bias to correct
+
+DDD is selective modeling for real business complexity, not decorative layers, framework shape, or blanket tactical ceremony.
+
+## Decision rules
+
+- Start from business capability, subdomain type, Bounded Context, and local Ubiquitous Language before tactical patterns.
+- Invest most design effort in the Core Domain; keep Supporting, Generic, CRUD, and mainly technical areas simpler.
+- Put every meaningful model inside one explicit Bounded Context that owns its language, rules, semantics, code, tests, and integration contracts.
+- Translate between contexts when meanings differ; never share domain classes or terms whose meanings diverge.
+- Choose context relationships and integration mechanisms deliberately, including Conformist or Anticorruption Layer when foreign meaning is involved.
+- Keep integration contracts separate from internal models, and do not expose Aggregate internals through REST or transport payloads.
+- Use Entities for identity, Value Objects for validated meaning, Aggregates for small invariant boundaries, and Domain Events for meaningful past-tense facts.
+- Modify one Aggregate per transaction by default; reference other Aggregates by identity and use eventual consistency when the business allows it.
+- Keep business decisions in the domain model; Application Services coordinate use cases.
+- Keep frameworks, persistence, transport, and external schemas out of the domain model.
+- Use scenarios, acceptance tests, Event Storming, spikes, and domain-expert walkthroughs to learn quickly without hiding modeling debt.
+
+## Trigger rules
+
+- When language is fuzzy or overloaded, sharpen terms before coding.
+- When one model absorbs unrelated concerns, redraw the subdomain or context boundary.
+- When foreign models, schemas, APIs, or frameworks drive domain shape, add boundary translation.
+- When a transaction wants many roots or a large graph, revisit Aggregate boundaries and consistency timing.
+- When services, controllers, setters, flags, or primitives carry business decisions, expose the missing domain concept.
+- When events are vague, command-like, or noisy field changes, redesign them as specific business facts.
+
+## Final checklist
+
+- Clear subdomain?
+- Clear context?
+- Clear language?
+- Clear translation?
+- Clear invariant boundary?
+- Clear modeling debt?

package/templates/skills/implementation-plan/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: implementation-plan
+description: >
+  Create, execute, or resume a phased plan from Len's approved feature spec.
+  Use for implementation planning, phase execution, or plan status.
+  Requires approval before execution, then continues through verified phase
+  commits until completion or a real blocker.
+license: MIT
+---
+
+# Implementation planning and execution
+
+Read project `AGENTS.md` and the current handoff for authority, commits, recovery, and evidence policy.
+For planning, read the approved product baseline, architecture, and feature spec before choosing tasks.
+An approved spec alone does not approve a new plan.
+
+## Create a plan
+
+Use `.agents/templates/docs/IMPLEMENTATION_PLAN.md`, installed by `len-toolkit start`.
+In the toolkit source checkout, the same source template is `templates/docs/IMPLEMENTATION_PLAN.md`.
+Write the active feature plan under `docs/plans/FEAT-NNN-implementation.md` unless an existing convention applies.
+Keep a root `IMPLEMENTATION_PLAN.md` pointer when useful; do not maintain a second task checklist there.
+Link tasks and verification to stable requirement IDs.
+Choose the number of phases by testable outcomes, with one phase sufficient for small work.
+Inspect actual branch, existing edits, scripts, and environment before filling commands; unresolved placeholders cannot pass a readiness gate.
+Present the feature spec and plan to Len for chat approval and record exact approved revisions in the current handoff.
+
+## Execute or resume
+
+Reread the approved files and reconcile plan state with actual Git status and evidence.
+Do not treat a checked box as proof that a command ran or a commit succeeded.
+Implement only the approved phase, verify with its required commands or scenarios, and review the diff for correctness and Ponytail simplicity.
+Update evidence, task progress, and handoff; stage only the reviewed phase paths and verify the staged diff.
+Complete the checkpoint only when Git confirms the phase commit succeeded.
+Proceed automatically through the remaining approved phases without requesting routine sign-off.
+If execution is interrupted, preserve edits uncommitted and record the exact next step.
+
+## Failure report
+
+Follow the shared three-attempt limit, counting attempted corrections followed by a check for the same problem.
+Report the failed requirement or gate, actual error, each attempt and result, outstanding edits, dependent work blocked, and the smallest decision or access needed.
+Do not reset counts between sessions or substitute a different architecture to force progress.

package/templates/skills/implementing-domain-driven-design/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: implementing-domain-driven-design
+description: Apply Vaughn Vernon-inspired implementation DDD rules when building aggregates, domain events, repositories, application services, or context integrations.
+license: MIT
+---
+
+# Implementing Domain-Driven Design Skill
+
+Use this skill when a task involves implementing DDD in code: aggregate boundaries, invariants, repositories, domain events, application services, modules, factories, or bounded-context integration.
+
+Before making design or code decisions, read and apply [implementing-domain-driven-design.mini.md](implementing-domain-driven-design.mini.md). Use [implementing-domain-driven-design.md](implementing-domain-driven-design.md) only as a deeper reference when the mini rules are not enough for the current implementation tradeoff.