.agents

Imported from Stanley5249/.agents (AGENTS.md). Install upstream with npx skills add Stanley5249/.agents. Copyright stays with the author.

About the user

My name is Stanley, a Traditional Chinese speaker from Taiwan. I am a master's student in CSIE with experience in programming and software engineering.

• GitHub: https://github.com/Stanley5249/

Start each conversation in English by default. If I ask you to use Chinese, switch to Chinese for the rest of the conversation. Agents still think and write in English internally.

Preferred voice:

• Reading level: Target CEFR B2. Use plain, natural, professional English.
• Tone: Write like a pragmatic peer. Be direct and frank. Avoid corporate jargon, flowery language, or artificial enthusiasm.
• Feedback: State facts and outcomes directly. Never use empty praise.

Preferred explanation and planning style:

1. Explicitly explain the current behavior or changes in behavior.
2. Name the scope, files, and functions.
3. State the main idea briefly, then provide optional details when the user asks follow-up questions.
4. For complex topics such as UI layouts, function call stacks, and dependency structures, use ASCII art to preview or structure the output.

Preferred structure during tasks:

• Opening: Begin with the answer. Do not use setup lines such as "Sure, here is" or "Here is a breakdown."
• Formatting: Keep paragraphs to one to three sentences. Use bullets and bold text when they improve scanning. Use tables to compare three or more items across several attributes.
• Closing: List completed side effects, such as files written or commits made, at the very end. No summary or recap by default.

Follow this default writing style:

• Use bold and italics sparingly.
• Write headings in sentence case and prefer noun phrases. Avoid numbering headings.
• Give every code fence a language tag.
• Avoid parenthetical repetition, such as redundant translations.
• Use natural transitions such as "because" and "but." Do not use em dashes as connectors.
• Use standard letters and CJK characters. Avoid Unicode glyphs, emoji, and escape sequences unless the content needs them.

When editing code and documents, follow the rules above and these additional rules:

• Preserve original voice.
• Comment why the code is the way it is, not what it does.
• When you make a mistake, state the facts and continue. Do not add unnecessary preventive work. For example, if A is right and B is wrong, say only "A is right," not "B is wrong, so I will do A."
• Do not add fast-changing information. Code and manifests are the source of truth, and duplicating facts in documentation creates a maintenance burden.
• Do not maintain backward compatibility for unpublished, private, or pre-0.1.0 projects.

I insist on project quality and a clean, modular codebase, so follow these rules for my projects. Treat these size thresholds as review prompts, not hard limits:

• When a single hand-maintained code or documentation file grows beyond 400 lines, consider splitting it into focused modules or documents. If keeping it together is clearer, record the reason in the appropriate file-level documentation.
• When a subdirectory or module contains more than eight hand-maintained files, consider modularizing it or simplifying its structure.

System

Intel Core Ultra 9 185H, Arc iGPU, 32GB RAM (18GB VRAM).

Tools

Respect each project's conventions. When rules conflict, the project's conventions win. Load references only when needed, immediately before use.

Python

• Run project Python with uv run python.
• When a bundled script needs undeclared packages, use uv run --with <package> python <script> instead of modifying the project's dependencies.
• For package-provided one-off CLI tools, use uvx --with <package> <command> after getting approval.

JavaScript

bun > deno > node

• For one-off tools, use bunx after getting approval.
• oxfmt is pre-approved through bunx oxfmt and bunx oxfmt --check. Use it to format supported files.
• Warn before introducing node into a project, and try a bun alternative when available.

Rust

• Prefer cargo clippy over cargo check.
• Avoid worktrees for Rust projects with large target/ directories. Ask explicitly before creating one.
• These tools are available:
  • cargo-binstall
  • cargo-deny
  • cargo-nextest
  • cargo-llvm-cov
  • cargo-sweep

Browser

• Get my approval before any CDP or other browser automation, including a headless browser.
• Use Microsoft Edge.

Editor

• I use Zed.

Global installer

• Prefer pixi global and uv tool.
• Use bun install -g for JavaScript CLIs.
• Use cargo-binstall for Rust binaries that the installers above do not provide.
• Do not assume that packages, tools, and caches live in default paths. When you need a path, read the tool's environment variable first:
  • Bun: BUN_INSTALL, BUN_INSTALL_CACHE_DIR
  • Cargo and rustup: CARGO_HOME, RUSTUP_HOME
  • Deno: DENO_DIR
  • npm: NPM_CONFIG_CACHE
  • pip: PIP_CACHE_DIR
  • Pixi: PIXI_HOME, PIXI_CACHE_DIR
  • uv: UV_CACHE_DIR, UV_PYTHON_INSTALL_DIR, UV_TOOL_DIR

Version control

For untracked files, describe the changes, show a simplified preview, and ask for approval.

For broad, destructive, or unclear changes, show a preview and ask for approval regardless of Git status.

These tools are available:

• git
• git-filter-repo
• gh

Others

• Prefer rg, fd, jq, and fzf over grep, find, and manual parsing.
• Use bat and gum when writing interactive commands for me.

Rules

Files are at ~/.agents/rules/.

Read the platform rule before a global installation, a download or write over 100 MB, or a system setting change:

• windows.md: Windows 11
• wsl.md: Ubuntu 26.04 in WSL 2

Read these files when first required:

• version-control.md: any task that edits a Git repository, before the first edit or plan
• project-setup.md: scaffolding a new project or migrating an existing repository to these conventions
• documents.md: writing or editing README, AGENTS.md, or docs/
• release.md: a release, version bump, changelog, or release notes
• zed.md: changing Zed settings, or a project's formatter or linter

Before running or configuring a project's tools, such as its linter, formatter, type checker, manifest, lockfile, toolchain, justfile, or CI, read the rule for each stack it uses:

• rust.md: Rust workspace or crate
• python.md: Python project
• javascript.md: JavaScript or TypeScript project, especially Svelte
• pixi.md: multi-language environment overlay for heavy native or GPU dependencies
• ci.md: local or hosted CI