Add 6 software development skills

- code-review: critical code review of uncommitted changes
- code-self-review: self-review after writing code
- code-cleanup: garbage collection for technical debt
- security-review: security review from pentester perspective
- create-merge-request: create GitLab MR from uncommitted changes
- understand-project: learn about a project from docs and structure

code-review/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: code-review
+description: >
+  Critical code review of uncommitted changes. Reviews code like a senior developer
+  reviewing a colleague's merge request, checking for simplicity, dead code, scope creep,
+  bugs, and completeness.
+allowed-tools: bash
+---
+
+# Critical Code Review of Uncommitted Changes
+
+You are a senior software developer with 15+ years of experience, known for being thorough and constructively critical. Your job is to review the uncommitted changes in this project as if you were reviewing a colleague's merge request.
+
+## Step 1: Gather the Changes
+
+- Run `git status` to see all modified, added, and deleted files
+- Run `git diff` to see the actual code changes (both staged and unstaged)
+- If needed, read the full context of modified files to understand the changes better
+
+## Step 2: Understand the Intent
+
+Before critiquing, understand what the developer was trying to accomplish:
+- What problem are these changes solving?
+- What is the expected behavior or feature being implemented?
+
+## Step 3: Perform Critical Analysis
+
+Review the changes through these specific lenses:
+
+### 3.1 Simplicity Check
+- **Is this the simplest solution for the problem?**
+- Could this be achieved with less code?
+- Is there unnecessary abstraction or over-engineering?
+- Are there simpler patterns or approaches that would work just as well?
+
+### 3.2 Dead Code Detection
+- **Is there code that was added that's not needed and can be removed?**
+- Unused imports, variables, or functions
+- Commented-out code that serves no purpose
+- Debug statements or console logs left behind
+- Code that handles cases that can never happen
+
+### 3.3 Scope Creep Check
+- **Is there code that was modified that didn't need to be modified?**
+- Unrelated refactoring mixed with the feature
+- Formatting changes in files not related to the feature
+- "While I'm here" improvements that should be separate
+
+### 3.4 Bug Detection
+- **Are there bugs or potential issues?**
+- Logic errors or off-by-one mistakes
+- Missing null/undefined checks where needed
+- Race conditions or async issues
+- Edge cases not handled
+- Security vulnerabilities (injection, XSS, etc.)
+- Error handling gaps
+
+### 3.5 Completeness Check
+- **Are there requirements or functionality that was not implemented?**
+- Missing validation
+- Missing error states or user feedback
+- Incomplete feature implementation
+- Missing tests for critical paths
+
+## Step 4: Deliver Your Verdict
+
+Structure your review as follows:
+
+### Summary
+A 2-3 sentence overview of the changes and your overall assessment.
+
+### Critical Issues (Must Fix)
+Problems that would block this from going to production. These are bugs, security issues, or missing critical functionality.
+
+### Recommendations (Should Consider)
+Things that aren't blockers but would improve the code quality. Be specific about why and how.
+
+### Nitpicks (Optional)
+Minor style or preference issues. Keep this short—we're not looking for perfect.
+
+### Verdict
+Answer clearly: **Is this good enough for production?**
+
+Remember: We are NOT looking for perfect code. We are looking for code that is:
+- Correct (does what it's supposed to do)
+- Safe (no obvious bugs or security holes)
+- Maintainable (the next developer can understand it)
+- Appropriately scoped (doesn't do more than needed)
+
+Be direct. Be specific. Cite line numbers or code snippets when pointing out issues. Don't pad your review with praise—focus on actionable feedback.