2026-03-03 16:35:54 +01:00
parent 8d81818ad4
commit e3cdcfc419
6 changed files with 454 additions and 0 deletions
@@ -0,0 +1,80 @@
---
name: code-cleanup
description: >
  Garbage collection for codebases. Clean up technical debt and entropy by removing dead code,
  finding duplication, reducing unnecessary complexity, and cleaning up stale comments.
  Strictly behavior-preserving.
allowed-tools: bash
argument-hint: "[file, directory, or 'all']"
---
# Garbage Collection — Clean Up Technical Debt
You are performing a focused cleanup pass on the codebase. Your goal is to reduce entropy and technical debt by removing what's not needed and simplifying what's left. This is strictly a behavior-preserving operation — nothing should work differently after your changes.
## Scope
Determine what to review:
- If the user provided a file or directory as $ARGUMENTS, focus on that
- If the user passed "all", review the main source directories of the project
- If nothing was provided, ask the user what to target
## Analysis
Go through the target files carefully and check for the following:
### 1. Dead Code
- **Unused functions, methods, classes, or variables** — defined but never called or referenced
- **Unused imports** — imported but never used in the file
- **Dead exports** — exported from a module but never imported anywhere else in the project
- **Commented-out code** — old code left in comments that serves no purpose
- **Dead dependencies** — packages in dependency files (package.json, requirements.txt, go.mod, etc.) that are installed but never imported anywhere in the codebase
### 2. Duplication and Pattern Inconsistency
- **Duplicated logic** — similar or identical code blocks that could be consolidated into a single function or utility
- **Inconsistent patterns** — different ways of doing the same thing across the codebase:
  - Import styles (default vs named, relative vs absolute paths)
  - How external services/APIs are called (direct fetch vs wrapper, different HTTP clients)
  - Error handling approaches (try/catch vs .catch, different error formats)
  - Logging patterns (different loggers, inconsistent log levels or formats)
  - Configuration access (env vars read directly vs config module)
- Identify which pattern is the dominant/preferred one and flag the outliers
### 3. Unnecessary Complexity
- **Over-abstraction** — wrapper classes, factories, or patterns that add indirection without adding value
- **Premature generalization** — code built to handle cases that don't exist and may never exist
- **Overly clever code** — complex one-liners or convoluted logic that could be written more simply
- **Unnecessary intermediate variables, transformations, or layers**
- **Functions that do too much** — could be simplified by removing responsibilities that don't belong
### 4. Stale Comments and TODOs
- **Outdated comments** — comments that describe behavior the code no longer has
- **Stale TODOs** — TODO/FIXME/HACK comments referencing old issues, completed work, or things no longer relevant
- **Redundant comments** — comments that just restate what the code obviously does
## Report
Present your findings organized by confidence:
### Safe to Remove
Items that are clearly dead or unused. No risk of breakage.
### Simplify
Code that works but is more complex than it needs to be. Include a brief description of how to simplify it.
### Inconsistent Patterns
List each inconsistency found, which pattern is dominant, and which files are the outliers.
### Verify Before Removing
Items that appear unused but might be referenced dynamically, via reflection, or from outside the codebase (e.g., API endpoints, CLI handlers, template references). These need manual verification.
## Important Constraints
- **This is behavior-preserving only.** Do not change how anything works.
- **Do not refactor for style.** Formatting and naming conventions are not in scope unless they are part of a pattern inconsistency.
- **Present findings first.** Do not make any changes until the user reviews and approves.
- **Be specific.** Include file names, line numbers, and code snippets for every finding.
@@ -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.
@@ -0,0 +1,64 @@
---
name: code-self-review
description: >
  Review your own work for improvements. Step back and critically evaluate code you just
  wrote, checking for simplicity, dead code, cleanup opportunities, and missing pieces.
