copilot-instructions: Instructions file for GitHub Copilot

Instruction Creation Standards

Content Format

• Prefer concise markdown over ornamental formatting
• Allow bullet lists when they improve clarity (e.g., references, checklists)
• Use markdown headings with a simple, consistent hierarchy
• Use inline code for paths, commands, globs, filenames, identifiers, and types when it improves precision
• Header must follow template exactly
• Start new instruction files from .github/templates/copilot-instruction-creation.instructions-template.md when creating or restructuring an instruction
• Do not assemble a final instruction directly from the inline examples in this file; use the template as the concrete structure and treat examples here as partial guidance only
• Actionable information only
• Pattern [area].instructions.md
• Examples inline prefixed with "Example:"

# Main Section
- Bullet point example
- Another point with technical detail

## Subsection (use sparingly)
Technical content with code blocks when needed

Heading Hierarchy

• Use # for primary sections to provide clear document structure
• Use ## for meaningful subsections when they improve navigation
• Use ### only as last resort for detailed breakdowns
• Avoid deeper nesting
• Ensure logical information hierarchy
• Maintain consistent formatting across all instruction files

# Primary Section (always use)
Content for main topics

## Secondary Section (use sparingly)
Content for important subdivisions

### Tertiary Section (last resort)
Content for detailed breakdowns

Code Examples

• Use code blocks for examples to illustrate technical guidance
• Specify language when possible (e.g., yaml, dockerfile, ```csharp)
• Keep examples concise and actionable
• Prefer real-world examples over placeholders
• Ensure examples are self-contained and runnable where possible

Content Structure

• One paragraph per line for readability
• Internal blank lines allowed to separate rule groups
• When using lists put one item per line
• End file on last content character with no trailing blank line
• English only for consistency
• Precise technical terms over generic language
• Avoid filler words and redundancy
• Match the style already established in the repository instead of inventing a competing instruction style
• Context before objective in explanations when that improves comprehension
• Measurable acceptance criteria when applicable
• Add a Validation Checklist or Verification Checklist section when the instruction defines concrete deliverables, acceptance rules, or reviewable outcomes
• Do not remove an existing checklist unless another instruction or global rule explicitly replaces it

Example paragraph structure:
Single line with specific technical guidance.

Next paragraph covers different aspect.
- Bullet point for specific requirement
- Another bullet with measurable criteria