菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Onboard a developer to an unfamiliar repository, big-picture first. Produces a Purpose/Context section (what the repo is and why it exists), a Big Picture built with C4 diagrams (L1 System Context, L2 Container, optional L3 Component) plus event-reaction flow diagrams for async triggers (stream/queue/schedule/object-event), a Navigating-the-Code section (conventions, lean directory map, testing strategy), a Running-It-Locally checklist with the fast pre-PR loop, a Deploying-It section (deployment model, function/trigger inventory, managed-service graph, envs/secrets, CI/CD), and a Security Posture map — every claim cited to exact files, diagrams before code. Use for "onboard me", "help me understand this repo", "give me an overview", "explain this codebase's architecture", "what architecture pattern does this use", "how is this repo structured", "how do I run this locally", "what's the testing strategy here", "how is this service deployed", "how does CI/CD work here", or "what's the security posture". Read-on
Orchestrate implementation of one hexagonal Rust slice by dispatching agents in the correct order — build the domain core (model + use case + ports) first, then fan out the driven and driving adapters in parallel, then wire bootstrap serially. Use when you want to implement a ports-and-adapters slice with parallel adapter work that does not interfere. Trigger for "implement this slice hexagonally", "build the domain then the adapters in parallel", "scaffold a ports-and-adapters feature end to end". For the layering RULES themselves use rust-hexagonal; this skill is the DISPATCH recipe.
Structure and write user documentation with the Diátaxis framework (Tutorials, How-to guides, Reference, Explanation). Use when documenting content for users, designing the architecture of a docs set, or deciding what kind of doc a piece of content should be. Trigger for: "document this for users", "write a tutorial", "write a how-to guide", "structure our docs", "organize the documentation", "what kind of doc is this", "how should I document X", "audit our docs", "are these docs in the right place". NOT for: API rule extraction from code (use spec-extract), feature specs (use spec-create), or onboarding a developer to a repo (use onboarding).
Design or review Rust services using hexagonal (ports and adapters) architecture with idiomatic ownership, errors, and testing. Use when structuring a Rust project, deciding where a trait or dependency belongs, or auditing layering between domain and infrastructure.
Structure Rust code into cohesive modules and functions. Use when writing new Rust feature code, adding a module or a non-trivial function, deciding how to organize a file, splitting a god-file into a directory module, breaking a long function into an orchestrator plus phase functions, keeping an owned resource (transaction, lock, accumulator) from leaking across boundaries, or reviewing module/function structure. Apply while writing, not only when refactoring. Architecture-agnostic — any Rust code, hexagonal or not.
Interview the user relentlessly about every aspect of a plan, walking down each branch of the design tree and resolving dependencies between decisions one-by-one until a shared understanding is reached. Use when pressure-testing a plan, design, or feature idea before implementation, or before running spec-create. Trigger for "grill me", "interview me about this plan", "poke holes in my design", "challenge my assumptions", "stress-test this approach". NOT for writing code or implementing tasks (use spec-impl).
| name | event-modeling-tasks |
| description | 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. |
Translates a completed event model into implementation tasks. Each slice becomes one task with the specification as its acceptance criteria.
A completed event model document (produced by event-modeling-spec skill) containing:
If the event model is incomplete, use event-modeling-spec first.
<TRIGRAM>-<SHORT_NAME>
| 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
[INFRA], kept minimal.Trace the Given clause of each slice:
Group tasks by dependency depth:
Tasks within the same phase can be implemented in parallel. Order tasks within a phase by: Commands first, then Views, then Automations.
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.
references/output-template.md (includes developer preamble)The task file has two levels per task:
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 | 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 |
| 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 |