oh-pr-workflow

oh-pr-workflow：OpenHarmony PR ライフサイクルワークフロー

OpenHarmony の GitCode リポジトリ向けの統合ワークフローです。5 つのモードがあります。

• コミットのみ：ユーザーが「提交」、「commit」と言った場合 → 標準化されたメッセージでコミットし、終了します
• フル PR：ユーザーが「创建PR」、「提个PR」と言った場合 → コミット（必要な場合）＋プッシュ＋Issue＋PR
• Codecheck の修正：ユーザーが「修复告警」、「修复门禁」、「修复codecheck」と言った場合、または PR URL を指定した場合 → ゲートの codecheck の欠陥を取得し、自動修正します
• PR のレビュー：ユーザーが「review pr」、「检视pr」、「看下这个pr」と言い、PR URL を指定した場合 → レビュー用に PR の変更をローカルに取得します
• レビュー指摘の修正：ユーザーが「修复review」、「修复检视意见」、「fix review」と言い、PR URL を指定した場合 → 未解決のレビューコメントを取得し、自動修正します

モード選択（クイックリファレンス）

ユーザーの意図	モード	移動先
「提交」、「commit」	モード 1：コミットのみ	モード 1
「创建PR」、「提个PR」	モード 2：フル PR	モード 2
「修复告警」、「修复门禁」、「fix codecheck」＋PR URL	モード 3：Codecheck の修正	モード 3
「review pr」、「检视pr」＋PR URL	モード 4：PR のレビュー	モード 4
「修复review」、「fix review」＋PR URL	モード 5：レビュー指摘の修正	モード 5

モードを特定したら、以下の前提条件を確認してから、該当するモードのセクションに直接進みます。

前提条件：いずれのモードを実行する場合も、事前に次の確認が必要です。

1. GitCode トークンが設定されている必要があります。確認方法：git config --get gitcode.token 空の場合は、ユーザーに次のように伝えます。 「GitCode の個人アクセストークンを設定してください：git config --global gitcode.token YOUR_TOKEN トークンの取得方法：GitCode の個人設定 → アクセストークン → 作成（api と read_api の権限が必要です）」 実行を停止します。
2. get_authenticated_user MCP ツールが利用可能か確認します（ToolSearch "get_authenticated_user"） 利用できない場合 → 自動的にセットアップを実行します。

   bash ~/.claude/skills/oh-pr-workflow/gitcode-mcp/setup.sh
   

   その後、ユーザーに「GitCode MCP を自動的にインストールしました。新しいツールを読み込むため、Claude Code のセッションを再起動してください。」と伝えます。 実行を停止します（MCP ツールの読み込みには新しいセッションが必要です）。
3. 両方の確認に合格したら、ワークフローを続行します。

対象範囲

このワークフローは、現在の作業ディレクトリだけでなく、すべての GitCode リポジトリへの提出に適用されます。別のリポジトリに提出する場合（PR のために別のリポジトリを /tmp にクローンする場合など）も、同じルールに従う必要があります。

• コミットメッセージの形式（type(scope): title ＋ Issue ＋ Signed-off-by ＋ Co-Authored-By）
• コミットメッセージに Issue を記載する前に、Issue が存在している必要があります（必要に応じて作成します）
• API で確認または作成する前に、Issue URL を参照してはいけません

コミットメッセージの形式

仕様の全容（形式、種類、ルール、例）については、references/commit-format.md を参照してください。

厳守事項：コミットメッセージの 1 行目（タイトル）は、49 文字以内でなければなりません（type(scope): の接頭辞を含みます）。コミットする前に文字数を数えてください。49 文字を超える場合は短くしてください。 例：fix(aptool): add ABC metadata checks（37 文字）✓ 反例：fix(aptool): add defensive checks for ABC metadata lookup（58 文字）✗

リモートの検出

リモート名を決めつけてはいけません。git remote -v を実行し、所有者に基づいて分類します。

• openharmony → UPSTREAM（PR のターゲット、Issue の作成先）
• その他 → FORK（プッシュ先、PR のヘッド）

両方が存在する必要があります。fork がない場合はユーザーに確認します。判断が曖昧な場合は、選択するようユーザーに尋ねます。

