diff --git a/.github/.markdownlint.yaml b/.github/.markdownlint.yaml
new file mode 100644
index 00000000..e4996298
--- /dev/null
+++ b/.github/.markdownlint.yaml
@@ -0,0 +1,3 @@
+# PR/issue templates do not start with a top-level heading
+extends: ../.markdownlint.yaml
+MD041: false
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
new file mode 100644
index 00000000..df02da58
--- /dev/null
+++ b/.github/pull_request_template.md
@@ -0,0 +1,45 @@
+<!--
+提交前请先阅读贡献指南 / Please read the contributing guide first:
+https://github.com/MaaAssistantArknights/maa-cli/blob/main/CONTRIBUTING.md
+如果是较小的改动，填写「动机」一节即可，其余部分可以按需删除。
+For small changes, filling in the Motivation section is enough; feel free to remove the rest.
+-->
+
+## 动机 / Motivation
+
+<!--
+为什么要改，解决什么问题。有相关 issue 请写 `Closes #123`。新功能、新命令、新配置请先开 issue 讨论。
+Why is this change needed? What problem does it solve? Link the issue if there is one, e.g. `Closes #123`. Discuss new features, commands and config options in an issue first.
+-->
+
+## 方案 / Solution
+
+<!--
+怎么解决的。重点写从 diff 里看不出来的设计取舍，以及哪里你不确定。
+How does this PR solve it? Focus on design choices that are not obvious from the diff, and on what you are unsure about.
+-->
+
+## 变更与影响 / Changes and impact
+
+<!--
+用户能感受到什么变化：命令行行为、配置格式、平台支持等。breaking change 请明确写出。纯内部改动写“无”。
+涉及设备连接或平台相关的改动，请说明在哪些平台或设备上实际测试过。
+What will users notice: CLI behavior, config format, platform support? Call out breaking changes explicitly. Write "None" for internal-only changes.
+For changes involving device connections or platform-specific behavior, say which platforms or devices you tested on.
+-->
+
+## 检查项 / Checklist
+
+- [ ] 本 PR 只包含实现上述目的所需的改动，无关的修复或重构已拆出 / This PR only contains changes needed for the purpose above; unrelated fixes and refactors are split out
+- [ ] 改了用户可见行为的话，已同步更新 `crates/maa-cli/docs/` 下所有语言的文档 / User-visible behavior changed: docs under `crates/maa-cli/docs/` are updated for every language
+
+## AI 辅助 / AI assistance
+
+<!--
+勾选其中一项。使用了 AI 时，请写明哪些部分由 AI 编写，如全部代码、只有测试、只有文档；也可以注明工具和模型。
+Check one. If AI was used, say which parts it wrote, e.g. all code, tests only, docs only; naming the tool and model is optional.
+-->
+
+- [ ] 未使用 AI / No AI used
+- [ ] 使用了 AI，我已亲自审阅并整理全部改动，能解释每一处修改 / AI was used, and I have personally reviewed and cleaned up all changes and can explain each of them
+  - AI 编写的部分 / AI-written parts:
diff --git a/AGENTS.md b/AGENTS.md
index ac9cd339..65df2337 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -129,6 +129,18 @@ graph TD
 - One paragraph per line; use `<br>` for line breaks only when needed; no trailing spaces.
 - Markdown is linted by `markdownlint-cli2`.
 
