看到了Baochun对这个不错的建议的想法，稍微修改了一下增加在我的AGENTS.md后面，感觉能比我以往手动要求触发subagent更好。
## Additional Agent Operating Rules
### Documentation
* When using third-party libraries or APIs, verify unfamiliar or version-sensitive behavior against the official documentation before implementing.
* Prefer official documentation for the version used by this project.
### Planning
* All non-trivial plans MUST include a dependency graph.
* Every task in a plan must declare `depends_on: []` using explicit task IDs such as `T1`, `T2`.
### Execution
* Complete all tasks from a plan without stopping for permission between steps. Use best judgment, keep moving.
* Only stop to ask when a step is destructive/irreversible or there is a genuine blocker.
### Subagents
* Spawn subagents automatically when:
* Parallelizable work (e.g., install + verify, npm test + typecheck, unblocked tasks from plan)
* Long-running or blocking tasks where a worker can run independently.
* Isolation for risky changes or checks
* Code review would be helpful
* Do not spawn a subagent when delegation and coordination overhead is likely to exceed the work itself.
* If you're launching subagents for parallelization, add this robust context to your prompt:
* **Context**: Share plan file location and info if available
* **Dependencies**: What work/files are completed? Any dependencies?
* **Related tasks**: Any adjacent tasks, files, or agents?
* **Exact task**: Description, file paths/names, acceptance criteria
* **Validation**: How to validate work if possible.
* **Constraints**: Risks, gotchas, things to avoid
* **Be thorough**: Provide ANY/ALL context that will aid success.
* ALWAYS wait for all blocking subagents to complete before yielding.
### Bugs
* Add a regression test when it is appropriate for bug-related changes.
* Never claim tests or validation passed unless they were actually run successfully.
想着顺便完善一下其他的规则，比如commit的规则，以及提交PR的规则。
commit的规则打算就用OpenAI symphony的这个skill，做了一下中文的适配：
---
name: commit
description:
Create a well-formed git commit from current changes using session history for
rationale and summary; use when asked to commit, prepare a commit message, or
finalize staged work.
---
# Commit
## Goals
- Produce a commit that reflects the actual code changes and the session
context.
- Follow common git conventions (type prefix, short subject, wrapped body).
- Include both summary and rationale in the body.
- Write commit messages in Chinese by default. Keep conventional commit types,
optional scopes, code identifiers, file names, commands, API names, and other
technical terms in their original form.
## Inputs
- Codex session history for intent and rationale.
- `git status`, `git diff`, and `git diff --staged` for actual changes.
- Repo-specific commit conventions if documented.
## Steps
1. Read session history to identify scope, intent, and rationale.
2. Inspect the working tree and staged changes (`git status`, `git diff`,
`git diff --staged`).
3. Stage intended changes, including new files (`git add -A`) after confirming
scope.
4. Sanity-check newly added files; if anything looks random or likely ignored
(build artifacts, logs, temp files), flag it to the user before committing.
5. If staging is incomplete or includes unrelated files, fix the index or ask
for confirmation.
6. Choose a conventional type and optional scope that match the change (e.g.,
`feat(scope): ...`, `fix(scope): ...`, `refactor(scope): ...`).
7. Write a concise Chinese subject line, <= 72 characters, with no trailing
punctuation.
8. Write a body that includes:
- Summary of key changes (what changed).
- Rationale and trade-offs (why it changed).
- Tests or validation run (or explicit note if not run).
9. Append a `Co-authored-by` trailer for Codex using `Codex <codex@openai.com>`
unless the user explicitly requests a different identity.
10. Wrap body lines at 72 characters.
11. Create the commit message with a here-doc or temp file and use
`git commit -F <file>` so newlines are literal (avoid `-m` with `\n`).
12. Commit only when the message matches the staged changes: if the staged diff
includes unrelated files or the message describes work that isn't staged,
fix the index or revise the message before committing.
## Output
- A single commit created with `git commit` whose message reflects the staged changes.
## Template
Type and scope are examples only; adjust to fit the repo and changes.
```
<type>(<scope>): <简短摘要>
摘要:
- <改了什么>
- <改了什么>
原因:
- <为什么>
- <为什么>
测试:
- <命令或“未运行（原因）”>
Co-authored-by: Codex <codex@openai.com>
```PR的规则借鉴了symphony push skill。我觉得使用AGENTS.md+.github/pull_request_template.md就足够了，类似于这样：
AGENTS.md
│
├── Commit
│ └── 使用 commit skill
│ └── Conventional Commit + 中文
│
└── Pull Requests
├── Title
│ └── Conventional Commit + 中文
│
├── Body
│ └── .github/pull_request_template.md
│
└── Scope
└── 描述整个 branch 的最终变化加入了这个到AGENTS.md:
## Pull Requests
- Follow `.github/pull_request_template.md` for the pull request body.
- Describe the full current scope of the branch, not only the latest commit.
- Write pull request titles and descriptions in Chinese by default.
- Preserve code identifiers, file names, commands, API names, library names, and other technical terms in their original form.
- When an existing pull request changes materially, update its title and body so they still reflect the full current scope.
### Pull Request Titles
- Follow the Conventional Commits format: `<type>(<scope>): <summary>`.
- Keep the type and optional scope in English.
- Write the summary in Chinese by default.
- Choose the type based on the primary outcome of the pull request.
- Keep the title concise and under 72 characters.
- Do not end the title with punctuation