PR Review Workflow
Review pull requests with correct AQE scope boundaries, clear communication, and actionable feedback.
Arguments
<pr-number> — GitHub PR number to review. If omitted, prompt the user.
Steps
1. Read the Full Diff
gh pr diff <pr-number>
gh pr view <pr-number>
Read the complete diff and PR description. Do not skim — read every changed file.
2. Scope Check
- Only analyze AQE/QE skills (NOT Claude Flow platform skills)
- Platform skills to EXCLUDE: v3-, flow-nexus-, agentdb-, reasoningbank-, swarm-, github-, hive-mind-advanced, hooks-automation, iterative-loop, stream-chain, skill-builder, sparc-methodology, pair-programming, release, debug-loop, aqe-v2-v3-migration
- If the PR touches skills, verify the count/scope matches expectations (~78 AQE skills)
- Flag any platform skill changes that may have leaked into an AQE-focused PR
3. Summarize Changes
Write a user-friendly summary of what changed and why:
- Focus on outcomes, not implementation details
- Avoid overly technical jargon
- Keep it to 3-5 bullet points
4. Trust Tier Validation
For any skill changes, validate trust_tier assignments:
- tier 3 = has eval infrastructure (evals/, schemas/, scripts/)
- tier 2 = tested but no eval framework
- tier 1 = untested
- Flag inconsistencies (e.g., a skill with evals at tier 2 should be tier 3)
5. Code Quality Review
Check for:
- Hardcoded version strings
- Production safety concerns (adapter changes, breaking changes)
- Missing test coverage for new code
- Security issues (exposed secrets, injection risks)
6. Post Review
gh pr review <pr-number> --body "review comments"
Communication Rules
- Keep tone constructive and actionable
- Be outcome-focused: what should the author do, not what's wrong
- Group related comments together instead of posting many small ones
- If approving with minor suggestions, use APPROVE with comments, not REQUEST_CHANGES
1---
2inclusion: auto
3name: qe-pr-review
4description: "Scope-aware GitHub PR review with user-friendly tone and trust tier validation"
5---
6
7# PR Review Workflow
8
9Review pull requests with correct AQE scope boundaries, clear communication, and actionable feedback.
10
11## Arguments
12
13- `<pr-number>` — GitHub PR number to review. If omitted, prompt the user.
14
15## Steps
16
17### 1. Read the Full Diff
18```bash
19gh pr diff <pr-number>
20gh pr view <pr-number>
21```
22Read the complete diff and PR description. Do not skim — read every changed file.
23
24### 2. Scope Check
25- Only analyze AQE/QE skills (NOT Claude Flow platform skills)
26- Platform skills to EXCLUDE: v3-*, flow-nexus-*, agentdb-*, reasoningbank-*, swarm-*, github-*, hive-mind-advanced, hooks-automation, iterative-loop, stream-chain, skill-builder, sparc-methodology, pair-programming, release, debug-loop, aqe-v2-v3-migration
27- If the PR touches skills, verify the count/scope matches expectations (~78 AQE skills)
28- Flag any platform skill changes that may have leaked into an AQE-focused PR
29
30### 3. Summarize Changes
31Write a user-friendly summary of what changed and why:
32- Focus on outcomes, not implementation details
33- Avoid overly technical jargon
34- Keep it to 3-5 bullet points
35
36### 4. Trust Tier Validation
37For any skill changes, validate trust_tier assignments:
38- **tier 3** = has eval infrastructure (evals/, schemas/, scripts/)
39- **tier 2** = tested but no eval framework
40- **tier 1** = untested
41- Flag inconsistencies (e.g., a skill with evals at tier 2 should be tier 3)
42
43### 5. Code Quality Review
44Check for:
45- Hardcoded version strings
46- Production safety concerns (adapter changes, breaking changes)
47- Missing test coverage for new code
48- Security issues (exposed secrets, injection risks)
49
50### 6. Post Review
51```bash
52gh pr review <pr-number> --body "review comments"
53```
54
55## Communication Rules
56
57- Keep tone constructive and actionable
58- Be outcome-focused: what should the author do, not what's wrong
59- Group related comments together instead of posting many small ones
60- If approving with minor suggestions, use APPROVE with comments, not REQUEST_CHANGES
proffesor-for-testing