oh-pr-workflow

oh-pr-workflow：OpenHarmony PR 生命周期工作流

适用于 OpenHarmony GitCode 仓库的统一工作流。包含五种模式：

• 仅提交：用户说“提交”或“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 Token。检查：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 仓库提交，而不仅限于当前工作目录。在向其他仓库提交时（例如，将单独的仓库克隆到 /tmp 以创建 PR），也必须遵循相同规则：

• 提交消息格式（type(scope): 标题 + Issue + Signed-off-by + Co-Authored-By）
• 将 Issue 写入提交消息前，必须确保 Issue 已存在（如有需要则创建）
• 未先通过 API 验证或创建 Issue，绝不引用 Issue URL

提交消息格式

完整规范（格式、类型、规则、示例）请参阅 references/commit-format.md。

严格限制：提交消息的第一行（标题）不得超过 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 → 上游（PR 目标、Issue 创建）
• 其他 → Fork（推送目标、PR 源分支）

两者都必须存在。缺少 Fork → 提示用户。存在歧义 → 请用户选择。

邮箱解析

获取 Signed-off-by 行所需的邮箱。优先级如下：

1. 内存缓存：检查自动记忆中是否存在 user_gitcode_email.md。如果存在，直接使用其中的 email 字段。
2. MCP API：调用 get_authenticated_user 工具（无参数）。提取 email 字段。将其以 user 类型保存到记忆中，文件名为 user_gitcode_email.md。
3. Git 配置：使用 git config user.email 作为后备选项。
4. 无邮箱：提示用户进行配置。

问题检测

确定提交消息和 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. 未找到 → 在上游仓库通过 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”“fix codecheck”，或提供 GitCode PR URL 并要求修复代码检查问题。

输入：GitCode PR URL，例如 https://gitcode.com/{owner}/{repo}/pull/{number}

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 并表达审查意图。

输入：GitCode PR URL，例如 https://gitcode.com/{owner}/{repo}/pull/{number}

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 并表达修复审查意见的意图。

输入：GitCode PR URL，例如 https://gitcode.com/{owner}/{repo}/pull/{number}

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：修复审查意见）

• 没有未解决的审查意见：告知用户“未找到未解决的审查意见”
• 审查意见不明确：向用户展示该意见并询问如何处理
• 本地找不到文件：发出警告并跳过
• 无法根据意见确定修复方式：向用户说明情况并提供上下文，以便手动修复

错误处理（模式 4：审查 PR）

• 未提供 PR URL：询问用户提供 PR URL
• 未找到 PR：告知用户，并确认 PR 编号是否正确
• head/base 字段为空：回退到使用 list_pr_commits + list_pr_files 获取审查数据
• 获取失败：PR 源分支可能是私有的或已删除；如果有可用的 API 补丁，则使用补丁
• 本地仓库与 PR 所属仓库不同：如果当前仓库与 PR 所属仓库不匹配，则发出警告
• 工作区有未提交的更改：提醒用户存在未提交的更改，并建议切换分支前先暂存

错误处理（模式 3：修复代码检查）

• 未提供 PR URL：询问用户提供 PR URL
• 未发现未通过的门禁：告知用户，并建议确认门禁是否已通过
• DCP API 返回 500：告知用户 DCP 服务可能不可用，并显示 eventId/taskId，以便手动重试
• 文件中的缺陷不在本地仓库中：发出警告并跳过（PR 可能来自不同的分支或仓库）
• 无法自动修复：向用户报告缺陷及其文件:行号和规则说明

错误处理（通用）

• 未配置 MCP：发出警告并立即停止
• 没有上游远程仓库：提示用户添加 openharmony 远程仓库
• 没有 fork 远程仓库：提示用户 fork 该仓库
• PR 已存在：仅推送，并告知用户 PR 编号
• 创建 Issue 失败：发出警告，继续提交（省略 Issue 行）
• 推送失败：显示错误，并建议检查远程仓库或权限
• 提交消息标题超过 49 个字符：提交前必须缩短——这是硬性限制（仅适用于提交消息标题，不适用于 PR 标题）。运行 git commit 前，务必计算包括 type(scope): 前缀在内的字符数
• 没有要提交的更改：PR 模式下跳过提交；提交模式下停止
• 未找到电子邮件地址：提示用户配置 git email 或 GitCode token

常见错误（反模式）

以下是曾导致实际故障的严重错误。绝对不要犯这些错误：

1. 绝对不要混淆 ciEventId 和 codecheckEventId（模式 3） 缺陷详情 API 需要的是 codeCheckSummary[0].uuid 中的 UUID，而不是从门禁评论 URL 中提取的 CI 事件 ID。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 — 从 fork 向上游创建 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 — 列出 PR 评论，可选按 comment_type 筛选（diff_comment/pr_comment）
• 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； 位置在文件的所有代码块之间累计）。
• 使用 list_pr_files 中的 patch 字段计算正确的位置。

删除评论：delete_pr_comment(owner, repo, comment_id=NOTE_ID)