+## Contributing on Behalf of a Human (Follow This)
+
+If you are an agent helping someone prepare a PR, follow [CONTRIBUTING.md](CONTRIBUTING.md). In particular:
+
+- **Check for an agreed design first.** For a new feature, command, config option, config format change, or anything likely to exceed about 500 lines, confirm there is an issue where a maintainer agreed on the approach. If there is none, stop and tell your human to open one instead of implementing.
+- **Stay in scope.** Implement only what the task needs. Do not add unrequested flags, subcommands, options or refactors. Report unrelated problems to your human instead of fixing them in the same PR.
+- **Keep the diff lean.** No explanatory comment blocks, no speculative defensive code, no design notes or conversation summaries committed to the repo.
+- **Follow existing patterns.** Look for how the codebase already solves a problem (tests included) before inventing a new mechanism.
+- **Your human reviews before anything is published.** Do not open or push a PR until your human has read the whole diff. Never tick the self-review checkbox in the PR template for them.
+- **Write the PR description from the template.** Keep it short, fill in the AI assistance section honestly, and do not paste long generated summaries.
+- **Do not ghost-write review replies.** Help your human understand review feedback; the reply on GitHub should be in their own words.
+
 ## MISC
 
 - Use conventional commits: `feat: ...`, `fix: ...`, `refactor: ...`, `perf: ...`, `docs: ...`, `test: ...`, etc.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 00000000..b1ec87e1
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,47 @@
+# 贡献指南 / Contributing
+
+[中文](#中文) | [English](#english)
+
+## 中文
+
+感谢你对 maa-cli 的关注。我们欢迎任何形式的贡献，包括 bug 报告、功能建议、文档改进和代码。开发环境、代码规范和提交流程见 [开发文档](DEVELOPMENT.md)，本文说明提交 PR 时需要注意的事项，无论是否使用 AI 工具均适用。
+
+本项目维护者人手有限，review 往往是合并的瓶颈。以下约定的目的是让改动能够更快地被审阅和合并。
+
+### 提交 PR 前
+
+1. **先在 issue 中讨论方案。** 新功能、新命令、新配置项、配置格式的变更，以及预计超过约 500 行的改动，请先开 issue 与维护者确认方案，再开始实现，以免方向不一致导致返工。bug 修复、文档和小幅改进可以直接提交 PR。开始之前，请先搜索是否已有相同主题的 issue 或 PR。
+2. **每个 PR 只解决一个问题。** 开发过程中发现的其他问题或希望进行的重构，请另开 PR。范围集中的 PR 更容易审阅，也能更快合并。
+3. **欢迎使用 AI 工具，但改动需要经过作者本人审阅。** 提交前请完整阅读所有改动，确认每一处都是必要的，并能说明修改的理由。AI 生成的代码常包含未被要求的功能、冗长的注释或不必要的防御性代码，请在提交前删除。使用 agent 开发时，请让它先阅读 [AGENTS.md](AGENTS.md)。
+4. **PR 描述应简洁。** 请按照 PR 模板说明修改的原因和实现方式，如有不确定之处也请注明。不需要附上工具生成的长篇摘要。
+5. **请用自己的语言回复 review。** 直接转贴 AI 的输出，会让维护者难以判断你是否认同修改意见，以及有哪些疑问。
+
+### 不符合约定的 PR
+
+维护者会在 PR 中说明原因，并视情况处理：
+
+- 需要先讨论方案的：请先开 issue，PR 可能会暂时关闭，方案确定后可以重新提交。
+- 改动过大或包含无关内容的：请拆分为多个 PR。
+- 明显未经作者本人审阅的 AI 生成 PR：可能会直接关闭，不进行逐行 review。
+- review 后 30 天内没有回应的：可能会关闭，之后可以随时重新打开。
+
+## English
+
+Thank you for your interest in maa-cli. Contributions of all kinds are welcome, including bug reports, feature suggestions, documentation improvements and code. See [DEVELOPMENT.md](DEVELOPMENT.md) for the development setup, code conventions and workflow. This document describes what we expect from a PR, whether or not AI tools were used. The project has few maintainers and review is often the bottleneck; these conventions help changes get reviewed and merged sooner.
+
+### Before submitting a PR
+
+1. **Discuss the design in an issue first.** For a new feature, command, config option, config format change, or a change expected to exceed roughly 500 lines, open an issue and agree on the approach with a maintainer before implementing it, to avoid rework. Bug fixes, docs and small improvements can be submitted as a PR directly. Search for existing issues and PRs on the same topic before starting.
+2. **One PR, one purpose.** Submit other problems you find or refactors you want to make as separate PRs. Focused PRs are easier to review and merge.
+3. **AI tools are welcome, but changes must be reviewed by the author.** Before submitting, read every change, make sure each one is necessary, and be able to explain it. AI-generated code often includes features nobody asked for, verbose comments and unnecessary defensive code; remove them before submitting. If you use an agent, have it read [AGENTS.md](AGENTS.md) first.
+4. **Keep the description concise.** Follow the PR template: why, how, and anything you are unsure about. Do not include long tool-generated summaries.
+5. **Reply to reviews in your own words.** Pasted AI output makes it hard for maintainers to tell whether you agree with the feedback and what questions you have.
+
+### PRs that do not follow these conventions
+
+Maintainers will explain why in the PR and, depending on the case:
+
+- Needs design discussion first: you will be asked to open an issue; the PR may be closed for now and can be resubmitted once the design is agreed.
+- Too large or contains unrelated changes: you will be asked to split it into several PRs.
+- AI-generated PRs clearly not reviewed by their author: may be closed without a line-by-line review.
+- No response within 30 days after a review: may be closed; it can be reopened at any time.
diff --git a/DEVELOPMENT.md b/DEVELOPMENT.md
index c879502d..fd12d83d 100644
--- a/DEVELOPMENT.md
+++ b/DEVELOPMENT.md
@@ -24,7 +24,8 @@
 
 - 避免直接向主分支提交代码，始终通过 PR 进行贡献。
 - 提交 PR 前，确保自己的分支已经与主分支同步，避免合并冲突。
-- 对于较大或影响范围广的变更，建议先在 Issue 中充分讨论方案。
+- 新功能、新命令、新配置项或影响范围广的变更，请先在 Issue 中讨论方案。
+- PR 的范围和使用 AI 工具的要求见 [贡献指南](CONTRIBUTING.md)。
 - 如对现有代码有任何疑问，可以在 Issue 中提出，以获得帮助和反馈。
 - 欢迎任何形式的贡献，包括文档、测试、CI 配置等。