5 Agent Skill Design Patterns Every ADK Developer Should Know

Google Cloud Tech’s original thread was not about a single workflow trick. It outlined five recurring Agent Skill design patterns that show up across the ADK ecosystem and explained how each pattern solves a different problem.

The key point is simple: formatting a SKILL.md file is no longer the hard part. With many agent tools standardizing around the same structure, the real challenge is how you design the logic inside the skill.

This ClawList version keeps the original thread’s structure and examples, while lightly editing the language into a readable article format.

The shift: from skill packaging to skill design

Google Cloud Tech argues that developers often focus too much on YAML, directory structure, and spec compliance. That made sense when the format itself was new.

But once the packaging layer becomes standardized, the harder question becomes: how should a skill think and act?

A FastAPI convention helper, a document generator, and a strict review pipeline may all share the same outer file format, but they work very differently internally. That is where design patterns matter.

According to the thread, five patterns show up again and again across the ecosystem:

• Tool Wrapper
• Generator
• Reviewer
• Inversion
• Pipeline

1) Tool Wrapper: make the agent an expert on a library

A Tool Wrapper gives the agent on-demand context for a specific library or framework.

Instead of stuffing framework rules into the global prompt, you package them as a skill. The agent loads those rules only when it is actually working in that domain.

In the original example, the skill teaches the agent how to write or review FastAPI code. The instructions tell the agent to load a references/conventions.md file only when it starts reviewing or writing code. That keeps the behavior targeted and avoids wasting context on rules that are irrelevant to the current task.

This is a practical pattern for:

• internal coding standards
• framework-specific best practices
• reusable team conventions
• domain-specific review rules

2) Generator: enforce consistent output structure

The Generator pattern is for cases where you want predictable output rather than ad hoc prose.

In the Google Cloud Tech example, the skill coordinates two supporting assets:

• an assets/ template for the final structure
• a references/ style guide for tone and formatting

The skill then tells the agent to:

1. load the style guide
2. load the template
3. ask for any missing variables
4. fill every section in order
5. return the completed document

This works well for:

• technical reports
• API documentation
• commit message standards
• architecture scaffolds
• repeatable internal documents

The pattern separates instructions from layout. The skill acts like a project manager instead of trying to embed the whole template directly in the prompt.

3) Reviewer: separate what to check from how to check it

The Reviewer pattern takes evaluation logic out of the prompt and puts it into a modular checklist.

Instead of baking every code smell or policy rule into the instructions, the agent loads a dedicated review rubric such as references/review-checklist.md and applies it systematically.

In the thread’s code review example, the agent is required to:

• understand the code before critiquing it
• apply each checklist rule
• classify findings by severity
• explain why an issue matters
• suggest a concrete fix

That makes the review process reusable. Swap the Python quality checklist for an OWASP checklist and you can reuse the same pattern for a very different audit.

This is strong for:

• PR reviews
• security audits
• style enforcement
• quality scoring
• pre-merge automation

4) Inversion: the agent interviews the user first

Agents love to guess. Inversion stops that habit.

Instead of letting the model jump straight into output generation, the agent becomes an interviewer. It asks structured questions one at a time and refuses to produce a final answer until all required context has been collected.

The project planner example in the original thread breaks the work into phases:

• Problem Discovery
• Technical Constraints
• Synthesis

Only after the first two phases are fully answered does the agent load the planning template and assemble the final project plan.

This is useful whenever the real failure mode is premature certainty:

• new project planning
• system design discovery
• requirements gathering
• deployment planning
• solution scoping

The core mechanism is explicit gating: do not build until the questions are complete.

5) Pipeline: enforce a strict workflow with checkpoints

Pipeline is the most procedural pattern in the thread.

It is designed for complex tasks where skipping a step creates bad outcomes. The agent must execute each stage in order and is not allowed to move forward if the current step fails or if an approval gate has not been satisfied.

The documentation example breaks the work into four steps:

1. Parse and inventory the public API
2. Generate docstrings
3. Assemble documentation
4. Run a quality check

The critical detail is the checkpoint between docstring generation and final assembly. The agent cannot proceed until the user confirms the generated docstrings. That one rule prevents the common failure mode where an agent silently blows past a review stage and hands over an unvalidated final artifact.

The original thread also points out another subtle benefit: optional references and templates are loaded only at the moment they are needed, which keeps the working context cleaner.

These patterns compose

One of the best lines in the original post is that these patterns are not mutually exclusive.

A Pipeline can end with a Reviewer step. A Generator can begin with Inversion. A Tool Wrapper can be embedded inside a larger multi-step workflow.

That composability is the real design insight. These are not isolated tricks. They are building blocks.

Takeaway from the original Google Cloud Tech post

The thread closes with a blunt but correct message: stop trying to cram fragile, complex instructions into one giant system prompt.

Instead:

• break the workflow into parts
• pick the right structural pattern
• load only the context you need
• enforce gates where mistakes are expensive

That is how you move from clever prompting to reliable agent design.

Source

• Original post: https://x.com/googlecloudtech/status/2033953579824758855?s=46&t=XvnC7kQ9xNYY6xAO-1HzbQ
• Source title: Google Cloud Tech on X — "5 Agent Skill design patterns every ADK developer should know"
• Adapted into ClawList article format with minimal restructuring for readability