[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69AWFXVD864EJSG2AS4DCMM":3,"skill-same:01M69AWFXVD864EJSG2AS4DCMM":68},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M69AWFXVD864EJSG2AS4DCMM","azldev-overlay-metadata",null,"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\u002Fbug 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.","microsoft\u002Fazurelinux","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69AVY9Y3D59ZBRVNKRJ851E",5362,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fazurelinux\u002Fblob\u002F4.0\u002F.agents\u002Fskills\u002Fazldev-overlay-metadata\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"overlay","azldev overlay metadata","azldev","metadata","file","when","can","URL","branding","triggers","upstream","do","references","schema","policy","metadata schema","backport","documents","status","commit","memory","2026-11-10 10:12:30",false,"---\nname: azldev-overlay-metadata\ndescription: \"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\u002Fbug 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.\"\n---\n\n# Overlay metadata — pick a category and annotate\n\nEvery overlay documents *why* it exists (`description`, **required**) and *what class\nof change* it is (`metadata`). When a `[metadata]` block is present it **requires** both\na `category` and an `upstream-status`. This skill covers how to pick the right values,\nattach provenance, and write the TOML at the moment you author or review an overlay.\n\nMetadata is **pure documentation** — it never changes the rendered spec and is excluded\nfrom component fingerprints, so adding or editing it never invalidates build caches or\nlocks. For overlay *types* and the render-and-inspect loop, read the `azldev-overlays`\nskill; this skill is only about the `metadata` table.\n\n## One `[metadata]` block = one logical change\n\nA single logical change (a CVE backport, a feature disablement, a Fedora cherry-pick)\nmay need **several overlays** — e.g. remove a sub-package *and* drop the configure flags\nthat went with it. The per-file overlay format (`overlay-files`) captures exactly this:\none top-level `[metadata]` table and one or more `[[overlays]]` entries it applies to.\nPer-overlay `metadata` inside an overlay file is **rejected** — the file-level block is\nthe single source of truth.\n\nSo: if you find yourself stamping the *same* metadata on several inline overlays, that is\na signal they are one logical change — move them into a single overlay file with one\n`[metadata]` block.\n\n## When to add metadata\n\n- **New overlay** (any inline `[[components.\u003Cname>.overlays]]` block or `[[overlays]]`\n  entry in an overlay file): add `metadata` with both a `category` and an `upstream-status`.\n- **An overlay's intent changed** (e.g. a prune becomes a backport): update the `category`\n  and `upstream-status` to match the new intent.\n\n## Step 1 — Pick the category\n\nChoose exactly one `category` from this closed set (authoritative — matches\n`metadata.category` in the schema):\n\n| `category` | Use when the overlay… | Extra required\u002Fexpected fields |\n|------------|-----------------------|--------------------------------|\n| `upstream-backport` | Backports a fix from an upstream source (Fedora dist-git or the component's OSS project) that AZL will inherit once it bumps past the fix. Self-resolves on version bump. | `commits` (≥1 upstream commit URL) — **required**. `upstream-status` must be `upstreamed` or `upstreamable`. |\n| `azl-pruning` | Removes content for AZL: unshipped deps, unneeded features, sub-packages, or files. | — |\n| `azl-compatibility` | Adapts a component to *how Azure Linux is built and shipped* — build tooling, buildroot, infrastructure, runtime ecosystem — when upstream builds\u002Fbehaves incorrectly for AZL-specific reasons that are **not** branding, a missing dependency, architecture, or tests (e.g. `azldev` downloader quirks, `rpmdiff` reproducibility, buildroot gaps, Fedora version-skew). | — |\n| `azl-temp-workaround` | Temporary workaround explicitly intended to be dropped once an upstream or environmental fix lands. Covers a dependency not yet imported into AZL (or unavailable on a target) **and** any other transient workaround waiting on an external change. | — |\n| `azl-branding-policy` | Fedora→Azure Linux identity differences: intentional name\u002Fpath\u002Fvendor conventions **and** spec fixes for upstream code that hard-codes Fedora identity strings (e.g. `_vendor=redhat`, `\u003Ccpu>-redhat-linux[-gnu]` triples, `redhat-linux-build` dirs). Also covers repointing a `Source`\u002F`URL` tag from a Fedora mirror to an Azure Linux one (e.g. `azurelinux-rpm-config`, `golang`). | — |\n| `azl-disable-flaky-tests` | Skips tests that fail intermittently \u002F due to environmental flakiness, not a real component bug. | — |\n| `azl-disable-unsupported-tests` | Skips tests that cannot meaningfully run in AZL's build\u002Fruntime env (need network, root, or unavailable hardware in mock). | — |\n| `azl-security-compliance` | Makes FIPS or crypto-policy changes. | — |\n| `azl-release-management` | Adjusts release-tag \u002F changelog mechanics. | — |\n| `azl-platform-adaptation` | Makes architecture-specific adjustments. | — |\n\n### Disambiguation tips\n\n- **Backport vs. compatibility\u002Fpruning:** if the exact change exists as a commit in Fedora\n  dist-git or the upstream project, it is `upstream-backport` (supply `commits`, with\n  `upstream-status` of `upstreamed` or `upstreamable`). Use an `azl-*` category only when\n  the change is AZL-specific with no upstream equivalent.\n- **Pruning vs. temp-workaround:** removing a dependency we deliberately don't ship is\n  `azl-pruning`; temporarily working around a dep that *should* exist but hasn't been\n  imported yet (or any transient workaround waiting on an external fix) is\n  `azl-temp-workaround`.\n- **Flaky vs. unsupported tests:** flaky = the test *could* pass but is intermittent;\n  unsupported = the test *cannot* run in mock (network\u002Froot\u002Fhardware). Require evidence of\n  the limitation before choosing `azl-disable-unsupported-tests`; investigate or ask when\n  the failure mode is unclear.\n- **Compatibility vs. platform-adaptation:** reserve `azl-platform-adaptation` for\n  architecture-specific (`%ifarch`-style) changes; general toolchain\u002Fmock\u002Fbuild-env fixes\n  are `azl-compatibility`.\n\n## Step 2 — Set `upstream-status`\n\nRequired whenever `[metadata]` is present. It classifies the overlay's relationship to\nupstream — \"why are we carrying this?\" and \"what would it take to drop it?\" Pick exactly one:\n\n| Value | Meaning |\n|-------|---------|\n| `upstreamed` | Already in Fedora; carried only until AZL bumps past it. |\n| `upstreamable` | The patch we carry is itself upstream-shaped (or already in the OSS project but not in Fedora yet); the same diff could be sent upstream and plausibly accepted. Link the upstream PR when you can. |\n| `needs-upstream-hook` | AZL-specific change that upstream wouldn't take as-is, but upstream could add a `bcond`\u002F`%if`\u002Fconfig knob so we could drop the overlay. |\n| `inapplicable` | Permanent AZL-only deviation with no upstream story (branding, deliberate pruning, enterprise policy). |\n| `unknown` | Not yet assessed. Prefer a definite value; reviewers should push back on `unknown` before approving. |\n\nOn an `upstream-backport` overlay only `upstreamed` and `upstreamable` are allowed — any\nother value is a validation error.\n\n**`upstreamable` vs. `needs-upstream-hook`:** `upstreamable` means the patch we carry is\nitself upstream-shaped (send the same diff upstream); `needs-upstream-hook` means the\nchange is AZL-specific and would *not* be accepted as-is, but upstream could add a hook\nthat makes patching unnecessary.\n\n## Step 3 — Add provenance (`commits`, `bugs`)\n\n- `commits` — list of `{ url = \"...\" }` tables pointing at upstream commits (absolute\n  http(s) URLs). **Required for `upstream-backport`**; optional elsewhere but valuable\n  whenever a change traces to a specific commit. For one logical change spanning several\n  commits, list them all. Verify each SHA actually exists upstream before recording it — a\n  discovered-and-verified URL is not \"inventing\" metadata; an unverified guess is.\n- `bugs` — list of `{ url = \"...\" }` tables referencing tracker entries. Never fabricate one.\n\n## Step 4 — Write the metadata (TOML forms)\n\n**Prefer the per-file layout (an overlay file loaded via `overlay-files`) for all new\nwork — even a component with a single overlay.** It keeps `category`\u002F`commits`\u002F`bugs` on\ntheir own lines (no inline-table one-line limit) and means a change never has to be\nreshuffled when it grows a second overlay. One top-level `[metadata]` table applies to\nevery `[[overlays]]` entry in the file.\n\nMulti-overlay change (one logical change, several overlays):\n\n```toml\n# One logical change: drop the devel sub-package AZL does not ship.\n[metadata]\ncategory = \"azl-pruning\"\nupstream-status = \"inapplicable\"\n\n[[overlays]]\ndescription = \"Remove the devel sub-package — AZL ships no -devel for this component\"\ntype = \"spec-remove-subpackage\"\npackage = \"devel\"\n\n[[overlays]]\ndescription = \"Drop the BuildRequires only the devel sub-package needed\"\ntype = \"spec-remove-tag\"\ntag = \"BuildRequires\"\nvalue = \"some-devel-only-dep\"\n```\n\n### Inline forms\n\nUse inline `metadata` only when the component is already inline and you are not\nrestructuring it. A single-line inline table must fit on one line (no lists), so it is\nlimited to one or two scalar fields:\n\n```toml\n[[components.rpm.overlays]]\ndescription = \"Customize RPM vendor to Azure Linux\"\ntype = \"spec-search-replace\"\nregex = \"RPM_VENDOR=redhat\"\nreplacement = \"RPM_VENDOR=azurelinux\"\nmetadata = { category = \"azl-branding-policy\", upstream-status = \"inapplicable\" }\n```\n\nUse the sub-table form whenever you need a list (`commits`, `bugs`) or more than a couple\nof fields:\n\n```toml\n[[components.xclock.overlays]]\ndescription = \"Pass --force to autoreconf so the build survives newer autotools\"\ntype = \"spec-search-replace\"\nregex = \"autoreconf -i\"\nreplacement = \"autoreconf -fi\"\n\n[components.xclock.overlays.metadata]\ncategory = \"upstream-backport\"\nupstream-status = \"upstreamed\"\ncommits = [{ url = \"https:\u002F\u002Fsrc.fedoraproject.org\u002Frpms\u002Fxclock\u002Fc\u002F1e407488\" }]\n```\n\n## Step 5 — Verify\n\nAdding or editing metadata must be a no-op on the rendered spec. Re-render and confirm\nthere is no diff:\n\n```sh\nazldev comp render -p \u003Cname>\ngit diff specs\u002F\n```\n\nIf you also moved overlays into files, prove the apply order was preserved with\n`azldev comp diff-sources -p \u003Cname>` before and after — any difference means an overlay\nchanged or the sequence shifted. Metadata-only edits need no rebuild or lock refresh; if\nyou also changed an overlay's behavior, finalize with the `azldev-update-component` skill.\n\nGenerated by `azldev docs agent`; do not hand-edit.\n","# Overlay metadata — pick a category and annotate\n\nEvery overlay documents *why* it exists (`description`, **required**) and *what class\nof change* it is (`metadata`). When a `[metadata]` block is present it **requires** both\na `category` and an `upstream-status`. This skill covers how to pick the right values,\nattach provenance, and write the TOML at the moment you author or review an overlay.\n\nMetadata is **pure documentation** — it never changes the rendered spec and is excluded\nfrom component fingerprints, so adding or editing it never invalidates build caches or\nlocks. For overlay *types* and the render-and-inspect loop, read the `azldev-overlays`\nskill; this skill is only about the `metadata` table.\n\n## One `[metadata]` block = one logical change\n\nA single logical change (a CVE backport, a feature disablement, a Fedora cherry-pick)\nmay need **several overlays** — e.g. remove a sub-package *and* drop the configure flags\nthat went with it. The per-file overlay format (`overlay-files`) captures exactly this:\none top-level `[metadata]` table and one or more `[[overlays]]` entries it applies to.\nPer-overlay `metadata` inside an overlay file is **rejected** — the file-level block is\nthe single source of truth.\n\nSo: if you find yourself stamping the *same* metadata on several inline overlays, that is\na signal they are one logical change — move them into a single overlay file with one\n`[metadata]` block.\n\n## When to add metadata\n\n- **New overlay** (any inline `[[components.\u003Cname>.overlays]]` block or `[[overlays]]`\n  entry in an overlay file): add `metadata` with both a `category` and an `upstream-status`.\n- **An overlay's intent changed** (e.g. a prune becomes a backport): update the `category`\n  and `upstream-status` to match the new intent.\n\n## Step 1 — Pick the category\n\nChoose exactly one `category` from this closed set (authoritative — matches\n`metadata.category` in the schema):\n\n| `category` | Use when the overlay… | Extra required\u002Fexpected fields |\n|------------|-----------------------|--------------------------------|\n| `upstream-backport` | Backports a fix from an upstream source (Fedora dist-git or the component's OSS project) that AZL will inherit once it bumps past the fix. Self-resolves on version bump. | `commits` (≥1 upstream commit URL) — **required**. `upstream-status` must be `upstreamed` or `upstreamable`. |\n| `azl-pruning` | Removes content for AZL: unshipped deps, unneeded features, sub-packages, or files. | — |\n| `azl-compatibility` | Adapts a component to *how Azure Linux is built and shipped* — build tooling, buildroot, infrastructure, runtime ecosystem — when upstream builds\u002Fbehaves incorrectly for AZL-specific reasons that are **not** branding, a missing dependency, architecture, or tests (e.g. `azldev` downloader quirks, `rpmdiff` reproducibility, buildroot gaps, Fedora version-skew). | — |\n| `azl-temp-workaround` | Temporary workaround explicitly intended to be dropped once an upstream or environmental fix lands. Covers a dependency not yet imported into AZL (or unavailable on a target) **and** any other transient workaround waiting on an external change. | — |\n| `azl-branding-policy` | Fedora→Azure Linux identity differences: intentional name\u002Fpath\u002Fvendor conventions **and** spec fixes for upstream code that hard-codes Fedora identity strings (e.g. `_vendor=redhat`, `\u003Ccpu>-redhat-linux[-gnu]` triples, `redhat-linux-build` dirs). Also covers repointing a `Source`\u002F`URL` tag from a Fedora mirror to an Azure Linux one (e.g. `azurelinux-rpm-config`, `golang`). | — |\n| `azl-disable-flaky-tests` | Skips tests that fail intermittently \u002F due to environmental flakiness, not a real component bug. | — |\n| `azl-disable-unsupported-tests` | Skips tests that cannot meaningfully run in AZL's build\u002Fruntime env (need network, root, or unavailable hardware in mock). | — |\n| `azl-security-compliance` | Makes FIPS or crypto-policy changes. | — |\n| `azl-release-management` | Adjusts release-tag \u002F changelog mechanics. | — |\n| `azl-platform-adaptation` | Makes architecture-specific adjustments. | — |\n\n### Disambiguation tips\n\n- **Backport vs. compatibility\u002Fpruning:** if the exact change exists as a commit in Fedora\n  dist-git or the upstream project, it is `upstream-backport` (supply `commits`, with\n  `upstream-status` of `upstreamed` or `upstreamable`). Use an `azl-*` category only when\n  the change is AZL-specific with no upstream equivalent.\n- **Pruning vs. temp-workaround:** removing a dependency we deliberately don't ship is\n  `azl-pruning`; temporarily working around a dep that *should* exist but hasn't been\n  imported yet (or any transient workaround waiting on an external fix) is\n  `azl-temp-workaround`.\n- **Flaky vs. unsupported tests:** flaky = the test *could* pass but is intermittent;\n  unsupported = the test *cannot* run in mock (network\u002Froot\u002Fhardware). Require evidence of\n  the limitation before choosing `azl-disable-unsupported-tests`; investigate or ask when\n  the failure mode is unclear.\n- **Compatibility vs. platform-adaptation:** reserve `azl-platform-adaptation` for\n  architecture-specific (`%ifarch`-style) changes; general toolchain\u002Fmock\u002Fbuild-env fixes\n  are `azl-compatibility`.\n\n## Step 2 — Set `upstream-status`\n\nRequired whenever `[metadata]` is present. It classifies the overlay's relationship to\nupstream — \"why are we carrying this?\" and \"what would it take to drop it?\" Pick exactly one:\n\n| Value | Meaning |\n|-------|---------|\n| `upstreamed` | Already in Fedora; carried only until AZL bumps past it. |\n| `upstreamable` | The patch we carry is itself upstream-shaped (or already in the OSS project but not in Fedora yet); the same diff could be sent upstream and plausibly accepted. Link the upstream PR when you can. |\n| `needs-upstream-hook` | AZL-specific change that upstream wouldn't take as-is, but upstream could add a `bcond`\u002F`%if`\u002Fconfig knob so we could drop the overlay. |\n| `inapplicable` | Permanent AZL-only deviation with no upstream story (branding, deliberate pruning, enterprise policy). |\n| `unknown` | Not yet assessed. Prefer a definite value; reviewers should push back on `unknown` before approving. |\n\nOn an `upstream-backport` overlay only `upstreamed` and `upstreamable` are allowed — any\nother value is a validation error.\n\n**`upstreamable` vs. `needs-upstream-hook`:** `upstreamable` means the patch we carry is\nitself upstream-shaped (send the same diff upstream); `needs-upstream-hook` means the\nchange is AZL-specific and would *not* be accepted as-is, but upstream could add a hook\nthat makes patching unnecessary.\n\n## Step 3 — Add provenance (`commits`, `bugs`)\n\n- `commits` — list of `{ url = \"...\" }` tables pointing at upstream commits (absolute\n  http(s) URLs). **Required for `upstream-backport`**; optional elsewhere but valuable\n  whenever a change traces to a specific commit. For one logical change spanning several\n  commits, list them all. Verify each SHA actually exists upstream before recording it — a\n  discovered-and-verified URL is not \"inventing\" metadata; an unverified guess is.\n- `bugs` — list of `{ url = \"...\" }` tables referencing tracker entries. Never fabricate one.\n\n## Step 4 — Write the metadata (TOML forms)\n\n**Prefer the per-file layout (an overlay file loaded via `overlay-files`) for all new\nwork — even a component with a single overlay.** It keeps `category`\u002F`commits`\u002F`bugs` on\ntheir own lines (no inline-table one-line limit) and means a change never has to be\nreshuffled when it grows a second overlay. One top-level `[metadata]` table applies to\nevery `[[overlays]]` entry in the file.\n\nMulti-overlay change (one logical change, several overlays):\n\n```toml\n# One logical change: drop the devel sub-package AZL does not ship.\n[metadata]\ncategory = \"azl-pruning\"\nupstream-status = \"inapplicable\"\n\n[[overlays]]\ndescription = \"Remove the devel sub-package — AZL ships no -devel for this component\"\ntype = \"spec-remove-subpackage\"\npackage = \"devel\"\n\n[[overlays]]\ndescription = \"Drop the BuildRequires only the devel sub-package needed\"\ntype = \"spec-remove-tag\"\ntag = \"BuildRequires\"\nvalue = \"some-devel-only-dep\"\n```\n\n### Inline forms\n\nUse inline `metadata` only when the component is already inline and you are not\nrestructuring it. A single-line inline table must fit on one line (no lists), so it is\nlimited to one or two scalar fields:\n\n```toml\n[[components.rpm.overlays]]\ndescription = \"Customize RPM vendor to Azure Linux\"\ntype = \"spec-search-replace\"\nregex = \"RPM_VENDOR=redhat\"\nreplacement = \"RPM_VENDOR=azurelinux\"\nmetadata = { category = \"azl-branding-policy\", upstream-status = \"inapplicable\" }\n```\n\nUse the sub-table form whenever you need a list (`commits`, `bugs`) or more than a couple\nof fields:\n\n```toml\n[[components.xclock.overlays]]\ndescription = \"Pass --force to autoreconf so the build survives newer autotools\"\ntype = \"spec-search-replace\"\nregex = \"autoreconf -i\"\nreplacement = \"autoreconf -fi\"\n\n[components.xclock.overlays.metadata]\ncategory = \"upstream-backport\"\nupstream-status = \"upstreamed\"\ncommits = [{ url = \"https:\u002F\u002Fsrc.fedoraproject.org\u002Frpms\u002Fxclock\u002Fc\u002F1e407488\" }]\n```\n\n## Step 5 — Verify\n\nAdding or editing metadata must be a no-op on the rendered spec. Re-render and confirm\nthere is no diff:\n\n```sh\nazldev comp render -p \u003Cname>\ngit diff specs\u002F\n```\n\nIf you also moved overlays into files, prove the apply order was preserved with\n`azldev comp diff-sources -p \u003Cname>` before and after — any difference means an overlay\nchanged or the sequence shifted. Metadata-only edits need no rebuild or lock refresh; if\nyou also changed an overlay's behavior, finalize with the `azldev-update-component` skill.\n\nGenerated by `azldev docs agent`; do not hand-edit.\n",{"name":5,"description":7},"4.0","431ad36a7a827e8ec414e96ae75517ec1ded115d",".agents\u002Fskills\u002Fazldev-overlay-metadata",714,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fazurelinux","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-11 08:47:36",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add microsoft\u002Fazurelinux --skill azldev-overlay-metadata",{"tool":60,"command":61},"bunx","bunx skills add microsoft\u002Fazurelinux --skill azldev-overlay-metadata",{"tool":63,"command":64},"pnpm","pnpm dlx skills add microsoft\u002Fazurelinux --skill azldev-overlay-metadata","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fazurelinux\u002Fblob\u002F4.0\u002F.agents\u002Fskills\u002Fazldev-overlay-metadata\u002FSKILL.md",true,[],[69,97,119,143,164,188],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":80,"publishedAt":40},"01M69AX4PP9MJPS4TE3XDW93NJ","skill-metrics","[Skill] metrics, azure-monitor, aks - Query Azure Monitor metrics for Koji AKS node CPU, memory, disk usage, and pod readiness.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fazurelinux\u002Fblob\u002F4.0\u002F.agents\u002Fskills\u002Fskill-metrics\u002FSKILL.md",[75],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[81,82,39,83,84,85,86,87,88,89,90,91,92,93,94,95,96],"skill metrics","metrics","azure","monitor","azure-monitor","aks","disk","node","query","azure monitor","false","readiness","CPU","disk usage","usage","for",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":104,"publishedAt":40},"01M69AX2WT9YWZTVMMQ6QWHG3Y","skill-mass-triage","[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.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fazurelinux\u002Fblob\u002F4.0\u002F.agents\u002Fskills\u002Fskill-mass-triage\u002FSKILL.md",[103],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},[105,106,107,108,109,23,110,111,112,113,114,115,28,116,117,118,24],"triage","skill mass triage","diagnose","produce","batch","json","parallel","results","use","build","summary","with","root","root cause",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":129,"publishedAt":40},"01M69AX11X7RJS8A0GBJV2X0WD","skill-kql-queries","[Skill] kql, queries, log analytics, container logs - KQL query templates for Koji container logs, pod errors, restarts, Kubernetes events, build job activity, and node resource usage via Log Analytics.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fazurelinux\u002Fblob\u002F4.0\u002F.agents\u002Fskills\u002Fskill-kql-queries\u002FSKILL.md",[125,128],{"categoryNo":126,"categoryName":127,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},[130,131,132,133,134,135,136,88,137,138,114,89,91,139,140,141,142,95,96],"skill kql queries","kql","queries","kubernetes","analytics","logs","templates","container","log","events","via","activity","errors",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":150,"publishedAt":40},"01M69AWYRJY05J3N3K9PZ0X38H","skill-koji-triage","[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.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fazurelinux\u002Fblob\u002F4.0\u002F.agents\u002Fskills\u002Fskill-koji-triage\u002FSKILL.md",[149],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},[105,151,152,153,154,155,156,135,157,158,159,113,138,160,161,28,162,163,96,118,24],"skill koji triage","web","root cause analysis","tasks","packages","ui","analysis","broken","fetch","task","info","failure analysis","web ui",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":171,"publishedAt":40},"01M69AWWNGM4S4DDN6MSXMJ1XY","skill-fedora-mirror-injections","[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 \u002F 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.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fazurelinux\u002Fblob\u002F4.0\u002F.agents\u002Fskills\u002Fskill-fedora-mirror-injections\u002FSKILL.md",[170],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},[172,173,174,175,176,107,83,177,178,179,113,180,181,182,183,28,184,185,186,96,187,24],"skill fedora mirror injections","fedora","mirror","spec","linux","pr","bootstrap","injection","dependency","bug","infra","entries","missing","argument","updates","backfill",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":195,"publishedAt":40},"01M69AWTVNFMTX4KQVR6EK62C0","skill-deployment-context","[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.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fazurelinux\u002Fblob\u002F4.0\u002F.agents\u002Fskills\u002Fskill-deployment-context\u002FSKILL.md",[194],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},[196,197,198,134,83,199,200,86,201,138,115,202,91,203,204,24],"skill deployment context","deployment","context","yaml","monitoring","workspace","discover","name","cluster"]