{"owner":"actions","repo":"runner-images","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":[".github/copilot-instructions.md"],"skills":{".github/copilot-instructions.md":"# GitHub Copilot Instructions for Actions Runner Images Repository\n\n## Scope and goals\n\n- This repository serves as the source for building GitHub Actions runner and Azure DevOps agent images for Windows, Ubuntu, and macOS. You can find exact versions in the [Available Images](../README.md#available-images) section of README.md. Windows and Ubuntu images build on Azure infrastructure using Packer; macOS images use Anka virtualization.\n- Emphasize best practices for contributing to open-source projects, including code style, commit messages, and pull request etiquette.\n- Prefer clarity and correctness over creativity. If information is missing, ask clarifying questions or insert TODOs instead of guessing.\n\n## Code and command instructions\n\n- Follow the code style guide in [CONTRIBUTING.md](../CONTRIBUTING.md#code-style-guide) for Bash and PowerShell scripts, including naming conventions, file structure, and indentation rules.\n- Focus on re-using helpers when writing scripts. Windows, Linux and Ubuntu scripts have helper functions available to simplify installation and validation.\n- Always confirm versions and installation paths against existing toolset files and installation scripts.\n\n## Output format\n\n- Use GitHub Flavored Markdown only. Avoid raw HTML unless necessary.\n- One H1 (`#`) per page, followed by logical, sequential headings (`##`, `###`, …).\n- Use fenced code blocks with language identifiers (` ```bash `, ` ```json `, ` ```yaml `, etc.).\n- Use blockquote callouts for notes:\n  > [!NOTE] Context or nuance  \n  > [!TIP] Helpful hint  \n  > [!WARNING] Risks or breaking changes  \n  > [!IMPORTANT] Critical requirement for functionality\n\n## Style and tone\n\n- Audience: Open-source contributors, GitHub Actions maintainers, and developers building custom runner images. Assume familiarity with CI/CD concepts, Packer, and basic infrastructure provisioning, but explain platform-specific details (Azure for Windows/Ubuntu, Anka for macOS) when relevant.\n- Voice: Second person (\"you\"), active voice, imperative for operational steps.\n- Be concise: short paragraphs and sentences. Prefer lists and step-by-steps, especially for operational procedures and troubleshooting.\n- Use inclusive, accessible language. Avoid idioms, sarcasm, and culturally specific references.\n- English: en-US (spelling, punctuation, and units).\n\n## Safety and integrity\n\n- Do not expose sensitive credentials (API tokens, Azure subscription IDs, etc.) in code examples.\n- Do not fabricate tool versions, installation paths, or software availability without verifying against toolset files or actual installation scripts.\n- Always call out assumptions and limitations explicitly, especially for changes affecting runner image behavior or software availability.\n- If ambiguous requests are made about image modifications, ask clarifying questions about target OS, tool versions, and compatibility requirements before proceeding.\n"},"files":{".github/copilot-instructions.md":"# GitHub Copilot Instructions for Actions Runner Images Repository\n\n## Scope and goals\n\n- This repository serves as the source for building GitHub Actions runner and Azure DevOps agent images for Windows, Ubuntu, and macOS. You can find exact versions in the [Available Images](../README.md#available-images) section of README.md. Windows and Ubuntu images build on Azure infrastructure using Packer; macOS images use Anka virtualization.\n- Emphasize best practices for contributing to open-source projects, including code style, commit messages, and pull request etiquette.\n- Prefer clarity and correctness over creativity. If information is missing, ask clarifying questions or insert TODOs instead of guessing.\n\n## Code and command instructions\n\n- Follow the code style guide in [CONTRIBUTING.md](../CONTRIBUTING.md#code-style-guide) for Bash and PowerShell scripts, including naming conventions, file structure, and indentation rules.\n- Focus on re-using helpers when writing scripts. Windows, Linux and Ubuntu scripts have helper functions available to simplify installation and validation.\n- Always confirm versions and installation paths against existing toolset files and installation scripts.\n\n## Output format\n\n- Use GitHub Flavored Markdown only. Avoid raw HTML unless necessary.\n- One H1 (`#`) per page, followed by logical, sequential headings (`##`, `###`, …).\n- Use fenced code blocks with language identifiers (` ```bash `, ` ```json `, ` ```yaml `, etc.).\n- Use blockquote callouts for notes:\n  > [!NOTE] Context or nuance  \n  > [!TIP] Helpful hint  \n  > [!WARNING] Risks or breaking changes  \n  > [!IMPORTANT] Critical requirement for functionality\n\n## Style and tone\n\n- Audience: Open-source contributors, GitHub Actions maintainers, and developers building custom runner images. Assume familiarity with CI/CD concepts, Packer, and basic infrastructure provisioning, but explain platform-specific details (Azure for Windows/Ubuntu, Anka for macOS) when relevant.\n- Voice: Second person (\"you\"), active voice, imperative for operational steps.\n- Be concise: short paragraphs and sentences. Prefer lists and step-by-steps, especially for operational procedures and troubleshooting.\n- Use inclusive, accessible language. Avoid idioms, sarcasm, and culturally specific references.\n- English: en-US (spelling, punctuation, and units).\n\n## Safety and integrity\n\n- Do not expose sensitive credentials (API tokens, Azure subscription IDs, etc.) in code examples.\n- Do not fabricate tool versions, installation paths, or software availability without verifying against toolset files or actual installation scripts.\n- Always call out assumptions and limitations explicitly, especially for changes affecting runner image behavior or software availability.\n- If ambiguous requests are made about image modifications, ask clarifying questions about target OS, tool versions, and compatibility requirements before proceeding.\n"},"items":[{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","title":"copilot-instructions.md","content":"# GitHub Copilot Instructions for Actions Runner Images Repository\n\n## Scope and goals\n\n- This repository serves as the source for building GitHub Actions runner and Azure DevOps agent images for Windows, Ubuntu, and macOS. You can find exact versions in the [Available Images](../README.md#available-images) section of README.md. Windows and Ubuntu images build on Azure infrastructure using Packer; macOS images use Anka virtualization.\n- Emphasize best practices for contributing to open-source projects, including code style, commit messages, and pull request etiquette.\n- Prefer clarity and correctness over creativity. If information is missing, ask clarifying questions or insert TODOs instead of guessing.\n\n## Code and command instructions\n\n- Follow the code style guide in [CONTRIBUTING.md](../CONTRIBUTING.md#code-style-guide) for Bash and PowerShell scripts, including naming conventions, file structure, and indentation rules.\n- Focus on re-using helpers when writing scripts. Windows, Linux and Ubuntu scripts have helper functions available to simplify installation and validation.\n- Always confirm versions and installation paths against existing toolset files and installation scripts.\n\n## Output format\n\n- Use GitHub Flavored Markdown only. Avoid raw HTML unless necessary.\n- One H1 (`#`) per page, followed by logical, sequential headings (`##`, `###`, …).\n- Use fenced code blocks with language identifiers (` ```bash `, ` ```json `, ` ```yaml `, etc.).\n- Use blockquote callouts for notes:\n  > [!NOTE] Context or nuance  \n  > [!TIP] Helpful hint  \n  > [!WARNING] Risks or breaking changes  \n  > [!IMPORTANT] Critical requirement for functionality\n\n## Style and tone\n\n- Audience: Open-source contributors, GitHub Actions maintainers, and developers building custom runner images. Assume familiarity with CI/CD concepts, Packer, and basic infrastructure provisioning, but explain platform-specific details (Azure for Windows/Ubuntu, Anka for macOS) when relevant.\n- Voice: Second person (\"you\"), active voice, imperative for operational steps.\n- Be concise: short paragraphs and sentences. Prefer lists and step-by-steps, especially for operational procedures and troubleshooting.\n- Use inclusive, accessible language. Avoid idioms, sarcasm, and culturally specific references.\n- English: en-US (spelling, punctuation, and units).\n\n## Safety and integrity\n\n- Do not expose sensitive credentials (API tokens, Azure subscription IDs, etc.) in code examples.\n- Do not fabricate tool versions, installation paths, or software availability without verifying against toolset files or actual installation scripts.\n- Always call out assumptions and limitations explicitly, especially for changes affecting runner image behavior or software availability.\n- If ambiguous requests are made about image modifications, ask clarifying questions about target OS, tool versions, and compatibility requirements before proceeding.\n","category":".github","tokens":733}]}