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.

install
source · Clone the upstream repo
git clone https://github.com/diegosouzapw/awesome-omni-skill
Claude Code · Install into ~/.claude/skills/
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"
manifest: skills/tools/make-instruction/SKILL.md
source content

Make 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.md
  • documentation.instructions.md
  • python-style.instructions.md
  • api-security.instructions.md

Step 2: Define applyTo Pattern

Required: Every instruction MUST have an

applyTo
pattern

Pattern Types:

PatternExampleWhen to Use
File extension
**/*.tf
All Terraform files
Multiple extensions
**/*.{ts,tsx}
TypeScript files
Directory + extension
tests/**/*.py
Python test files
Specific paths
docs/adr/**/*.md
ADR documents
Multiple patterns
**/*.md,variables.tf
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:

LinesStatusAction
<100Too smallAdd to existing instruction or expand
100-500✅ PerfectSweet spot
500-800⚠️ LargeConsider if all content is essential
800-1000🔴 Too largeRefactor - move details to skill
>1000🚫 CriticalMUST 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
    applyTo
    pattern in frontmatter
  • 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:

  1. Check activation:

    • Open file matching applyTo pattern
    • Verify instruction is loaded
  2. Validate content:

    • All rules are prescriptive
    • No lengthy explanations
    • Cross-references present
  3. Check length:

    • File is 100-800 lines
    • If larger, refactor to skill
  4. 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

FileLinesapplyToWhy Good
terraform.instructions.md814
**/*.tf
Clear rules, proper size
documentation.instructions.md418
**/*.md,...
Prescriptive, focused
conventional-commits.instructions.md142
**
Pure rules, no tutorial

❌ Anti-Pattern

FileLinesProblemFix
terraform-tests.instructions.md2,206Too large, descriptiveConvert 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