Source: Google Cloud Tech — 5 Agent Skill Design Patterns
Adapted for: OpenClaw Agent System
Purpose: Build reliable, composable agent skills using proven architectural patterns
The specification explains how to package a skill, but offers zero guidance on how to structure the logic inside it. These 5 patterns solve that problem.
PatternQuestion It AnswersUse WhenTool Wrapper"How do I make my agent an expert on a specific library?"Agent needs deep, contextual knowledge about a technologyGenerator"How do I enforce consistent output structure?"Output format must be predictable every timeReviewer"How do I separate what to check from how to check it?"Code review, quality gates, compliance checkingInversion"How do I stop the agent from guessing and gather requirements first?"Complex tasks requiring full context before executionPipeline"How do I enforce a strict multi-step workflow?"Multi-phase tasks with checkpoints and approvals
Purpose: Give your agent on-demand context for a specific library/framework.
Mechanism:
references/Example Use Cases:
Template: See templates/tool-wrapper-SKILL.md
Purpose: Enforce consistent output via fill-in-the-blank orchestration.
Mechanism:
assets/ holds output templatereferences/ holds style guideExample Use Cases:
Template: See templates/generator-SKILL.md
Purpose: Separate review criteria from review execution.
Mechanism:
references/review-checklist.mdExample Use Cases:
Template: See templates/reviewer-SKILL.md
Purpose: Stop agents from guessing — make them interview first.
Mechanism:
Example Use Cases:
Template: See templates/inversion-SKILL.md
Purpose: Enforce strict sequential workflow with hard checkpoints.
Mechanism:
Example Use Cases:
Template: See templates/pipeline-SKILL.md
text
START: What does your skill need to do?
│
├─→ Provide deep knowledge about a specific library/framework?
│ └─→ Use: TOOL WRAPPER
│
├─→ Produce consistent, templated output?
│ └─→ Use: GENERATOR
│
├─→ Check/audit something against criteria?
│ └─→ Use: REVIEWER
│
├─→ Gather requirements before acting?
│ └─→ Use: INVERSION
│
├─→ Execute strict multi-step workflow?
│ └─→ Use: PIPELINE
│
└─→ Multiple of the above?
└─→ Patterns COMPOSE (see below)
These patterns are not mutually exclusive — they compose:
CombinationEffectPipeline + ReviewerMulti-step workflow with quality gate at the endGenerator + InversionGather variables via interview, then fill templatePipeline + Tool WrapperEach step loads specific expertise as neededReviewer + GeneratorReview output before generating final document
Principle: Your agent only spends context tokens on the exact patterns it needs at runtime.
ScenarioPatternWhy"Teach my agent FastAPI conventions"Tool WrapperContext loads only when FastAPI mentioned"Generate consistent API docs"GeneratorTemplate + style guide = predictable output"Automate PR reviews"ReviewerSwap checklist for different audit types"Plan a new project"InversionGathers full requirements before designing"Generate docs from code"PipelineParse → Generate → Review → Assemble
text
skills/
└── your-skill/
├── SKILL.md # Instructions (implements pattern)
├── references/ # Knowledge, checklists, style guides
│ ├── conventions.md
│ ├── review-checklist.md
│ └── style-guide.md
└── assets/ # Templates, examples
├── report-template.md
└── plan-template.md
❌ Cramming everything into system prompt — Use Tool Wrapper instead
❌ Different output every run — Use Generator for consistency
❌ Hardcoded review criteria — Use Reviewer for modularity
❌ Agent assumes context — Use Inversion to gather requirements
❌ Skipped steps in workflows — Use Pipeline for enforcement
read tool to load references/assets dynamicallysessions_spawn for complex workflowsAsk me: "Use the [pattern-name] pattern to [task]"
Examples:
Ask: "Which pattern should I use for [scenario]?"
Ask: "How do I combine [pattern-1] and [pattern-2]?"
Source Article: https://x.com/GoogleCloudTech/status/2033953579824758855
Last Updated: March 29, 2026