From bfeb4b26e4eb28b435bd6ca748ab9ef7aea32b27 Mon Sep 17 00:00:00 2001 From: Huxley Date: Sun, 5 Jul 2026 15:34:22 +0800 Subject: [PATCH] docs(AGENTS.md): clarify and tighten Git workflow instructions --- AGENTS.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 1bd3557..8561963 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -37,11 +37,11 @@ ## Git Version Control -- Do not create a commit unless the user explicitly asks for one. -- Before any commit, verify the work with the required project checks. For code changes, run `go vet ./... && go test ./...`; for docs-only changes, run the most relevant non-mutating checks available. +- DON'T create a commit unless the user explicitly asks for one. +- Before any commit, verify the work with the required project checks. For code changes, run `go vet ./... && go test ./...`; for docs-only changes, run the most relevant non-mutating checks if available. - Create a commit only when all required checks pass and the current implementation area has no unresolved issues. - If a known failing check or unresolved issue belongs to another module and is outside the current task, report it clearly before asking for commit approval. -- Before running `git commit`, write the complete commit message first, show it to the user, and ask for explicit approval. Do not commit until the user approves that exact message. +- Before running `git commit`, write the complete commit message first, show it to the user, and ask for explicit approval. DON'T commit until the user approves that exact message. - Never include `Co-authored-by`, generated-tool signatures, or external attribution trailers unless the user explicitly asks for them. ### Commit Message Format @@ -49,7 +49,7 @@ Use Conventional Commits: ```text -[optional scope]: +[optional scope][optional !]: ``` @@ -58,17 +58,16 @@ Use Conventional Commits: - Add `!` after `type` or `scope` when the change contains a breaking API change. - Keep the title to one concise sentence describing the main change. - Write the body as bullet points grouped by change category. Each bullet starts with a typed prefix such as `feat:`, `fix:`, `test:`, `docs:`, `refactor:`, or `build:`. +- Use as few as possible bullets. - Use one blank line between the title and body, and one blank line between body bullets. -- Do not paste full code sentences into the message body; summarize behavior and intent. +- DON'T paste full code sentences into the message body; summarize behavior and intent. Example: ```text feat(middleware): add AdminRequired authorization middleware -- feat: AdminRequired gates admin endpoints by checking user IsAdmin flag. - -- feat: Placed after AuthRequired; fetches user from repository, returns 403 for non-admins. +- feat: AdminRequired gates admin endpoints by checking user IsAdmin flag. Placed after AuthRequired; fetches user from repository, returns 403 for non-admins. - fix: soft-deleted users are rejected with 401 since FindByID excludes them.