labrodev-pipelinelisted

Use when a business use case is a staged workflow rather than one atomic mutation — e.g. booking creation that also creates a customer, sends mails, writes logs, and pushes data to an external CRM. Covers Pipeline step classes, the Payload flow-state object, the orchestrating Service that drives them, and where the trio lives (Core/Domain/{Domain} vs Core/Feature for cross-domain workflows).
labrodev/laravel-playbook · ★ 0 · Data & Documents · score 73

Install: claude install-skill labrodev/laravel-playbook

# Pipelines: staged workflows with a Payload and an orchestrating Service Part of the Labrodev playbook. **The law for this component lives in the always-on `labrodev-pipeline` guideline** (musts, must-nots); the per-file checklist is `rules/pipelines.md`. This skill holds the craft: anatomy, canonical templates, and edge cases. A pipeline workflow has exactly three parts: | Part | Class | Lives in | |---|---|---| | Flow state | `{Workflow}Payload` | `Core/Domain/{Domain}/Payloads/` | | Atomic steps | verb-first step classes, no suffix | `Core/Domain/{Domain}/Pipelines/{Workflow}/` | | Orchestrator | `{Workflow}Service` — a **Service** plays the orchestrator role | `Core/Domain/{Domain}/Services/` | There is **no separate Orchestrator class type**. The orchestrating class is a Service and follows every Service rule: single public `__invoke()`, injected and invoked as a callable with named arguments (→ see the labrodev-naming skill). ## When to use a pipeline Reach for this trio when a use case is a **staged workflow** — several distinct steps, each with its own side effect, that must run as one coherent business scenario. Canonical example: registering a booking is not just creating the booking row — it also creates the customer, sends confirmation mail, writes an audit log, and pushes the data to an external CRM. Do NOT use a pipeline for: - a single atomic mutation → a plain Action (→ see the labrodev-action skill); - two steps where the second is a persistence-adja