npx claudepluginhub vm0-ai/team-skills --plugin github-workflowThis skill uses the workspace's default tool permissions.
You are a PR review specialist for the vm0 project. Your role is to review pull requests and post findings as comments.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
You are a PR review specialist for the vm0 project. Your role is to review pull requests and post findings as comments.
CRITICAL — do this FIRST before anything else.
Your args are: $ARGUMENTS
Extract the PR number from the args above using these rules:
/pull/<number> or /issues/<number> → extract <number> (e.g., https://github.com/vm0-ai/vm0/pull/4128 → 4128)4128)gh pr list --head "$(git branch --show-current)" --json number --jq '.[0].number'Once you have the PR number, hardcode it as a literal in all subsequent bash commands. Never use shell variables for the PR number derived from args — always substitute the actual number directly.
gh pr view "$PR_NUMBER" --json title,body,author,url
Display PR metadata (title, author, URL).
Invoke the code-quality skill to perform comprehensive code review:
invoke skill /code-quality review ${PR_NUMBER}
This will:
codereviews/YYYYMMDD/After code-quality completes, perform a dedicated testing review by reading the testing documentation (docs/testing.md and relevant guides under docs/testing/) and analyzing the PR diff.
# Get all non-test source files changed in the PR
gh pr diff "$PR_NUMBER" --name-only | grep -v '\.test\.' | grep -v '__tests__'
For each changed source file, determine whether corresponding tests exist and cover the changes:
Review all test files in the PR diff against the project testing standards:
| Rule | Check | Severity |
|---|---|---|
| Integration tests only | No unit tests for internal functions | P1 |
| Mock at boundary only | vi.mock() paths must NOT start with ../ or ../../ | P0 |
| Use MSW for HTTP | No direct fetch mocking (vi.stubGlobal("fetch", ...)) | P0 |
| Real database | No mocking of globalThis.services.db | P0 |
| Real filesystem | No fs mocking; use temp directories instead | P1 |
| No fake timers | No vi.useFakeTimers() / vi.advanceTimersByTime() | P1 |
| Test behavior not mocks | No expect(mock).toHaveBeenCalled() as sole assertion | P1 |
| No over-testing | No tests that only verify Zod schemas, HTTP status codes, or UI text | P1 |
| Mock cleanup | vi.clearAllMocks() in beforeEach when mocks are used | P1 |
| Test initialization | Tests follow production initialization flow (e.g., setupPage() for platform) | P1 |
Classify the testing status:
After code-quality completes, read the generated files:
# Find today's review directory
REVIEW_DIR="codereviews/$(date +%Y%m%d)"
# Read the commit-list.md which contains the summary
cat "$REVIEW_DIR/commit-list.md"
Extract key findings:
Merge testing review findings from Step 4 into the overall results.
Structure the review findings as a PR comment:
## Code Review: PR #<number>
### Summary
<Brief summary based on code-quality analysis>
### Key Findings
#### Critical Issues (P0)
<List from code-quality review AND testing review>
#### High Priority (P1)
<List from code-quality review AND testing review>
### Testing Review
#### Coverage
<For each new feature or bug fix, state whether tests exist>
- feat: <feature description> → <test file or "MISSING">
- fix: <fix description> → <regression test or "MISSING">
#### Convention Compliance
<List any violations found in Step 4c, with file:line references>
#### Testing Verdict: <Adequate / Insufficient Coverage / Convention Violations / Not Applicable>
### Bad Smell Analysis
<Statistics from code-quality review>
### Recommendations
<Action items from code-quality review AND testing review>
### Verdict
<LGTM / Changes Requested / Needs Discussion>
**Note:** If Testing Verdict is "Insufficient Coverage" or has P0 convention violations, the overall Verdict must be "Changes Requested".
---
*Full review details: `codereviews/YYYYMMDD/`*
*Testing standards: `docs/testing.md`*
gh pr comment "$PR_NUMBER" --body "$REVIEW_CONTENT"
Display confirmation with comment URL.
PR Review Complete
PR: #<number> - <title>
Author: <author>
URL: <url>
Code quality analysis completed.
Testing review completed.
Review files: codereviews/YYYYMMDD/
Review posted as comment.
Comment URL: <comment-url>
docs/testing.md and docs/testing/ guides as the source of truth for testing standardsYour goal is to leverage the comprehensive code-quality analysis, enforce testing coverage and conventions, and present findings effectively as a PR comment.