Composable Workflows: From One Command to a Governed Process
A plugin becomes a workflow when it does more than perform one action: it sequences decisions, delegates bounded work, waits for information, checks results, and reports what happened. This chapter uses the official feature-development, code-review, and Agent SDK plugins to show how that composition works. The practical judgment is whether a workflow makes its triggers, checkpoints, authority, and verification visible—or merely hides a long chain of model calls behind one convenient command.
The difference matters after a plugin reaches outside the session. An MCP call can retrieve a pull request or create a task, but a real development process also has to decide whether the request is clear, which files matter, what architecture fits, whether the user approves the plan, and whether the result deserves review. A workflow gives those decisions a shape. Its quality depends less on the number of components than on what each stage owns and what must be true before the next stage begins.
Feature development makes ambiguity an explicit state
The feature-dev plugin starts from a premise that is easy to skip in ordinary agent use: writing code is not the first problem. The first problem is understanding what should be built and how it fits the existing codebase. Its documented process has seven phases—discovery, codebase exploration, clarifying questions, architecture design, implementation, quality review, and summary—and its command makes several transitions explicit.
In discovery, the workflow identifies the problem, desired behavior, constraints, and requirements. If the request is unclear, the process asks for clarification and confirms its understanding. This is not conversational decoration. An ambiguous request is an unresolved input state. Starting implementation before resolving it forces later stages to guess about scope, edge cases, or compatibility.
In codebase exploration, the workflow launches several code-explorer agents with different questions. One may trace a similar feature, another may map the relevant architecture, and another may examine a related implementation or user-facing pattern. The agents are instructed to return the most important files to read. The main workflow then reads those files to build a deeper understanding rather than treating the agents’ summaries as a substitute for the source.
That handoff is an important ownership boundary. The explorer owns discovery of paths, flows, abstractions, and dependencies. The main process owns the decision about what evidence is sufficient for design. If the workflow only accepted a summary, an agent could omit a critical file and the omission would become invisible. Requiring essential files to be read keeps the evidence path connected to the codebase.
Clarifying questions follow exploration. The workflow looks for underspecified edge cases, error handling, integration points, backward compatibility, design preferences, and performance needs, then waits for answers before architecture design. This waiting point is a form of control. It prevents the model from converting uncertainty into an unannounced implementation choice.
Architecture design then produces multiple approaches with different trade-offs, such as minimal changes, clean separation, or a pragmatic balance.