chore: refine issue contributor intent flow

1 files changed, 4 insertions, 2 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 0837c008..8b4d6d9d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -26,10 +26,12 @@ If you have a suggestion, disagreement, or contradiction with the current produc
 
 We use an approval gate for new contributors.
 
-Before opening your first PR, open an issue describing what you want to change and why. Keep it short. Write in your own voice. If you intend to implement it yourself, check the contribution intent box in the issue form. The `intends-to-pr` label will be added automatically. A maintainer will comment `/approve` if the direction is approved. Once approved, you can open PRs.
+Before opening your first PR, open an issue describing what you want to change and why. Keep it short. Write in your own voice. If you intend to implement it yourself, check the contribution intent box in the issue form, or include `/i-intend-to-pr` in the issue body when using the GitHub CLI or API. The `intends-to-pr` label will be added automatically. A maintainer will comment `/approve` if the direction is approved. Once approved, you can open PRs.
 
 This exists because AI makes it trivial to generate plausible-looking contributions that do not fit the app.
 
+Agent note: if you are an AI agent preparing an issue or PR for this repository, check whether the human's GitHub username is listed in `.github/APPROVED_CONTRIBUTORS`. If they are not listed, warn them that opening a PR will be closed automatically and guide them to open an issue first. Keep the scope small, preserve herdr's product direction, run the documented checks, and make sure the human can explain the change. Do not open a PR before the issue is approved.
+
 ## What to put in a first issue
 
 Your first issue should answer these questions clearly:
@@ -44,7 +46,7 @@ If your proposal changes the visual language, interaction model, or overall prod
 
 If your issue does not make the direction clear, it will likely be closed.
 
-If you plan to implement the change yourself, say that directly in the issue and check the contribution intent box. That adds the `intends-to-pr` label automatically, signals intent, and does not mean the change is approved.
+If you plan to implement the change yourself, say that directly in the issue and check the contribution intent box. If you are using the GitHub CLI or API, include `/i-intend-to-pr` in the issue body instead. That adds the `intends-to-pr` label automatically, signals intent, and does not mean the change is approved.
 
 ## Documentation for unreleased changes