Awesome-omni-skill make-instruction
Create GitHub Copilot instruction files with proper applyTo patterns and prescriptive rules. Use when asked to "create instruction", "make instruction", "scaffold instruction", or when building file-type-specific rules that should always be active. Generates .instructions.md files with YAML frontmatter and DO/DONT patterns.
git clone https://github.com/diegosouzapw/awesome-omni-skill
T=$(mktemp -d) && git clone --depth=1 https://github.com/diegosouzapw/awesome-omni-skill "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/tools/make-instruction" ~/.claude/skills/diegosouzapw-awesome-omni-skill-make-instruction && rm -rf "$T"
skills/tools/make-instruction/SKILL.mdMake Instruction
Create properly structured GitHub Copilot instruction files. Instructions are always-active prescriptive rules that auto-load for specific file types.
When to Use This Skill
- User asks to "create an instruction", "make instruction file", "scaffold instruction"
- Need to define mandatory rules for specific file types
- Want to enforce coding standards automatically
- Creating DO's and DON'Ts that should always apply
When NOT to Use (Use Skill Instead)
- ❌ Content is descriptive/educational (not prescriptive)
- ❌ Content exceeds 800 lines
- ❌ Should load on-demand, not automatically
- ❌ Contains extensive examples/tutorials
See copilot.instructions.md for decision criteria
Prerequisites
- Clear understanding of rules to enforce
- File type pattern to apply to (
)applyTo - Prescriptive content (DO's/DON'Ts)
- Target length: 100-800 lines
Instruction vs Skill Decision Tree
Is content prescriptive (MUST/DON'T)? ├─ Yes → Should it auto-load for file types? │ ├─ Yes → Is it <800 lines? │ │ ├─ Yes → CREATE INSTRUCTION ✅ │ │ └─ No → Use SKILL instead (too large) │ └─ No → Use SKILL instead (on-demand better) └─ No (descriptive) → Use SKILL instead
Creating a New Instruction
Step 1: Choose Location and Name
Location:
.github/instructions/{name}.instructions.md
Naming Convention:
- Lowercase with hyphens
- Must end with
.instructions.md - Descriptive of scope
Examples:
terraform.instructions.mddocumentation.instructions.mdpython-style.instructions.mdapi-security.instructions.md
Step 2: Define applyTo Pattern
Required: Every instruction MUST have an
applyTo pattern
Pattern Types:
| Pattern | Example | When to Use |
|---|---|---|
| File extension | | All Terraform files |
| Multiple extensions | | TypeScript files |
| Directory + extension | | Python test files |
| Specific paths | | ADR documents |
| Multiple patterns | | Markdown + specific file |
| Global | | Rare - all files |
Examples:
# Terraform files only applyTo: "**/*.tf" # Test files applyTo: "**/*.tftest.hcl,tests/**/*.tf" # Documentation applyTo: "**/*.md,variables.tf,outputs.tf" # Examples directory applyTo: "examples/**/*,README.md" # Specific subdirectory applyTo: "docs/adr/**/*.md" # Global (use sparingly!) applyTo: "**"
Step 3: Write the Frontmatter
Required Format:
--- applyTo: "file/pattern/**/*.ext" ---
Complete Example:
--- applyTo: "**/*.py" --- # Python Coding Standards ## Quick Reference [Content here]
Step 4: Structure the Content
Recommended Sections:
--- applyTo: "pattern" --- # Instruction Name ## Quick Reference [One-line summary of key rules] **Cross-references:** - Related skill → Use the **skill-name** skill --- ## Required Format/Structure [Mandatory patterns and formats] ## Naming Conventions ✅ **DO:** - Use descriptive names - Follow snake_case for variables ❌ **DON'T:** - Use single-letter variables - Mix naming conventions ## Code Style ⚠️ **ALWAYS:** - Use 2-space indentation - Add docstrings to functions ❌ **NEVER:** - Commit commented-out code - Use wildcard imports ## Best Practices Checklist - [ ] Item 1 - [ ] Item 2 ## Common Mistakes to Avoid 1. **Mistake:** Description **Fix:** Solution ## Additional Resources - **Related Skill:** skill-name - External docs: [Link]
Step 5: Keep It Concise
Size Guidelines:
| Lines | Status | Action |
|---|---|---|
| <100 | Too small | Add to existing instruction or expand |
| 100-500 | ✅ Perfect | Sweet spot |
| 500-800 | ⚠️ Large | Consider if all content is essential |
| 800-1000 | 🔴 Too large | Refactor - move details to skill |
| >1000 | 🚫 Critical | MUST convert to skill |
Refactoring Example:
# BEFORE (900 lines - TOO LARGE) --- applyTo: "**/*.tf" --- # Terraform Instructions ## Rules (200 lines) ## Detailed Explanations (400 lines) ## Examples (300 lines) # AFTER - Split into instruction + skill # terraform.instructions.md (300 lines) --- applyTo: "**/*.tf" --- ## Rules ✅ DO: Use module.label.id ❌ DON'T: Hardcode names **For detailed explanations, see the **terraform-resources** skill** # terraform-resources skill (600 lines) - Comprehensive examples - Deep explanations - Best practices
Content Guidelines
Prescriptive Language
Use:
- ✅ DO / DON'T
- ⚠️ ALWAYS / NEVER
- 🔴 MUST / MUST NOT
- ✔️ REQUIRED / FORBIDDEN
- 💡 RECOMMENDED / DISCOURAGED
Examples:
✅ **DO:** - Use type hints in Python functions - Write unit tests for all public methods ❌ **DON'T:** - Use `print()` for logging - Commit `.env` files ⚠️ **ALWAYS:** - Run `terraform fmt` before committing - Add description to all variables 🔴 **MUST:** - Pass security scans before merging - Follow semver for releases ❌ **NEVER:** - Hardcode credentials - Disable security features 💡 **RECOMMENDED:** - Use virtual environments for Python - Enable pre-commit hooks
Cross-References
Pattern: Link to skills for deep dives
## Dynamic Blocks **Quick Rule:** Use `dynamic` for repeating blocks **For comprehensive examples and syntax details, see the **terraform-resources** skill**
Quick Reference Section
Include at top:
## Quick Reference **When writing Terraform code:** - Use `module.label.id` for resource names - Variables: alphabetical order, `context` first - Outputs: alphabetical order - Run: `terraform fmt`, `terraform validate` - Security: `checkov -d .` **Cross-references:** - HCL syntax → Use the **terraform-syntax** skill - Functions → Use the **terraform-functions** skill
Templates
Template 1: Code Style Instruction
--- applyTo: "**/*.{ext}" --- # [Language] Code Style Instructions ## Quick Reference **When writing [Language] code:** - Indentation: [X] spaces - Line length: Max [X] characters - Naming: [convention] **Cross-references:** - Syntax → Use the **[language]-syntax** skill --- ## Formatting ✅ **DO:** - Use [X]-space indentation - Align [specific elements] ❌ **DON'T:** - Mix tabs and spaces - Exceed [X] character lines ## Naming Conventions | Element | Convention | Example | |---------|------------|---------| | Variables | snake_case | `user_name` | | Functions | camelCase | `getUserData` | | Classes | PascalCase | `UserModel` | ## Required Patterns ⚠️ **ALWAYS:** - Add docstrings/comments - Use type hints/annotations ❌ **NEVER:** - Use magic numbers - Ignore linter warnings ## Checklist - [ ] Code formatted with [tool] - [ ] All tests pass - [ ] Linter shows no errors
Template 2: Domain-Specific Instruction
--- applyTo: "specific/path/**/*.ext" --- # [Domain] Instructions ## Quick Reference [Key rules summary] **Cross-references:** - Details → Use the **[domain]-guide** skill --- ## Required Structure [Mandatory format/organization] ## DO's and DON'Ts ✅ **DO:** - [Specific good practice] ❌ **DON'T:** - [Specific anti-pattern] ## Validation **Before committing:** - [ ] Validation check 1 - [ ] Validation check 2 ## Common Mistakes 1. **Issue:** Description **Solution:** Fix
Template 3: Testing Instruction
--- applyTo: "tests/**/*,**/*.test.*" --- # Testing Instructions ## Quick Reference **When writing tests:** - Naming: `test_[feature]_[scenario]` - Structure: Arrange-Act-Assert - Coverage: Aim for 80%+ **Cross-references:** - Patterns → Use the **test-organization-patterns** skill - Assertions → Use the **test-assertions** skill --- ## Test Structure ✅ **DO:** - Group related tests - Use descriptive names - Test edge cases ❌ **DON'T:** - Write tests depending on order - Skip error cases ## Naming | Type | Pattern | Example | |------|---------|---------| | Unit tests | `test_unit_function_scenario` | `test_calculates_total` | | Integration | `test_integration_feature` | `test_api_creates_user` | ⚠️ **ALWAYS:** - Clean up test data - Mock external dependencies ## Checklist - [ ] All tests pass locally - [ ] No test dependencies - [ ] Coverage >80%
Validation Checklist
Before committing an instruction:
- File ends with
.instructions.md - Has
pattern in frontmatterapplyTo - applyTo pattern is valid glob syntax
- Content is prescriptive (DO's/DON'Ts)
- Length is 100-800 lines
- No extensive tutorials (those go in skills)
- Cross-references skills for details
- Quick reference section included
- Proper markdown formatting
- No trailing whitespace
Common Issues
Issue 1: Missing applyTo
# ❌ WRONG --- # No applyTo! --- # ✅ CORRECT --- applyTo: "**/*.tf" ---
Issue 2: Too Large
Problem: Instruction is 1,200 lines Solution: 1. Extract detailed explanations → Create skill 2. Keep only rules in instruction (200-300 lines) 3. Add cross-reference to new skill
Issue 3: Descriptive Instead of Prescriptive
# ❌ WRONG (Descriptive) ## How Dynamic Blocks Work Dynamic blocks generate nested configurations... [500 lines of explanation] # ✅ CORRECT (Prescriptive) ## Dynamic Blocks ✅ **DO:** - Use `dynamic` for repeating blocks - Set `for_each` to collection **For detailed examples, see the **terraform-resources** skill**
Issue 4: Duplicate Content with Skill
Problem: 70% overlap with existing skill Solution: 1. Remove duplicate content from instruction 2. Keep only prescriptive rules 3. Add cross-reference to skill
Testing Your Instruction
After creating:
-
Check activation:
- Open file matching applyTo pattern
- Verify instruction is loaded
-
Validate content:
- All rules are prescriptive
- No lengthy explanations
- Cross-references present
-
Check length:
- File is 100-800 lines
- If larger, refactor to skill
-
Test with agent:
- Open matching file
- Ask agent to follow rules
- Verify rules are applied
Migration from Skill
If you have a skill that should be an instruction:
# BEFORE: terraform-basics skill (400 lines) # Descriptive content + some rules # AFTER: Split into instruction + skill # terraform.instructions.md (200 lines) - Prescriptive rules only - Cross-reference to skill # terraform-basics skill (600 lines) - All explanations and examples - Merged from both sources
Examples from This Repository
✅ Good Instructions
| File | Lines | applyTo | Why Good |
|---|---|---|---|
| terraform.instructions.md | 814 | | Clear rules, proper size |
| documentation.instructions.md | 418 | | Prescriptive, focused |
| conventional-commits.instructions.md | 142 | | Pure rules, no tutorial |
❌ Anti-Pattern
| File | Lines | Problem | Fix |
|---|---|---|---|
| terraform-tests.instructions.md | 2,206 | Too large, descriptive | Convert to skill |
Quick Start
1. Decide if you need an instruction:
- See copilot.instructions.md decision tree
2. Create the file:
touch .github/instructions/my-topic.instructions.md
3. Add frontmatter:
--- applyTo: "pattern/**/*.ext" ---
4. Write prescriptive rules:
- DO's and DON'Ts
- Keep under 800 lines
- Cross-reference skills
5. Validate:
- Test with matching files
- Verify rules apply correctly
References
- copilot.instructions.md - When to use instruction vs skill
- make-skill-template skill - Create skills instead
- See existing instructions for examples