10 Claude Code Skill Design Patterns: Descriptions and Templates That Trigger Reliably
Ten Skill design patterns for Claude Code: how to write descriptions that trigger reliably, split Skills by audience, and embed AdSense quality gates.
Ten Skill design patterns for Claude Code: how to write descriptions that trigger reliably, split Skills by audience, and embed AdSense quality gates.
10 Claude Code Skill Design Patterns: Descriptions and Templates That Trigger Reliably
Claude Code Skills are not just prompt snippets. In my workflow, they are operating standards for a project. ZYL0 Blog uses separate Skills for investment posts, creator posts, and technical posts. That split helped, but the first versions still failed in a predictable way: the descriptions were too vague, so the right Skill did not always trigger.
This article turns that operating experience into ten design patterns. The goal is not to make a clever prompt. The goal is to make a Skill that routes reliably, produces consistent Nuxt Content Markdown, and protects the blog from thin-content signals during AdSense review.
Version note: This article reflects Claude Code and the ZYL0 Blog local Skill workflow as of May 2026. CLI behavior and Skill documentation can change, so implementation details should be checked against official documentation before reuse.
TL;DR: What You'll Learn
| Theme | Practical takeaway |
|---|---|
| description | Write when the Skill should be used, not only what it does |
| trigger phrases | Include words users actually type |
| scope | Keep Skill, subagent, hook, and MCP responsibilities separate |
| quality gate | Require originality, references, and disclaimers for blog posts |
| validation | Run build and lightweight content audits before publishing |
1. Treat the Description as Routing Metadata
The first thing to fix is usually the description.
Weak:
description: Write high quality blog posts.
That line does not say which audience, which input phrases, which output format, or which repository path. A stronger version is more explicit:
description: >
Write bilingual Japanese and English technical blog posts for ZYL0 Blog.
Use when the user asks for a developer tutorial, Claude Code article,
MCP guide, architecture deep dive, or implementation note.
Produce Nuxt Content Markdown under content/blogs/ with frontmatter,
Japanese and English language blocks, references, and disclaimers.
The Skill does not need a flattering self-description. It needs routing conditions. That mental model has made my Skills much more reliable.
2. Use the Words Users Actually Type
I used to write abstract phrases such as technical content or investment content. Real requests are messier. Users say "write an MCP article," "fix the Claude Code Skill," or "make this blog pass AdSense review."
So the description should contain realistic trigger phrases.
| Weak phrase | Stronger trigger phrase |
|---|---|
| technical content | Claude Code, MCP, API integration |
| creator content | YouTube, SNS, pricing, proposal template |
| investment content | semiconductor, CPO, AI infrastructure |
| quality content | AdSense, references, disclaimer, originality |
This feels close to SEO. Elegant abstractions are pleasant for humans, but concrete phrases route better.
3. Split Skills by Audience
ZYL0 Blog uses three writing Skills.
| Skill | Audience | Required elements |
|---|---|---|
| zyl0-blog-writer | investors, CVCs, individual investors | scenarios, numbers, primary sources, disclaimer |
| zyl0-creator-blog-writer | creators and solo operators | experience, before/after, pricing, CTA |
| zyl0-tech-blog-writer | engineers and developers | version note, code, gotchas, official docs |
If one Skill tries to handle everything, tone drifts. Investment posts need scenarios. Creator posts need concrete operating examples. Technical posts need versions, code, and pitfalls. I have found Skills more stable when split by the reader's definition of value, not just by task type.
4. Make Frontmatter and Paths Explicit
Nuxt Content articles are sensitive to metadata. If the Skill says only "use appropriate frontmatter," field names and ordering drift.
The blog standard is:
---
title: 'Japanese Title | English Title'
description: 'Japanese description, 80-160 characters.'
date: '22nd May 2026'
image: '/blogs-img/blog-slug.png'
alt: 'Image description in Japanese.'
ogImage: '/blogs-img/blog-slug.png'
tags: ['テック解説', 'AI活用']
tagsEn: ['Tech Deep Dive', 'AI Tools']
published: true
---
I prefer one correct example. Multiple examples invite unnecessary variation.
5. Put the AdSense Quality Gate Inside the Skill
The main lesson from the AdSense rejection is that length alone is not enough. A long article can still look thin if it lacks original judgment, visible references, and a clear reason to revisit.
The Skill now needs these gates:
| Gate | What to check |
|---|---|
| Originality | Personal experience, hypothesis, or decision framework |
| Evidence | Official docs, investor relations, public data, or research sources |
| Revisit reason | What the reader should track next |
| Disclaimer | Not investment advice, possible interests, AI assistance, disclaimer link |
| Duplication control | Remove repeated template language and SEO filler |
The important change is that references should be visible to readers. Keeping sources only in the drafting process is weaker for trust and user experience.
6. Research Instructions Should Prefer Primary Sources
The Skill should require research, but it should not freeze the source list too tightly.
For technical posts:
Before writing:
- verify official documentation or release notes
- check GitHub changelog/issues where relevant
- avoid uncertain API behavior
- include references readers can revisit
For investment posts, company filings, investor relations, regulation, and market data matter more. For creator posts, concrete before/after numbers and workflow evidence matter more. The point of research is not to add links. The point is to avoid unsupported claims.
7. Keep Skill, Subagent, Hook, and MCP Responsibilities Separate
Claude Code's surrounding tools are useful, but stuffing everything into a Skill makes maintenance harder.
| Mechanism | Best at | Failure mode when overloaded |
|---|---|---|
| Skill | workflow, tone, output format, quality gates | bloated operating rules |
| Subagent | isolated research and review | missing always-on writing rules |
| Hook | forced checks before or after actions | blocking editorial judgment |
| MCP | external data and service access | scattering local formatting rules |
My current rule is simple: Skills define how to do the work, subagents investigate, hooks stop accidents, and MCP connects external state.
8. Include One Bad Example
Bad examples help because they define the boundary.
# Bad
description: Write useful articles.
# Good
description: >
Use when the user asks to create, revise, or audit a bilingual ZYL0 Blog
article for AdSense review, especially when the request mentions references,
originality, disclaimer, AI tools, investing, or Claude Code.
This mirrors how investment teams are trained. Showing a good memo helps. Showing the kind of memo that gets challenged in committee often helps faster.
9. Add Exit Checks
A Skill should also say what to verify at the end.
After writing:
- confirm frontmatter fields
- confirm Japanese and English blocks both exist
- confirm references and disclaimers exist in both languages
- run npm run build before publishing
For AdSense-oriented publishing, I also check body length, references, Next Issue Ideas, approved tags, and forbidden MDC or inline HTML. A lightweight audit catches mistakes that are easy to miss by eye.
10. Skills Reduce Repeated Decisions
The best Skill is not magical. It removes repeated decisions.
For ZYL0 Blog, the new baseline is:
| Item | New standard |
|---|---|
| References | Add a references section in both languages |
| Originality | Include at least one personal observation, hypothesis, or decision lens |
| Disclaimer | Cover advice status, AI assistance, and possible interests |
| Tags | Use only the eight approved categories |
| Validation | Run build and lightweight content audit |
The loop is practical: every failed trigger, weak article, or review rejection becomes a new rule in the Skill. It is boring, but it compounds, and over enough iterations the accumulated rules become the real asset rather than any single clever prompt.
Next Issue Ideas
- Idea 1: An AdSense blog audit checklist — A practical checklist for frontmatter, references, disclaimers, body depth, and category hygiene.
- Idea 2: Researching articles with subagents — Split investment, technical, and reader-need research before merging one final post.
- Idea 3: Connecting internal knowledge over MCP — Wire research notes, old proposals, and meeting minutes into Claude Code for faster article production.
Related Posts
- How Claude Cut My Video + Web Workflow to 1/5 the Time — Combining Skills, MCP, and Claude Design to run planning → design → video script → publishing as one continuous flow c…
- Claude Skills, MCP, Website Generation, and Programmatic Video in Production: A Practical Engineer's Guide 2026 — Claude Code skills, MCP server building, website generation, and Remotion programmatic video — a practical engineer's …
- Claude Code 2026 Feature Roundup: Putting 1M Context, Skills, Hooks, Subagents, MCP, and Plan Mode to Real Work — Six Claude Code features ordered by adoption priority — 1M context, Skills, Hooks, Subagents, MCP, and Plan Mode — wit…
References
The technical assumptions and operating recommendations in this article are grounded in official documentation that readers can revisit.
- Anthropic Claude Code documentation
- Anthropic Skills documentation
- Model Context Protocol documentation
This article is for informational purposes only and does not constitute investment advice or a recommendation of any specific stock, service, or contract structure. The author may hold positions or interests related to companies or services mentioned. Generative AI was used for parts of research, translation, and proofreading, with final review by ZYL0. See the disclaimer for details.
