diff --git a/.chezmoitemplates/ai/coding-principles.md b/.chezmoitemplates/ai/coding-principles.md
index 72fa676..e65cfbd 100644
--- a/.chezmoitemplates/ai/coding-principles.md
+++ b/.chezmoitemplates/ai/coding-principles.md
@@ -39,6 +39,12 @@ When your changes create orphans:
 
 The test: Every changed line should trace directly to the user's request.
 
+## Managed Personal Configuration
+
+- Before editing a user-level configuration file, check whether chezmoi manages it with `chezmoi source-path <target>`. If it does, edit the source file, review `chezmoi diff`, run `chezmoi apply --dry-run -v`, and then apply it. Never leave a target-only edit that the next chezmoi apply will overwrite.
+- Treat the chezmoi source as public. Never add employer-specific names, internal URLs, issue keys, repository names, source code, architecture details, customer data, credentials, or other non-public business information. Keep reusable instructions generic. If a rule cannot be made generic without losing its meaning, keep it out of dotfiles.
+- Apply the same public-information check to every GitHub surface for the dotfiles repository, including branch names, commit messages, pull request titles and descriptions, review comments, issues, and releases. Describe only the generic change and its public rationale. Never publish the private repository, incident, conversation, or business context that prompted it.
+
 ## Diagnose Before Fixing
 
 **Measure first. Don't theorize about the cause of a bug when you can instrument and observe.**
diff --git a/.chezmoitemplates/ai/git-workflow.md b/.chezmoitemplates/ai/git-workflow.md
index b2a5edf..4275c3d 100644
--- a/.chezmoitemplates/ai/git-workflow.md
+++ b/.chezmoitemplates/ai/git-workflow.md
@@ -9,3 +9,4 @@
 ## Pull Requests
 
 - **Always squash merge PRs.** Use `gh pr merge --squash` (or the GitHub UI squash-and-merge option) so each PR lands on `main` as a single, clean commit. This keeps `main` history readable regardless of how many granular commits the working branch had.
+- **Explain surprising choices where the reviewer sees them.** If a dependency, flag, workaround, suppression, or implementation choice looks unused or wrong without hidden context, add a concise inline GitHub comment on the relevant diff line. State what loads or requires it and why the obvious alternative was not used. Do not make reviewers reconstruct intent from tooling internals or the PR description.