To use this template, open the Google Doc link above and make your own copy (File > Make a Copy). Share it with your team or put it on a screen for a collaborative planning session. Use the tabs as a scratchpad to map out your skill’s architecture before building it.

Claude Skill Creation Template

This template is a thinking tool, not a writing tool. Its purpose is to help you plan the architecture of a Claude skill before you build it. Whether you’re working solo or running a team workshop with the doc on a shared screen, the goal is the same: map out what your skill needs to do, what context it requires, what it should produce, and what systems it connects to.

You don’t need to write polished instructions here. Jot down notes, bullet points, rough workflows, and the names of documents that already exist. Once your architecture is clear, use Claude’s built-in skill-creator skill to assemble the actual skill files from your plan.

Claude skills are reusable instruction packages that give Claude specialized capabilities for specific tasks. A well-structured skill turns a one-off prompt into a reliable, shareable workflow that anyone on your team can activate. This template helps you think through that structure before committing to building it.

Template Structure

The Google Doc contains the following tabs. Use each tab as a scratchpad to capture your thinking about that component of the skill:

Tab 1: SKILL.md

The main instruction file. This is the only required component of a skill.

---
name: Your Skill Name
description: Use when the user wants to [specific task]. Also use when the user mentions [related keywords or triggers].
---

Detailed instructions for Claude go here...

The frontmatter contains two fields:

• name - A clear, descriptive name for your skill (e.g., “Code Review Assistant”, “Meeting Notes Generator”)
• description - This is critically important. Claude loads the description of every available skill into its context and uses it to decide which skill to activate. Your description should clearly explain when to use this skill versus other skills. Don’t just describe what the skill does; describe the situations, triggers, and user requests that should activate it. For example: “Use when the user asks to review code, check for bugs, or audit pull requests. Also use when the user mentions ‘code quality’ or ‘PR review’.”

The body contains your full instructions. Write these as if you’re briefing a knowledgeable colleague on exactly how to approach a task.

Tab 2: References (Folder Overview)

References are optional supporting documents that get loaded into Claude’s context to inform its work. Use references for:

• Process documentation - Step-by-step workflows the skill should follow
• Decision frameworks - Criteria for choosing between options (Option A vs. Option B)
• Style guides - Tone, formatting, and brand guidelines
• Domain knowledge - Technical specifications, regulatory requirements, or industry context

References are loaded into the conversation alongside the SKILL.md, giving Claude the background knowledge it needs to execute well.

Tabs 3-4: Reference #1, Reference #2

Placeholder tabs for individual reference documents. Each reference should be a self-contained document covering one topic or process. Keep references focused rather than creating one large document covering everything.

Tab 5: Assets (Folder Overview)

Assets are optional template documents that define what Claude should produce. Unlike references (which inform Claude’s thinking), assets direct Claude’s output. Use assets for:

• Document templates - Agendas, reports, proposals, emails
• Form structures - Customer intake forms, feedback surveys, checklists
• Content formats - Blog post structures, social media templates, newsletter layouts
• Code scaffolds - Project templates, test suite structures, configuration files

Assets are not loaded into Claude’s context directly. Instead, your SKILL.md instructions reference them and tell Claude to use them as output blueprints.

Tabs 6-7: Asset #1, Asset #2

Placeholder tabs for individual asset documents. Create one tab per output template your skill needs to produce.

Tab 8: Scripts (Folder Overview)

Scripts are optional executable files that give your skill the ability to interact with external systems. Use scripts for:

• Bash commands - File operations, build processes, deployment steps
• API integrations - Fetching data from external services, posting updates
• System automation - Running tests, generating reports, managing infrastructure

Important: Scripts are NOT required for using MCP servers or connectors that are already enabled in your Claude environment. If you have Slack, GitHub, Jira, or other integrations available via MCP, simply mention them in your SKILL.md or Reference files. Claude will use them directly without needing separate scripts.

Tabs 9-10: Script #1, Script #2

Placeholder tabs for individual scripts. Each script should handle one specific automation task.

What to Capture in Each Section

When planning your skill, these are the key things to think through and jot down in each tab. You don’t need final copy, just enough detail that the skill-creator (or a colleague) could understand your intent.

Start with the Trigger

Note when the skill should activate:

Use this skill when the user asks to [specific task].
Also use when the user mentions [related keywords or phrases].

Define the Workflow

Sketch out the steps, even roughly:

## Workflow

1. **Gather context** - Ask the user for [specific inputs]
2. **Analyze requirements** - Check [specific conditions]
3. **Generate output** - Create [specific deliverable] following the template in assets/
4. **Review and refine** - Verify [quality criteria] before presenting

Include Decision Criteria

Note any points where the skill needs to choose between approaches:

## Decision Framework

When choosing between approaches:
- If [condition A], use [approach 1] because [reason]
- If [condition B], use [approach 2] because [reason]
- If unclear, ask the user to clarify before proceeding

Specify Output Format

Describe what the finished output should look like:

