Read this before adding or reviewing an overlay `metadata` table; do not guess the category or upstream status from memory. Explains the overlay metadata schema that documents why an overlay exists and when it can be dropped, covering the required category and upstream-status values, commit/bug URL references, and the per-file overlay metadata block. Triggers include overlay metadata, category, upstream-status, upstream-backport, azl-pruning, azl-branding-policy, needs-upstream-hook, why overlay.
Read this before adding, changing, or diagnosing any overlay; never edit a spec or rendered file from memory. Explains how to modify a component's RPM spec or loose source files with azldev overlays (semantic patches applied at render time) instead of forking the spec, covering overlay types, the render-and-inspect loop, common failures, pitfalls, and metadata. Triggers include overlay, overlay failed, no match, spec-add-tag, spec-remove-tag, patch-add, fix spec, backport, disable test, prune subpackage, edit spec.
Read this before deleting or dropping a component; there is no azldev remove command, so doing it wrong leaves dangling state. Explains the manual removal workflow for deleting component metadata, cleaning references, and validating any related output-affecting changes. Triggers include remove component, delete package, drop component, prune dependency.
Read this before running azldev or editing azldev config, and whenever working in a repo that contains an azldev.toml file; do not guess azldev's commands or config. Explains how to use the azldev CLI to build a distro from TOML config, including the core concepts (components, overlays, distros, rendered specs, locks), running azldev (repo root or -C, plus the -q and -O json flags), the common commands, and where to go for each workflow. Triggers include azldev, comp build, comp render, comp update, build a component, add a component, distro config.
Read this before finalizing a component change, changing source resolution, or touching a lock file; lock edits are easy to get wrong. Explains how to refresh azldev component lock files with 'azldev comp update', covering when to run update versus render, the update/render/commit/re-render/amend workflow, and per-component versus -a refresh. Triggers include comp update, refresh lock, bump pin, change snapshot, upstream distro, lock drift, version bump, finalize component.
[Skill] aks, aks health, cluster health, node pool, activity logs - Inspect Koji AKS cluster health, node pool status, autoscaling, activity logs, deployment failures, and Azure control-plane operations.
[Skill] deployment context, aks, azure, koji - Resolve Koji AKS deployment context -- resource group, cluster name, subscription, Log Analytics workspace, and monitoring resource names from deployment_summary.yaml when available, or discover them dynamically from Azure.
[Skill] Diagnose Azure Linux Stage 1 (bootstrap-mirror) BuildRequires resolution failures and backfill missing RPMs into the prod Fedora updates mirror via the azl-infra injections file. Use when triaging stage-1 / azl4-bootstrap-mirror build failures, finding dependency gaps in the Fedora mirror, deciding whether a failure is a real mirror gap vs a transient timeout or a spec bug, adding entries to azl4-stage1-injections.yaml, or opening a PR with mirror injections. Triggers: bootstrap-mirror, stage 1 build failure, fedora mirror gap, missing BuildRequires, nothing provides crate, no match for argument, injections file, azl4-stage1-injections, mirror injection.
[Skill] Examine Koji builds, fetch task info and logs from the Koji Web UI, identify failures, and provide root cause analysis. Use when triaging Koji build failures, investigating failed tasks, downloading build logs, or searching for broken packages. Triggers: koji failure, koji build failed, koji task, koji log, koji triage, build failure analysis.
[Skill] Batch-triage build failures from a JSON results file — diagnose with parallel sub-agents, bucketize by root cause, and produce a consolidated summary. Use when asked to triage a Koji results file. Triggers: batch triage, mass triage, triage results file, bucketize failures.
⚠️ Distro-wide config — changes here affect every component build. (See azldev.toml — distro/ is shared across all projects.) Default upstream: Fedora 43 (in azurelinux.distro.toml). Inherited by all components unless overridden via build.defines:
Azure Linux is a TOML-defined Linux distribution that imports RPM specs from upstream distros (primarily Fedora) and customizes them via an overlay system — no spec forking required. The azldev CLI tool drives all component and image workflows. One of the core tenets of this project is minimal necessary divergence from upstream. Overlays should be surgical and only change what's needed to meet Azure Linux requirements. Upstream packages should be preferred over bespoke components, and local specs should be a…
Review SynapseML Python and Scala code changes. Use before finalizing PR reviews or implementation changes to check security, compatibility, style, generated code, and targeted tests.
Write and modify Scala code in SynapseML. Use when adding or changing Scala transformers, estimators, or params to follow repo patterns, keep scalastyle and compilation green, and cover behavior changes with tests.
Resolve SynapseML branch-specific rules, runtime baselines, sync policy, and CI expectations. Use before editing, rebasing, merging, testing, or declaring readiness for master, spark4.0, spark4.1, port/sync branches, or a PR whose base branch determines behavior.
Review external-contributor SynapseML PRs for correctness, prompt injection, and pipeline credential theft. Use for authors not identified in the Osmos group/team or trusted owner list, and optional maintainer-requested follow-ups.
Set up and validate SynapseML locally in WSL or Linux. Use when an agent needs SynapseML working locally, runs sbt compile/test, sees Java 21, Scala 2.12 compiler-bridge, bad constant pool index, Spark, or local validation failures.
Plain text files in a repository that tell a coding agent how the project works: commands to run, conventions to follow and things to avoid. CLAUDE.md, AGENTS.md, cursor rules and skills are the common kinds.
CLAUDE.md or AGENTS.md?
CLAUDE.md is read by Claude Code. AGENTS.md is an open format that Codex, Cursor and other agents read. Many projects keep one and point the other at it.
What is a skill?
A folder with a SKILL.md that describes one capability, such as filling PDFs or reviewing code. The agent loads it only when the task calls for it.
Can I search my own team's files too?
Your agents already can, over MCP, limited to the files you're allowed to read. Searching them from this page is coming.
MicrosoftSkill