@schalkneethling/calavera-skill-code-review 0.2.0-next.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/calavera-artifact.json +11 -0
- package/package.json +24 -0
- package/payload/code-review/SKILL.md +89 -0
- package/payload/code-review/agents/openai.yaml +6 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2024 Schalk Neethling
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://calavera.schalkneethling.com/schemas/calavera-artifact.schema.json",
|
|
3
|
+
"schemaVersion": 1,
|
|
4
|
+
"id": "skill-code-review",
|
|
5
|
+
"type": "skill",
|
|
6
|
+
"displayName": "Code review",
|
|
7
|
+
"payload": "payload/code-review",
|
|
8
|
+
"compatibility": {
|
|
9
|
+
"calavera": ">=2.2.0 <3"
|
|
10
|
+
}
|
|
11
|
+
}
|
package/package.json
ADDED
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@schalkneethling/calavera-skill-code-review",
|
|
3
|
+
"version": "0.2.0-next.1",
|
|
4
|
+
"description": "Code review artifact for Calavera.",
|
|
5
|
+
"license": "MIT",
|
|
6
|
+
"repository": {
|
|
7
|
+
"type": "git",
|
|
8
|
+
"url": "git+ssh://git@github.com/schalkneethling/create-project-calavera.git",
|
|
9
|
+
"directory": "packages/artifacts/skill-code-review"
|
|
10
|
+
},
|
|
11
|
+
"files": [
|
|
12
|
+
"calavera-artifact.json",
|
|
13
|
+
"payload"
|
|
14
|
+
],
|
|
15
|
+
"type": "module",
|
|
16
|
+
"exports": {
|
|
17
|
+
".": "./calavera-artifact.json",
|
|
18
|
+
"./package.json": "./package.json"
|
|
19
|
+
},
|
|
20
|
+
"publishConfig": {
|
|
21
|
+
"access": "public",
|
|
22
|
+
"provenance": true
|
|
23
|
+
}
|
|
24
|
+
}
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: code-review
|
|
3
|
+
description: Review code changes for correctness, security, performance, accessibility, maintainability, tests, dependencies, design-system adherence, and localization. Use when the user asks for a code review, PR review, review of local changes, risk assessment, code quality feedback, or actionable findings before merge.
|
|
4
|
+
disable-model-invocation: true
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Code Review
|
|
8
|
+
|
|
9
|
+
Review code to catch issues the original engineer may have missed and to improve the codebase without creating unnecessary friction. Prioritize real risks over style noise.
|
|
10
|
+
|
|
11
|
+
## Review Workflow
|
|
12
|
+
|
|
13
|
+
1. Determine the review scope:
|
|
14
|
+
- Inspect `git status`, the relevant diff, and any user-specified files or PR context.
|
|
15
|
+
- Preserve unrelated user changes. Do not modify code unless the user asks for fixes.
|
|
16
|
+
- Identify whether the change is frontend, backend, library, CLI, infrastructure, docs, or mixed.
|
|
17
|
+
2. Check project context before judging:
|
|
18
|
+
- Frameworks and languages.
|
|
19
|
+
- Test tooling and CI coverage.
|
|
20
|
+
- Linting, formatting, type checking, and build scripts.
|
|
21
|
+
- Dependency management and lockfiles.
|
|
22
|
+
- Accessibility, localization, and design-system tooling when UI code is involved.
|
|
23
|
+
3. Review the change for material issues:
|
|
24
|
+
- Correctness: broken behavior, edge cases, data loss, error handling, and regressions.
|
|
25
|
+
- Security: injection risks, unsafe auth, secret handling, dependency risk, and permission scope.
|
|
26
|
+
- Performance and resources: unnecessary CPU, memory, network use, leaks, race conditions, deadlocks, async coordination, and missing back-pressure or throttling.
|
|
27
|
+
- Accessibility: semantic HTML, labels, keyboard support, focus management, ARIA misuse, and contrast.
|
|
28
|
+
- Maintainability: naming, structure, type safety, readability, duplication, and fit with local patterns.
|
|
29
|
+
- Tests and docs: missing coverage for new behavior, insufficient regression tests, and stale public docs.
|
|
30
|
+
- Dependencies: added packages, bundle/runtime impact, maintenance state, security posture, and whether built-in or existing project utilities would be enough.
|
|
31
|
+
- Design systems and branding: token usage, component reuse, theme consistency, and justified deviations.
|
|
32
|
+
- Localization: hard-coded UI strings, date/number formatting, translation keys, and future translation workflow.
|
|
33
|
+
4. Produce review feedback:
|
|
34
|
+
- Lead with findings, ordered by severity.
|
|
35
|
+
- Include file and line references for repo-local issues.
|
|
36
|
+
- Explain impact and give a concrete fix.
|
|
37
|
+
- Group repeated instances when one root cause explains them.
|
|
38
|
+
- Mark non-blocking refactors as follow-up suggestions, not merge blockers.
|
|
39
|
+
- If no issues are found, say so clearly and mention any residual test or tooling gaps.
|
|
40
|
+
|
|
41
|
+
## Context Skills
|
|
42
|
+
|
|
43
|
+
Load related skills only when the diff makes that domain relevant:
|
|
44
|
+
|
|
45
|
+
- Load `frontend-engineering` when reviewing markup-producing or style-producing code: HTML templates, JSX/TSX, Astro/Vue/Svelte components, Lit templates, Twig/ERB/Handlebars/Nunjucks, MDX, CSS, Sass/Less, CSS modules, scoped component styles, CSS-in-JS, or code that materially changes rendered HTML structure, selectors, layout, cascade, responsive behavior, colors, motion, or focus states.
|
|
46
|
+
|
|
47
|
+
For large or high-risk diffs, consider a focused specialist subagent for the relevant skill. Pass only the user request, relevant diff, surrounding component context, and known project conventions. Reconcile specialist feedback into one prioritized final review rather than forwarding it verbatim.
|
|
48
|
+
|
|
49
|
+
## Setup Deficiencies
|
|
50
|
+
|
|
51
|
+
If essential review infrastructure is missing, call it out early before deep findings:
|
|
52
|
+
|
|
53
|
+
- No runnable tests or tests absent from CI.
|
|
54
|
+
- No linting, formatting, type checking, or build validation for the changed area.
|
|
55
|
+
- Missing lockfile or unpinned dependencies.
|
|
56
|
+
- No dependency or supply-chain scanning for publishable/server code.
|
|
57
|
+
- No accessibility checks for UI-heavy changes.
|
|
58
|
+
- No i18n framework or translation process for localized UI.
|
|
59
|
+
- Missing design-system tokens/components when the project clearly depends on them.
|
|
60
|
+
|
|
61
|
+
When a setup deficiency would make the review noisy or unreliable, report the deficiency as the primary finding and then provide only the highest-confidence code findings.
|
|
62
|
+
|
|
63
|
+
## Feedback Standards
|
|
64
|
+
|
|
65
|
+
- Be direct, specific, and respectful. Focus on code and impact, never the author.
|
|
66
|
+
- Avoid nitpicks that an existing formatter or linter should handle.
|
|
67
|
+
- Prefer established local helpers, components, patterns, and style systems over new abstractions.
|
|
68
|
+
- Flag redundant implementations when the project already has an equivalent helper, component, CSS pattern, or service.
|
|
69
|
+
- Challenge clever but opaque code. Prefer readable control flow and well-named helpers.
|
|
70
|
+
- Encourage comments only for non-obvious decisions, tradeoffs, constraints, or nuanced behavior. Discourage comments that restate the code.
|
|
71
|
+
- Include positive feedback after findings when something is genuinely strong, such as clean tests, simple abstractions, or thoughtful design.
|
|
72
|
+
|
|
73
|
+
## Severity Guide
|
|
74
|
+
|
|
75
|
+
- `P0`: Must fix immediately. Security exploit, data loss, severe outage, or merge-blocking broken core behavior.
|
|
76
|
+
- `P1`: Should fix before merge. Likely bug, serious regression, accessibility blocker, unsafe dependency/auth pattern, or missing critical test.
|
|
77
|
+
- `P2`: Important but may be follow-up. Maintainability issue, incomplete edge coverage, performance concern, duplicate implementation, or design-system drift.
|
|
78
|
+
- `P3`: Optional improvement. Clarity, small refactor, documentation polish, or non-blocking suggestion.
|
|
79
|
+
|
|
80
|
+
## Output Shape
|
|
81
|
+
|
|
82
|
+
Use this order for review responses:
|
|
83
|
+
|
|
84
|
+
1. Findings, ordered by severity, with `file:line`.
|
|
85
|
+
2. Open questions or assumptions.
|
|
86
|
+
3. Brief positive notes, if useful.
|
|
87
|
+
4. Validation performed or not performed.
|
|
88
|
+
|
|
89
|
+
Keep summaries short. The findings are the review.
|