Consolidate jj command syntax, remove redundant skill invocation guidance,
clarify title generation to reflect overall change not individual commits,
and tighten attribution requirements.

Assisted-by: Claude Haiku 4.5 via Claude Code

diff --git a/ai/claude/commands/pr.md b/ai/claude/commands/pr.md
index 9f23e7c1..ef7bf0de 100644
--- a/ai/claude/commands/pr.md
+++ b/ai/claude/commands/pr.md
@@ -4,34 +4,27 @@ Create a pull request using gh for a bookmark that has already been
 pushed.
 
 Usage:
+- `/pr` - Create a PR for the closest pushable bookmark
 - `/pr <bookmark-name>` - Create a PR for the specified bookmark
 
 When creating a pull request:
-1. Run `jj log -r 'trunk()::<bookmark-name>'` to see all commits from
-trunk to the bookmark
-2. Run `jj diff -r 'trunk()::<bookmark-name>' --stat` to understand all
-changes from trunk
-3. Analyze all commits and changes that will be included in the pull
-request
-4. Check if there are any .github templates for pull requests and follow
-them
-5. Invoke the `writing` skill for assistance with PR description style
-and conventions
-6. Draft a pull request summary:
-   - Focus on why the changes were made and their impact
-   - CRITICAL: Do NOT repeat information that is obvious from the diff
-     itself. Reviewers will read the diff. Your description should
-     provide context, motivation, and implications that cannot be
-     determined by examining the code changes alone
-   - Avoid describing implementation details like "added function X",
-     "modified file Y", or "changed variable Z" unless explaining
-     non-obvious reasoning
-   - Explain user-facing impact, architectural decisions, or tradeoffs
-     that justify the approach taken
+1. If no bookmark is provided, use `jj log -r 'max(bookmarks() &
+   bookmarks(remote=origin))'` to find the closest pushable bookmark (a local
+   bookmark that has been pushed to origin)
+2. Run `jj log -r 'trunk()::bookmark-name'` to list all commits from trunk to
+   the bookmark
+3. Run `jj diff -r 'trunk()::bookmark-name' --stat` to review all changes
+4. Check for .github PR templates and follow them
+5. Generate a PR title summarizing all commits in the changeset (not just the
+   most recent). The title reflects the overall change, not individual commits
+6. Draft a PR summary explaining why the changes were made and their impact.
+   Focus on context and motivation, not implementation details. Include only
+   "Assisted-by" footer for attribution—no "Generated with Claude Code"
+   - Do not repeat information obvious from the diff
+   - Omit details like "added function X" or "modified file Y" unless
+     non-obvious reasoning justifies them
+   - Explain user-facing impact, architectural decisions, and tradeoffs
    - Follow repository conventions
-   - Do NOT include duplicate attribution (e.g., both "Generated with
-     Claude Code" and "Assisted-by" footer)
-7. Create PR using `gh pr create --head <bookmark-name>` with the
-summary. Use a HEREDOC to pass the body and include ONLY the
-"Assisted-by" footer with the current model and tool being used
-8. Return the PR URL when done
+7. Create the PR: `gh pr create --head <bookmark-name> --title "<title>"` using
+   a HEREDOC to pass the body
+8. Return the PR URL