Skills: Variables & Template System
Last updated: 2026-08-31
Variables turn Skills from "hardcoded templates" into "flexible tools" — one definition, a thousand reuses.
1. Variable Types
(1) User Input Variables
Parameters provided by the caller:
YAML
variables:
- name: target_file
description: "File path to review"
required: true
- name: severity_level
description: "Minimum severity level"
default: "warning"
choices: ["info", "warning", "error", "critical"]
(2) Environment Variables
Auto-obtained from the runtime environment:
YAML
variables:
- name: current_branch
type: env
source: "GIT_BRANCH"
- name: project_root
type: env
source: "PROJECT_ROOT"
(3) Context Variables
Injected from conversation or project context:
YAML
variables:
- name: tech_stack
type: context
source: "project.language"
- name: changed_files
type: context
source: "git.changed_files"
2. Template Syntax
(1) Basic Substitution
MARKDOWN
Please review {{target_file}}, focusing on issues at {{severity_level}} level and above.
(2) Conditional Rendering
MARKDOWN
## Review Strategy
{{#if tech_stack == "python"}}
Review by Python standards: type hints, docstrings, PEP 8
{{/if}}
{{#if tech_stack == "typescript"}}
Review by TypeScript standards: type safety, any detection, interface definitions
{{/if}}
(3) Loop Rendering
MARKDOWN
## Changed Files List
{{#each changed_files}}
- {{this}}
{{/each}}
(4) Default Values & Fallback
MARKDOWN
Code style follows {{linter_config || "industry default standards"}}.
3. Variable Validation
(1) Type Validation
YAML
variables:
- name: max_lines
type: integer
min: 10
max: 500
default: 100
- name: output_format
type: enum
choices: ["markdown", "json", "table"]
default: "markdown"
(2) Required Check
TEXT
📖 Display only
Variable validation flow:
1. Check if all required variables are provided
2. Check if types match
3. Check if values are within choices range
4. Check min/max constraints
5. Not provided but has default → Use default value
6. Validation failed → Prompt user to provide
4. Variable Practice
▶ Example: Parameterized Deploy Skill
Alice created a flexible deployment Skill:
YAML
---
name: smart-deploy
variables:
- name: environment
description: "Deployment environment"
required: true
choices: ["staging", "production"]
- name: skip_tests
description: "Whether to skip tests"
type: boolean
default: false
- name: rollback_on_fail
description: "Whether to rollback on failure"
type: boolean
default: true
---
MARKDOWN
# Deploy to {{environment}}
{{#if skip_tests}}
⚠️ Skipping tests, deploying directly
{{/if}}
{{#if !skip_tests}}
1. Run full test suite
2. Confirm all tests pass
{{/if}}
3. Deploy to {{environment}}
{{#if rollback_on_fail}}
4. Verify deployment success, auto-rollback on failure
{{/if}}
Bob commented: "Parameterization makes one Skill worth ten — no need to write separate Skills for staging and production, one variable does it all."
❓ FAQ
Q Do too many variables make a Skill complex?
A Yes. We recommend no more than 5 core variables and no more than 3 optional variables. If exceeded, consider splitting into multiple Skills.
Q Is template syntax the same across platforms?
A No. Claude Code uses
{{var}}, Cursor uses $var, Copilot uses ${var}. This course uses Claude Code syntax; the concepts are cross-platform.Q Can variables be dynamically computed at runtime?
A Yes, through context variables and environment variables. For complex computations, we recommend describing the logic in natural language within the Skill prompt and letting AI derive it.
📖 Summary
- Three variable types: user input, environment, context
- Template syntax: substitution, conditions, loops, defaults
- Variable validation: type, required, range constraints
- Design principle: core variables <5, reasonable default values
📝 Exercises
- Basic (⭐): Add a
severity_levelvariable to the code-review Skill to control the review output level. - Intermediate (⭐⭐): Create a parameterized deploy Skill supporting environment selection, skip-test toggle, and rollback strategy variables.
- Advanced (⭐⭐⭐): Design a variable validation system handling type checking, dependencies (e.g., production requires an approver), and dynamic defaults.