## Output Format

Present results as:
- A summary section (2-3 sentences)
- A detailed breakdown using the template in assets/report-template
- Action items as a numbered list with owners and deadlines

Add Quality Checks

Note how the skill should verify its own work:

## Before Finishing

Verify:
- [ ] All required sections are complete
- [ ] Tone matches [specified style guide]
- [ ] No assumptions made without user confirmation
- [ ] Output follows the template structure exactly

Folder Structure

For reference, here’s what the final skill package looks like once the skill-creator builds it from your plan:

your-skill-name/
├── SKILL.md              # Main instructions (required)
├── references/           # Context documents (optional)
│   ├── process-guide.md
│   └── style-guide.md
├── assets/               # Output templates (optional)
│   ├── report-template.md
│   └── email-template.md
└── scripts/              # Executable scripts (optional)
    ├── deploy.sh
    └── fetch-data.sh

Planning Best Practices

Keep Skills Focused

If you’re sketching out a skill and it starts covering multiple unrelated tasks, that’s a signal to split it into separate skills. A “Code Review” skill and a “Test Writer” skill are better than a “Code Quality” skill that tries to do both. Catching this at the planning stage saves significant rework later.

Think About the Workflow End-to-End

Walk through a real scenario in your head (or as a team). What triggers the skill? What does Claude need to know? What decisions does it face? What does the output look like? What could go wrong? This end-to-end thinking is the main value of using this template rather than jumping straight to building.

Be Selective with References

When listing references, ask: “Does Claude actually need this to do the job?” Every reference consumes context window space. A focused 500-word process guide is more effective than a 5,000-word comprehensive manual where only 10% is relevant. Note existing documents by name; you don’t need to write new ones during planning.

Sketch Assets, Don’t Perfect Them

When planning assets, focus on structure rather than content. Note what sections the output template should have, what fields to include, and what format to use. Placeholder text like [Company Name] or [Date] is perfect at this stage. The skill-creator will flesh them out.

Identify Scripts Early

If your skill needs to interact with external systems, note that during planning. It’s easier to design the skill workflow around available integrations than to bolt them on afterward. Also note which integrations are already available via MCP (and therefore don’t need scripts).

Example: What Planning Notes Might Look Like

Here’s what your planning notes might look like for a simple meeting summary skill. Notice it’s structured enough to communicate intent, but doesn’t need to be polished prose:

SKILL.md:

---
name: Meeting Summary Writer
description: Use when the user shares meeting notes, transcripts, or asks to summarize a meeting. Also use when the user mentions "meeting recap", "action items from the call", or "what did we decide".
---

## When to Use
Use this skill when the user shares meeting notes, transcripts,
or asks to summarize a meeting.

## Workflow
1. Read the provided meeting content
2. Identify: attendees, key decisions, action items, and open questions
3. Generate a summary following the template in assets/
4. Present the summary and ask if any corrections are needed

## Output Rules
- Keep summaries under 500 words
- List action items with owner and deadline
- Flag any decisions that need follow-up confirmation
- Use professional but accessible tone

assets/summary-template.md:

# Meeting Summary: [Meeting Title]
**Date:** [Date] | **Duration:** [Duration]
**Attendees:** [Names]

## Key Decisions
- [Decision 1]
- [Decision 2]

## Action Items
| Action | Owner | Deadline |
|--------|-------|----------|
| [Task] | [Name] | [Date] |

## Open Questions
- [Question requiring follow-up]

## Notes
[Additional context or discussion points]

These planning notes are detailed enough that you (or the skill-creator) could build the complete skill from them. That’s the goal: capture the architecture, then let Claude handle the assembly.

Using This Template in Different Contexts

Solo Planning

When working alone, use the template as a personal thinking exercise. Walk through each tab and jot down notes. You might spend 15-30 minutes mapping out a skill’s architecture before asking the skill-creator to build it. This upfront investment saves significant back-and-forth during construction.

Team Workshops

Put the Google Doc on a shared screen and facilitate a discussion through each tab. This works especially well when the skill encodes a workflow that multiple people contribute to. The marketing team might know what the output should look like (assets), while the operations team knows the process steps (SKILL.md), and IT knows the system integrations (scripts). The template gives everyone a shared structure to contribute to.

Organization-Wide Skills

For enterprise skills, the planning stage is especially important. Use the References tab to identify compliance requirements and brand guidelines. Use Assets for standardized deliverables. Use Scripts for internal system integrations. Consider having the plan reviewed by relevant stakeholders (legal for compliance skills, brand team for content skills) before passing it to the skill-creator.

For Different Claude Interfaces

• Claude Code (CLI): Full skill support including scripts. Best for developer workflows and automation-heavy tasks.
• Claude.ai Projects: SKILL.md and references work as project instructions and knowledge. Assets can be included as knowledge files. Scripts are not supported.
• API Integrations: SKILL.md content becomes system prompts. References become additional context. Assets and scripts are handled by your application logic.