メールアドレスの解決

Signed-off-by 行に使用するメールアドレスを取得します。優先順位は次のとおりです。

1. メモリーキャッシュ：auto-memory に user_gitcode_email.md が存在するか確認します。存在する場合は、email フィールドをそのまま使用します。
2. MCP API：get_authenticated_user ツールを（パラメーターなしで）呼び出します。email フィールドを抽出します。user_gitcode_email.md として、種類を user に設定してメモリーに保存します。
3. Git の設定：フォールバックとして git config user.email を使用します。
4. なし：ユーザーに設定を依頼します。

Issue の検出

コミットメッセージと PR に使用する Issue を決定します。どちらのモードでも共通です。

入力：ユーザーは --issue N または --issue URL を指定できます。

アルゴリズム：

1. ユーザーが Issue を指定した場合 → get_issue で検証し、有効であれば使用します
2. git log {upstream_remote}/{target_branch}..HEAD をスキャンし、既存の Issue URL を検索します
   • 正規表現：Issue:\s*https://gitcode\.com/[^/]+/[^/]+/issues/(\d+)
   • 見つかった場合 → 最も古い一致を再利用します
3. 見つからない場合 → upstream リポジトリで create_issue を使用して自動作成します
   • タイトル：ブランチ名またはコミット差分から生成します
   • 本文：references/issue_template.md を使用し、git diff のコンテキストから内容を入力します

Issue URL の形式：https://gitcode.com/{upstream_owner}/{upstream_repo}/issues/{number}

モード 1：コミットのみ

トリガー：ユーザーが PR を作成せずにコミットしたい場合。

Step 1: Check uncommitted changes
  git status --porcelain

Step 2: Resolve email
  Follow Email Resolution above

Step 3: Determine Issue
  Follow Issue Detection above (target_branch defaults to master)

Step 4: Generate commit message
  - Title: MUST be ≤49 chars (count before committing!), Claude generates from diff or user provides
  - Body: Issue URL + Signed-off-by + Co-Authored-By: Agent

