Platform to programmatically author, schedule and monitor workflows.
On this page
Overview
Airflow's file ranges from repository structure and commands to writing and contribution policy. It defines one domain term, classifies security reports, explains newsfragments, fixes remote names, and limits commit trailers.
The term uses title case in prose. Literal code tokens keep their original spelling, including inside fenced blocks, and anti-pattern quotes may show the wrong form when teaching the rule.
Source excerpt starting at line 8.
8Write **Dag** (title case) in all prose. Keep the all-caps or lowercase9spelling only when reproducing a literal code token — never rewrite these,10even inside fenced code blocks:
02
How to classify a security finding
The guide separates security findings into vulnerabilities, known limitations, and deployment hardening. It links the security model, including the chapter that defines what is not a vulnerability.
03 / Contribution etiquette
Open the pull request, not the issue
Known fixes go straight to a pull request to avoid duplicate work. Deferred fixes still need an issue that outlives the workaround.
Source excerpt starting at line 368.
368- Open issues attract drive-by submissions, often from other agents, that369 haven't seen the in-flight work. That produces duplicate fixes, low-quality
04
Deferred work linked from the code
Create a tracking issue before finalizing a workaround, version cap, or partial fix. Cite its number in the pull request and place the full URL beside the code.
05 / Hard prohibitions
No agent co-author trailer
Agents may not add themselves as co-authors. A separate pull-request field records the agent's name and version.
Source excerpt starting at line 210.
210- NEVER add Co-Authored-By with yourself as co-author of the commit. Agents cannot be authors, humans can be, Agents are assistants.
06
Remote names checked rather than assumed
Before remote commands, run git remote -v. If the two expected names differ, report the mismatch and propose the exact rename commands.
07
A coverage target with an upper bound
Tests are to cover exactly what the PR changes: every changed behavior gets a test, every test must fail without the change, and tests for pre-existing logic or third-party functions are excluded.
Source excerpt starting at line 152.
152- Target exactly 100% coverage of what the PR changes — no more, no less. Every changed or added behaviour must have a test; every test must fail without the PR's change. Do not add tests for pre-existing logic that was already present before the PR, and do not test standard-library or third-party functions. The exception is deliberate behaviour or integration tests, which may cross those boundaries by design.
Ideas for your repo
01If your project has a term people spell three ways, fix the spelling and enumerate the exceptions.
02Tell agents how to classify a security finding, including which categories not to report.
03State whether an agent may add itself as a commit co-author.
04Before any remote command, have the agent verify remote names rather than assume them.
05"Every test must fail without the change" is a sharper instruction than a coverage percentage.
Sponsored by
Give your agents the whole story.
These instructions explain how to work in Airflow. Modem shows your agents what customers said, who is affected, and what changed.