skill-sync AGENTS.md

AGENTS.md

General Development Rules

1. Prefer existing repository patterns. Use this document when the codebase has no stricter rule.
2. Preserve existing comments. If you need to add comments, write them in Chinese.
3. Keep changes focused. Do not perform broad unrelated refactors.
4. Use rg / rg --files first when searching.
5. Use apply_patch for manual file edits.

AI Collaboration Rules

• Prefer implementing the user's current request directly. Ask only when missing information makes a safe assumption risky.
• Do not delete user code, comments, or uncommitted changes. If unrelated changes exist, leave them alone.
• If the user explicitly says not to write tests, do not add tests. Otherwise choose the smallest verification that matches the risk.
• After UI, layout, color, or copy changes, run the matching lint command. Before committing, run npm run lint and npm run build.
• Do not add empty abstractions, thin components, thin helpers, or functions that only forward runes state reads or setters.
• Report changed files and verification commands. Do not claim unverified success.

Git Commit Rules

• Commit messages must follow Conventional Commits, for example feat: add user filter, fix: handle empty response, or docs: update usage notes.
• Allowed types are build, chore, ci, docs, feat, fix, refactor, revert, and test.
• Commit subjects must not use Start Case, PascalCase, or all caps.
• The project uses a husky commit-msg hook that runs commitlint.
• The project uses a husky pre-commit hook that runs npm run precommit before each commit.
• npm run precommit runs lint-staged and checks only staged files.
• lint-staged formats staged files with prettier --ignore-unknown --write, and runs staged source lint checks for matching src files; do not hand-format around the configured Prettier rules.

Anti-Thin-Wrapper Rule

• Do not create wrappers that only forward simple runes state reads or setter calls.
• Add a wrapper only when it contains real semantics such as business rules, defaults, validation, unit conversion, error handling, telemetry, cross-state coordination, or stable reuse from 3+ call sites.
• If a function only does return state.xxx or state.setXxx(value), inline the state access at the use site.
• When reading state only to apply a fallback, prefer keeping the fallback explicit at the use site, for example const value = stateValue ?? 0.
• Before adding any helper, confirm that it adds meaning rather than just another name.