Step 5: Stage files
  a. Identify files to commit:
     - Files that Claude created or modified in this session → always include
     - Other changed files in working tree → need user confirmation
  b. Filter out files that should NEVER be committed:
     Exclude patterns:
       - .idea/*, .vscode/*, .claude/*, .DS_Store
       - .env, .env.*, credentials*, *secret*
       - out/*, build/*, *.o, *.so, *.a, *.pyc, __pycache__/
       - report.json, rules.txt, *.log
       - Any file matched by .gitignore
  c. If there are files beyond what Claude modified:
     Present to user: "以下文件也有变更，是否一起提交？" + file list
     User selects which to include
  d. git add {final file list} — always add specific files by name
     NEVER use "git add ." or "git add -A"

Step 6: Pre-commit codecheck
  If oh-precommit-codecheck skill is available, run it on staged files:
    Invoke: /oh-precommit-codecheck
  If defects found:
    - Present defects to user
    - Ask: "发现代码告警，是否先修复再提交？"
    - User confirms fix → fix defects, re-stage, re-run codecheck
    - User skips → proceed to commit (warn that gate may fail)
  If no defects or skill not available → proceed

Step 7: Commit
  - git commit with formatted message (use HEREDOC for multi-line)
  - Output: commit hash, linked Issue

コミットコマンドのテンプレート：

git commit -m "$(cat <<'EOF'
type(scope): title here

Issue: https://gitcode.com/owner/repo/issues/N
Signed-off-by: Name <email>
Co-Authored-By: Agent
EOF
)"

モード 2：完全な PR

トリガー：ユーザーが PR を作成したい場合。

入力：--target branch（任意、デフォルト：master）

Step 1: Check status & detect remotes
  git status, git remote -v
  Identify upstream and fork
  Determine target branch

Step 2: Handle uncommitted changes
  git status --porcelain
  Has changes → execute Commit Only mode (Steps 2-7)

Step 3: Push to fork
  git push -u {fork_remote} {current_branch}

Step 4: Check existing PR
  MCP list_pull_requests (upstream owner/repo)
  Search results for current branch name
  Found → inform user "PR !{number} already exists", stop
  Not found → continue

Step 5: Determine Issue
  Follow Issue Detection above

Step 6: Create PR
  Read .gitee/PULL_REQUEST_TEMPLATE.zh-CN.md from repo (prioritize repo template if exists)
  Fill template with bilingual content (Chinese + English per item, NOT repeated blocks):
    - Issue: full URL https://gitcode.com/{upstream_owner}/{upstream_repo}/issues/{number}
      (NEVER use #{number} shorthand — always use the full Issue URL)
    - 描述/Description, 原因/Reason, 修改方案/Scheme: write bilingual per item.
      Format each point as "中文 / English" on the same bullet, e.g.:
        - `FindRecordByName` 匹配失败时无日志 / No log output when match fails
      Do NOT write all Chinese first then repeat all English — interleave per item.
    - Checklist: intelligently check items based on change scope
  If no template found in repo, use a simple bilingual structure with Issue URL,
  Description, Reason, Scheme sections.
  MCP create_pull_request:
    owner: {upstream_owner}
    repo: {upstream_repo}
    title: concise summary from commit messages
    head: {fork_owner}:{current_branch}
    base: {target_branch}
    body: filled template content (bilingual)
  Output: PR URL, linked Issue number

Step 7: Trigger gate CI
  After PR is created, post comment to trigger build:
  MCP create_pr_comment:
    owner: {upstream_owner}
    repo: {upstream_repo}
    pull_number: {pr_number from Step 6}
    body: "start build"
  Output: inform user that gate CI has been triggered

実行成功時の例：

git remote -v → openharmony (upstream), origin (fork)
git status → 2 files changed
→ Commit: fix(napi): add null check [32 chars] ✓
→ Push: origin/fix-null-check
→ Issue: #1985 created on openharmony/arkui_napi
→ PR: !2610 created (zhuheng_z:fix-null-check → master)
→ Comment: "start build" posted, gate CI triggered

モード 3：Codecheck の修正

トリガー：ユーザーが「修復告警」、「修復门禁」、「修復codecheck」、「fix codecheck」と言う場合、または修正を求めて GitCode の PR URL を提示する場合。

入力：https://gitcode.com/{owner}/{repo}/pull/{number} のような GitCode の PR URL

Step 1: Parse PR URL and get PR details
  Extract owner, repo, pull_number from the URL
  Regex: https://gitcode\.com/([^/]+)/([^/]+)/pull/(\d+)
  MCP get_pull_request(owner, repo, pull_number) to get:
    - head.ref: source branch
    - head.sha: head commit SHA
    - head.repo.full_name: fork repo (e.g., "zhuheng_z/arkui_napi")

Step 2: Ensure PR code is checked out locally
  a. Check if head commit exists locally:
       git cat-file -t {head.sha} 2>/dev/null
  b. Check if current branch matches PR branch:
       git branch --show-current == head.ref ?
  c. Decision:
     - Current branch matches AND head SHA matches → code is local, proceed
     - Head SHA exists but wrong branch → git checkout {head.ref}
     - Head SHA not local → fetch and checkout:
         Extract head_owner from head.repo.full_name
         git remote add pr-fix-{head_owner} https://gitcode.com/{head_owner}/{repo}.git 2>/dev/null || true
         git fetch pr-fix-{head_owner} {head.ref}
         git checkout -b fix/pr-{pull_number} FETCH_HEAD
  d. Record original branch for later return

Step 3: Get PR comments and find failed gate check
  MCP list_pr_comments(owner, repo, pull_number, per_page=100)
  Search for the first comment containing "代码门禁未通过"
  If not found → inform user "No failed gate check found", stop

Step 4: Extract CI eventId and taskId from the failed comment body
  ciEventId: regex /detail/([a-f0-9]+)/runlist  (this is the CI event ID)
  taskId:    regex taskId=(MR_[a-f0-9]+)
  date:      extract from comment created_at (YYYY-MM-DD)

Step 5: Get codecheck UUID from CI event info
  IMPORTANT: The defect detail API needs the codecheck UUID, NOT the CI event ID.
  Fetch CI event info:
    GET https://dcp.openharmony.cn/api/codecheckAccess/ci-portal/v1/event/{ciEventId}
  Extract codecheck UUID from response:
    response.data.codeCheckSummary[0].uuid → this is the codecheckEventId
  Use codecheckEventId (not ciEventId) for the defect API.

Step 6: Fetch all defects
  Run: bash ~/.claude/skills/oh-pr-workflow/scripts/fetch_gate_defects.sh <codecheckEventId> <taskId> <date>
  This auto-paginates and outputs a JSON array to stdout
  Parse the JSON to get the defect list

Step 7: Summarize defects
  Present a summary table to user:
    - Total defect count
    - Breakdown by rule (e.g., G.FMT.11-CPP: 56, G.FMT.04-CPP: 48, ...)
    - Breakdown by file
  Ask user to confirm before proceeding with fixes

Step 8: Auto-fix defects
  For each defective file:
    a. Read the file
    b. For each defect in that file, understand the rule and fix it:
       - G.FMT.04-CPP (one statement per line): split multi-declarations
       - G.FMT.11-CPP (braces): add {} around single-line if/for/while/else
       - G.FMT.05-CPP (line width): break lines over 120 chars
       - G.NAM.03-CPP (naming): rename to match convention
       - G.EXP.35-CPP (nullptr): replace NULL/0 with nullptr
       - G.EXP.41-CPP (loop variable): restructure loop
       - G.FUN.01-CPP (function size): cannot auto-fix, report to user
       - Other rules: read the defectContent, apply best-effort fix
    c. Edit the file with fixes

Step 9: Verify fixes (optional)
  If oh-precommit-codecheck skill is available, run local codecheck on fixed files
  Report any remaining issues

モード 4：PR のレビュー

トリガー：ユーザーが「review pr」、「review这个pr」、「看下这个pr」、「检视pr」と言う場合、またはレビューの意図を添えて PR URL を提示する場合。

入力：https://gitcode.com/{owner}/{repo}/pull/{number} のような GitCode の PR URL

Step 1: Parse PR URL
  Extract owner, repo, pull_number from the URL
  Regex: https://gitcode\.com/([^/]+)/([^/]+)/pull/(\d+)

Step 2: Get PR details via MCP
  MCP get_pull_request(owner, repo, pull_number)
  From response extract:
    - head.ref: source branch name (e.g., "fix/strdup-free-mismatch")
    - head.sha: head commit SHA
    - head.repo.full_name: fork full name (e.g., "yewei0794/arkui_napi")
    - head.user.login: PR author login
    - base.ref: target branch (e.g., "master")
    - base.sha: base commit SHA
    - title, body, state, labels

Step 3: Get PR commits and files via MCP (precise, no git fetch needed)
  MCP list_pr_commits(owner, repo, pull_number)
    → exact commit list with SHA and message
  MCP list_pr_files(owner, repo, pull_number)
    → exact changed file list with filename, additions, deletions, patch

Step 4: Present PR summary
  - PR title, author, head branch → base branch
  - Commit list (from Step 3)
  - Changed files with +/- stats (from Step 3)

Step 5: Fetch PR code to local
  Always fetch to local so user can browse the code after review:
    a. Record current branch: git branch --show-current
    b. Stash if dirty: git stash (if needed)
    c. Extract head_owner from head.repo (e.g., "yewei0794")
    d. git remote add pr-review-{head_owner} https://gitcode.com/{head_owner}/{repo}.git 2>/dev/null || true
    e. git fetch pr-review-{head_owner} {head.ref}
    f. git checkout -b review/pr-{pull_number} FETCH_HEAD
  Use patch data from Step 3 for the review analysis itself (faster),
  but the local branch ensures user can inspect files afterwards.

Step 6: Perform code review
  For each changed file:
    a. Use patch from list_pr_files for diff analysis
    b. Read full file from local checkout when deeper context is needed
    c. Identify issues: bugs, style, security, performance, logic errors
    d. Present review comments organized by file with line references
  After presenting all review findings, ask the user which comments (if any)
  should be posted as line-level diff comments on the PR.
  If the user confirms specific comments → post them using the Line-Level
  Review Comment API described below.

Step 7: Keep local branch, inform user
  After review, switch back to original branch but DO NOT delete the review branch:
    git checkout {original_branch}
    git stash pop (if stashed)
  Inform user:
    "Review 完成。PR 代码保留在本地分支 review/pr-{pull_number}，你可以随时切换查看。
     清理命令: git branch -D review/pr-{pull_number} && git remote remove pr-review-{head_owner}"

モード 5：レビュー指摘の修正

トリガー：ユーザーが「修复review」、「修复检视意见」、「fix review」と言う場合、またはレビューコメントを修正する意図を添えて PR URL を提示する場合。

入力：https://gitcode.com/{owner}/{repo}/pull/{number} のような GitCode の PR URL

Step 1: Parse PR URL and get PR details
  Extract owner, repo, pull_number from the URL
  MCP get_pull_request(owner, repo, pull_number) to get:
    - head.ref, head.sha, head.repo.full_name

Step 2: Ensure PR code is checked out locally
  Same logic as Mode 3 Step 2:
    - Check head SHA exists locally + current branch matches
    - If not → fetch and checkout

Step 3: Fetch diff data and review comments
  a. Get PR changed files with diff hunks (needed for file path mapping):
     MCP list_pr_files(owner, repo, pull_number)
     For each file, parse hunk headers from patch.diff:
       Regex: @@ -(\d+),?(\d*) \+(\d+),?(\d*) @@
     Build a line-to-file mapping:
       For each file, each hunk defines a new_line range:
         new_start to new_start + new_count - 1 → filename

     Worked example:
       A review comment has diff_position.start_new_line = 2650.
       list_pr_files returns ark_native_engine.cpp with hunk header:
         @@ -2638,15 +2640,31 @@
       Parse: new_start=2640, new_count=31 → range is [2640, 2670].
       Check: 2650 falls within [2640, 2670].
       Result: comment maps to ark_native_engine.cpp, line 2650 in the new file.

       If another file utils.cpp has hunk @@ -100,10 +100,12 @@ (range [100, 111]),
       2650 does NOT fall in [100, 111], so utils.cpp is ruled out.

  b. Get review comments:
     MCP list_pr_comments(owner, repo, pull_number, comment_type="diff_comment", per_page=100)
     Filter for unresolved only: resolved == false
     Extract from each:
       - user.login: reviewer name
       - body: review comment content
       - diff_position.start_new_line / end_new_line: line number in new file
       - discussion_id: for grouping replies

  c. Map each comment to its file:
     IMPORTANT: GitCode API does NOT return a `path` field in diff_comment JSON.
     Use the line-to-file mapping from step (a) to determine the file:
       For each comment, find the file whose hunk range contains
       diff_position.start_new_line → that is the file the comment belongs to.

  d. Outdated detection (after force-push, diff line numbers shift):
     For each review comment, compare its diff_position line against the current
     diff's hunk ranges:
       - Line falls within a current hunk range → comment is still ACTIVE
       - Line out of range for all hunks → comment is OUTDATED
     Present outdated comments separately (greyed out) so user can confirm skipping.

Step 4: Present review comments and proposed fixes to user
  Group comments into ACTIVE and OUTDATED based on Step 3(d) outdated detection.

  For OUTDATED comments:
    Show as "~~已过期~~" with original content, no fix proposed.

  For ACTIVE comments:
    - Reviewer: {user.login}
    - File: {mapped filename from Step 3(c)}
    - Line: {diff_position.start_new_line}
    - Comment: {body}
    - Proposed fix: Claude reads the file at that line, analyzes the comment, shows before/after diff

  *** HARD GATE: STOP HERE AND WAIT FOR USER CONFIRMATION ***
  Do NOT proceed to Step 6 until the user explicitly confirms.
  Present all proposed fixes and ask: "以上修复方案是否可以执行？"
  User may:
    - Confirm all → proceed to Step 6
    - Confirm some, reject others → adjust and re-present
    - Reject all → stop

Step 5: Apply confirmed fixes
  Only apply fixes the user confirmed:
    a. Read the target file
    b. Apply the fix at the indicated line
    c. Edit the file

Step 6: Squash into original commit and push
  IMPORTANT: Always squash fix into original commit, never create separate commit.
    git add {fixed files}
    git commit --amend --no-edit

  *** CONFIRM BEFORE FORCE-PUSH ***
  Inform user: "将 squash 进原始 commit 并 force-push 到 {fork_remote}/{branch}。确认？"
  Wait for user confirmation before proceeding. Do NOT force-push without explicit approval.

    git push --force {fork_remote} {branch}

Step 7: Trigger rebuild
  MCP create_pr_comment(owner, repo, pull_number, body="start build")

エラー処理（モード 5：レビュー指摘の修正）

• 未解決のレビューコメントがない場合：ユーザーに「No unresolved review comments found」と伝えます
• レビューコメントが不明確な場合：コメントをユーザーに提示し、指示を求めます
• ファイルがローカルに見つからない場合：警告してスキップします
• コメントから修正方法を特定できない場合：手動修正用のコンテキストを添えてユーザーに報告します

エラー処理（モード 4：PR のレビュー）

• PR URL が指定されていない場合：ユーザーに PR URL を求めます
• PR が見つからない場合：ユーザーに伝え、PR 番号が正しいか確認します
• head/base フィールドが空の場合：レビュー用データの取得に list_pr_commits + list_pr_files を使用します
• フェッチに失敗した場合：PR のソースフォークが非公開または削除されている可能性があります。利用可能であれば API のパッチを使用します
• ローカルリポジトリが別のリポジトリの場合：現在のリポジトリが PR のリポジトリと一致しない場合は警告します
• 作業ツリーに変更がある場合：未コミットの変更についてユーザーに警告し、ブランチ切り替え前に stash することを提案します

エラー処理（モード 3：Codecheck の修正）

• PR URL が指定されていない場合：ユーザーに PR URL を求めます
• 失敗したゲートが見つからない場合：ユーザーに伝え、ゲートを通過したか確認するよう提案します
• DCP API が 500 を返した場合：DCP サービスが停止している可能性をユーザーに伝え、手動で再試行できるよう eventId/taskId を表示します
• ローカルリポジトリにないファイルに不具合がある場合：警告してスキップします（PR が別のブランチまたはリポジトリからのものである可能性があります）
• 自動修正できない場合：ファイルと行番号、およびルールの説明を添えて不具合をユーザーに報告します

エラー処理（全般）

• MCP が設定されていない場合：警告して直ちに停止します
• upstream リモートがない場合：openharmony リモートを追加するようユーザーに促します
• フォークリモートがない場合：リポジトリをフォークするようユーザーに促します
• PR がすでに存在する場合：プッシュのみを行い、PR 番号をユーザーに伝えます
• Issue の作成に失敗した場合：警告し、コミットは続行します（Issue の行は省略します）
• プッシュに失敗した場合：エラーを表示し、リモートまたは権限を確認するよう提案します
• コミットメッセージのタイトルが 49 文字を超える場合：コミット前に必ず短くします — これは厳格な上限です（コミットメッセージのタイトルのみに適用され、PR タイトルには適用されません）。git commit の実行前に、type(scope): のプレフィックスも含めて必ず文字数を数えます
• コミットする変更がない場合：PR モードではコミットをスキップし、コミットモードでは停止します
• メールアドレスが見つからない場合：git のメールアドレスまたは GitCode トークンを設定するようユーザーに促します

よくある間違い（アンチパターン）

これらは、実際に障害を引き起こした重大なエラーです。絶対に次の間違いをしないでください。

1. ciEventId と codecheckEventId を絶対に混同しないでください（モード 3） 欠陥詳細 API で必要なのは、ゲートコメントの URL から抽出した CI イベント ID ではなく、codeCheckSummary[0].uuid の UUID です。CI イベント ID（/detail/{id}/runlist から取得）は、コードチェックのサマリーを取得するためだけに使用します。実際に欠陥を照会するには、codeCheckSummary 内で返される uuid フィールドが必要です。

2. 認識できないルールに対して、推測で修正を試みないでください（モード 3） コードチェックのルールがステップ 8 の既知のルール（G.FMT.04-CPP、G.FMT.11-CPP など）に記載されていない場合、推測で修正を試みてはいけません。その代わり、ルール ID、ファイル名:行番号、defectContent をユーザーに報告し、対処方法を判断できるようにしてください。

3. diff_position.start_new_line がグローバルなオフセットだと決めつけないでください（モード 5） diff_position.start_new_line は、特定のファイルの新しいバージョン内の行番号であり、全ファイルをまたぐグローバルな位置ではありません。どのファイルにその行が属するかを特定するには、list_pr_files の hunk ヘッダーにある行とファイルの対応付けを必ず使用してください。

4. ユーザーの確認なしに強制プッシュしないでください（モード 5） git push --force は破壊的な操作です。プッシュする内容とプッシュ先を必ずユーザーに示し、明示的な確認を待ってください。

5. レビュー修正用に別のコミットを作成しないでください（モード 5） レビュー修正は、必ず git commit --amend --no-edit で元のコミットにまとめてください。新しいコミットを作成すると PR の履歴が乱れ、上流のマージポリシーに違反するおそれがあります。

使用する GitCode MCP ツール

注：このセクションは参照用のカタログです。通常の実行中に読む必要はありません。呼び出す具体的な MCP ツールは、各モードの上記の手順内に記載されています。

コアワークフローツール：

• get_authenticated_user — 現在のユーザーのメールアドレスを取得（Signed-off-by 用）
• create_issue — 上流リポジトリに Issue を作成
• get_issue — ユーザー指定の Issue が存在することを確認
• list_pull_requests — 既存の PR を確認
• create_pull_request — フォークから上流リポジトリへの PR を作成
• get_pull_request — PR の詳細を取得（head.ref、head.sha、head.repo、base.ref、base.sha）
• list_pr_commits — PR 内の正確なコミットを一覧表示
• list_pr_files — 追加・削除・パッチ情報とともに変更ファイルを一覧表示
• list_pr_comments — オプションの comment_type フィルター（diff_comment/pr_comment）を指定して PR コメントを一覧表示
• create_pr_comment — PR にコメントを投稿（全般、または path+position を指定した行単位）
• delete_pr_comment — note_id を指定して PR コメントを削除

利用可能なその他のツール：

• update_pull_request — PR のタイトル／本文／状態／ベースブランチを更新
• merge_pull_request — PR をマージ（merge/squash/rebase）
• submit_pr_review — PR レビューを承認
• submit_pr_test — PR のテストを合格としてマーク
• update_pr_reviewers — レビュアーを割り当て
• update_pr_testers — テスターを割り当て
• update_pr_labels — PR ラベルを追加／削除
• pr_link_issues — Issue を PR にリンク
• list_pr_operation_logs — PR の操作履歴を一覧表示
• update_issue / close_issue / reopen_issue — Issue の状態を管理
• add_issue_comment / list_issue_comments / edit_issue_comment / delete_issue_comment — Issue コメントを操作
• add_issue_labels / remove_issue_label / list_labels — ラベルを管理
• list_pr_reactions / create_pr_reaction — PR の絵文字リアクションを操作
• list_issue_reactions / create_issue_reaction — Issue の絵文字リアクションを操作
• create_release — リポジトリのリリースを作成

行単位のレビューコメント

MCP の create_pr_comment ツールは、全般的なコメントと行単位のコメントの両方に対応しています。

全般的なコメント：create_pr_comment(owner, repo, pull_number, body="...") 行単位のコメント：create_pr_comment(owner, repo, pull_number, body="...", path="file.cpp", position=N)

position の決定方法：

• position は統合差分内の行番号であり、ファイルの行番号ではありません。
• 新規ファイル（追加のみで100％構成）の場合：差分の行番号 ＝ ファイルの行番号です。
• 変更されたファイルの場合：ファイルの統合差分内で行を順に数えます （@@ ヘッダー行は数えません。@@ の後に続く最初の内容行が position 1 です。 position はファイル内のすべてのハンクを通じて累積します）。
• 正しい position を計算するには、list_pr_files の patch フィールドを使用してください。

コメントの削除：delete_pr_comment(owner, repo, comment_id=NOTE_ID)