github-code-review

Name: github-code-review
Author: AlexAI-MCP

132stars24forks

How to install github-code-review?

alexai-mcp/hermes-ccc/github-code-review

$npx -y skills add AlexAI-MCP/hermes-CCC --skill github-code-review

Installs into the current project.

Summary

Review GitHub pull requests with a findings-first engineering mindset. Use when auditing diffs for bugs, regressions, security issues, missing tests, or risky design choices, and when producing actionable review comments instead of generic summaries.

Files · 1

View on GitHub

SKILL.md

1	# GitHub Code Review
2
3	## Purpose
4
5	- Find real defects and risks before merge.
6	- Prioritize correctness, security, and regressions over style nits.
7	- Produce review comments that are concrete and defensible.
8	- Keep summaries brief and findings primary.
9	- Tie each concern to evidence in the diff.
10
11	## Activation Signals
12
13	- Use this skill when the user asks for a review.
14	- Use this skill when a PR must be audited before merge.
15	- Use this skill when code changes touch critical systems.
16	- Use this skill when a team needs structured findings with severity.
17	- Use this skill when review comments should map cleanly onto changed files.
18
19	## Review Order
20
21	1. Read PR metadata.
22	2. Read changed-file list.
23	3. Identify risky files first.
24	4. Read the diff with behavioral intent in mind.
25	5. Check tests and verification claims.
26	6. Produce findings ordered by severity.
27	7. Add a brief summary only after the findings.
28
29	## High-Risk Change Types
30
31	- auth or session logic
32	- data migrations
33	- concurrency changes
34	- caching invalidation
35	- payment or billing logic
36	- permission checks
37	- serialization or schema changes
38	- error handling rewrites
39
40	## Evidence Sources
41
42	- file diffs
43	- PR description
44	- CI status
45	- changed filenames
46	- related issue text
47	- existing review comments
48	- nearby tests
49
50	## Finding Categories
51
52	- correctness bug
53	- regression risk
54	- security issue
55	- missing validation
56	- missing test coverage
57	- maintainability risk
58	- performance regression
59
60	## Severity Guidelines
61
62	- `high` when merge could cause data loss, security exposure, or broken primary flows
63	- `medium` when likely behavior is wrong under realistic conditions
64	- `low` when risk is limited but still worth fixing before merge
65
66	## Comment Structure
67
68	- Start with the risk, not praise.
69	- Name the exact behavior at risk.
70	- Point to the file and line.
71	- Explain why the current diff is unsafe or incomplete.
72	- Suggest the minimal corrective direction when possible.
73
74	## Example Finding
75
76	```markdown
77	High: The new session guard treats a missing cache entry as "guest" even during token refresh, which can incorrectly revoke authenticated users during normal refresh windows. This path appears in `auth/middleware.ts` and does not have matching regression coverage.
78	```
79
80	## Review Questions
81
82	- What behavior changed?
83	- What assumptions does the change introduce?
84	- Where could the new logic be called unexpectedly?
85	- What happens on failure paths, not just the happy path?
86	- What tests prove the changed behavior?
87	- What edge case is still uncovered?
88
89	## Test Review Rules
90
91	- Do not trust "tests added" without reading what they assert.
92	- Check whether tests cover the risky branch or only the happy path.
93	- Check whether the test would have failed before the change.
94	- Note when the code change outscopes the tests.
95
96	## Anti-Patterns
97
98	- summarizing the PR without surfacing defects
99	- focusing on naming while skipping broken behavior
100	- making speculative comments with no evidence
101	- reviewing only one changed file in a large risky PR
102	- assuming CI passing means behavior is correct
103
104	## Connector And CLI Paths
105
106	- Use GitHub connector metadata and diff tools when available.
107	- Use `gh pr view`, `gh pr diff`, or local `git diff` when working from CLI.
108	- Prefer file-by-file patch review for large PRs.
109	- Read inline comment threads before duplicating the same concern.
110
111	## Output Contract
112
113	Return:
114
115	- numbered findings first
116	- each finding with severity and concise evidence
117	- open questions or assumptions second
118	- short overall summary last
119
120	## Example Review Skeleton
121
122	```markdown
123	1. High: ...
124	2. Medium: ...
125
126	Open questions:
127	- ...
128
129	Summary:
130	The PR is close, but the auth refresh path and missing regression coverage should be addressed before merge.
131	```
132
133	## Decision Rules
134
135	- If there are no findings, say so explicitly.
136	- If a concern is speculative, present it as an open question rather than a finding.
137	- If the diff is too large to fully trust, call out residual risk.
138	- If review scope is partial, say what you did and did not inspect.
139
140	## Common Failure Modes
141
142	- reviewing intent instead of actual code
143	- missing transitive risk in adjacent files
144	- underweighting missing tests
145	- overproducing nitpicks and hiding serious issues
146	- skipping residual risk when certainty is limited
147
148	## Recovery Moves
149
150	- Re-read the highest-risk file after forming a first opinion.
151	- Compare changed tests against changed production branches.
152	- Re-check assumptions against the actual code path.
153	- Col

