diff --git a/packages/cloud-agents/src/server/workflows/__tests__/githubPrReviewSkill.test.ts b/packages/cloud-agents/src/server/workflows/__tests__/githubPrReviewSkill.test.ts index 36be3e516..c009ac555 100644 --- a/packages/cloud-agents/src/server/workflows/__tests__/githubPrReviewSkill.test.ts +++ b/packages/cloud-agents/src/server/workflows/__tests__/githubPrReviewSkill.test.ts @@ -71,9 +71,32 @@ describe('review-code GitHub workflow paths', () => { expect(skillContent).toContain( 'When `pull_request_details` or current head metadata is missing, or when it must be revalidated before a side effect, call `mcp__roomote__manage_source_control` with `action: "get_pull_request"`, `repositoryFullName`, and `prNumber`.', ); - expect(skillContent).toContain( - "When `pull_request_diff` is missing, or when the current diff must be revalidated before a side effect, compute it locally: `git fetch origin '' ''`, then `git diff ...` using the SHAs from `get_pull_request`. Use this local git diff for every provider instead of a provider CLI.", - ); + for (const appendixName of [ + 'review-github-pr', + 'review-github-pr-with-approval', + ]) { + const appendix = readAppendix(skillContent, appendixName); + expect(appendix).toContain( + "For a GitHub cross-repository PR, run `git fetch origin '' '+refs/pull/[PR_NUMBER]/head:refs/remotes/origin/pr-[PR_NUMBER]-head'`, then verify `git rev-parse refs/remotes/origin/pr-[PR_NUMBER]-head` exactly equals `` from `get_pull_request`.", + ); + expect(appendix).toContain( + 'If it differs, call `get_pull_request` once more and proceed only when the fetched SHA matches the refreshed ``; otherwise report the blocker.', + ); + } + for (const appendixName of [ + 'review-github-pr', + 'review-github-pr-with-approval', + 'sync-github-pr-review', + 'sync-github-pr-review-with-approval', + ]) { + const appendix = readAppendix(skillContent, appendixName); + expect(appendix).toContain( + "For a GitHub cross-repository PR, fetch the upstream PR ref with `git fetch origin '+refs/pull/[PR_NUMBER]/head:refs/remotes/origin/pr-[PR_NUMBER]-head'`, verify its resolved SHA exactly equals `` from `get_pull_request`, and if it differs call `get_pull_request` once more and proceed only when the fetched SHA matches the refreshed ``; otherwise report the blocker. Then run `git checkout --detach `.", + ); + expect(appendix).toContain( + 'For a cross-repository PR on another provider whose source branch cannot be fetched with task credentials, report that blocker instead of fetching the fork directly or improvising credentials.', + ); + } expect(skillContent).toContain( 'When `existing_review_comments` or `issue_comments` are missing, or when current thread or top-level discussion state must be revalidated before a side effect, call `mcp__roomote__manage_source_control` with `action: "list_pull_request_comments"`.', ); diff --git a/packages/cloud-agents/src/server/workflows/skills/standard/review-code/SKILL.md b/packages/cloud-agents/src/server/workflows/skills/standard/review-code/SKILL.md index b63b76e28..8a054ea4a 100644 --- a/packages/cloud-agents/src/server/workflows/skills/standard/review-code/SKILL.md +++ b/packages/cloud-agents/src/server/workflows/skills/standard/review-code/SKILL.md @@ -237,11 +237,11 @@ You are a pull request review workflow specialist. Review the assigned pull requ If prompt-supplied PR snapshots exist, start from them and skip redundant fetches. Use the Roomote MCP `manage_source_control` read actions only to fill missing context or to revalidate mutable provider state before posting comments, patching summary comments, or approving; do not use provider-specific CLIs such as `gh` for pull-request state. When `pull_request_details` or current head metadata is missing, or when it must be revalidated before a side effect, call `mcp__roomote__manage_source_control` with `action: "get_pull_request"`, `repositoryFullName`, and `prNumber`. The result carries the title, body, state, draft flag, source and target branches, head and base SHAs, author, mergeability, and cross-repository (fork) information. - When `pull_request_diff` is missing, or when the current diff must be revalidated before a side effect, compute it locally: `git fetch origin '' ''`, then `git diff ...` using the SHAs from `get_pull_request`. Use this local git diff for every provider instead of a provider CLI. + When `pull_request_diff` is missing, or when the current diff must be revalidated before a side effect, compute it locally. For a same-repository PR, run `git fetch origin '' ''`. For a GitHub cross-repository PR, run `git fetch origin '' '+refs/pull/[PR_NUMBER]/head:refs/remotes/origin/pr-[PR_NUMBER]-head'`, then verify `git rev-parse refs/remotes/origin/pr-[PR_NUMBER]-head` exactly equals `` from `get_pull_request`. If it differs, call `get_pull_request` once more and proceed only when the fetched SHA matches the refreshed ``; otherwise report the blocker. For a cross-repository PR on another provider whose source branch cannot be fetched with task credentials, report that blocker instead of improvising credentials. Then run `git diff ...`. Use this local git diff for every provider instead of a provider CLI. When `existing_review_comments` or `issue_comments` are missing, or when current thread or top-level discussion state must be revalidated before a side effect, call `mcp__roomote__manage_source_control` with `action: "list_pull_request_comments"`. The result returns review threads (each with a `threadId`, `resolved` state when the provider exposes it, and inline path/line anchors) plus top-level `issueComments`; heed any capability warnings it reports. Before PR checkout or deep repository reading, if `TOP_LEVEL_COMMENT_ID` is already supplied or the available PR issue comments already reveal a reusable canonical summary comment, recover that reusable comment immediately and patch only its status block in place (using `mcp__roomote__manage_source_control` `action: "update_pull_request_comment"` with that comment's `commentId`, plus its `threadId` when the provider returns one) to show a short in-progress line such as `Reviewing the PR now. {task_link_follow}`. Rewrite only the content inside the hidden `` and `` markers when they exist, and otherwise normalize the comment into the hidden status/checklist block format before continuing. Carry the recovered comment ID forward as `TOP_LEVEL_COMMENT_ID` for the later canonical-summary step instead of leaving stale status text visible during startup latency. If `linked_issue` context is missing, use the linked-work-item context supplied by the current workflow instructions or referenced in the pull-request body when present; do not fetch issues through provider-specific CLIs. - Check out the PR branch locally with `git fetch origin '' && git checkout ''`, using the source branch from the pull-request details. For cross-repository (fork) PRs whose source branch cannot be fetched with task credentials, report that blocker instead of improvising credentials. + Check out a same-repository PR branch with `git fetch origin '' && git checkout ''`. For a GitHub cross-repository PR, fetch the upstream PR ref with `git fetch origin '+refs/pull/[PR_NUMBER]/head:refs/remotes/origin/pr-[PR_NUMBER]-head'`, verify its resolved SHA exactly equals `` from `get_pull_request`, and if it differs call `get_pull_request` once more and proceed only when the fetched SHA matches the refreshed ``; otherwise report the blocker. Then run `git checkout --detach `. For a cross-repository PR on another provider whose source branch cannot be fetched with task credentials, report that blocker instead of fetching the fork directly or improvising credentials. Read the changed files in full, then read any related types, schemas, callers, tests, or utilities needed to verify correctness in context. The live pull request state, existing discussion, and relevant repository context have been read deeply enough to support evidence-based review findings. @@ -512,11 +512,11 @@ You are a pull request review workflow specialist. Review the assigned pull requ If prompt-supplied PR snapshots exist, start from them and skip redundant fetches. Use the Roomote MCP `manage_source_control` read actions only to fill missing context or to revalidate mutable provider state before posting comments, patching summary comments, or approving; do not use provider-specific CLIs such as `gh` for pull-request state. When `pull_request_details` or current head metadata is missing, or when it must be revalidated before a side effect, call `mcp__roomote__manage_source_control` with `action: "get_pull_request"`, `repositoryFullName`, and `prNumber`. The result carries the title, body, state, draft flag, source and target branches, head and base SHAs, author, mergeability, and cross-repository (fork) information. - When `pull_request_diff` is missing, or when the current diff must be revalidated before a side effect, compute it locally: `git fetch origin '' ''`, then `git diff ...` using the SHAs from `get_pull_request`. Use this local git diff for every provider instead of a provider CLI. + When `pull_request_diff` is missing, or when the current diff must be revalidated before a side effect, compute it locally. For a same-repository PR, run `git fetch origin '' ''`. For a GitHub cross-repository PR, run `git fetch origin '' '+refs/pull/[PR_NUMBER]/head:refs/remotes/origin/pr-[PR_NUMBER]-head'`, then verify `git rev-parse refs/remotes/origin/pr-[PR_NUMBER]-head` exactly equals `` from `get_pull_request`. If it differs, call `get_pull_request` once more and proceed only when the fetched SHA matches the refreshed ``; otherwise report the blocker. For a cross-repository PR on another provider whose source branch cannot be fetched with task credentials, report that blocker instead of improvising credentials. Then run `git diff ...`. Use this local git diff for every provider instead of a provider CLI. When `existing_review_comments` or `issue_comments` are missing, or when current thread or top-level discussion state must be revalidated before a side effect, call `mcp__roomote__manage_source_control` with `action: "list_pull_request_comments"`. The result returns review threads (each with a `threadId`, `resolved` state when the provider exposes it, and inline path/line anchors) plus top-level `issueComments`; heed any capability warnings it reports. Before PR checkout or deep repository reading, if `TOP_LEVEL_COMMENT_ID` is already supplied or the available PR issue comments already reveal a reusable canonical summary comment, recover that reusable comment immediately and patch only its status block in place (using `mcp__roomote__manage_source_control` `action: "update_pull_request_comment"` with that comment's `commentId`, plus its `threadId` when the provider returns one) to show a short in-progress line such as `Reviewing the PR now. {task_link_follow}`. Rewrite only the content inside the hidden `` and `` markers when they exist, and otherwise normalize the comment into the hidden status/checklist block format before continuing. Carry the recovered comment ID forward as `TOP_LEVEL_COMMENT_ID` for the later canonical-summary step instead of leaving stale status text visible during startup latency. If `linked_issue` context is missing, use the linked-work-item context supplied by the current workflow instructions or referenced in the pull-request body when present; do not fetch issues through provider-specific CLIs. - Check out the PR branch locally with `git fetch origin '' && git checkout ''`, using the source branch from the pull-request details. For cross-repository (fork) PRs whose source branch cannot be fetched with task credentials, report that blocker instead of improvising credentials. + Check out a same-repository PR branch with `git fetch origin '' && git checkout ''`. For a GitHub cross-repository PR, fetch the upstream PR ref with `git fetch origin '+refs/pull/[PR_NUMBER]/head:refs/remotes/origin/pr-[PR_NUMBER]-head'`, verify its resolved SHA exactly equals `` from `get_pull_request`, and if it differs call `get_pull_request` once more and proceed only when the fetched SHA matches the refreshed ``; otherwise report the blocker. Then run `git checkout --detach `. For a cross-repository PR on another provider whose source branch cannot be fetched with task credentials, report that blocker instead of fetching the fork directly or improvising credentials. Read the changed files in full, then read any related types, schemas, callers, tests, or utilities needed to verify correctness in context. The live pull request state, existing discussion, and relevant repository context have been read deeply enough to support evidence-based review findings. @@ -833,7 +833,7 @@ You are a sync-review workflow specialist. Re-review pull requests after new com If prompt-supplied delta snapshots exist, start from them and skip redundant fetches. Use the Roomote MCP `manage_source_control` read actions or local git only to fill missing delta context or to revalidate mutable provider state before posting comments, patching summary comments, or approving; do not use provider-specific CLIs such as `gh` for pull-request state. When `pull_request_details` or current head metadata is missing, or when it must be revalidated before a side effect, call `mcp__roomote__manage_source_control` with `action: "get_pull_request"`, `repositoryFullName`, and `prNumber`. The result carries the title, body, state, draft flag, source and target branches, head and base SHAs, author, mergeability, and cross-repository (fork) information. If you are not in `legacy_full_rereview_path` and the current head SHA matches `last_review_sha`, update the summary comment with a short no-op note, mark the terminal outcome as `no_new_delta`, then continue directly to the linked-task handoff step so the implementation task receives that explicit status before you stop. - Check out the PR branch locally with `git fetch origin '' && git checkout ''`, using the source branch from the pull-request details. For cross-repository (fork) PRs whose source branch cannot be fetched with task credentials, report that blocker instead of improvising credentials. + Check out a same-repository PR branch with `git fetch origin '' && git checkout ''`. For a GitHub cross-repository PR, fetch the upstream PR ref with `git fetch origin '+refs/pull/[PR_NUMBER]/head:refs/remotes/origin/pr-[PR_NUMBER]-head'`, verify its resolved SHA exactly equals `` from `get_pull_request`, and if it differs call `get_pull_request` once more and proceed only when the fetched SHA matches the refreshed ``; otherwise report the blocker. Then run `git checkout --detach `. For a cross-repository PR on another provider whose source branch cannot be fetched with task credentials, report that blocker instead of fetching the fork directly or improvising credentials. If you are not in `legacy_full_rereview_path`, first decide whether there is any new delta at all with a two-dot diff `git diff [last_review_sha]..[HEAD_SHA]` and `git log --oneline [last_review_sha]..[HEAD_SHA]`. Two-dot (`..`) is the actual content difference between the two reviewed commits. If it is empty — for example the head SHA changed only because the branch was rebased, with no new content — treat it the same as the head-SHA-match case: update the summary comment with a short no-op note, mark the terminal outcome `no_new_delta`, and continue to the linked-task handoff step instead of re-reviewing. When there is a delta, the authoritative set of changes you may review is the PR's current Files Changed — its base-to-head diff, `git diff ...` (three-dot from the current base), scoped to the files in `pull_request_changed_files`/`changed_files_since_last_review` and the supplied `diff_in_range` when present. Report findings only for hunks that appear in that current PR diff. A change that is not in the PR's base-to-head diff — including a base-branch modification to a file the PR also touches — is out of scope: it belongs to the base branch, not this PR, and must not be reported or carried forward. Use the two-dot delta and commit log only to focus on what is new since the last review, never as the review scope itself. If you are in `legacy_full_rereview_path`, re-review the full current PR diff with a local base-to-head comparison: `git fetch origin ''`, then `git diff ...` using the SHAs from `get_pull_request`. Use this local git diff for every provider. @@ -1144,7 +1144,7 @@ You are a sync-review workflow specialist. Re-review pull requests after new com If prompt-supplied delta snapshots exist, start from them and skip redundant fetches. Use the Roomote MCP `manage_source_control` read actions or local git only to fill missing delta context or to revalidate mutable provider state before posting comments, patching summary comments, or approving; do not use provider-specific CLIs such as `gh` for pull-request state. When `pull_request_details` or current head metadata is missing, or when it must be revalidated before a side effect, call `mcp__roomote__manage_source_control` with `action: "get_pull_request"`, `repositoryFullName`, and `prNumber`. The result carries the title, body, state, draft flag, source and target branches, head and base SHAs, author, mergeability, and cross-repository (fork) information. If you are not in `legacy_full_rereview_path` and the current head SHA matches `last_review_sha`, update the summary comment with a short no-op note, mark the terminal outcome as `no_new_delta`, then continue directly to the linked-task handoff step so the implementation task receives that explicit status before you stop. - Check out the PR branch locally with `git fetch origin '' && git checkout ''`, using the source branch from the pull-request details. For cross-repository (fork) PRs whose source branch cannot be fetched with task credentials, report that blocker instead of improvising credentials. + Check out a same-repository PR branch with `git fetch origin '' && git checkout ''`. For a GitHub cross-repository PR, fetch the upstream PR ref with `git fetch origin '+refs/pull/[PR_NUMBER]/head:refs/remotes/origin/pr-[PR_NUMBER]-head'`, verify its resolved SHA exactly equals `` from `get_pull_request`, and if it differs call `get_pull_request` once more and proceed only when the fetched SHA matches the refreshed ``; otherwise report the blocker. Then run `git checkout --detach `. For a cross-repository PR on another provider whose source branch cannot be fetched with task credentials, report that blocker instead of fetching the fork directly or improvising credentials. If you are not in `legacy_full_rereview_path`, first decide whether there is any new delta at all with a two-dot diff `git diff [last_review_sha]..[HEAD_SHA]` and `git log --oneline [last_review_sha]..[HEAD_SHA]`. Two-dot (`..`) is the actual content difference between the two reviewed commits. If it is empty — for example the head SHA changed only because the branch was rebased, with no new content — treat it the same as the head-SHA-match case: update the summary comment with a short no-op note, mark the terminal outcome `no_new_delta`, and continue to the linked-task handoff step instead of re-reviewing. When there is a delta, the authoritative set of changes you may review is the PR's current Files Changed — its base-to-head diff, `git diff ...` (three-dot from the current base), scoped to the files in `pull_request_changed_files`/`changed_files_since_last_review` and the supplied `diff_in_range` when present. Report findings only for hunks that appear in that current PR diff. A change that is not in the PR's base-to-head diff — including a base-branch modification to a file the PR also touches — is out of scope: it belongs to the base branch, not this PR, and must not be reported or carried forward. Use the two-dot delta and commit log only to focus on what is new since the last review, never as the review scope itself. If you are in `legacy_full_rereview_path`, re-review the full current PR diff with a local base-to-head comparison: `git fetch origin ''`, then `git diff ...` using the SHAs from `get_pull_request`. Use this local git diff for every provider.