Sync AGENTS.md commands from contributing docs via prek hook

[RoyLee1224]

related: #62500

Problem

AGENTS.md (468 lines) is loaded in full at session start. Anthropic's own guidance recommends keeping CLAUDE.md under 200 lines — longer files consume more context and reduce adherence. In long multi-turn sessions, agents accumulate enough context to enter the "Dumb Zone": they revert to generic Python patterns and lose Airflow-specific routing (e.g. choosing uv over breeze for a db_test-only case).

A prerequisite to addressing this (via modular skills, selective context loading) is having a single source of truth for the commands that AGENTS.md exposes. Today the Commands section is hand-maintained independently from the contributing docs — they can drift without anyone noticing.

What this PR does

Makes contributing-docs the single source of truth for the AGENTS.md Commands section (#62500).

• Adds .. AGENT-SKILL-START / .. AGENT-SKILL-END markers to three contributing docs (08_static_code_checks.rst, testing/unit_tests.rst, 05_pull_requests.rst)
• Adds a generate-agent-skills prek hook that extracts them and syncs the Commands block in AGENTS.md via insert_documentation()
• The existing prek CI job catches drift automatically
• AGENTS.md content is unchanged — the only diff is two HTML comment markers wrapping the existing commands

Future Work

With contributing-docs as the enforced source of truth, subsequent PRs can:

1. Modular skills — move commands from AGENTS.md into on-demand SKILL.md files so agents load only what's relevant to the current task, reducing context pressure
2. AGENTS.md slimdown — keep only judgment rules (architecture boundaries, coding standards) in the always-loaded file, targeting the recommended < 200 lines
3. Evaluation harness — context-pressure benchmarks measuring skill lift (with-skill vs without-skill baseline) and routing accuracy (correct breeze/uv/--project selection) over long sessions, to validate that future skill changes actually improve agent compliance

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 4.6)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[potiuk]

@RoyLee1224 A few things need addressing before review — see our Pull Request quality criteria.

• ❌ Helm tests. See docs.
• ❌ Pre-commit / static checks. See docs.
• ❌ Unit tests. See docs.

No rush.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

[jason810496]

Thanks for the hardening, we just sync in offline call and it LGTM. Thanks.

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test