From abc342be11b38dc7fb01e70c9e28c1767261cef3 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 27 Mar 2026 17:09:19 +0000 Subject: [PATCH 1/7] docs(claude): instruct agents to use git apply for diffs Instead of manually interpreting and applying each hunk via the Edit tool, agents should pipe diffs through git apply or save to a temp file and apply. This avoids slow, error-prone block-by-block editing. https://claude.ai/code/session_013WwSdSkpqSyDZ7WhJWn2f1 --- CLAUDE.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CLAUDE.md b/CLAUDE.md index 7e086d48..0e03eeb4 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -20,3 +20,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. - `gh` (GitHub CLI) is not installed — do not attempt to use it +- **When the user provides a diff/patch** (e.g. pasted output from `git diff`): save it to a temporary file and apply it with `git apply`, or pipe it directly via `git apply`. Do **not** manually read and interpret each hunk or use the Edit tool to apply changes block-by-block — that is slow and error-prone. If `git apply` fails, try `git apply --3way` or `patch -p1` before falling back to manual edits, and report the failure to the user. From 329de32e7acbfacaec98cc01af85f3a18bbded1e Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 27 Mar 2026 17:16:34 +0000 Subject: [PATCH 2/7] docs: instruct agents to use git apply for user-provided diffs When a user provides a diff/patch and asks for it to be applied, agents should use git apply (or patch -p1 as fallback) instead of manually interpreting and applying each hunk via the editor. Added nuance that diffs provided for context/discussion should not be blindly applied. https://claude.ai/code/session_013WwSdSkpqSyDZ7WhJWn2f1 --- .github/copilot-instructions.md | 1 + AGENTS.md | 1 + CLAUDE.md | 2 +- template/ai-instructions/shared.md | 1 + 4 files changed, 4 insertions(+), 1 deletion(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index f47276eb..b88cf1d0 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -19,3 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. +- **When the user provides a diff/patch** (e.g. pasted output from `git diff`) and asks you to apply it: save it to a temporary file and apply it with `git apply`, or pipe it directly via `git apply`. Do **not** manually read and interpret each hunk or use the editor to apply changes block-by-block — that is slow and error-prone. If `git apply` fails, try `git apply --3way` or `patch -p1` before falling back to manual edits, and report the failure to the user. If the user provides a diff for context or discussion rather than asking you to apply it, respond accordingly instead. diff --git a/AGENTS.md b/AGENTS.md index f47276eb..b88cf1d0 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -19,3 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. +- **When the user provides a diff/patch** (e.g. pasted output from `git diff`) and asks you to apply it: save it to a temporary file and apply it with `git apply`, or pipe it directly via `git apply`. Do **not** manually read and interpret each hunk or use the editor to apply changes block-by-block — that is slow and error-prone. If `git apply` fails, try `git apply --3way` or `patch -p1` before falling back to manual edits, and report the failure to the user. If the user provides a diff for context or discussion rather than asking you to apply it, respond accordingly instead. diff --git a/CLAUDE.md b/CLAUDE.md index 0e03eeb4..d72a8d43 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -19,5 +19,5 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. +- **When the user provides a diff/patch** (e.g. pasted output from `git diff`) and asks you to apply it: save it to a temporary file and apply it with `git apply`, or pipe it directly via `git apply`. Do **not** manually read and interpret each hunk or use the editor to apply changes block-by-block — that is slow and error-prone. If `git apply` fails, try `git apply --3way` or `patch -p1` before falling back to manual edits, and report the failure to the user. If the user provides a diff for context or discussion rather than asking you to apply it, respond accordingly instead. - `gh` (GitHub CLI) is not installed — do not attempt to use it -- **When the user provides a diff/patch** (e.g. pasted output from `git diff`): save it to a temporary file and apply it with `git apply`, or pipe it directly via `git apply`. Do **not** manually read and interpret each hunk or use the Edit tool to apply changes block-by-block — that is slow and error-prone. If `git apply` fails, try `git apply --3way` or `patch -p1` before falling back to manual edits, and report the failure to the user. diff --git a/template/ai-instructions/shared.md b/template/ai-instructions/shared.md index f47276eb..b88cf1d0 100644 --- a/template/ai-instructions/shared.md +++ b/template/ai-instructions/shared.md @@ -19,3 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. +- **When the user provides a diff/patch** (e.g. pasted output from `git diff`) and asks you to apply it: save it to a temporary file and apply it with `git apply`, or pipe it directly via `git apply`. Do **not** manually read and interpret each hunk or use the editor to apply changes block-by-block — that is slow and error-prone. If `git apply` fails, try `git apply --3way` or `patch -p1` before falling back to manual edits, and report the failure to the user. If the user provides a diff for context or discussion rather than asking you to apply it, respond accordingly instead. From 898908095fa69560a0ed6cc2dd1417b885841d69 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 27 Mar 2026 17:31:38 +0000 Subject: [PATCH 3/7] docs: simplify git apply instruction for diffs https://claude.ai/code/session_013WwSdSkpqSyDZ7WhJWn2f1 --- .github/copilot-instructions.md | 2 +- AGENTS.md | 2 +- CLAUDE.md | 2 +- template/ai-instructions/shared.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index b88cf1d0..29185a85 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- **When the user provides a diff/patch** (e.g. pasted output from `git diff`) and asks you to apply it: save it to a temporary file and apply it with `git apply`, or pipe it directly via `git apply`. Do **not** manually read and interpret each hunk or use the editor to apply changes block-by-block — that is slow and error-prone. If `git apply` fails, try `git apply --3way` or `patch -p1` before falling back to manual edits, and report the failure to the user. If the user provides a diff for context or discussion rather than asking you to apply it, respond accordingly instead. +- **When the user provides a diff**, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. diff --git a/AGENTS.md b/AGENTS.md index b88cf1d0..29185a85 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- **When the user provides a diff/patch** (e.g. pasted output from `git diff`) and asks you to apply it: save it to a temporary file and apply it with `git apply`, or pipe it directly via `git apply`. Do **not** manually read and interpret each hunk or use the editor to apply changes block-by-block — that is slow and error-prone. If `git apply` fails, try `git apply --3way` or `patch -p1` before falling back to manual edits, and report the failure to the user. If the user provides a diff for context or discussion rather than asking you to apply it, respond accordingly instead. +- **When the user provides a diff**, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. diff --git a/CLAUDE.md b/CLAUDE.md index d72a8d43..0a4d778f 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -19,5 +19,5 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- **When the user provides a diff/patch** (e.g. pasted output from `git diff`) and asks you to apply it: save it to a temporary file and apply it with `git apply`, or pipe it directly via `git apply`. Do **not** manually read and interpret each hunk or use the editor to apply changes block-by-block — that is slow and error-prone. If `git apply` fails, try `git apply --3way` or `patch -p1` before falling back to manual edits, and report the failure to the user. If the user provides a diff for context or discussion rather than asking you to apply it, respond accordingly instead. +- **When the user provides a diff**, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. - `gh` (GitHub CLI) is not installed — do not attempt to use it diff --git a/template/ai-instructions/shared.md b/template/ai-instructions/shared.md index b88cf1d0..29185a85 100644 --- a/template/ai-instructions/shared.md +++ b/template/ai-instructions/shared.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- **When the user provides a diff/patch** (e.g. pasted output from `git diff`) and asks you to apply it: save it to a temporary file and apply it with `git apply`, or pipe it directly via `git apply`. Do **not** manually read and interpret each hunk or use the editor to apply changes block-by-block — that is slow and error-prone. If `git apply` fails, try `git apply --3way` or `patch -p1` before falling back to manual edits, and report the failure to the user. If the user provides a diff for context or discussion rather than asking you to apply it, respond accordingly instead. +- **When the user provides a diff**, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. From 0f8769a2145b8f8493eb3a4af737f2e2d118774c Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 27 Mar 2026 17:47:05 +0000 Subject: [PATCH 4/7] docs: tone down git apply instruction Remove unnecessary bold emphasis and add conditional ("and you need to update the files") so the instruction doesn't read as "always apply". https://claude.ai/code/session_013WwSdSkpqSyDZ7WhJWn2f1 --- .github/copilot-instructions.md | 2 +- AGENTS.md | 2 +- CLAUDE.md | 2 +- template/ai-instructions/shared.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 29185a85..337e2b48 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- **When the user provides a diff**, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. diff --git a/AGENTS.md b/AGENTS.md index 29185a85..337e2b48 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- **When the user provides a diff**, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. diff --git a/CLAUDE.md b/CLAUDE.md index 0a4d778f..73cd19c2 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -19,5 +19,5 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- **When the user provides a diff**, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. - `gh` (GitHub CLI) is not installed — do not attempt to use it diff --git a/template/ai-instructions/shared.md b/template/ai-instructions/shared.md index 29185a85..337e2b48 100644 --- a/template/ai-instructions/shared.md +++ b/template/ai-instructions/shared.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- **When the user provides a diff**, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. From f0a968e9c87ef672b79831e1618817a87cbfe22e Mon Sep 17 00:00:00 2001 From: khai96_ Date: Sat, 28 Mar 2026 01:03:06 +0700 Subject: [PATCH 5/7] docs(ai): improve --- .github/copilot-instructions.md | 2 +- AGENTS.md | 2 +- CLAUDE.md | 2 +- template/ai-instructions/shared.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 337e2b48..3142e0f9 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- When the user provides a diff and you need to update the files, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, don't manually interpreting each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. diff --git a/AGENTS.md b/AGENTS.md index 337e2b48..3142e0f9 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- When the user provides a diff and you need to update the files, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, don't manually interpreting each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. diff --git a/CLAUDE.md b/CLAUDE.md index 73cd19c2..0ea1fa9b 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -19,5 +19,5 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- When the user provides a diff and you need to update the files, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, don't manually interpreting each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. - `gh` (GitHub CLI) is not installed — do not attempt to use it diff --git a/template/ai-instructions/shared.md b/template/ai-instructions/shared.md index 337e2b48..3142e0f9 100644 --- a/template/ai-instructions/shared.md +++ b/template/ai-instructions/shared.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- When the user provides a diff and you need to update the files, apply it with `git apply` instead of manually interpreting each hunk via the editor. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, don't manually interpreting each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. From 8744987495c56c662d20449d7e3b75dc984f91a1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kh=E1=BA=A3i?= Date: Sat, 28 Mar 2026 01:08:48 +0700 Subject: [PATCH 6/7] docs: fix grammar Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- .github/copilot-instructions.md | 2 +- AGENTS.md | 2 +- CLAUDE.md | 2 +- template/ai-instructions/shared.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 3142e0f9..c4e3c5bf 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- When the user provides a diff and you need to update the files, don't manually interpreting each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, don't manually interpret each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. diff --git a/AGENTS.md b/AGENTS.md index 3142e0f9..c4e3c5bf 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- When the user provides a diff and you need to update the files, don't manually interpreting each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, don't manually interpret each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. diff --git a/CLAUDE.md b/CLAUDE.md index 0ea1fa9b..ee222b85 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -19,5 +19,5 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- When the user provides a diff and you need to update the files, don't manually interpreting each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, don't manually interpret each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. - `gh` (GitHub CLI) is not installed — do not attempt to use it diff --git a/template/ai-instructions/shared.md b/template/ai-instructions/shared.md index 3142e0f9..ace2126b 100644 --- a/template/ai-instructions/shared.md +++ b/template/ai-instructions/shared.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- When the user provides a diff and you need to update the files, don't manually interpreting each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, don't manually interpret each hunk (that'd be slow); apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. From d8415a6f7e1ba39e159a613cd204ca6f26c5b3bb Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 27 Mar 2026 18:17:24 +0000 Subject: [PATCH 7/7] docs: regenerate ai instruction files from templates https://claude.ai/code/session_013WwSdSkpqSyDZ7WhJWn2f1 --- .github/copilot-instructions.md | 2 +- AGENTS.md | 2 +- CLAUDE.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index c4e3c5bf..ace2126b 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- When the user provides a diff and you need to update the files, don't manually interpret each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, don't manually interpret each hunk (that'd be slow); apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. diff --git a/AGENTS.md b/AGENTS.md index c4e3c5bf..ace2126b 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -19,4 +19,4 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- When the user provides a diff and you need to update the files, don't manually interpret each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, don't manually interpret each hunk (that'd be slow); apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. diff --git a/CLAUDE.md b/CLAUDE.md index ee222b85..0b9e615f 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -19,5 +19,5 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c - If you change CLI arguments, help text, or anything that affects command-line output, run `./generate-completions.sh` to regenerate the shell completion files, help text files, and `USAGE.md`. **Do not attempt to regenerate these files manually** — always use the script. - Run `FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh` to validate changes. If a test fails with a hint about `TEST_SKIP`, follow the hint and rerun with the suggested variable. If a sync test fails, read its error message carefully and run the exact command it tells you to run. - **ALWAYS run the full test suite** (`FMT=true LINT=true BUILD=true TEST=true DOC=true ./test.sh`) before committing, regardless of how trivial the change seems — this includes documentation-only changes, comment edits, config changes, and refactors. The test suite checks formatting, linting, building, tests, and docs across multiple feature combinations; any type of change can break any of these checks. -- When the user provides a diff and you need to update the files, don't manually interpret each hunk (that'd be slow), apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. +- When the user provides a diff and you need to update the files, don't manually interpret each hunk (that'd be slow); apply it with `git apply` instead. If the user provides a diff for context or discussion rather than as a change to apply, respond accordingly instead. - `gh` (GitHub CLI) is not installed — do not attempt to use it