---
# Self-Review Your Work
Now that you have written the code, take a step back and critically evaluate your own work. Pretend you're reviewing someone else's code with fresh eyes.
## Step 1: Review What You Wrote
Go through all the changes you made in this session:
- Run `git diff` to see the uncommitted changes
- Re-read the code you wrote or modified
- Look at each file you touched
## Step 2: Ask Yourself These Questions
### Could this be simpler?
- Is there a more straightforward way to achieve the same result?
- Did you over-engineer or add unnecessary abstraction?
- Are there complex patterns that could be replaced with simpler ones?
- Could any functions be shorter or more focused?
### Is there code that's no longer needed?
- Did you write helper functions that ended up unused?
- Are there variables, imports, or constants that aren't being used?
- Did you leave any debug statements, console logs, or commented code?
- Did earlier iterations leave behind dead code?
### Can anything be cleaned up?
- Are there inconsistent naming conventions?
- Is there duplicated code that could be consolidated?
- Are there magic numbers or strings that should be constants?
- Could the code be better organized or structured?
### Is anything missing?
- Look back at the original task or implementation plan
- Did you implement everything that was requested?
- Are there edge cases you discussed but didn't handle?
- Did you skip any error handling or validation?
- Are there TODOs you left that should be addressed now?
## Step 3: Report Your Findings
Provide an honest assessment:
### Things I Would Improve
List specific changes you'd make, with file names and descriptions.
### Code to Remove
Any unnecessary code you spotted that should be deleted.
### Missing Pieces
Anything from the original plan that still needs to be implemented.
### Overall Assessment
Is the code in a good state, or does it need more work before it's ready?
---
After this review, ask if the user wants you to make any of the identified improvements.
@@ -0,0 +1,62 @@
---
name: create-merge-request
description: >
  Create a GitLab Merge Request from uncommitted changes. Automatically creates a feature
  branch, organizes changes into logical commits, pushes to remote, and opens an MR.
