Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions .agents/rules/docs.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,12 @@ globs: docs/*.md
* Act as an expert in tech writing, Sphinx, MyST, and markdown.
* Wrap lines at 80 columns.
* Use hyphens (`-`) in file names instead of underscores (`_`).
* **How-to Guides (`docs/howto/`)**:
* Prefer adding sections to an existing topical guide (e.g.
`docs/howto/build-a-wheel.md`) over creating a separate granular file.
* Write from the user's task perspective (e.g. "How do I generate the right
wheel filename for the active Python version?") rather than internal rule
or provider jargon, and omit low-level implementation parentheticals.
* In Sphinx MyST markup, outer directives must have more colons than inner directives.
* When adding `{versionadded}` or `{versionchanged}` sections, add them at the end of the documentation text.
* For unreleased features or attributes, use `VERSION_NEXT_FEATURE` in
Expand Down
2 changes: 2 additions & 0 deletions .agents/rules/news.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,8 @@ Before drafting any news entry, adhere strictly to the rules in
## Brevity and Content
* Write a short snippet (1-2 concise sentences) so the combined `CHANGELOG.md`
is easy to skim and grok.
* Summarize the capability rather than listing every new variable, attribute, or
field name (leave exhaustive lists to the API reference docs).
* State high-level, user-visible behavior and outcomes (what now works, what
changed).
* Omit internal implementation details, refactoring mechanics, and exhaustive
Expand Down
6 changes: 6 additions & 0 deletions .agents/rules/starlark.md
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,12 @@ globs: "*.bzl,BUILD,BUILD.bazel,*.bazel"
not use mutable `list[T]`.

## Code Style & Conventions
* **Direct Attribute Access**: Use normal attribute access (`x.field`) instead
of `getattr(x, "field", default)` for fields defined on a provider or struct
schema. When an object may be one of multiple provider/struct variants with
different field sets, guard once with `if hasattr(x, "field"):` (with a
comment explaining why the field may be absent) and use normal attribute
access inside the block.
* **Dict union (`|`)**: Use `|` instead of `dicts.add(...)` from
`@bazel_skylib//lib:dicts.bzl` when merging dictionaries.
* **Type Checks (`@bazel_skylib//lib:types.bzl`)**: Prefer `types.is_*` helpers
Expand Down
5 changes: 3 additions & 2 deletions .agents/skills/review-code/review-news-prompt.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,8 +23,9 @@ Your sole task is to audit `news/` fragment files and user-visible changes in
- Verify each news entry is a short snippet (1-2 concise sentences) that is
easy to skim and grok when combined into `CHANGELOG.md`.
- Flag overly long, verbose entries or entries that explain internal
implementation details, background rationale, or exhaustive edge cases
(provide a shortened rewrite in your report).
implementation details, background rationale, exhaustive lists of symbol
names, or exhaustive edge cases (provide a shortened rewrite in your
report).
5. **Formatting & Cross-References**:
- Verify no leading bullet points (`*` or `-`).
- Verify subsystem prefix in parentheses when applicable (e.g., `(pypi)`,
Expand Down
Loading