Pre-Built Workflow Plugins
Across Phases 1 through 3 you packaged three quality gates as skills: validate-spec, design-review, and self-review. Every one of them started as a prompt you ran manually, then got promoted to .claude/skills/ so the team could reuse it. This is the right pattern for the prompts that are specific to your project and your quality bar.
But not every skill needs to start from your own notes. There are ready-made plugins that package entire SDLC workflows as slash commands — dozens of them, maintained by teams that have been shipping with Claude Code for months. Borrow their work rather than rediscovering it.
The EPCC (Explore-Plan-Code-Commit) plugin is one of the clearest examples. It maps almost one-to-one onto the workflow you just learned:
| Command | Purpose | Our Equivalent |
|---|---|---|
/prd | Generate a Product Requirements Document | Phase 1: Sources → requirements → stories |
/trd | Generate a Technical Requirements Document | Phase 2: Architecture exploration → architecture doc |
/epcc-explore | Map the codebase — code archaeologist | Phase 2: Codebase mapping → architecture doc |
/epcc-plan | Design an implementation plan | Phase 3: Write implementation plan |
/epcc-code | Implement with auto-validation | Phase 3: TDD cycle → implement → verify |
/epcc-commit | Run tests and commit | Phase 3: Self-review → update backlog |
/epcc-resume | Resume interrupted work | (No equivalent) |
Browse the source: epcc-workflow/commands on GitHub . Each .md file is a slash command — read them to see how production teams structure their workflow prompts.
The principle matters more than the specific plugin. Your team's workflow might look different — maybe you need /threat-model or /generate-migration or /write-runbook. The building blocks are the same: a SKILL.md file in .claude/skills/ with a description and a well-crafted prompt. Start with the ones you write yourself (the three you just built), then fill in the gaps with pre-built plugins like EPCC.
| Situation | Recommendation |
|---|---|
| Quality gate specific to your team's standards (review checklists, spec validation) | Write your own — you know the bar |
| Workflow step that's generic across projects (code archaeology, commit conventions, resuming work) | Use a pre-built plugin; borrow battle-tested prompts |
| Workflow step that's generic but you want fine control over behavior | Start from a pre-built plugin, then fork and customize |
| Domain-specific expertise (e.g., AWS CDK patterns, regulated-industry compliance) | Look for community plugins first; if none exist, write your own |
The three skills you built in this workshop fall into the first category: they encode your quality bar for specs, architecture, and implementation. They're yours to keep, version, and evolve. The EPCC-style workflow plugins fall into the second: good starting points that save you writing boilerplate prompts for generic steps.