People who liked this also viewed

6 picks

Type

github-code-review

132stars24forks

View on GitHub

How to install github-code-review?

alexai-mcp/hermes-ccc/github-code-review

$npx -y skills add AlexAI-MCP/hermes-CCC --skill github-code-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# GitHub Code Review
2
3	## Purpose
4
5	- Find real defects and risks before merge.
6	- Prioritize correctness, security, and regressions over style nits.
7	- Produce review comments that are concrete and defensible.
8	- Keep summaries brief and findings primary.
9	- Tie each concern to evidence in the diff.
10
11	## Activation Signals
12
13	- Use this skill when the user asks for a review.
14	- Use this skill when a PR must be audited before merge.
15	- Use this skill when code changes touch critical systems.
16	- Use this skill when a team needs structured findings with severity.
17	- Use this skill when review comments should map cleanly onto changed files.
18
19	## Review Order
20
21	1. Read PR metadata.
22	2. Read changed-file list.
23	3. Identify risky files first.
24	4. Read the diff with behavioral intent in mind.
25	5. Check tests and verification claims.
26	6. Produce findings ordered by severity.
27	7. Add a brief summary only after the findings.
28
29	## High-Risk Change Types
30
31	- auth or session logic
32	- data migrations
33	- concurrency changes
34	- caching invalidation
35	- payment or billing logic
36	- permission checks
37	- serialization or schema changes
38	- error handling rewrites
39
40	## Evidence Sources
41
42	- file diffs
43	- PR description
44	- CI status
45	- changed filenames
46	- related issue text
47	- existing review comments
48	- nearby tests
49
50	## Finding Categories
51
52	- correctness bug
53	- regression risk
54	- security issue
55	- missing validation
56	- missing test coverage
57	- maintainability risk
58	- performance regression
59
60	## Severity Guidelines
61
62	- `high` when merge could cause data loss, security exposure, or broken primary flows
63	- `medium` when likely behavior is wrong under realistic conditions
64	- `low` when risk is limited but still worth fixing before merge
65
66	## Comment Structure
67
68	- Start with the risk, not praise.
69	- Name the exact behavior at risk.
70	- Point to the file and line.
71	- Explain why the current diff is unsafe or incomplete.
72	- Suggest the minimal corrective direction when possible.
73
74	## Example Finding
75
76	```markdown
77	High: The new session guard treats a missing cache entry as "guest" even during token refresh, which can incorrectly revoke authenticated users during normal refresh windows. This path appears in `auth/middleware.ts` and does not have matching regression coverage.
78	```
79
80	## Review Questions
81
82	- What behavior changed?
83	- What assumptions does the change introduce?
84	- Where could the new logic be called unexpectedly?
85	- What happens on failure paths, not just the happy path?
86	- What tests prove the changed behavior?
87	- What edge case is still uncovered?
88
89	## Test Review Rules
90
91	- Do not trust "tests added" without reading what they assert.
92	- Check whether tests cover the risky branch or only the happy path.
93	- Check whether the test would have failed before the change.
94	- Note when the code change outscopes the tests.
95
96	## Anti-Patterns
97
98	- summarizing the PR without surfacing defects
99	- focusing on naming while skipping broken behavior
100	- making speculative comments with no evidence
101	- reviewing only one changed file in a large risky PR
102	- assuming CI passing means behavior is correct
103
104	## Connector And CLI Paths
105
106	- Use GitHub connector metadata and diff tools when available.
107	- Use `gh pr view`, `gh pr diff`, or local `git diff` when working from CLI.
108	- Prefer file-by-file patch review for large PRs.
109	- Read inline comment threads before duplicating the same concern.
110
111	## Output Contract
112
113	Return:
114
115	- numbered findings first
116	- each finding with severity and concise evidence
117	- open questions or assumptions second
118	- short overall summary last
119
120	## Example Review Skeleton
121
122	```markdown
123	1. High: ...
124	2. Medium: ...
125
126	Open questions:
127	- ...
128
129	Summary:
130	The PR is close, but the auth refresh path and missing regression coverage should be addressed before merge.
131	```
132
133	## Decision Rules
134
135	- If there are no findings, say so explicitly.
136	- If a concern is speculative, present it as an open question rather than a finding.
137	- If the diff is too large to fully trust, call out residual risk.
138	- If review scope is partial, say what you did and did not inspect.
139
140	## Common Failure Modes
141
142	- reviewing intent instead of actual code
143	- missing transitive risk in adjacent files
144	- underweighting missing tests
145	- overproducing nitpicks and hiding serious issues
146	- skipping residual risk when certainty is limited
147
148	## Recovery Moves
149
150	- Re-read the highest-risk file after forming a first opinion.
151	- Compare changed tests against changed production branches.
152	- Re-check assumptions against the actual code path.
153	- Col

People who liked this also viewed

6 picks

Type