docs: add protocol/tag change scope guidelines and reviewer checklist (#677)

Closes #662

Author: JiwaniZakir

AGENTS.md

@@ -36,6 +36,7 @@
 - Commit subject: imperative, ≤50 chars; sign with `git commit -S`.
 - Squash fixups before review.
 - PRs: link the motivating issue, include `cargo test` output, and call out schema or config changes to ease verification.
+- **Protocol/tag changes:** prefer single-kind (single event domain) PRs. Cross-kind changes require a scope declaration and compatibility statement in the PR body (see `CONTRIBUTING.md § Protocol / Tag Changes`).
 
 ## Documentation Guidelines
 - Do not hardcode source code line numbers in documentation (e.g., `src/app/take_buy.rs:11`). Line numbers drift as the codebase evolves, misleading developers. Reference file paths (`src/app/take_buy.rs`) or function names (`fn take_buy_action`) instead, which are far more stable and easily searchable.

CONTRIBUTING.md

@@ -21,6 +21,24 @@ All Mostro contributors submit changes via pull requests. The workflow is as fol
 
 Pull requests should be focused on a single change. Do not mix, for example, refactorings with a bug fix or implementation of a new feature. This practice makes it easier for fellow contributors to review each pull request.
 
+### Protocol / Tag Changes
+
+Changes that affect Nostr event tags (e.g. `y` tags, `z` tags) or event kinds are **protocol changes** and deserve extra care:
+
+- **Single-kind PRs preferred** – limit each PR to one event domain (orders, info, dispute, admin, dev-fee) whenever possible.
+- **Cross-kind changes** – if a PR must touch multiple event domains, include a "Scope Declaration" section in the PR body (see template below) and explain why the change cannot be split.
+- **Compatibility statement** – every protocol-tag PR must state the impact on external consumers (indexers, clients, relays).
+
+#### PR Body Template for Protocol Changes
+
+```markdown
+## Scope Declaration
+- **Event domains affected:** (e.g. orders, info, dispute)
+- **Cross-kind change:** yes / no
+- **Reason (if cross-kind):** …
+- **External compatibility impact:** (indexers, clients, relays)
+```
+
 ## Reviewing Pull Requests
 
 Mostro follows the review workflow established by the Bitcoin Core project. The following is adapted from the [Bitcoin Core contributor documentation](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#peer-review):
@@ -33,6 +51,8 @@ Anyone may participate in peer review which is expressed by comments in the pull
 - `Concept ACK` means "I agree in the general principle of this pull request";
 - `Nit` refers to trivial, often non-blocking issues.
 
+Reviewers should also verify **external contract impact** for any PR that modifies event kinds, tags, or message formats — confirm that indexers, clients, and relays are not silently broken by the change.
+
 Please note that Pull Requests marked `NACK` and/or GitHub's `Change requested` are closed after 30 days if not addressed.
 
 ## Code formatting