diff --git a/code-cleanup/SKILL.md b/code-cleanup/SKILL.md new file mode 100644 index 0000000..0a7fa7e --- /dev/null +++ b/code-cleanup/SKILL.md @@ -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. diff --git a/code-review/SKILL.md b/code-review/SKILL.md new file mode 100644 index 0000000..9ef34fb --- /dev/null +++ b/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. diff --git a/code-self-review/SKILL.md b/code-self-review/SKILL.md new file mode 100644 index 0000000..83c059b --- /dev/null +++ b/code-self-review/SKILL.md @@ -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. diff --git a/create-merge-request/SKILL.md b/create-merge-request/SKILL.md new file mode 100644 index 0000000..7632dc9 --- /dev/null +++ b/create-merge-request/SKILL.md @@ -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: `/` 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: + ``` + (): + + [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 ` + +### 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 --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 diff --git a/security-review/SKILL.md b/security-review/SKILL.md new file mode 100644 index 0000000..4c5e3f9 --- /dev/null +++ b/security-review/SKILL.md @@ -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. diff --git a/understand-project/SKILL.md b/understand-project/SKILL.md new file mode 100644 index 0000000..85d7796 --- /dev/null +++ b/understand-project/SKILL.md @@ -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.