code-review-action AGENTS.md

AGENTS.md

Generated by Agent Sync Action. Do not edit this file directly.

The canonical project rules live in .agents/rules/.

GitHub Rules

Workflows

• Keep run steps declarative. Invoke checked-in scripts for control flow, validation, filesystem changes, or other implementation logic instead of embedding arbitrary shell or program code in workflow YAML; place those scripts under .github/scripts/ and prefer Python.
• Do not hard-code runtime versions when a shared action, reusable workflow, or repository version file supplies them; omit python-version when shared Python automation provides it, and use node-version-file: ".nvmrc" for Node.js workflows.
• Do not add glue steps that only read versions or forward setup data. Pass repository-owned version files and inputs directly to the action that uses them whenever supported.
• Keep workflow files concise: merge related setup and dependency commands into one clearly named generic step when their execution order and conditions allow it. Do not split tool or package installation into separate steps merely by dependency.
• Environment configuration that tunes a tool — retry counts, timeouts, cache locations, path entries — belongs in the step that installs or runs that tool, not in a step of its own. A step whose whole body writes to $GITHUB_ENV is named for a concern rather than an action, and the reader has to look elsewhere to find out which later step it affects. Write those exports at the end of the owning step so the setting and its consumer stay together.
• Add an explanatory comment when an edge case requires an explicit version override.
• Use version-tagged GitHub Actions such as actions/checkout@v4 and actions/setup-python@v5, not full commit SHAs.

Branches and Pull Requests

• Keep pull requests focused and give them descriptive titles and descriptions; request appropriate reviewers when the repository workflow requires them.
• A pull request description covers the changes in that pull request and nothing else. Leave out alternatives considered and rejected, work deferred to a later change, and the reasoning behind not doing something.
• Repositories are independent. A pull request in one repository does not describe, reference, or explain changes made in another.
• When additional work arrives on a non-default branch, retain that branch and add the work to its pull request even when the task could be reviewed independently.
• Query the current branch's pull request before creating one. Reuse it while it is open, or create one from the current branch when none exists.
• Create a separate branch only when the user asks or the current branch's pull request is already merged; start post-merge work from the default branch.