From 47f8ff47d677fefc44e0a590853fb6b96d2e7625 Mon Sep 17 00:00:00 2001 From: Nan Liu Date: Thu, 2 Jul 2026 00:14:23 +0000 Subject: [PATCH 1/2] feat (instructions): add overlay-metadata.instructions.md for overlay metadata annotation --- .../overlay-metadata.instructions.md | 228 ++++++++++++++++++ 1 file changed, 228 insertions(+) create mode 100644 .github/instructions/overlay-metadata.instructions.md diff --git a/.github/instructions/overlay-metadata.instructions.md b/.github/instructions/overlay-metadata.instructions.md new file mode 100644 index 00000000000..83315426f73 --- /dev/null +++ b/.github/instructions/overlay-metadata.instructions.md @@ -0,0 +1,228 @@ +--- +applyTo: "**/*.comp.toml, **/*.overlay.toml" +description: How to pick a `category` and attach `metadata` when you add or modify an overlay while working on a component. Read this whenever you write a new `[[...overlays]]` entry or `.overlay.toml` file. +--- + +# Overlay Metadata — Category Selection & Annotation + +Every overlay in Azure Linux documents *why* it exists (`description`, **required**) +and *what class of change* it is (`metadata.category`, strongly expected on new +overlays). This file tells you how to pick the right category and stamp the +metadata **at the moment you write the overlay**. + +## The unit of intent: one overlay file = one logical change + +An overlay file (`.overlay.toml`) is the **unit of intentional change** — it says +"these edits go together." A single logical change may require **several +overlays** (e.g. remove a subpackage *and* drop the `--disable-` configure +flags that went with it, or a backport that touches the spec and adds a patch). +That is why the per-file format has exactly **one** top-level `[metadata]` block +and a list of one or more `[[overlays]]` entries it applies to. Per-overlay +`metadata` inside an overlay file is **rejected** — the file-level block is the +single source of truth. + +So: **one `[metadata]` block = one logical change.** If you find yourself giving +several inline overlays the *same* metadata, that is a signal they are one logical +change — `azldev` does not currently reject duplicated inline metadata, but you +**should** move them into a single `.overlay.toml` file with one `[metadata]` +block. + +## When to add metadata + +- **New overlay** (any `[[components..overlays]]` block or `[[overlays]]` + entry in a `.overlay.toml`): add `metadata` with at least a `category`. +- **Modifying an existing overlay's intent** (e.g. a prune becomes a backport): + update the `category` to match the new intent. + +Metadata is excluded from component fingerprints, so adding or editing it never +invalidates build caches or locks. + +## Step 1 — Pick the category + +Choose exactly one `category` from this closed set (these ten values are +authoritative — they match `metadata.category` in the schema): + +| `category` | Use when the overlay… | Extra required/expected fields | +|------------|-----------------------|--------------------------------| +| `backport-dist-git` | Backports (or upstreams) a fix from Fedora dist-git or an upstream project. Self-resolves when AZL bumps past it. | `commits` (≥1 upstream commit URL) — **required** | +| `azl-pruning` | Removes content for AZL: unshipped deps, unneeded features, subpackages, or files. | — | +| `azl-compatibility` | Makes the component build/run in the AZL environment: toolchain or mock adjustments that are **not** themselves backports. | — | +| `azl-dep-missing-workaround` | Works around a build/runtime dependency not yet imported into AZL (or unavailable on a target). Drop it once the dep lands. | — | +| `azl-branding-policy` | Applies Fedora→Azure Linux name/path changes, or RHEL/enterprise convention alignment. | — | +| `azl-disable-flaky-tests` | Skips tests that fail intermittently / due to environmental flakiness, not a real component bug. | — | +| `azl-disable-unsupported-tests` | Skips tests that can't meaningfully run in AZL's build/runtime env (need network, root, or unavailable hardware in mock). | — | +| `azl-security-compliance` | Makes FIPS or crypto-policy changes. | — | +| `azl-release-management` | Adjusts release-tag / changelog mechanics. | — | +| `azl-platform-adaptation` | Makes architecture-specific adjustments. | — | + +### Disambiguation tips + +- **Backport vs. compatibility/pruning:** if the exact change exists as a commit + in Fedora dist-git or the upstream project, it's `backport-dist-git` (and you + must supply `commits`). Only use an `azl-*` category when the change is + AZL-specific with no upstream equivalent. +- **Pruning vs. dep-missing-workaround:** removing a dependency we deliberately + don't ship is `azl-pruning`; temporarily working around a dep that *should* + exist but hasn't been imported yet is `azl-dep-missing-workaround`. +- **Flaky vs. unsupported tests:** flaky = the test *could* pass but is + intermittent; unsupported = the test *cannot* run in mock (network/root/hardware). +- **Compatibility vs. platform-adaptation:** reserve `azl-platform-adaptation` + for architecture-specific (`%ifarch`-style) changes; general + toolchain/mock/build-env fixes are `azl-compatibility`. + +## Step 2 — Set `upstreamable` (optional but encouraged) + +A boolean recording whether the change *could* go upstream: + +- `upstreamable = true` — a generic fix that upstream would plausibly accept. +- `upstreamable = false` — inherently AZL-specific (branding, pruning we want, + policy) that upstream would not take. +- **Omit the field** when you haven't assessed it. + +## Step 3 — Add provenance (`commits`, `bugs`) + +- `commits` — list of absolute upstream commit URLs. **Required for + `backport-dist-git`**; optional elsewhere but valuable whenever a change traces + to a specific commit. For a single logical change that spans several commits, + list them all: `commits = [url1, url2, …]`. Verify each SHA actually exists + before recording it. +- `bugs` — list of `{ url = "…" }` tables referencing tracker entries. + +## Step 4 — Write the metadata (TOML forms) + +**Prefer the per-file layout (`.overlay.toml`) for all new work — even a component +with a single overlay.** It keeps `category`/`commits`/`bugs` on their own lines +(no inline-table one-line limit) and means a change never has to be reshuffled when +it grows a second overlay. Reach for inline `metadata` only when editing a +component that is already inline and you don't want to restructure it. + +**Per-file layout** — one top-level `[metadata]` table applies to every +`[[overlays]]` entry in the file. + +Single-overlay change: + +```toml +# One logical change: rebrand the RPM vendor for Azure Linux. +[metadata] +category = "azl-branding-policy" +upstreamable = false + +[[overlays]] +description = "Customize RPM vendor to Azure Linux" +type = "spec-search-replace" +regex = "RPM_VENDOR=redhat" +replacement = "RPM_VENDOR=azurelinux" +``` + +Multi-overlay change: + +```toml +# One logical change: drop the maven-local-openjdk21 subpackage. +[metadata] +category = "azl-pruning" + +[[overlays]] +description = "Remove maven-local-openjdk21 %package section — AZL ships no java-21-openjdk" +type = "spec-remove-subpackage" +package = "maven-local-openjdk21" + +[[overlays]] +description = "Remove maven-local-openjdk21 %files section — subpackage above is gone" +type = "spec-remove-subpackage" +package = "javapackages-local-openjdk21" +``` + +### File layout & naming + +Set `overlay-files` on the component to one or more globs (resolved relative to the +component config) and put one overlay file per logical change into a directory. The +conventional layout is a sibling `overlays/` directory with a `*.overlay.toml` +suffix — neither is strictly required (`overlay-files` is just a glob), but follow +the convention unless you have a reason not to: + +``` +base/comps/mypackage/ +├── mypackage.comp.toml +└── overlays/ + ├── 0001-cve-2024-1234.overlay.toml + ├── 0002-disable-broken-tests.overlay.toml + └── 0003-azl-branding.overlay.toml +``` + +```toml +# mypackage.comp.toml +[components.mypackage] +overlay-files = ["overlays/*.overlay.toml"] +``` + +`overlay-files` can also be set on `default-component-config` at the project, +distro, or component-group level, so you don't have to repeat the same pattern in +every component's TOML. Inherited relative patterns are resolved per concrete +component (from its config file, or the matched spec's directory), making a default +like `overlay-files = ["overlays/*.overlay.toml"]` a convenient +component-local discovery rule. A component that sets its own `overlay-files` +**replaces** the inherited list; use `overlay-files = []` to opt out, or list both +the inherited and component-specific patterns to keep default discovery and add +more. + +Naming and ordering rules: + +- **Prefix every file with a numeric ordinal** (`0001-`, `0002-`, …). Files load in + **filename (lexicographic) order** within each glob, and globs concatenate in + declaration order, so the ordinal makes the apply order obvious and stable. +- **Give the file a short, descriptive slug** after the ordinal that names the + logical change (`0001-cve-2024-1234`, `0002-disable-broken-tests`, + `0003-drop-openjdk21`). One file = one logical change, so the slug should read + like a one-line summary of that change. +- Overlays loaded via `overlay-files` are **appended after** any inline overlays + still declared on the component. To avoid surprising apply order, move **all** of + a component's overlays into files rather than mixing inline + file overlays. +- Relative `source` paths inside an overlay file resolve against the **overlay + file's own directory**, not the component config — a sibling patch in the + component root becomes `source = "../my.patch"`. + +### Inline forms (not recommended, the support will be removed in the future) + +**Single-line inline table** — one or two scalar fields, ≤ ~80 chars. Must fit on +one line (no lists): + +```toml +[[components.rpm.overlays]] +description = "Customize RPM vendor to Azure Linux" +type = "spec-search-replace" +regex = "RPM_VENDOR=redhat" +replacement = "RPM_VENDOR=azurelinux" +metadata = { category = "azl-branding-policy", upstreamable = false } +``` + +**Sub-table form** — required whenever you need a list (`commits`, `bugs`) or more +than a couple of fields: + +```toml +[[components.xclock.overlays]] +description = "Pass --force to autoreconf so the build survives newer autotools" +type = "spec-search-replace" +regex = "autoreconf -i" +replacement = "autoreconf -fi" + +[components.xclock.overlays.metadata] +category = "backport-dist-git" +upstreamable = true +commits = ["https://src.fedoraproject.org/rpms/xclock/c/1e407488"] +``` + +## Step 5 — Verify + +After editing, confirm the metadata parses and is attached where you expect. This +is a no-op on the rendered spec: + +```bash +# Rendered spec must be unchanged by the metadata itself +azldev comp render -p +git diff specs/ +``` + +If you added or modified the overlay's actual behavior (not just metadata), +follow the normal build + smoke-test protocol in +[`AGENTS.md`](../../AGENTS.md) and re-run `azldev comp update -p ` before +opening a PR. Metadata-only edits need neither a rebuild nor a lock refresh. From 9922f66b5f58db535a311d4083f12e2cc91fc1ef Mon Sep 17 00:00:00 2001 From: Nan Liu Date: Thu, 2 Jul 2026 00:11:51 +0000 Subject: [PATCH 2/2] feat (instructions): add skill-annotate-overlays for overlay metadata annotation --- .../skills/skill-annotate-overlays/SKILL.md | 296 ++++++++++++++++++ AGENTS.md | 1 + 2 files changed, 297 insertions(+) create mode 100644 .github/skills/skill-annotate-overlays/SKILL.md diff --git a/.github/skills/skill-annotate-overlays/SKILL.md b/.github/skills/skill-annotate-overlays/SKILL.md new file mode 100644 index 00000000000..66bc2eb338e --- /dev/null +++ b/.github/skills/skill-annotate-overlays/SKILL.md @@ -0,0 +1,296 @@ +--- +name: skill-annotate-overlays +description: "[Skill] Suggest a metadata `category` and annotate overlays in the Azure Linux repo — either new overlays you are adding or a specific set of existing overlays a user points you at. Uses an LLM to classify the change, hunt for the originating upstream commit(s) and bug(s), and judge upstreamability, then writes the metadata per the overlay-metadata instructions. Triggers: annotate overlay, add overlay metadata, classify overlay, pick overlay category, suggest category, upstreamable, overlay commits/bugs." +--- + +# Suggest Category & Annotate Overlays + +This skill helps you attach `metadata` (at minimum a `category`) to overlays in +the Azure Linux repo. It is **targeted**, not a bulk sweep — use it for: + +- **New overlays** you (or the user) are adding to a component, or +- **A specific set of existing overlays** the user points you at (one component, + one overlay file, or a named list). + +It is **not** for mass-annotating or migrating every overlay in the tree. + +For each overlay in scope the skill: + +1. Reads the overlay's actual change and **suggests a `category`** (with reasoning). +2. **Hunts for the originating upstream commit(s) and bug(s)** so `commits` / + `bugs` are grounded in real provenance, not guesses. +3. **Judges `upstreamable`** (true / false / omit). +4. **Writes the metadata** following + [`overlay-metadata.instructions.md`](../../instructions/overlay-metadata.instructions.md) + — that file is the source of truth for the category set, the field semantics, + the per-file vs. inline TOML forms, and file layout/naming. Re-read it at the + start of every run; the guidance below only adds the *classification workflow*. + +Annotation is **pure documentation** — it must not change the rendered spec. The +overlay's behavior, order, and count stay identical; only `metadata` is added or +edited. + +## Inputs + +| Input | Required | Notes | +|-------|----------|-------| +| Scope | **Yes** | The overlay(s) to annotate: a component name, an overlay file, or an explicit list. For new overlays, the ones you just wrote. | +| User-supplied provenance | No | Any commit/PR/bug URLs the user already knows. Prefer these over rediscovery. | + +If the scope is ambiguous (e.g. "annotate the qemu overlays" when only some are +new), ask the user which overlays they mean before editing. + +## Step 1 — Read each overlay's change + +For every overlay in scope, understand *what it actually does* before classifying: + +```bash +# Read the defining file(s) +find base/comps// -type f \( -name '*.comp.toml' -o -name '*.overlay.toml' \) | sort +``` + +Note the overlay `type`, target `section`/`package`, the `description`, any +top-of-file comments, and — for `patch-add` — the patch header and body. These are +your primary classification signals. + +## Step 2 — Suggest a category (LLM classification) + +Map the change to exactly one `category` from the closed set in +[`overlay-metadata.instructions.md`](../../instructions/overlay-metadata.instructions.md#step-1--pick-the-category). +Do **not** restate the table here — read it there. Apply its disambiguation tips +(backport vs. compat/pruning, pruning vs. dep-missing, flaky vs. unsupported +tests, compatibility vs. platform-adaptation). + +Classification heuristics from the overlay itself: + +- `spec-remove-*`, `patch-remove`, `file-remove`, dropping a `BuildRequires`/ + subpackage we don't ship → usually `azl-pruning`. +- `spec-remove-tag` on a dep that *should* exist but isn't imported yet → + `azl-dep-missing-workaround`. +- A `patch-add` whose header matches a real upstream/dist-git commit, or a spec + edit that mirrors a dist-git change → `backport-dist-git` (**requires** + `commits`). +- Skipping tests → `azl-disable-flaky-tests` (intermittent) vs. + `azl-disable-unsupported-tests` (can't run in mock: network/root/hardware). + Grep the overlay's `description`, surrounding comp.toml comments, and the + component's git history for the word **`flaky`** — if it appears, the intent is + intermittent failure, so classify as `azl-disable-flaky-tests`: + + ```bash + # Comments / descriptions in the component config + grep -niE 'flaky|flake|intermittent|racy|race' base/comps//*.toml base/comps//**/*.toml + # Commit messages touching the component (same keyword set) + git log -i -E --grep='flaky|flake|intermittent|racy|race' --oneline -- base/comps// + ``` + + For a component defined inside a **component-group** file (its overlays live in + a shared `base/comps/component-*.toml` under + `[component-groups..overlays]` rather than a dedicated comp dir), the + history above won't isolate it. `git blame` the specific line(s) that define the + component / its overlay and inspect the originating commit message for the same + keywords: + + ```bash + # Find the line range for the component/overlay, then blame it + grep -n '' base/comps/component-.toml + git blame -L , base/comps/component-.toml + # Inspect the commit(s) the blame points at + git show -s --format='%h %s%n%b' | grep -iE 'flaky|flake|intermittent|racy|race' + ``` + + If any of these turns up the keywords, classify as `azl-disable-flaky-tests`; + otherwise treat the skipped test as `azl-disable-unsupported-tests`. +- Fedora→AZL name/path or RHEL-alignment edits → `azl-branding-policy`. +- Toolchain/mock/build-env fixes with no upstream equivalent → `azl-compatibility`. +- `%ifarch`-style arch-specific tweaks → `azl-platform-adaptation`. +- FIPS / crypto-policy → `azl-security-compliance`. +- Release-tag / changelog mechanics → `azl-release-management`. + +State your suggested category **and a one-line rationale** for each overlay so the +user can sanity-check. When two categories are plausible, say so and pick the +higher one in the instructions' priority order (first match wins). + +## Step 3 — Hunt for commits & bugs (provenance) + +Grounded `commits` are the most valuable field for `backport-dist-git` (and are +**required** there), and useful for any category that traces to a specific fix. +Prefer provenance the user supplied; otherwise actively look for it. **A commit +URL you discovered and verified is not "inventing" metadata; an unverified guess +is.** Never fabricate a `bugs` entry. + +Search in this order, stopping at the first that yields a **verifiable** commit: + +1. **The overlay's own comments / `description`** — reuse any `# Backport from …/c/`, `(upstream )`, PR, or bug link already present. +2. **`patch-add` patch headers** — `git format-patch` output starts with + `From <40-hex-sha> …`; that SHA is the upstream commit. Also scan the body for + `Ref:`, `Closes:`, `Resolves:`, `(cherry picked from commit )`, or + `owner/repo#` / PR / issue URLs. + + ```bash + sed -n '1,40p' base/comps//.patch + grep -nE '^From [0-9a-f]{7,40}|cherry picked from|Ref:|Closes:|Resolves:|#[0-9]+|/(pull|commit|issues)/' \ + base/comps//.patch + ``` +3. **Fedora dist-git / upstream `git log`** — for spec edits that mirror an + upstream change, find the commit in + `https://src.fedoraproject.org/rpms/` or the project's repo. + +Always confirm a candidate SHA exists upstream before recording it, and resolve +PR/issue references to the concrete commit: + +```bash +gh api repos///commits/ -q '.html_url' +gh api repos///pulls//commits -q '.[].sha' +gh api repos///pulls/ -q '.merge_commit_sha' +gh api repos///issues//timeline \ + -q '.[] | select(.event=="cross-referenced" or .event=="closed")' +``` + +Record canonical URLs in `commits` (upstream-project repo for project patches, +Fedora dist-git for dist-git backports). List all commits of one logical change: +`commits = [url1, url2, …]`. Add `bugs = [{ url = "…" }]` for any tracker entry the +overlay or a resolved reference points to. If no commit can be found **and** +verified for a `backport-dist-git` overlay, note the gap in your summary and flag +it for the user rather than guessing. + +## Step 4 — Judge `upstreamable` + +Decide whether the change *could* go upstream and set the boolean per the +instructions: + +- `upstreamable = true` — a generic fix upstream would plausibly accept (most + backports, real bug fixes, portable compatibility fixes). +- `upstreamable = false` — inherently AZL-specific (branding, deliberate pruning, + enterprise policy) that upstream would not take. +- **Omit** when you genuinely can't assess it. Never emit a string + `upstreamability` field. + +## Step 5 — Write the metadata + +Apply the metadata using the exact TOML forms and layout/naming rules in +[`overlay-metadata.instructions.md` → Step 4](../../instructions/overlay-metadata.instructions.md#step-4--write-the-metadata-toml-forms): + +- **Prefer the per-file `.overlay.toml` layout** for new work — even single-overlay + changes — with one top-level `[metadata]` block per logical change. +- Overlays that share the same intent are **one logical change** → one + `.overlay.toml` file with one `[metadata]`. Don't stamp identical inline metadata + on several overlays. +- Inside a `.overlay.toml`, per-overlay `metadata` is **rejected** — the file-level + block is the single source of truth. +- Use inline `metadata` only when the component is already inline and you're not + restructuring it (single-line form for one or two scalar fields; sub-table form + when you need `commits`/`bugs` or more fields). + +### Preserve apply order when moving overlays into files + +Overlay apply order is **significant** — later overlays operate on the spec text +produced by earlier ones, so reordering can silently change (or break) the render. +When you migrate inline overlays into `.overlay.toml` files you **must** reproduce +the exact original sequence: + +- **Files apply in filename (lexicographic) order**, and globs concatenate in + declaration order. Prefix every file with a zero-padded ordinal (`0001-`, + `0002-`, …) so the file order matches the original inline order top-to-bottom. +- **Within a file, `[[overlays]]` apply in declaration order.** Keep overlays in + the same relative order they had inline; don't sort or regroup them in a way + that moves an overlay across another it depended on. +- **Split on real boundaries only.** A group of inline overlays may become one + file only if they were contiguous in the original array (or their reordering is + provably irrelevant). If two logical groups were interleaved inline, either keep + that interleaving via ordinals or confirm with the Step 6 diff that pulling them + apart is a no-op. +- **Move *all* of a component's overlays into files.** Overlays loaded via + `overlay-files` are **appended after** any inline overlays left on the + component, so a partial migration silently moves the file-loaded overlays to the + end of the sequence. Leave no inline `[[overlays]]` behind (or preserve the + exact global order via ordinals across both). + +The Step 6 diff is the enforcement mechanism: if the order changed, the rendered +spec (or `diff-sources` output) will differ. + +Preserve any explanatory top-of-file comments and the existing `description` text +verbatim; if a `description` is missing, leave it absent unless the user asks you +to write one. + +## Step 6 — Validate (mandatory) + +Annotation **and** the file migration must be a no-op on the applied overlays. The +rendered spec, the overlay set, and — critically — the overlay **apply order** must +be identical before and after. + +```bash +# Baseline before editing +azldev comp render -p +cp specs///.spec ./base/build/work/scratch/overlay-annotate--before.spec + +# … make the metadata edits … + +# After editing — expect NO diff +azldev comp render -p +diff -u ./base/build/work/scratch/overlay-annotate--before.spec specs///.spec +``` + +**Order check without a full render.** If `render` is unavailable (e.g. the mock +build root is locked in a shared environment), use `diff-sources`, which applies +the overlays in order and shows the resulting patch. Capture it before and after +the migration and confirm they are byte-identical — this directly proves the apply +order was preserved: + +```bash +azldev component diff-sources -p -q > ./base/build/work/scratch/-diff-before.txt # before edits +# … move overlays into files / add metadata … +azldev component diff-sources -p -q > ./base/build/work/scratch/-diff-after.txt # after edits +diff -u ./base/build/work/scratch/-diff-before.txt ./base/build/work/scratch/-diff-after.txt \ + && echo "IDENTICAL — order and content preserved" +``` + +Any diff means an overlay changed **or** the apply order shifted (a common symptom +of a partial migration, a mis-ordered file ordinal, or overlays regrouped across a +dependency). Fix the ordinals/grouping until the diff is empty. + +- Every in-scope overlay carries the expected `category`. +- `upstreamable` is a boolean where set (or absent), never the string + `upstreamability`. +- `backport-dist-git` overlays carry `commits`. +- The overlay **order and count** are unchanged (the before/after diff is empty). + +If `render` fails, re-check the per-file rules in the instructions — common +mistakes: per-overlay `metadata` in a `.overlay.toml`; a file-level `[metadata]` +missing `category`; an `overlay-files` glob that matches no files; leftover inline +`[[overlays]]` blocks after moving them into a file (these append **after** the +file overlays and reorder the sequence). + +## Step 7 — Finalize for PR + +Metadata is excluded from component fingerprints, so annotation alone does not +invalidate locks and needs **no build or smoke-test** (the rendered spec is +identical). Still, run `update` to capture any incidental drift and follow the +standard finalize flow: + +```bash +azldev comp update -p +git status base/comps// locks/.lock specs/ +``` + +If `update` or `render` touched anything, include it in the same commit, then +re-render and amend so `%changelog` / `Release:` track the commit (see +[`skill-update-component`](../skill-update-component/SKILL.md)). + +## Common pitfalls + +- **Discover provenance, don't invent it.** `commits` may be added only when you + **verified** the SHA exists upstream; `bugs`/PR links must come from the overlay, + a resolved reference, or the user — never a guess. +- **`upstreamable` is a boolean.** `true` / `false` / omit — never a string. +- **Don't change overlay order, count, or behavior.** This skill only adds + `metadata` (and optionally regroups overlays into files). The apply order must be + **identical** before and after — later overlays depend on earlier ones' output, + so a reorder can change or break the render. Use zero-padded file ordinals + (`0001-`, …) and declaration order within each file to reproduce the original + sequence exactly, and prove it with the Step 6 before/after diff. +- **Move all overlays into files, or none.** A partial migration appends the + file-loaded overlays **after** any remaining inline ones, silently reordering the + sequence. +- **Don't merge or split the overlays' *behavior*.** Grouping into one + `.overlay.toml` for annotation is fine; altering what the overlays *do* is not. +- **Ambiguous scope → ask.** Don't guess which overlays the user meant. diff --git a/AGENTS.md b/AGENTS.md index 529cc846e76..e59a6d9ee19 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -58,6 +58,7 @@ Detailed workflows live in skills (loaded on-demand when relevant): | Add a new component to the distro | [`skill-add-component`](.github/skills/skill-add-component/SKILL.md) | | Remove component(s) from the distro | [`skill-remove-component`](.github/skills/skill-remove-component/SKILL.md) | | Diagnose and fix overlay issues | [`skill-fix-overlay`](.github/skills/skill-fix-overlay/SKILL.md) | +| Suggest category & annotate overlay metadata | [`skill-annotate-overlays`](.github/skills/skill-annotate-overlays/SKILL.md) | | Test and inspect packages in mock chroot | [`skill-mock`](.github/skills/skill-mock/SKILL.md) | | Review component for hygiene and best practices | [`skill-review-component`](.github/skills/skill-review-component/SKILL.md) | | Triage Koji build failures | [`skill-koji-triage`](.github/skills/skill-koji-triage/SKILL.md) |