/pr — Summarize work and maintain PR

ECC Resource Awareness: If there are available code-reviewer or security-reviewer Agent, Step 2 can delegate for deeper review.

Step 1: Analyze current work

1a. Git Analysis

1. Run

   git status

   and

   git diff

   (staged + unstaged) to understand uncommitted changes
2. Run

   git log

   to check recent commit style
3. Key step — Confirm full scope of PR:
   • Run

     git log --oneline <base-branch>..HEAD

     to view all commits included in the PR
   • Run

     gh pr diff <PR-number> --name-only

     to view all files involved in the PR
   • If there is already an open PR, run

     gh pr view <PR-number> --json body

     to read the existing description

1b. Conversation Context Analysis

• Motivation: What was the original problem or requirement raised by the user?
• Discussion process: What solutions were explored during the process? What comparisons or investigations were done?
• Decision points: Where there were multiple options? Why was this solution finally chosen?
• Abandoned attempts: Are there any practices that were tried but abandoned? Why were they abandoned?
• Implicit knowledge: Important context that appears in the conversation but will not be reflected in the diff (e.g. survey data, external tool comparisons, performance considerations)
• Industry/academic basis: Does the technical decision reference industry standards (RFC, OWASP, etc.) or academic research? Is the solution based on standardized solutions?

⚠️ Common mistakes:

• Only looking at

  git diff

  will miss the content of other commits in the PR
• Only looking at diff not conversation will miss the decision context of "why this was done"
• PR description must reflect both what changed (diff) and why it changed (conversation context)

1c. Summary

Step 2: Quick Review

Checklist

• Security: Is there any sensitive information leakage (API keys, secrets, .env content)
• Correctness: Is the logic correct, are there any obvious bugs
• Omissions: Are there any debug codes (console.log, debugger) not cleared
• Types: Are TypeScript types correct, is there any abuse of

  any

• Style: Does it conform to the existing coding style of the project

Output format

• ✅ Passed items are mentioned in one sentence
• ⚠️ Items with concerns but not blocking explain the reason
• ❌ Problems that must be fixed list the file and line number

Interactive confirmation

• Continue PR process: The review result is okay, continue commit → push → PR
• Fix problems first: Deal with the problems found in the review first, and re-run

  /pr

  after the fix is completed

Step 3: Commit current changes

1. If there are uncommitted changes, write a commit message based on the content of the changes
2. Use conventional commits format (feat / fix / chore / refactor / test / docs)
3. Commit message uses English
4. Ensure that sensitive files (.env, credentials, etc.) are not committed

Step 4: Push to remote

1. Confirm whether the current branch has a corresponding remote tracking branch
2. If not, use

   git push -u origin <branch>

   to push
3. If yes, use

   git push

   to push

Step 5: Create or update PR

Base Branch Protection (Mandatory)

master

main

1. Read the project's branch policy (if there is

   skills/git-workflow/SKILL.md

   or similar files)
2. If the project has a defined default base branch (such as

   hotfix

   ,

   develop

   ), use that branch automatically
3. If the user explicitly requests to point to

   master

   or

   main

   → must interrupt and warn:
   • Use AskUserQuestion to remind: "According to project specifications, PR is not recommended to point directly to master/main. Are you sure you want to continue?"
   • Provide options: "Change to [project default base branch] (recommended)" / "I confirm to point to master/main"
   • Only continue after the user explicitly confirms
4. If the project has no special branch policy, use the repo's default branch

# Example: Project specification base branch is hotfix
gh pr create --base hotfix ...

# Prohibited (unless explicitly confirmed by the user)
gh pr create --base master ...

Judgment Logic

• If a PR number is provided (

  $ARGUMENTS

  ), update that PR
• If no number is provided, check if there is already an open PR for the current branch
  • Yes → Update the PR description
  • No → Create a new PR (using the project-specified base branch)

PR Description Format

## Summary

<!-- 1-3 句話說明這個 PR 的目的和背景脈絡 -->
<!-- 重點：讓 reviewer 30 秒內理解「為什麼要做這件事」 -->

## Context（對話脈絡）

<!-- 這是最重要的區塊 — 從對話中提取 reviewer 需要知道的 context -->
<!-- 來源：Step 1b 的對話脈絡分析結果 -->
<!--
必須包含：
- 使用者的原始需求（不只是最終實作，而是「為什麼要做這件事」）
- 過程中的調查/比較（例如：比較了 3 個框架，選了 X 因為 Y）
- 關鍵決策點和取捨（例如：選擇性採用而非全面導入，因為...）
- 放棄的方案和原因（例如：考慮過 Semcheck 但太早期）
- 不會出現在 diff 中的重要數據（例如：審計發現 145+ 檔案使用 Bootstrap）
- 技術方案的業界/學術依據（例如：採用 OAuth 2.0 因為 RFC 6749、選擇 bcrypt 因為 OWASP 建議）
-->
<!-- 目標：reviewer 不需要問「為什麼這樣做？」就能從這裡找到答案 -->

## Changes

<!-- 按主題分類列出變更，涵蓋 PR 的所有 commits（不只是當次對話的工作） -->
<!-- 用 git log <base-branch>..HEAD 確認完整範圍 -->
<!-- 用 git diff <base-branch>..HEAD --diff-filter=D --name-only 確認刪除的檔案 -->
<!-- 每個主題明確標示：新增了什麼、刪除了什麼、修改了什麼 -->

## Test plan

<!-- 測試計畫，checkbox 格式 -->

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Key points for writing Context block

1. Conversation context (Step 1b) — user's original intention, discussion process, decision reason
2. Git diff — what was actually changed
3. Commit messages — purpose of each commit

• The reason that triggered this work (bug report, feature request, tech debt)
• Investigation and comparison results in the process (data, framework comparison, technical evaluation)
• Attempts that were made but abandoned (if any), and the reasons for abandonment
• Key decision points (why choose A instead of B)
• Design considerations of the final solution
• Context that will not appear in the diff but reviewers need to know

• "Investigated 4 frameworks, chose X based on GitHub stars and feature comparison"
• "Audit found that more than 145 files are affected, so divided into 4 phases"
• "Considered full implementation but it is too heavy, changed to selective adoption"
• "This tool only has 111 stars, it is too early so we wrote it ourselves"

Step 6: Confirm results

1. Output PR URL
2. Confirm that the PR description has been updated
3. If there are other related PRs (such as feature → develop, develop → master), check whether synchronous update is required

Usage