|
| 1 | +# Copilot authoring guidelines for customization Markdown files |
| 2 | + |
| 3 | +These instructions apply when you create or edit any of the following files: |
| 4 | + |
| 5 | +- `agents/*.agent.md` |
| 6 | +- `prompts/*.prompt.md` |
| 7 | +- `instructions/*.instructions.md` |
| 8 | +- `skills/**/SKILL.md` |
| 9 | + |
| 10 | +## General Markdown rules |
| 11 | + |
| 12 | +- Use ATX headings (`#`, `##`, `###`) and keep a clean hierarchy (one `#` at top). |
| 13 | +- Prefer short paragraphs and bullet lists; avoid overly long blocks of text. |
| 14 | +- Use fenced code blocks for any code or config. Label the fence language (`yaml`, `bash`, `json`, `md`, etc.). |
| 15 | +- Never place YAML frontmatter anywhere except the very top of the file. |
| 16 | +- Always separate YAML frontmatter from body with a blank line after the closing `---`. |
| 17 | +- Keep instructions unambiguous, testable, and scoped: |
| 18 | + - Use “MUST / SHOULD / MAY” for requirements. |
| 19 | + - Add acceptance criteria when helpful. |
| 20 | +- Avoid contradictions across files. If two instruction files could both apply, ensure they agree. |
| 21 | + |
| 22 | +## YAML frontmatter conventions |
| 23 | + |
| 24 | +- Use `---` on the first line and `---` to close the frontmatter block. |
| 25 | +- Prefer quoted strings when values contain special characters (`:`, `*`, `{}`, `#`, `@`, etc.). |
| 26 | +- Use lower-kebab-case for identifiers (e.g., `name: markdown-authoring`). |
| 27 | + |
| 28 | +## Authoring standards per file type |
| 29 | + |
| 30 | +### A) Custom agent profiles: `agents/*.agent.md` |
| 31 | + |
| 32 | +- Frontmatter MUST include: |
| 33 | + - `description` (required) |
| 34 | + - `name` (recommended; otherwise filename is used) |
| 35 | +- Frontmatter MAY include: |
| 36 | + - `tools` (list of tool names/aliases) |
| 37 | + - `model` (IDE-supported) |
| 38 | + - `target` (`vscode` or `github-copilot`), if you want environment-specific availability |
| 39 | +- Body MUST: |
| 40 | + - Define the agent’s role, boundaries, and output format expectations. |
| 41 | + - State what the agent should do when missing info (ask concise questions or propose safe defaults). |
| 42 | + - Include formatting rules for produced Markdown (headings, lists, code fences, links). |
| 43 | +- Keep the agent prompt focused on a single domain (e.g., “authoring Copilot customization files”). |
| 44 | + |
| 45 | +### B) Prompt files: `prompts/*.prompt.md` |
| 46 | + |
| 47 | +- Frontmatter SHOULD include: |
| 48 | + - `description` (short, action-oriented) |
| 49 | + - `agent` (when you want agent mode behavior) |
| 50 | +- Body MUST: |
| 51 | + - Start with the goal in one sentence. |
| 52 | + - Use `${input:<name>:<prompt>}` placeholders for required parameters. |
| 53 | + - Specify a deterministic output structure (headings + bullet lists). |
| 54 | +- Ensure the prompt can be invoked as `/<filename-without-.prompt.md>`. |
| 55 | + |
| 56 | +### C) Path-specific instructions: `instructions/*.instructions.md` |
| 57 | + |
| 58 | +- Frontmatter MUST include: |
| 59 | + - `applyTo: "<glob pattern(s)>"` |
| 60 | +- Frontmatter MAY include: |
| 61 | + - `excludeAgent: "code-review"` or `"coding-agent"` if only one should read it |
| 62 | +- Body MUST: |
| 63 | + - Describe exactly what to do for files matching `applyTo`. |
| 64 | + - Contain rules that are compatible with repo-wide instructions. |
| 65 | + |
| 66 | +### D) Skills: `skills/<skill-dir>/SKILL.md` |
| 67 | + |
| 68 | +- File MUST be named `SKILL.md`. |
| 69 | +- Frontmatter MUST include: |
| 70 | + - `name` (lowercase, hyphenated) |
| 71 | + - `description` (when to use this skill) |
| 72 | +- Body MUST: |
| 73 | + - Provide step-by-step guidance, examples, and “do/don’t” lists. |
| 74 | + - Include any scripts/resources in the same directory by relative path. |
| 75 | + |
| 76 | +## Output requirements when generating/editing these files |
| 77 | + |
| 78 | +- When proposing changes, output the full file contents in a single fenced `md` code block. |
| 79 | +- If editing an existing file, describe the minimal set of changes before showing the updated file. |
| 80 | +- Never invent tool names, file paths, or capabilities—use what exists in the repo. |
0 commit comments