Skip to content

AGENTS.md

Latest commit

 

History

History
35 lines (31 loc) · 4.68 KB

AGENTS.md

File metadata and controls

35 lines (31 loc) · 4.68 KB

AGENTS.md

Project Skills

  • update-std-tests: project-local skill at .claude/skills/update-std-tests/SKILL.md
  • Use update-std-tests when the user wants to audit or update scripts/test/std_crates.csv, compare workspace packages against the std test whitelist, or confirm which new std-test candidates should be added.
  • starry-test-suit: project-local skill at .claude/skills/starry-test-suit/SKILL.md
  • Use starry-test-suit when the user wants to add, regroup, adapt, or validate test-suit/starryos cases, including qemu-*.toml, normal/stress grouping, success/fail regexes, or Starry test-suit related CI behavior.
  • cross-kernel-driver: project-local skill at .claude/skills/cross-kernel-driver/SKILL.md
  • Use cross-kernel-driver when the user wants to create, refactor, review, or optimize portable Rust driver crates under drivers/ by device type, separate Driver Core / Capability Boundary / OS Glue / Runtime layers, handle MMIO/iomap with mmio-api, handle DMA with dma-api, design IRQ event or queue contracts, or audit OS API coupling in driver code.
  • review-open-prs: project-local skill at .claude/skills/review-open-prs/SKILL.md
  • Use review-open-prs when the user wants to audit all open GitHub PRs, review non-self PRs, re-review PRs updated after their last review, use subagents/worktrees for PR review, compare changes with POSIX/Linux/RFC/VirtIO semantics, run local validation, and submit approve or request-changes reviews.
  • review-single-pr: project-local skill at .claude/skills/review-single-pr/SKILL.md
  • Use review-single-pr when the user names one PR number or URL and wants a focused review, re-review, Linux/POSIX/RFC/VirtIO comparison, local validation, Chinese inline review comments, approval, or request-changes submission.
  • board-uboot-fsck-repair: project-local skill at .claude/skills/board-uboot-fsck-repair/SKILL.md
  • Use board-uboot-fsck-repair when a physical board Linux rootfs needs ext4 recovery through U-Boot, initramfs fsck reports unrepaired corruption, OrangePi-5-Plus needs extraboardargs=fsckfix, or Starry board write tests must be bracketed by Linux fsck/boot checks.
  • crates-io-owner: project-local skill at .claude/skills/crates-io-owner/SKILL.md
  • Use crates-io-owner when the user wants to add or verify github:rcore-os:crates-io for branch-added crates, asks which new crates still need the crates.io team owner, or explicitly wants cargo owner used instead of Cargo.toml metadata.

Other Requirements

  • When changing logic, run a relevant cargo clippy check after the code change.
  • After modifying a crate, ensure that crate passes clippy. Prefer cargo xtask clippy --package <crate> for targeted verification, and if the crate now passes but is missing from scripts/test/clippy_crates.csv, add it in the same change.
  • Do not silence clippy warnings with allow as a shortcut; prefer fixing the root cause unless the user explicitly asks otherwise.
  • Run cargo fmt after code edits.
  • For ArceOS, StarryOS, and Axvisor builds/tests/runs, prefer the cargo xtask command family instead of raw cargo build, cargo test, or cargo run.
  • If cargo xtask cannot satisfy a special configuration, inspect the xtask flow first and only then fall back to native Cargo commands with manually matched arguments.
  • For PRs, issues, review replies, discussions, and similar project-facing submissions, keep the language neutral and project-focused.
  • For PR titles, follow type(scope): content in Conventional Commits style. Prefer the main affected crate name as scope when one crate clearly dominates the change; for cross-cutting or infrastructure work, broader scopes such as ci, repo, or docs are acceptable.
  • PR title examples: feat(axbuild): add Starry remote board test flow, fix(starry-process): correct tty session cleanup, chore(ci): split Starry self-hosted board matrix.
  • When submitting a PR, write the title in English and the body in Chinese.
  • PR descriptions must clearly cover: the problem being solved, what was changed to solve it, and the logic behind each step of the solution.
  • Before submitting a PR, locally validate the CI flow as much as practical, excluding only physical board tests and self-hosted test flows unless the user explicitly asks to run them. Changes unrelated to building or testing, such as documentation-only updates, do not require local CI validation.
  • After adding or changing commits on a PR branch, update the PR description so it stays synchronized with the committed changes.
  • Do not insert agent-related labels, signatures, branding, or other advertisement-style wording such as codex, agent, AI, or similar self-promotional tags unless the user explicitly requests it.