diff --git a/apps/agent/agent/prompt.py b/apps/agent/agent/prompt.py
index 4f7113ca..e9c484a7 100644
--- a/apps/agent/agent/prompt.py
+++ b/apps/agent/agent/prompt.py
@@ -200,13 +200,14 @@ When you have completed your implementation, follow these steps in order:
    ```
    Where type is one of: `fix` (bug fix), `feat` (new feature), `chore` (maintenance), `ci` (CI/CD)
 
-   **PR Body**:
+   **PR Body** (keep under 10 lines total. the more concise the better):
    ```
    ## Description
-   <Explain WHY this PR is needed, list the changes, and reference the Linear issue>
+   <1-3 sentences on WHY and the approach.
+   NO "Changes:" section — file changes are already in the commit history.>
 
    ## Test Plan
-   - [ ] <specific verification step>
+   - [ ] <new/novel verification steps only — NOT "run existing tests" or "verify existing behavior">
    ```
 
    **Commit message**: Concise, focusing on the "why" rather than the "what". If not provided, the PR title is used.
diff --git a/apps/agent/agent/tools/commit_and_open_pr.py b/apps/agent/agent/tools/commit_and_open_pr.py
index 1088d787..f2a4fe83 100644
--- a/apps/agent/agent/tools/commit_and_open_pr.py
+++ b/apps/agent/agent/tools/commit_and_open_pr.py
@@ -64,33 +64,30 @@ def commit_and_open_pr(
     The PR body MUST follow this exact template:
 
         ## Description
-        <Explain WHY this PR is needed. Include:
-        - List of changes made
-        - Reference to the Linear issue or design docs
-        - Any context on the approach taken>
+        <1-3 sentences explaining WHY this PR is needed and the approach taken.
+        DO NOT list files changed or enumerate code
+        changes — that information is already in the commit history.>
 
         ## Test Plan
-        - [ ] <specific test step 1>
-        - [ ] <specific test step 2>
+        - [ ] <new test case or manual verification step ONLY for new behavior>
+
+    IMPORTANT RULES for the body:
+    - NEVER add a "Changes:" or "Files changed:" section — it's redundant with git commits
+    - Test Plan must ONLY include new/novel verification steps, NOT "run existing tests"
+      or "verify existing functionality is unaffected" — those are always implied
+      If it's a UI change you may say something along the lines of "Test in preview deployment"
+    - Keep the entire body concise (aim for under 10 lines total)
 
     Example body:
 
         ## Description
-        Fixes the null pointer exception that occurs when a user without
-        a profile attempts to authenticate. The root cause was a missing
-        null check in the `getProfile` method.
-
-        Changes:
-        - Added null check in `auth/getProfile.ts`
-        - Added fallback default profile object
-        - Updated related unit tests
+        Fixes the null pointer exception when a user without a profile authenticates.
+        The root cause was a missing null check in `getProfile`.
 
         Resolves AA-123
 
         ## Test Plan
         - [ ] Verify login works for users without profiles
-        - [ ] Verify existing users are unaffected
-        - [ ] Run `yarn test` and confirm all tests pass
 
     ## Commit Message