# Event Modeling Tasks

> Use when translating a completed event model into implementation tasks. Invoke when an event model with slices and specifications exists and needs to become a development plan, task breakdown, or spec-create compatible output.

- Skill: `jrollin/event-modeling-tasks` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add jrollin/event-modeling-tasks`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jrollin/event-modeling-tasks/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: jrollin (https://skillmd.com/u/jrollin)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jrollin/event-modeling-tasks

---


# Event Model to Tasks

Translates a completed event model into implementation tasks. Each slice becomes one task with the specification as its acceptance criteria.

## Input

A completed event model document (produced by **event-modeling-spec** skill) containing:
- Named slices, each with a pattern (Command / View / Automation / Translation)
- Specifications: Given-When-Then for commands/automations, Given-Then for views
- Swim lanes with domain assignments
- Passed completeness check

If the event model is incomplete, use **event-modeling-spec** first.

## Task ID Convention

```
<TRIGRAM>-<SHORT_NAME>
```

- **Trigram:** 3 letters from the feature name (confirm with user if ambiguous)
- **Short name:** Short, readable abbreviation of the slice — prefer a single word when unambiguous, use two words hyphenated when needed

| Slice Name | Short Name | Why |
|------------|-----------|-----|
| RegisterGuest | `REGISTER` | Unambiguous single word |
| InitiateBooking | `BOOK` | "Initiate" is ceremony — "book" is the action |
| RoomAvailability | `AVAIL` | Common abbreviation |
| ConfirmBooking | `CONFIRM` | Unambiguous |
| CancelBooking | `CANCEL` | Unambiguous |
| GuestProfile | `PROFILE` | Unambiguous |
| EarnLoyaltyPoints | `EARN` | Clear in context |
| OpenLoyaltyAccount | `LOYALTY-OPEN` | Two words needed — "open" alone is ambiguous |

Infrastructure tasks use `<TRIGRAM>-INFRA-<NAME>` and go in Phase 0:

| Task | Short Name | Why |
|------|-----------|-----|
| Event persistence setup | `INFRA-EVENTS` | Shared foundation for all slices |
| Automation dispatcher setup | `INFRA-DISPATCH` | Required by all Automation and Translation slices |

Example: `HTL-INFRA-EVENTS`, `HTL-INFRA-DISPATCH`

## Rules

- **One slice = one task.** Do not merge. Do not split. Merging makes it impossible to correctly sequence dependent slices, eliminates parallelism within a phase, and prevents spec-impl from marking partial work as complete.
- **Event names:** Use exactly as named in the model. Do not rename.
- **Specifications → Acceptance criteria:** Copy Given-When-Then verbatim from the event model.
- **No invented concepts:** No aggregates, entities, or schemas not in the model.
- **Infrastructure tasks** go in Phase 0, marked `[INFRA]`, kept minimal.
- **Error case verification per pattern:**
  - Commands: test precondition rejection (Given events missing → rejected)
  - Automations: test idempotency (run robot twice → second run does nothing)
  - Translations: test idempotency (run translator twice → second run does nothing; stub external system in tests)
  - Views: test empty/missing data response (no events → empty result or 404)

## Deriving Dependencies

Trace the Given clause of each slice:

- **Command** depends on: any Command whose events appear in its Given clause
- **View** depends on: all Commands producing the events it reads
- **Automation** depends on: the Commands producing events for its todo-list view

## Phasing

Group tasks by dependency depth:
- Phase 1: slices with no dependencies
- Phase 2: slices depending only on Phase 1
- Phase N: slices depending on Phase N-1

Tasks within the same phase can be implemented in parallel. Order tasks within a phase by: Commands first, then Views, then Automations.

## Process

> **Always include the "How to Read These Tasks" preamble** in every generated task file — never omit it. The preamble is the primary guide for developers unfamiliar with Event Modeling. It is not optional.

1. **Assign trigram** — Confirm with user
2. **List slices** — ID, pattern, swim lane
3. **Build dependency graph** — Trace Given clauses
4. **Phase by depth**
5. **Write task file** — Using `references/output-template.md` (includes developer preamble)
6. **Add [INFRA] tasks** in Phase 0 if needed
7. **Generate Mermaid dependency graph**

## Output Format

The task file has two levels per task:
- **Table row** — for spec-impl scanning: task ID, status, one-line verification summary, blocked-by
- **Detailed section** — for developer/agent: Build instructions, verbatim acceptance criteria, full verification list

The `Blocked by:` in the Notes column is the **source of truth** for dependencies. The Mermaid graph is generated from it.

See `references/output-template.md` for the full template with preamble.

## Reference

| Reference | Load When |
|-----------|-----------|
| `references/output-template.md` | Generating the task file — template with developer preamble, table + detail format |
| `references/tasks-example.md` | Full Hotel Booking example — 18 tasks across 6 phases with Mermaid dependency graph |

## Common Mistakes

| Mistake | Fix |
|---------|-----|
| Merging slices into one task | One slice = one task. Merging breaks sequencing, parallelism, and atomic completion |
| Renaming events from the model | Use event names verbatim — the model IS the contract |
| Introducing aggregates not in the model | Event Modeling doesn't prescribe aggregates |
| Dropping specifications from tasks | Copy Given-When-Then exactly as acceptance criteria |
| Applying Command error tests to Views | Commands: test rejection. Automations: test idempotency. Views: test empty response |
| Business logic in the automation robot | Robot just reads todo and calls command. Logic lives in handler |
| Preamble missing from task file | Always include "How to Read These Tasks" for the developer |
| Inconsistent task ordering within phases | Commands first, then Views, then Automations |