Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/apache/airflow/prepare-providers-documentationnpx skills add apache/airflow --skill prepare-providers-documentationgit clone --depth 1 https://github.com/apache/airflowWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00113 | $0.13830 |
| Opus 5 | $0.00056 | $0.06915 |
| Sonnet 5 | $0.00023 | $0.02766 |
| Haiku 4.5 | $0.00011 | $0.01383 |
Grade A, and why
prepare-providers-documentation scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 1,130 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Prepare Providers Documentation (AI-driven)
This skill replaces the manual commit-by-commit classification step that the
release manager normally performs when running
breeze release-management prepare-provider-documentation. Instead of asking
the release manager to type d/b/f/x/m/s/v for each commit, the
skill drives the classification itself — inspecting every PR (with extra care
for potentially breaking changes), scoping multi-provider PRs to the slice
that touched the current provider, and asking the release manager only when
genuinely uncertain.
The skill keeps the existing breeze tooling as the source of truth for
template generation. Claude only owns the classification + version bump +
changelog entries; everything else (__init__.py, README.rst,
pyproject.toml, conf.py, get_provider_info.py, index.rst) is still
regenerated by breeze release-management prepare-provider-documentation --reapply-templates-only.
[!IMPORTANT] This is a release-manager workflow. It mutates
provider.yamlandchangelog.rstfor many providers in one pass. Always run on a clean working tree (or in a dedicated branch) and let the release manager review the diff before committing.
When to Use This Skill
Use during the regular provider release cycle, in place of either of:
breeze release-management prepare-provider-documentation
breeze release-management prepare-provider-documentation --incremental-update
…when the release manager wants Claude to classify the changes instead of doing it by hand. The skill covers the same scope: classifying changes, bumping versions, generating changelog sections, reapplying templates, and folding new commits into an already-prepared release PR (incremental update).
Two entry points:
- Initial run — classify everything from scratch for a new release. Follow Phases 1–5 below.
- Incremental update — extend an existing release PR with commits that
landed on
mainsince the changelog was first generated (typical when rebasing a release PR before merging). Skip ahead to the Incremental Update section after Phase 5.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 1,130 lines · 113 tokens per session scan A 85f96e0699a4
prepare-providers-documentation is a skill published in the GitHub repository apache/airflow (46,687 stars, last pushed today), licensed Apache-2.0. It adds 113 tokens to every session and 13,830 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
airflow-workflow
Execution guide for Airflow scheduled jobs — troubleshooting, updating, connid conventions, and cron references.
hex-release
Guides interactive Hex package release for AgentJido repos. Supports automated (GitHub Actions workflowdispatch) and manual release flows. Uses gitops for version bumping and changelog generation. Triggers on: release, hex publish, bump version, new release, publish package.
share-a-library
Use when a managed library is ready to publish to GitHub and hand to teammates as an install command. Run the GitHub publishing steps, then return the exact shareable install command.
git-workflow
Git operations: commits, branches, PRs, and conflict resolution.
magpie-release-prepare
Draft release preparation artefacts for : the planning issue, the version-bump and changelog prep PR, or the post-release development-version bump PR. Reads release metadata from /release-trains.md and /release-management-config.md. Every output is a draft confirmed by the Release Manager before filing; the agent…
magpie-release-announce-draft
Draft the [ANNOUNCE] email body and open (not merge) the site-bump PR for a promoted release of . Reads release metadata from the planning issue and /release-management-config.md; produces a ready-to-copy [ANNOUNCE] subject + body and proposes the site-bump PR. Never sends mail and never merges the PR without explicit…