The skills directory was getting disorganized — mlops alone had 40 skills in a flat list, and 12 categories were singletons with just one skill each. Code change: - prompt_builder.py: Support sub-categories in skill scanner. skills/mlops/training/axolotl/SKILL.md now shows as category 'mlops/training' instead of just 'mlops'. Backwards-compatible with existing flat structure. Split mlops (40 skills) into 7 sub-categories: - mlops/training (12): accelerate, axolotl, flash-attention, grpo-rl-training, peft, pytorch-fsdp, pytorch-lightning, simpo, slime, torchtitan, trl-fine-tuning, unsloth - mlops/inference (8): gguf, guidance, instructor, llama-cpp, obliteratus, outlines, tensorrt-llm, vllm - mlops/models (6): audiocraft, clip, llava, segment-anything, stable-diffusion, whisper - mlops/vector-databases (4): chroma, faiss, pinecone, qdrant - mlops/evaluation (5): huggingface-tokenizers, lm-evaluation-harness, nemo-curator, saelens, weights-and-biases - mlops/cloud (2): lambda-labs, modal - mlops/research (1): dspy Merged singleton categories: - gifs → media (gif-search joins youtube-content) - music-creation → media (heartmula, songsee) - diagramming → creative (excalidraw joins ascii-art) - ocr-and-documents → productivity - domain → research (domain-intel) - feeds → research (blogwatcher) - market-data → research (polymarket) Fixed misplaced skills: - mlops/code-review → software-development (not ML-specific) - mlops/ml-paper-writing → research (academic writing) Added DESCRIPTION.md files for all new/updated categories.
2.2 KiB
2.2 KiB
name, description
| name | description |
|---|---|
| code-review | Guidelines for performing thorough code reviews with security and quality focus |
Code Review Skill
Use this skill when reviewing code changes, pull requests, or auditing existing code.
Review Checklist
1. Security First
- No hardcoded secrets, API keys, or credentials
- Input validation on all user-provided data
- SQL queries use parameterized statements (no string concatenation)
- File operations validate paths (no path traversal)
- Authentication/authorization checks present where needed
2. Error Handling
- All external calls (API, DB, file) have try/catch
- Errors are logged with context (but no sensitive data)
- User-facing errors are helpful but don't leak internals
- Resources are cleaned up in finally blocks or context managers
3. Code Quality
- Functions do one thing and are reasonably sized (<50 lines ideal)
- Variable names are descriptive (no single letters except loops)
- No commented-out code left behind
- Complex logic has explanatory comments
- No duplicate code (DRY principle)
4. Testing Considerations
- Edge cases handled (empty inputs, nulls, boundaries)
- Happy path and error paths both work
- New code has corresponding tests (if test suite exists)
Review Response Format
When providing review feedback, structure it as:
## Summary
[1-2 sentence overall assessment]
## Critical Issues (Must Fix)
- Issue 1: [description + suggested fix]
- Issue 2: ...
## Suggestions (Nice to Have)
- Suggestion 1: [description]
## Questions
- [Any clarifying questions about intent]
Common Patterns to Flag
Python
# Bad: SQL injection risk
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
# Good: Parameterized query
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
JavaScript
// Bad: XSS risk
element.innerHTML = userInput;
// Good: Safe text content
element.textContent = userInput;
Tone Guidelines
- Be constructive, not critical
- Explain why something is an issue, not just what
- Offer solutions, not just problems
- Acknowledge good patterns you see