type: skill name: PR Review description: Review pull requests against team standards and best practices skillSlug: pr-review phases: [R, V] generated: 2026-03-18 status: filled scaffoldVersion: "2.0.0"
PR Review
Review pull requests for the @dotcontext/cli project against established patterns and quality standards.
When to Use
- Reviewing a PR before merge
- Validating changes during the Review (R) or Validation (V) phases
- Checking that a PR meets the project's architectural and testing standards
PR Review Process
1. Understand the Change Scope
Check which areas are affected:
# View changed files grouped by area
git diff main...HEAD --stat
Map changes to project layers:
src/services/mcp/-- MCP server and gateway toolssrc/services/<domain>/-- Service layer business logicsrc/generators/-- Scaffold generationsrc/workflow/-- PREVC workflow systemsrc/utils/-- Shared utilitiessrc/index.ts-- CLI command definitions.context/-- Documentation and scaffolding content
2. Verify the Commit History
This project uses Conventional Commits:
<type>(<scope>): <description>
Check that:
- Each commit has a valid type (
feat,fix,refactor,docs,test,chore) - Scope matches the primary area of change (see commit-message skill for scope list)
- Messages are in imperative mood ("add", not "added")
- Breaking changes use
!suffix andBREAKING CHANGE:footer
3. Architecture Review
Service Layer Compliance
- New services follow the directory-per-service pattern under
src/services/ - Services export through
index.tsbarrel files - Constructor accepts options object; async init is a separate method
- Dependencies are injectable (like
contextBuilderinAIContextMCPServer)
MCP Tool Changes
- Zod schemas have
.describe()on every parameter - Gateway handler covers all actions in the enum (no unreachable branches)
- Responses use
createJsonResponse/createErrorResponsefromresponse.ts - New types exported through
gatewayTools.tsbarrel - Total MCP tool count remains manageable (currently 9)
- Tool description strings include all action names for AI discovery
Generator Changes
- Generators use v2 frontmatter (
scaffoldVersion: "2.0.0") -
forceflag is respected (skip existing when false) - Result type includes generated/skipped counts
- Templates are in
templates/subdirectory
Workflow Changes
- Phase transitions follow PREVC order
- Scale-dependent phases are correctly skipped
- Gate logic is enforced unless explicitly bypassed
4. Code Quality Checks
- No
anytypes; useunknown+ type guards - No
console.login MCP server code (useprocess.stderr.write) - File paths use
path.join()/path.resolve(), never string concatenation - Optional dependencies (tree-sitter) handled with graceful fallback
- Error messages are user-friendly (CLI) or structured JSON (MCP)
5. Testing Verification
# Run all tests
npm test
# Build check
npm run build
- New services have
.test.tsfiles - Tests mock external dependencies (
jest.mock()for AI providers, fs) - Temp directories used (
fs.mkdtemp) and cleaned up (afterEach) - Mock
CLIInterfaceandTranslateFnprovided where needed - MCP handler tests call handler functions directly (not through transport)
6. i18n Completeness
- New user-facing strings added to both
enandpt-BRinsrc/utils/i18n.ts - Translation keys use dot notation (
commands.new.description) - CLI output uses
t()function, not hardcoded strings
7. Documentation Impact
-
CHANGELOG.mdupdated if the change is user-facing -
README.mdupdated if public CLI commands or MCP tools changed -
.context/docs/updated if architecture changed significantly - MCP tool description strings updated if actions added/removed
Common PR Issues
Missing Barrel Exports
New types or handlers added in src/services/mcp/gateway/*.ts but not re-exported through gateway/index.ts and gatewayTools.ts.
Inconsistent Error Handling
MCP handlers that throw instead of returning createErrorResponse(). CLI commands that swallow errors silently.
Untested Edge Cases
- What happens when
.context/directory does not exist? - What happens when tree-sitter is not installed?
- What happens with empty or malformed frontmatter?
- What happens with relative vs. absolute paths?
Breaking MCP Compatibility
Renaming or removing an MCP tool action without a migration path. Always add new actions alongside old ones, then deprecate.
PR Description Template
When creating PRs for this project:
## Summary
- What this PR does (1-3 bullet points)
## Changes
- List of key changes by file/area
## Test plan
- [ ] Unit tests pass: `npm test`
- [ ] Build succeeds: `npm run build`
- [ ] Manual verification: `npx tsx src/index.ts <command>`
- [ ] MCP tool tested (if applicable)