fix(agents): PR descriptions must be snapshots, not chronological narratives

Agents were appending "Review fixes" / "Consolidation" sections to PR
descriptions after each push, producing changelog-style narratives
instead of clean comparisons to main. Add snapshot principle to the
PR Maintenance rule, explicit "rewrite from scratch" guidance, and
prohibitions on narrating review rounds or mentioning internal workflow
tools (code-reviewer, crossfire, etc.) in PR descriptions.

Author: wpfleger96

src/ai_rules/config/AGENTS.md

@@ -259,22 +259,26 @@ def test_calls_hash_password():
 
 ### PR Maintenance After Pushing Commits
 
-**Rule:** After pushing commits to a branch with an existing open PR, always re-evaluate whether the PR title and description still accurately reflect the PR's content.
+**Rule:** After pushing commits to a branch with an existing open PR, re-evaluate the title and description. A PR description is a point-in-time snapshot of what this branch changes vs. main — never a timeline or narrative of how the PR evolved.
 
 **Mandatory workflow after every push to an existing PR:**
 1. Re-read: `gh pr view <number> --json title,body`
 2. Evaluate: does the title/description accurately describe ALL commits on the branch — not just the latest push?
-3. If stale, incomplete, or misleading: `gh pr edit <number> --title "..." --body "$(cat <<'EOF'...EOF)"`
+3. If stale: rewrite from scratch, then update via `gh pr edit <number> --title "..." --body "$(cat <<'EOF'...EOF)"`
 
-Updates are required when the PR's scope has materially changed — new direction, expanded scope, different approach. A minor fix already implied by the description probably doesn't need changes. But always evaluate; never skip the check.
+A minor fix already implied by the description probably doesn't need changes. But always evaluate; never skip the check.
 
-- ❌ Pushing 3 feedback-driven commits and moving on without checking the description
-- ✅ Re-reading, evaluating against the full commit set, editing if the description is now stale
+- ❌ Adding a "Review fixes" or "Consolidation" section that narrates what changed after feedback
+- ✅ Rewriting the full description to reflect what the branch currently does vs. main
 
 ### PR Description Content
 
 **NEVER include a "Test Plan", "Testing", or "Test plan" section in PR descriptions.** CI passing is a gate, not a finding.
 
+**NEVER narrate the development process** — no "after review," "following feedback," "consolidated from," or references to review rounds. Describe the final state only.
+
+**NEVER mention internal workflow tools** (code-reviewer, crossfire, test-writer, etc.) in PR descriptions.
+
 ### Commit Messages
 **Rule:** Subject states WHAT changed. Body explains WHY -- the problem, motivation, or design decision. Never narrate what's visible in `git show --stat` or the diff itself.
 

src/ai_rules/config/skills/pr-creator/SKILL.md

@@ -116,6 +116,6 @@ EOF
 
 **Formatting:** Always use HEREDOC in `gh pr create --body` | Ensure proper line breaks/bullets | Blank line before issue refs
 
-**PR Maintenance:** This skill covers PR creation only. After pushing additional commits to an existing PR, follow the PR Maintenance rule in AGENTS.md: re-read the current title/description and evaluate whether they still accurately reflect all commits.
+**PR Maintenance:** This skill covers PR creation only. After pushing additional commits to an existing PR, follow the PR Maintenance rule in AGENTS.md: rewrite the description from scratch as a snapshot of what the branch changes vs. main.
 
 Goal: Create PR descriptions making code review efficient and thorough, providing reviewers all context to understand and evaluate changes quickly.

src/ai_rules/config/skills/pr-creator/references/templates.md

@@ -293,6 +293,30 @@ Currently, webhook failures are silently dropped, causing data sync issues for i
 
 ✅ **Omit test plan entirely** -- leave test planning to humans.
 
+---
+
+❌ **Chronological narrative (narrates review rounds):**
+```
+This PR adds rate limiting to the API.
+
+- Add `RateLimiter` middleware with `check_rate()` method
+
+## Review fixes
+- Renamed `check_rate()` to `enforce_limit()` per code-reviewer feedback
+- Moved config to `settings.py` after crossfire review
+- Added input validation (round 2 feedback)
+```
+
+✅ **Clean snapshot (describes final state vs. main):**
+```
+This PR adds rate limiting to the API to prevent abuse.
+
+Authentication overhead was allowing unbounded request rates.
+
+- Add `RateLimiter` middleware with configurable limits via `settings.py`
+- Expose `enforce_limit()` as the public interface
+```
+
 ## Brevity Principles
 
 1. **Every word must earn its place** - Reviewers skim descriptions