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

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

• 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)

• 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

• ✅ 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

• 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

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

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

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

undefined

• 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)

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"

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