@vodailoc/kilo-kit-mcp 1.1.0 → 1.1.1

package/skills/kilo-kit/quality/code-review/SKILL.md

@@ -1,297 +1,297 @@
----
-name: code-review
-description: >-
-  Comprehensive code review checklist and methodology.
-  Use when reviewing PRs, conducting code audits, or assessing code quality.
-  Keywords: review, PR, code review, audit, assess, quality, check
-version: 1.0.0
-behaviors: [read_file, reason, validate]
-dependencies: []
-token_estimate:
-  min: 1000
-  typical: 2500
-  max: 5000
----
-
-# 👁️ Code Review Skill
-
-> **Philosophy:** Code review is collaboration, not criticism.
-
-## When to Use
-
-Use this skill when:
-- Reviewing a Pull Request
-- Conducting a code audit
-- Assessing code quality before merge
-- Mentoring through code feedback
-- Preparing code for production
-
-**Do NOT use this skill when:**
-- Just need to run linter
-- Simple typo fix
-- Automated formatting changes only
-
----
-
-## Prerequisites
-
-Before starting review:
-- [ ] Understand the purpose/goal of the change
-- [ ] Have context on the project architecture
-- [ ] Know the coding standards for the project
-- [ ] Can run the code locally (if needed)
-
----
-
-## Process
-
-### Phase 1: CONTEXT UNDERSTANDING 📋
-
-**Goal:** Understand WHAT and WHY before HOW.
-
-**Steps:**
-
-1. **Read the PR Description**
-   - What problem does this solve?
-   - What approach was taken?
-   - Are there any caveats noted?
-
-2. **Check Related Issues**
-   - Link to issue/ticket
-   - Requirements met?
-   - Edge cases addressed?
-
-3. **Assess Scope**
-   - How many files changed?
-   - Is this focused or sprawling?
-   - Should this be multiple PRs?
-
-**Output:** Clear understanding of change purpose.
-
----
-
-### Phase 2: HIGH-LEVEL REVIEW 🔭
-
-**Goal:** Evaluate architecture and design decisions.
-
-**Checklist:**
-
-```
-DESIGN
-□ Does the solution make sense?
-□ Is this the right place for this code?
-□ Does it follow project patterns?
-□ Is it over-engineered?
-□ Is it under-engineered?
-
-ARCHITECTURE
-□ Proper separation of concerns?
-□ Dependencies going the right direction?
-□ New dependencies justified?
-□ Breaking any architectural boundaries?
-
-SCOPE
-□ Does change match stated purpose?
-□ Any scope creep?
-□ Any missing pieces?
-```
-
-**Output:** Assessment of overall approach.
-
----
-
-### Phase 3: LINE-BY-LINE REVIEW 🔍
-
-**Goal:** Examine code quality and correctness.
-
-**Checklist:**
-
-```
-CORRECTNESS
-□ Logic is correct
-□ Edge cases handled
-□ Error cases handled
-□ Null/undefined handled
-□ No off-by-one errors
-□ Concurrency issues addressed
-
-QUALITY
-□ Clear variable/function names
-□ Single responsibility principle
-□ DRY (no unnecessary duplication)
-□ Comments explain WHY, not WHAT
-□ No dead code
-□ No commented-out code
-□ No TODOs without tracking
-
-SECURITY
-□ Input validation
-□ No SQL injection risks
-□ No XSS risks
-□ Secrets not hardcoded
-□ Proper authentication checks
-□ Authorization verified
-
-PERFORMANCE
-□ No obvious N+1 queries
-□ Appropriate caching
-□ No blocking operations where async needed
-□ Large data sets handled efficiently
-```
-
-**Output:** Detailed feedback on code quality.
-
----
-
-### Phase 4: TESTING REVIEW 🧪
-
-**Goal:** Ensure adequate test coverage.
-
-**Checklist:**
-
-```
-TEST PRESENCE
-□ Tests added for new functionality?
-□ Tests updated for modified functionality?
-□ Test file naming consistent?
-
-TEST QUALITY
-□ Tests are meaningful (not just coverage)?
-□ Edge cases tested?
-□ Error cases tested?
-□ Tests are independent/isolated?
-□ No flaky tests introduced?
-
-TEST COVERAGE
-□ Happy path covered?
-□ Unhappy path covered?
-□ Boundary conditions covered?
-```
-
-**Output:** Assessment of test adequacy.
-
----
-
-### Phase 5: FINAL CHECKS ✅
-
-**Goal:** Ensure readiness for merge.
-
-**Checklist:**
-
-```
-DOCUMENTATION
-□ README updated if needed?
-□ API docs updated if needed?
-□ Inline comments sufficient?
-□ Migration guide if breaking changes?
-
-OPERATIONAL
-□ Logs added for debugging?
-□ Metrics/monitoring considered?
-□ Feature flags if needed?
-□ Rollback plan if needed?
-
-MERGE READINESS
-□ CI passes?
-□ No merge conflicts?
-□ Approved by required reviewers?
-□ All conversations resolved?
-```
-
-**Output:** Clear approve/request changes decision.
-
----
-
-## Review Comment Guidelines
-
-### Categorize Your Comments
-
-| Prefix | Meaning | Action Required |
-|--------|---------|-----------------|
-| `🔴 BLOCKER:` | Must fix before merge | Yes, mandatory |
-| `🟡 SUGGESTION:` | Should consider | Recommended |
-| `🟢 NIT:` | Minor, optional | No |
-| `❓ QUESTION:` | Need clarification | Response needed |
-| `💡 IDEA:` | Future improvement | No |
-| `👍 PRAISE:` | Great work! | No |
-
-### Example Comments
-
-**Good:**
-```
-🔴 BLOCKER: This SQL query is vulnerable to injection.
-Use parameterized queries instead:
-`db.query("SELECT * FROM users WHERE id = ?", [userId])`
-```
-
-**Bad:**
-```
-This is wrong.
-```
-
-### Tone Guidelines
-
-- ✅ "Consider using X because Y"
-- ✅ "What happens if Z is null?"
-- ✅ "Great use of pattern X!"
-- ❌ "This is stupid"
-- ❌ "Obviously you should..."
-- ❌ "Why didn't you just..."
-
----
-
-## Common Issues to Watch For
-
-### Security Issues
-
-| Issue | Detection | Solution |
-|-------|-----------|----------|
-| SQL Injection | String concatenation in queries | Parameterized queries |
-| XSS | Unescaped user input in HTML | Proper escaping/encoding |
-| Hardcoded secrets | API keys in code | Environment variables |
-| Missing auth | Endpoints without checks | Add auth middleware |
-
-### Performance Issues
-
-| Issue | Detection | Solution |
-|-------|-----------|----------|
-| N+1 queries | Loop with DB calls | Batch/eager loading |
-| Missing index | Slow queries on large tables | Add database index |
-| Blocking I/O | Sync calls in async context | Use async/await |
-| Memory leak | Unbounded caches/listeners | Cleanup/limits |
-
-### Code Quality Issues
-
-| Issue | Detection | Solution |
-|-------|-----------|----------|
-| God function | 100+ lines, many responsibilities | Break into smaller functions |
-| Magic numbers | `if (status === 3)` | Named constants |
-| Deep nesting | 4+ levels of if/for | Early returns, extraction |
-| Copy-paste code | Similar blocks repeated | Extract utility function |
-
----
-
-## Success Criteria
-
-Before approving:
-
-- [ ] I understand what this code does and why
-- [ ] The approach is appropriate for the problem
-- [ ] Code is correct and handles edge cases
-- [ ] Code is secure (no obvious vulnerabilities)
-- [ ] Tests are adequate and meaningful
-- [ ] Code is readable and maintainable
-- [ ] No blocking issues remain
-- [ ] All my questions have been answered
-
----
-
-## Related Skills
-
-- `skills/kilo-kit/quality/testing/` - For test quality guidance
-- `skills/kilo-kit/development/security/` - For security review
-- `skills/kilo-kit/debugging/systematic/` - If bugs found during review
-
----
-
-*Code Review Skill v1.0.0 — Collaboration, not criticism*
+---
+name: code-review
+description: >-
+  Comprehensive code review checklist and methodology.
+  Use when reviewing PRs, conducting code audits, or assessing code quality.
+  Keywords: review, PR, code review, audit, assess, quality, check
+version: 1.0.0
+behaviors: [read_file, reason, validate]
+dependencies: []
+token_estimate:
+  min: 1000
+  typical: 2500
+  max: 5000
+---
+
+# 👁️ Code Review Skill
+
+> **Philosophy:** Code review is collaboration, not criticism.
+
+## When to Use
+
+Use this skill when:
+- Reviewing a Pull Request
+- Conducting a code audit
+- Assessing code quality before merge
+- Mentoring through code feedback
+- Preparing code for production
+
+**Do NOT use this skill when:**
+- Just need to run linter
+- Simple typo fix
+- Automated formatting changes only
+
+---
+
+## Prerequisites
+
+Before starting review:
+- [ ] Understand the purpose/goal of the change
+- [ ] Have context on the project architecture
+- [ ] Know the coding standards for the project
+- [ ] Can run the code locally (if needed)
+
+---
+
+## Process
+
+### Phase 1: CONTEXT UNDERSTANDING 📋
+
+**Goal:** Understand WHAT and WHY before HOW.
+
+**Steps:**
+
+1. **Read the PR Description**
+   - What problem does this solve?
+   - What approach was taken?
+   - Are there any caveats noted?
+
+2. **Check Related Issues**
+   - Link to issue/ticket
+   - Requirements met?
+   - Edge cases addressed?
+
+3. **Assess Scope**
+   - How many files changed?
+   - Is this focused or sprawling?
+   - Should this be multiple PRs?
+
+**Output:** Clear understanding of change purpose.
+
+---
+
+### Phase 2: HIGH-LEVEL REVIEW 🔭
+
+**Goal:** Evaluate architecture and design decisions.
+
+**Checklist:**
+
+```
+DESIGN
+□ Does the solution make sense?
+□ Is this the right place for this code?
+□ Does it follow project patterns?
+□ Is it over-engineered?
+□ Is it under-engineered?
+
+ARCHITECTURE
+□ Proper separation of concerns?
+□ Dependencies going the right direction?
+□ New dependencies justified?
+□ Breaking any architectural boundaries?
+
+SCOPE
+□ Does change match stated purpose?
+□ Any scope creep?
+□ Any missing pieces?
+```
+
+**Output:** Assessment of overall approach.
+
+---
+
+### Phase 3: LINE-BY-LINE REVIEW 🔍
+
+**Goal:** Examine code quality and correctness.
+
+**Checklist:**
+
+```
+CORRECTNESS
+□ Logic is correct
+□ Edge cases handled
+□ Error cases handled
+□ Null/undefined handled
+□ No off-by-one errors
+□ Concurrency issues addressed
+
+QUALITY
+□ Clear variable/function names
+□ Single responsibility principle
+□ DRY (no unnecessary duplication)
+□ Comments explain WHY, not WHAT
+□ No dead code
+□ No commented-out code
+□ No TODOs without tracking
+
+SECURITY
+□ Input validation
+□ No SQL injection risks
+□ No XSS risks
+□ Secrets not hardcoded
+□ Proper authentication checks
+□ Authorization verified
+
+PERFORMANCE
+□ No obvious N+1 queries
+□ Appropriate caching
+□ No blocking operations where async needed
+□ Large data sets handled efficiently
+```
+
+**Output:** Detailed feedback on code quality.
+
+---
+
+### Phase 4: TESTING REVIEW 🧪
+
+**Goal:** Ensure adequate test coverage.
+
+**Checklist:**
+
+```
+TEST PRESENCE
+□ Tests added for new functionality?
+□ Tests updated for modified functionality?
+□ Test file naming consistent?
+
+TEST QUALITY
+□ Tests are meaningful (not just coverage)?
+□ Edge cases tested?
+□ Error cases tested?
+□ Tests are independent/isolated?
+□ No flaky tests introduced?
+
+TEST COVERAGE
+□ Happy path covered?
+□ Unhappy path covered?
+□ Boundary conditions covered?
+```
+
+**Output:** Assessment of test adequacy.
+
+---
+
+### Phase 5: FINAL CHECKS ✅
+
+**Goal:** Ensure readiness for merge.
+
+**Checklist:**
+
+```
+DOCUMENTATION
+□ README updated if needed?
+□ API docs updated if needed?
+□ Inline comments sufficient?
+□ Migration guide if breaking changes?
+
+OPERATIONAL
+□ Logs added for debugging?
+□ Metrics/monitoring considered?
+□ Feature flags if needed?
+□ Rollback plan if needed?
+
+MERGE READINESS
+□ CI passes?
+□ No merge conflicts?
+□ Approved by required reviewers?
+□ All conversations resolved?
+```
+
+**Output:** Clear approve/request changes decision.
+
+---
+
+## Review Comment Guidelines
+
+### Categorize Your Comments
+
+| Prefix | Meaning | Action Required |
+|--------|---------|-----------------|
+| `🔴 BLOCKER:` | Must fix before merge | Yes, mandatory |
+| `🟡 SUGGESTION:` | Should consider | Recommended |
+| `🟢 NIT:` | Minor, optional | No |
+| `❓ QUESTION:` | Need clarification | Response needed |
+| `💡 IDEA:` | Future improvement | No |
+| `👍 PRAISE:` | Great work! | No |
+
+### Example Comments
+
+**Good:**
+```
+🔴 BLOCKER: This SQL query is vulnerable to injection.
+Use parameterized queries instead:
+`db.query("SELECT * FROM users WHERE id = ?", [userId])`
+```
+
+**Bad:**
+```
+This is wrong.
+```
+
+### Tone Guidelines
+
+- ✅ "Consider using X because Y"
+- ✅ "What happens if Z is null?"
+- ✅ "Great use of pattern X!"
+- ❌ "This is stupid"
+- ❌ "Obviously you should..."
+- ❌ "Why didn't you just..."
+
+---
+
+## Common Issues to Watch For
+
+### Security Issues
+
+| Issue | Detection | Solution |
+|-------|-----------|----------|
+| SQL Injection | String concatenation in queries | Parameterized queries |
+| XSS | Unescaped user input in HTML | Proper escaping/encoding |
+| Hardcoded secrets | API keys in code | Environment variables |
+| Missing auth | Endpoints without checks | Add auth middleware |
+
+### Performance Issues
+
+| Issue | Detection | Solution |
+|-------|-----------|----------|
+| N+1 queries | Loop with DB calls | Batch/eager loading |
+| Missing index | Slow queries on large tables | Add database index |
+| Blocking I/O | Sync calls in async context | Use async/await |
+| Memory leak | Unbounded caches/listeners | Cleanup/limits |
+
+### Code Quality Issues
+
+| Issue | Detection | Solution |
+|-------|-----------|----------|
+| God function | 100+ lines, many responsibilities | Break into smaller functions |
+| Magic numbers | `if (status === 3)` | Named constants |
+| Deep nesting | 4+ levels of if/for | Early returns, extraction |
+| Copy-paste code | Similar blocks repeated | Extract utility function |
+
+---
+
+## Success Criteria
+
+Before approving:
+
+- [ ] I understand what this code does and why
+- [ ] The approach is appropriate for the problem
+- [ ] Code is correct and handles edge cases
+- [ ] Code is secure (no obvious vulnerabilities)
+- [ ] Tests are adequate and meaningful
+- [ ] Code is readable and maintainable
+- [ ] No blocking issues remain
+- [ ] All my questions have been answered
+
+---
+
+## Related Skills
+
+- `skills/kilo-kit/quality/testing/` - For test quality guidance
+- `skills/kilo-kit/development/security/` - For security review
+- `skills/kilo-kit/debugging/systematic/` - If bugs found during review
+
+---
+
+*Code Review Skill v1.0.0 — Collaboration, not criticism*