Azldev Add Component Agent Skill
Read this before adding or importing a component; follow the workflow instead of guessing. Explains how to add a new component to an azldev distro, covering inspecting the upstream spec, the inline-versus-dedicated-file decision, and validating with render, diff-sources, and build. Triggers include add component, new package, import package, create comp.toml, new component.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/microsoft/azurelinux --skill azldev-add-componentThe instruction itself
6 sections, as written by the authorAdd a component
Before you start
Confirm the component does not already exist:
azldev comp list -p <name> -q -O json
Inspect the upstream spec first
The reliable way to see what you are importing (direct web fetches of upstream
dist-git often fail bot detection):
- Add a bare entry so azldev can resolve the component: run
azldev comp add <name>
(it appends [components.<name>] to the root config file), or hand-add
[components.<name>] to an included config file if you want it to live elsewhere.
A bare root entry is *perfect* for initial testing, but real distros will usually
segment the configuration into included files. Once the initial pass is done,
ensure the component is in the right place and remove the root entry.
- Create the initial lock so source resolution is pinned before inspection:
azldev comp update -p <name>
- Pull the sources without overlays into a scratch dir under the work dir:
azldev comp prep-sources -p <name> --skip-overlays --force -o base/build/work/scratch/<name> -q
- Read the spec and plan any overlays.
Inline vs dedicated file
- Inline — a bare upstream import with no changes stays in a shared config file:
[components.jq]
- Dedicated — anything that needs overlays, build config, or a local spec gets its
own <name>/<name>.comp.toml. Rule of thumb: more than [components.<name>] earns a
dedicated file. An includes = ["**/*.comp.toml"] glob picks it up automatically.
azldev comp add <name> [<name>...] adds bare [components.<name>] entries that inherit
the distro defaults; it writes to the root config file and does not scaffold spec or
source files. If your distro keeps components in included or dedicated files, move the
entry there afterward.
Customize
For spec source types and overlays, read the azldev-comp-toml and azldev-overlays skills. Key
points when adding a component:
- Prefer overlays over forking the spec — overlays get upstream updates for free.
Forking a spec is a last resort and a long-term maintenance commitment. Get explicit
user sign-off first, document every change, and keep the delta minimal.
- Every overlay needs a
descriptionexplaining why it is needed. - Keep
%checkenabled. Disable it only as a last resort viabuild.check.skip = true
with a required build.check.skip_reason (see the azldev-build-component skill).
Validate
The initial lock pins the upstream revision you inspected. Refresh it after the
component inputs settle, then validate:
azldev comp update -p <name> # resolve the upstream commit and write the lock
azldev comp render -p <name> # apply overlays and write the rendered spec
azldev comp diff-sources -p <name> # see exactly what the overlays change
azldev comp build -p <name> # build the RPMs
Inspect the rendered spec under specs/. A new component always needs a
smoke test — see the azldev-build-component and azldev-mock skills.
After all component inputs are final, run azldev comp update -p <name> again and
re-render. Stage the component definition and sources, locks/<name>.lock, and
the rendered output before committing. Then re-render, stage
specs/<first-char>/<name>/, and amend the commit so %changelog and
Release: reflect it. See the azldev-update-component skill for the complete
finalization workflow.
Generated by azldev docs agent; do not hand-edit. Generated for azldev version v0.1.0.
Other skills for the same job
different authors, same section of the catalogue
Mobile-first design and engineering doctrine for iOS and Android apps. Covers touch interaction, performance, platform conventions, offline behavior, and mobile-specific decision-making. Teaches principles and constraints, not fixed layouts. Use for React Native, Flutter, or native mobile apps.
Design experiments and studies BEFORE data is collected — choosing a design, randomizing, blocking, and laying out treatment combinations so results are interpretable. Use whenever someone is planning a study, asks how to assign subjects/samples to groups, mentions randomization, blocking, stratification, controls, factorial or fractional-factorial designs, design of experiments (DOE), screening many factors, response-surface optimization, crossover or repeated-measures or split-plot designs, cluster/group randomization, Latin squares, plate layouts, batch/run-order effects, replication vs. pseudoreplication, or sequential/adaptive/group-sequential designs. Trigger even for informal phrasings like "how should I set up this experiment", "how do I avoid confounding", "what's the best way to test these 6 factors", or "assign these mice to conditions". For computing the sample size or power once the design is chosen, use statistical-power; for analyzing data already collected, use statistical-analysis.
Design systems, plan implementations, review architecture decisions - Use when you need to plan a complex feature, design system architecture, or make high-level technical decisions.
Analyze and prioritize a list of feature requests by theme, strategic alignment, impact, effort, and risk. Use when reviewing customer feature requests, triaging a backlog, or making prioritization decisions.
>- Plans, configures, and manages core GKE cluster networking. Covers private clusters, VPC-native configurations, DNS, node egress, Dataplane V2, and IP planning. Use when designing GKE networking layouts, configuring private clusters, setting up Dataplane V2, planning GKE IP ranges, or managing VPC- native cluster modes. Don't use for application ingress, load balancing, or service networking (use gke-service-networking instead).
How to work in a Plain Notes project (the `plain-notes` starter pack): a flat notes/ folder plus a daily/ journal. The 'I just want to write' layout. Read when the project has these folders, OR when asked to jot a note, capture a quick thought, or write today's journal entry. Carries the linking habit and daily-entry behavior so templates and folder descriptions stay minimal. Complements the platform `open-knowledge` skill; does not replace it.
How to work in a Worldbuilding project (the `worldbuilding` starter pack): a fiction encyclopedia of characters, settings, themes, factions, and lore. Read when the project has these folders, OR when asked to add a character, setting, faction, or piece of lore, or to check the world for internal consistency. Carries the auto-stub and consistency behaviors so that guidance does not live inside template bodies or folder descriptions. Complements the platform `open-knowledge` skill; does not replace it.
Modern, clean UI/UX guidance + review skill. Use when you need actionable UX/UI recommendations, design principles, or a design review checklist for new features or existing systems (web/app). Focus on CRAP (Contrast/Repetition/Alignment/Proximity) plus task-first UX, information architecture, feedback & system status, consistency, affordances, error prevention/recovery, and cognitive load. Enforce a modern minimal style (clean, spacious, typography-led), reduce unnecessary copy, forbid emoji as icons, and recommend intuitive refined icons from a consistent icon set.
How to use it
Take microsoft/azldev-add-component from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.