SkillCheck validator, Cursor exports, and per-agent installers (#27)
Three more learnings from alirezarezvani/claude-skills, applied: 1. SkillCheck validator (scripts/skillcheck.mjs) — validates every SKILL.md against the authoring standard (frontmatter, name/folder match, trigger + produces clauses, required headings) plus tier referential integrity. Errors fail CI; --strict fails on warnings too. New skillcheck.yml workflow and a SkillCheck status badge in the README. Current: 0 errors / 14 advisory warnings across 172 skills. 2. Cursor export platform — build-exports.mjs now generates exports/cursor/<bundle>/<skill>/<skill>.mdc rule files. The PLATFORMS registry now supports per-skill filenames (file as a function). 3. Per-agent installers — scripts/install.sh unifies install for claude/hermes/codex/openclaw/cursor (--link, --target, --dry-run, --list). Curl-able one-liners codex-install.sh, openclaw-install.sh, and cursor-install.sh clone the library and install in a single command. README documents the one-line installs and Cursor exports; CHANGELOG and the authoring standard updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
mohitagw15856
GitHub
@@ -0,0 +1,123 @@
|
||||
---
|
||||
description: "Generate a tailored code review checklist for any pull request based on the language, type of change, and risk level. Use when asked to review code, check a PR, review a pull request, or generate a code review checklist. Produces a focused checklist with language-specific checks, risk-level-appropriate depth, and a clear approve/request-changes recommendation."
|
||||
globs:
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# Code Review Checklist Skill
|
||||
|
||||
Produces a tailored code review checklist for a specific pull request — scaled to the language, type of change, and risk level. Not a generic template.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Language and framework** (e.g. TypeScript + React / Python + FastAPI / Go)
|
||||
- **Type of change** (feature / bug fix / refactor / dependency upgrade / security patch / performance)
|
||||
- **Risk level** (low / medium / high / critical)
|
||||
- **PR description** (paste the description or link to the PR)
|
||||
- **Code or diff** (optional — paste key changed files or a `git diff`; significantly improves checklist specificity)
|
||||
- **Author context** (new starter / experienced / external contributor)
|
||||
|
||||
## Output Format
|
||||
|
||||
---
|
||||
|
||||
# Code Review: [PR Title or Reference]
|
||||
|
||||
### 1. PR Overview
|
||||
**Scope assessment:** [Small / Medium / Large / Too large — should be split]
|
||||
**Recommended review depth:** [Skim / Standard / Deep dive]
|
||||
**Estimated review time:** [e.g. 20–30 min — use 5 min per 50 lines of diff as a rough guide]
|
||||
|
||||
### 2. Correctness Checks
|
||||
|
||||
Language-specific correctness checks — choose based on the language stated:
|
||||
|
||||
**For TypeScript/JavaScript:**
|
||||
- Type definitions match actual usage
|
||||
- No implicit `any` in non-test code
|
||||
- Async/await used consistently; no unhandled promises
|
||||
- Null/undefined handling is explicit
|
||||
|
||||
**For Python:**
|
||||
- Type hints present on public functions
|
||||
- Exception handling is specific (no bare except)
|
||||
- Resources are closed (context managers, with blocks)
|
||||
|
||||
**For Go:**
|
||||
- Errors are handled or explicitly ignored with a comment
|
||||
- Context propagation is correct
|
||||
- Goroutine lifetimes are bounded
|
||||
|
||||
[Include only the section matching the stated language]
|
||||
|
||||
### 3. Change-Type-Specific Checks
|
||||
|
||||
**For bug fixes:**
|
||||
- A test exists that would have caught this bug
|
||||
- The fix addresses root cause, not symptom
|
||||
- Related code paths checked for the same issue
|
||||
|
||||
**For features:**
|
||||
- Acceptance criteria met
|
||||
- Edge cases handled (empty, large, concurrent)
|
||||
- Error paths tested, not just happy path
|
||||
- Telemetry/logging added for debugging
|
||||
|
||||
**For refactors:**
|
||||
- Behaviour unchanged (tests still pass)
|
||||
- No scope creep — refactor only
|
||||
- Complexity reduced, not just moved
|
||||
|
||||
**For dependency upgrades:**
|
||||
- Breaking changes reviewed
|
||||
- Security advisories checked
|
||||
- License compatibility verified
|
||||
|
||||
[Include only the section matching the stated change type]
|
||||
|
||||
### 4. Risk-Appropriate Checks
|
||||
|
||||
**Low risk:** basic correctness, style conventions, test coverage
|
||||
**Medium risk:** above + rollback plan, monitoring updates, performance considerations
|
||||
**High risk:** above + security implications, data migration safety, feature flag/gradual rollout
|
||||
**Critical risk:** above + staging validation plan, incident response plan, post-deploy verification checklist
|
||||
|
||||
### 5. Testing Adequacy
|
||||
- Unit tests cover new logic
|
||||
- Integration tests cover the contract changes
|
||||
- Edge cases tested
|
||||
- Failure modes tested
|
||||
- Performance tests if performance-sensitive
|
||||
|
||||
### 6. Review Decision Framework
|
||||
|
||||
**Approve if:** [2-3 specific conditions based on this PR]
|
||||
**Request changes if:** [Specific blockers]
|
||||
**Comment (non-blocking) if:** [Items worth discussing but not blocking merge]
|
||||
|
||||
### 7. Common Pitfalls for This Change Type
|
||||
Based on the change type and language, flag 2-3 things reviewers typically miss for this combination.
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Checklist is tailored to the stated language (not generic)
|
||||
- [ ] Change-type-specific section is included
|
||||
- [ ] Risk-appropriate depth matches stated risk level
|
||||
- [ ] Decision framework includes at least one named blocking condition and one named non-blocking comment condition
|
||||
- [ ] Common pitfalls are specific to the stated language + change-type combo (not generic advice like "watch out for bugs")
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not generate a generic checklist that ignores the stated language — a Python checklist and a Go checklist have fundamentally different correctness concerns
|
||||
- [ ] Do not treat "looks fine" as a valid review outcome — the checklist exists to surface specific concerns, not validate a superficial read
|
||||
- [ ] Do not scope a "high risk" review the same as a "low risk" review — depth must scale with the stated risk level
|
||||
- [ ] Do not flag every stylistic preference as a blocking issue — distinguish between blocking correctness issues and non-blocking comments
|
||||
- [ ] Do not skip the "common pitfalls" section for the stated language and change-type combination — this is where the most valuable knowledge lives
|
||||
|
||||
## Usage Examples
|
||||
- "Generate a code review checklist for [PR description]"
|
||||
- "What should I check in this pull request?"
|
||||
- "Give me a code review checklist for a [language] [change type]"
|
||||
- "Review checklist for a high-risk PR in [language]"
|
||||
Reference in New Issue
Block a user