allowed-tools: bash
argument-hint: "[branch-name] [optional: description]"
---
# Create a GitLab Merge Request from Uncommitted Changes
You are tasked with creating a GitLab Merge Request (MR) from the current uncommitted changes in the working directory.
## Steps to Follow
### 1. Analyze the Current State
- Run `git status` to see all uncommitted changes (staged and unstaged)
- Run `git diff` to understand what has been modified
- Identify the default branch (check if it's `main` or `master`)
### 2. Create a New Feature Branch
- Create and checkout a new branch with a descriptive name
- If the user provided a branch name as $1, use that
- Otherwise, derive a meaningful branch name from the changes (e.g., `feature/add-user-authentication`, `fix/login-validation-bug`)
- Use the format: `<type>/<short-description>` where type is one of: feature, fix, refactor, docs, chore
### 3. Organize and Commit Changes Logically
- Group related changes into logical, atomic commits
- Each commit should represent a single logical change
- Write clear, conventional commit messages following this format:
  ```
  <type>(<scope>): <description>
  [optional body explaining what and why]
  ```
- Types: feat, fix, refactor, docs, style, test, chore
- If all changes are related, a single well-described commit is acceptable
- Stage and commit the changes appropriately
### 4. Push the Branch to Remote
- Push the new branch to the GitLab remote: `git push -u origin <branch-name>`
### 5. Create the Merge Request
- Use the GitLab CLI (`glab`) to create the merge request
- Target the default branch (main or master)
- Command: `glab mr create --target-branch <default-branch> --title "<title>" --description "<description>"`
- The title should summarize the changes concisely
- The description should include:
  - A summary of what the MR accomplishes
  - List of key changes made
  - Any relevant context or notes
- If the user provided a description as $ARGUMENTS (after the branch name), incorporate it
### 6. Report the Result
- Display the MR URL for easy access
- Summarize what was done (branch created, commits made, MR opened)
## Important Notes
- Do NOT force push or use destructive git operations
- Ensure all changes are properly staged before committing
- If there are no uncommitted changes, inform the user and stop
- If `glab` CLI is not installed, inform the user how to install it
@@ -0,0 +1,96 @@
---
name: security-review
description: >
  Security review from a pentester perspective. Analyzes code for injection vulnerabilities,
  authentication issues, data exposure, input handling flaws, misconfigurations, and
  cryptography weaknesses.
allowed-tools: bash
argument-hint: "[optional: feature or area to focus on]"
---
# Security Review
You are a senior security pentester with extensive experience in application security. Your job is to review code for security vulnerabilities—not to nitpick, but to catch issues that could be exploited in production.
## What to Review
If the user provided a specific feature or area to focus on via $ARGUMENTS:
- Focus your review on that specific feature or area
- Read the relevant files and understand the implementation
If no specific focus was provided:
- Run `git diff` to see uncommitted changes
- Review all modified and added code for security issues
## Security Analysis
Analyze the code through these security lenses:
### Injection Vulnerabilities
- **SQL Injection**: Is user input properly parameterized in database queries?
- **Command Injection**: Is user input passed to shell commands or system calls?
- **Code Injection**: Is user input evaluated as code (eval, exec, etc.)?
- **LDAP/XPath Injection**: Is user input used in LDAP or XPath queries?
### Authentication & Authorization
- **Broken Authentication**: Weak password policies, session issues, credential exposure?
- **Broken Access Control**: Can users access resources they shouldn't? Missing permission checks?
- **Privilege Escalation**: Can a user elevate their privileges?
- **Insecure Direct Object References**: Can users access other users' data by manipulating IDs?
### Data Exposure
- **Sensitive Data in Logs**: Are passwords, tokens, or PII being logged?
- **Sensitive Data in Responses**: Is the API returning more data than necessary?
- **Hardcoded Secrets**: Are API keys, passwords, or tokens hardcoded?
- **Insecure Storage**: Is sensitive data stored without encryption?
### Input Handling
- **Cross-Site Scripting (XSS)**: Is user input properly escaped before rendering?
- **Path Traversal**: Can user input manipulate file paths (../, etc.)?
- **Deserialization**: Is untrusted data being deserialized unsafely?
- **File Upload**: Are uploaded files validated and stored safely?
### Security Misconfigurations
- **CORS Issues**: Is CORS configured too permissively?
- **Missing Security Headers**: CSP, X-Frame-Options, etc.?
- **Debug Mode in Production**: Are debug features exposed?
- **Default Credentials**: Are default passwords or keys in use?
### Cryptography
- **Weak Algorithms**: MD5, SHA1 for security purposes, weak ciphers?
- **Poor Randomness**: Using predictable random number generation for security?
- **Missing Encryption**: Is data that should be encrypted being sent in plaintext?
## Severity Classification
Rate each finding:
- **CRITICAL**: Easily exploitable, severe impact (RCE, auth bypass, data breach)
- **HIGH**: Exploitable with moderate effort, significant impact
- **MEDIUM**: Requires specific conditions, limited impact (mention briefly)
- **LOW/INFO**: Skip these—we're not looking for perfection
## Report Format
### Executive Summary
One paragraph: What did you review and what's the overall security posture?
### Critical Findings
Issues that must be fixed before production. Include:
- What the vulnerability is
- Where it is (file and line number)
- How it could be exploited
- How to fix it
### High Severity Findings
Serious issues that should be addressed. Same format as above.
### Notable Observations
Brief mentions of medium-severity issues or areas that warrant attention but aren't blocking.
### Verdict
Is this code **secure enough for production** from a security standpoint?
---
Remember: We want production-ready, not paranoid. Focus on real, exploitable vulnerabilities—not theoretical risks that require unrealistic attack scenarios.
@@ -0,0 +1,62 @@
---
name: understand-project
description: >
  Learn about a project from its docs, README, and structure. Provides a quick overview
  of the tech stack, project structure, how to run it, and key conventions.
---
# Understand This Project
Take a moment to familiarize yourself with this project before doing any work. Your goal is to build context so you can assist effectively.
## Step 1: Find and Read Documentation
Look for and read the following files (if they exist):
### Primary Documentation
- `README.md` or `README` (any case variation)
- `docs/` directory - read key files inside
- `CONTRIBUTING.md` - contribution guidelines
- `ARCHITECTURE.md` or `docs/architecture.md` - system design
### Configuration Files (skim for context)
- `package.json`, `Cargo.toml`, `pyproject.toml`, `go.mod` - understand dependencies and project type
- `.env.example` or `.env.sample` - understand required configuration
- `Makefile`, `justfile`, or similar - understand available commands
### Additional Context
- `CHANGELOG.md` - recent changes and version history
- `.claude/` directory - any project-specific Claude instructions
## Step 2: Understand the Structure
Get a high-level view of the project structure:
- What are the main directories and their purposes?
- What language(s) and framework(s) is this project using?
- What's the entry point of the application?
## Step 3: Report Back
Once you've gathered context, provide a brief summary:
### Project Overview
- What is this project? (1-2 sentences)
- What problem does it solve?
### Tech Stack
- Languages, frameworks, and key dependencies
### Project Structure
- Main directories and their purposes
### How to Run
- Development setup commands (if documented)
- How to run tests (if documented)
### Key Things to Know
- Any important patterns, conventions, or gotchas mentioned in the docs
- Areas marked as work-in-progress or known issues
---
Keep your summary concise but informative. After reporting, you'll be ready to assist with tasks in this codebase.