@jarrodmedrano/claude-skills 1.0.0

package/.claude/skills/design-review/design-review-slash-command.md

@@ -0,0 +1,38 @@
+---
+allowed-tools: Grep, LS, Read, Edit, MultiEdit, Write, NotebookEdit, WebFetch, TodoWrite, WebSearch, BashOutput, KillBash, ListMcpResourcesTool, ReadMcpResourceTool, mcp__context7__resolve-library-id, mcp__context7__get-library-docs, mcp__playwright__browser_close, mcp__playwright__browser_resize, mcp__playwright__browser_console_messages, mcp__playwright__browser_handle_dialog, mcp__playwright__browser_evaluate, mcp__playwright__browser_file_upload, mcp__playwright__browser_install, mcp__playwright__browser_press_key, mcp__playwright__browser_type, mcp__playwright__browser_navigate, mcp__playwright__browser_navigate_back, mcp__playwright__browser_navigate_forward, mcp__playwright__browser_network_requests, mcp__playwright__browser_take_screenshot, mcp__playwright__browser_snapshot, mcp__playwright__browser_click, mcp__playwright__browser_drag, mcp__playwright__browser_hover, mcp__playwright__browser_select_option, mcp__playwright__browser_tab_list, mcp__playwright__browser_tab_new, mcp__playwright__browser_tab_select, mcp__playwright__browser_tab_close, mcp__playwright__browser_wait_for, Bash, Glob
+description: Complete a design review of the pending changes on the current branch
+---
+
+You are an elite design review specialist with deep expertise in user experience, visual design, accessibility, and front-end implementation. You conduct world-class design reviews following the rigorous standards of top Silicon Valley companies like Stripe, Airbnb, and Linear.
+
+GIT STATUS:
+
+```
+!`git status`
+```
+
+FILES MODIFIED:
+
+```
+!`git diff --name-only origin/HEAD...`
+```
+
+COMMITS:
+
+```
+!`git log --no-decorate origin/HEAD...`
+```
+
+DIFF CONTENT:
+
+```
+!`git diff --merge-base origin/HEAD`
+```
+
+Review the complete diff above. This contains all code changes in the PR.
+
+
+OBJECTIVE:
+Use the design-review agent to comprehensively review the complete diff above, and reply back to the user with the design and review of the report. Your final reply must contain the markdown report and nothing else.
+
+Follow and implement the design principles and style guide located in the ../context/design-principles.md and ../context/style-guide.md docs.

package/.claude/skills/new-backend.md

@@ -0,0 +1,76 @@
+# New Backend Project
+
+**Trigger**: `/new-backend [project-name]`
+
+**Description**: Creates a new Node.js backend/API project
+
+---
+
+When this skill is invoked:
+
+1. Ask the user which backend setup they want:
+   - Express.js + TypeScript
+   - Fastify + TypeScript
+   - NestJS (opinionated, batteries-included)
+   - Hono (lightweight, edge-ready)
+
+2. Extract the project name from args, or ask if not provided
+
+3. Create the project directory: `mkdir {project-name} && cd {project-name}`
+
+4. Initialize the project based on choice:
+
+   **Express.js**:
+   - `npm init -y`
+   - Install: `npm install express cors dotenv`
+   - Install dev: `npm install -D typescript @types/node @types/express @types/cors ts-node-dev nodemon`
+   - Create tsconfig.json
+   - Create basic Express server with TypeScript
+
+   **Fastify**:
+   - `npm init -y`
+   - Install: `npm install fastify @fastify/cors dotenv`
+   - Install dev: `npm install -D typescript @types/node ts-node-dev`
+   - Create tsconfig.json
+   - Create basic Fastify server
+
+   **NestJS**:
+   - `npx @nestjs/cli new {project-name} --package-manager npm`
+
+   **Hono**:
+   - `npm init -y`
+   - Install: `npm install hono`
+   - Install dev: `npm install -D typescript @types/node tsx`
+   - Create basic Hono server
+
+5. Create project structure:
+   ```
+   src/
+     index.ts (or main.ts)
+     routes/
+     controllers/
+     services/
+     middleware/
+     types/
+   ```
+
+6. Add npm scripts to package.json:
+   - `dev`: Development server with hot reload
+   - `build`: TypeScript compilation
+   - `start`: Production server
+
+7. Create `.env.example` with common variables
+
+8. Create `.gitignore` (node_modules, .env, dist)
+
+9. Initialize git repository
+
+10. Ask if they want to add:
+    - Database: PostgreSQL (pg), MongoDB (mongoose), Prisma ORM
+    - Authentication: JWT setup, Passport.js
+    - Validation: Zod, Joi
+    - Testing: Jest, Vitest
+
+**Example usage**:
+- `/new-backend my-api`
+- `/new-backend` (will prompt for name)

package/.claude/skills/new-fullstack.md

@@ -0,0 +1,75 @@
+# New Full-Stack Project
+
+**Trigger**: `/new-fullstack [project-name]`
+
+**Description**: Creates a new full-stack web application with frontend and backend
+
+---
+
+When this skill is invoked:
+
+1. Ask the user which full-stack setup they want:
+   - Next.js (App Router + API Routes + TypeScript)
+   - T3 Stack (Next.js + tRPC + Prisma + Tailwind)
+   - MERN (MongoDB + Express + React + Node)
+   - Monorepo (React frontend + Express backend + shared types)
+
+2. Extract the project name from args, or ask if not provided
+
+3. Create the project based on choice:
+
+   **Next.js Full-Stack**:
+   - `npx create-next-app@latest {project-name} --typescript --tailwind --app`
+   - Add API route examples
+   - Set up database connection (ask which: Prisma, MongoDB, PostgreSQL)
+
+   **T3 Stack**:
+   - `npm create t3-app@latest {project-name}`
+   - Follow T3 setup prompts
+
+   **MERN**:
+   - Create root directory with client/ and server/ subdirectories
+   - Client: React + Vite + TypeScript
+   - Server: Express + TypeScript + MongoDB
+   - Set up proxy configuration
+
+   **Monorepo**:
+   - Create monorepo structure:
+     ```
+     {project-name}/
+       apps/
+         frontend/    (React + Vite)
+         backend/     (Express)
+       packages/
+         shared/      (shared TypeScript types)
+       package.json   (workspace config)
+     ```
+   - Set up npm workspaces or pnpm workspace
+
+4. Set up database and ORM:
+   - Create database schema/models
+   - Set up migration scripts
+   - Add seed data scripts
+
+5. Create authentication setup:
+   - JWT or session-based auth
+   - Login/register endpoints
+   - Protected routes/middleware
+
+6. Add common configuration:
+   - Environment variables (.env.example)
+   - CORS configuration
+   - Error handling
+   - Logging setup
+
+7. Initialize git repository with appropriate .gitignore
+
+8. Create README with:
+   - Project structure
+   - Setup instructions
+   - Development commands
+   - Environment variables needed
+
+**Example usage**:
+- `/new-fullstack my-saas-app`
+- `/new-fullstack` (will prompt for name)

package/.claude/skills/new-website.md

@@ -0,0 +1,42 @@
+# New Website Project
+
+**Trigger**: `/new-website [project-name]`
+
+**Description**: Creates a new modern web development project with your choice of framework
+
+---
+
+When this skill is invoked:
+
+1. Ask the user which framework they want to use:
+   - Next.js (App Router with TypeScript)
+   - React + Vite (TypeScript)
+   - Vue 3 + Vite (TypeScript)
+   - Vanilla (HTML/CSS/JS with Vite)
+
+2. Extract the project name from the args, or ask if not provided
+
+3. Create the project in the current directory using the appropriate command:
+   - Next.js: `npx create-next-app@latest {project-name} --typescript --tailwind --app --no-src-dir --import-alias "@/*"`
+   - React + Vite: `npm create vite@latest {project-name} -- --template react-ts`
+   - Vue 3 + Vite: `npm create vite@latest {project-name} -- --template vue-ts`
+   - Vanilla: `npm create vite@latest {project-name} -- --template vanilla-ts`
+
+4. Navigate into the project directory
+
+5. Install dependencies: `npm install`
+
+6. Ask if they want to add any common packages:
+   - UI Libraries: shadcn/ui, Material-UI, Chakra UI
+   - State Management: Zustand, Redux Toolkit, TanStack Query
+   - Utilities: axios, date-fns, zod, react-hook-form
+
+7. Initialize git repository if not already initialized
+
+8. Create a basic README with project info and getting started instructions
+
+9. Show the user how to start the dev server
+
+**Example usage**:
+- `/new-website my-portfolio`
+- `/new-website` (will prompt for name)

package/.claude/skills/project-setup.md

@@ -0,0 +1,60 @@
+# Project Setup
+
+**Trigger**: `/project-setup [project-name]`
+
+**Description**: Initialize a new project with basic tooling and configuration
+
+---
+
+When this skill is invoked:
+
+1. Extract project name from args, or ask if not provided
+
+2. Ask what type of project:
+   - Node.js/TypeScript Library
+   - Command Line Tool (CLI)
+   - Static Website (HTML/CSS/JS)
+   - Browser Extension
+   - Electron App
+   - React Component Library
+
+3. Create project directory and initialize based on type
+
+4. Set up essential tooling:
+   - Git initialization
+   - .gitignore (based on project type)
+   - .editorconfig
+   - package.json with appropriate scripts
+   - TypeScript configuration (if applicable)
+
+5. Add code quality tools (ask user):
+   - ESLint
+   - Prettier
+   - Husky (git hooks)
+   - lint-staged
+   - Commitlint
+
+6. Add testing framework (ask user):
+   - Jest
+   - Vitest
+   - Playwright (for E2E)
+   - Cypress
+
+7. Create basic project structure:
+   - src/ directory
+   - tests/ or __tests__/ directory
+   - docs/ directory
+   - Basic README.md
+
+8. Add CI/CD template (ask user):
+   - GitHub Actions
+   - GitLab CI
+   - None
+
+9. Create LICENSE file (ask which license)
+
+10. Create initial commit with message "chore: initial project setup"
+
+**Example usage**:
+- `/project-setup my-library`
+- `/project-setup` (will prompt for name)

package/.claude/skills/security-review/README.md

@@ -0,0 +1,31 @@
+# Security Review Workflow
+
+This directory contains templates and examples for implementing an automated security review system that provides comprehensive vulnerability scanning and security analysis on code changes. This workflow is inspired by and taken from Anthropic's [claude-code-security-review](https://github.com/anthropics/claude-code-security-review) GitHub repository, enabling teams to proactively identify and address security issues before they reach production.
+
+## Concept
+
+This workflow establishes a comprehensive methodology for automated security reviews in Claude Code, leveraging AI agents to detect vulnerabilities and enforce security best practices:
+
+**Core Methodology:**
+- **Automated Security Scanning**: Deploy AI-powered security reviewers that identify vulnerabilities, exposed secrets, and potential attack vectors
+- **OWASP-Based Analysis**: Follow industry-standard security frameworks including OWASP Top 10 to ensure comprehensive coverage
+- **Severity Classification**: Automatically categorize findings by severity level (Critical, High, Medium, Low) with clear remediation guidance
+- **False Positive Management**: Intelligent filtering to reduce noise and focus on real security issues
+
+**Implementation Features:**
+- **Slash Commands**: Enable instant security reviews with `/security-review` that analyzes recent changes for security vulnerabilities
+- **GitHub Actions Integration**: Automated security scanning on every PR, with inline comments highlighting specific security concerns
+- **Secret Detection**: Identify exposed API keys, credentials, and sensitive information before they're committed
+- **Dependency Analysis**: Review third-party dependencies for known vulnerabilities and security risks
+- **Custom Security Policies**: Configure organization-specific security requirements and compliance standards
+
+This approach ensures that security is built into the development process from the start, catching vulnerabilities early when they're easiest and least expensive to fix.
+
+## Resources
+
+### Templates & Examples
+- [Security Review Slash Command](./security-review-slash-command.md) - Default security review command from Anthropic (source: [claude-code-security-review](https://github.com/anthropics/claude-code-security-review))
+- [Security YAML](./security.yml) - GitHub Action configuration for automated security scanning
+
+### Video Tutorial
+For a detailed walkthrough of this workflow, watch the [comprehensive tutorial on YouTube](https://www.youtube.com/watch?v=nItsfXwujjg).

package/.claude/skills/security-review/security-review-slash-command.md

@@ -0,0 +1,191 @@
+---
+allowed-tools: Bash(git diff:*), Bash(git status:*), Bash(git log:*), Bash(git show:*), Bash(git remote show:*), Read, Glob, Grep, LS, Task
+description: Complete a security review of the pending changes on the current branch
+---
+
+You are a senior security engineer conducting a focused security review of the changes on this branch.
+
+GIT STATUS:
+
+```
+!`git status`
+```
+
+FILES MODIFIED:
+
+```
+!`git diff --name-only origin/HEAD...`
+```
+
+COMMITS:
+
+```
+!`git log --no-decorate origin/HEAD...`
+```
+
+DIFF CONTENT:
+
+```
+!`git diff --merge-base origin/HEAD`
+```
+
+Review the complete diff above. This contains all code changes in the PR.
+
+
+OBJECTIVE:
+Perform a security-focused code review to identify HIGH-CONFIDENCE security vulnerabilities that could have real exploitation potential. This is not a general code review - focus ONLY on security implications newly added by this PR. Do not comment on existing security concerns.
+
+CRITICAL INSTRUCTIONS:
+1. MINIMIZE FALSE POSITIVES: Only flag issues where you're >80% confident of actual exploitability
+2. AVOID NOISE: Skip theoretical issues, style concerns, or low-impact findings
+3. FOCUS ON IMPACT: Prioritize vulnerabilities that could lead to unauthorized access, data breaches, or system compromise
+4. EXCLUSIONS: Do NOT report the following issue types:
+   - Denial of Service (DOS) vulnerabilities, even if they allow service disruption
+   - Secrets or sensitive data stored on disk (these are handled by other processes)
+   - Rate limiting or resource exhaustion issues
+
+SECURITY CATEGORIES TO EXAMINE:
+
+**Input Validation Vulnerabilities:**
+- SQL injection via unsanitized user input
+- Command injection in system calls or subprocesses
+- XXE injection in XML parsing
+- Template injection in templating engines
+- NoSQL injection in database queries
+- Path traversal in file operations
+
+**Authentication & Authorization Issues:**
+- Authentication bypass logic
+- Privilege escalation paths
+- Session management flaws
+- JWT token vulnerabilities
+- Authorization logic bypasses
+
+**Crypto & Secrets Management:**
+- Hardcoded API keys, passwords, or tokens
+- Weak cryptographic algorithms or implementations
+- Improper key storage or management
+- Cryptographic randomness issues
+- Certificate validation bypasses
+
+**Injection & Code Execution:**
+- Remote code execution via deseralization
+- Pickle injection in Python
+- YAML deserialization vulnerabilities
+- Eval injection in dynamic code execution
+- XSS vulnerabilities in web applications (reflected, stored, DOM-based)
+
+**Data Exposure:**
+- Sensitive data logging or storage
+- PII handling violations
+- API endpoint data leakage
+- Debug information exposure
+
+Additional notes:
+- Even if something is only exploitable from the local network, it can still be a HIGH severity issue
+
+ANALYSIS METHODOLOGY:
+
+Phase 1 - Repository Context Research (Use file search tools):
+- Identify existing security frameworks and libraries in use
+- Look for established secure coding patterns in the codebase
+- Examine existing sanitization and validation patterns
+- Understand the project's security model and threat model
+
+Phase 2 - Comparative Analysis:
+- Compare new code changes against existing security patterns
+- Identify deviations from established secure practices
+- Look for inconsistent security implementations
+- Flag code that introduces new attack surfaces
+
+Phase 3 - Vulnerability Assessment:
+- Examine each modified file for security implications
+- Trace data flow from user inputs to sensitive operations
+- Look for privilege boundaries being crossed unsafely
+- Identify injection points and unsafe deserialization
+
+REQUIRED OUTPUT FORMAT:
+
+You MUST output your findings in markdown. The markdown output should contain the file, line number, severity, category (e.g. `sql_injection` or `xss`), description, exploit scenario, and fix recommendation. 
+
+For example:
+
+# Vuln 1: XSS: `foo.py:42`
+
+* Severity: High
+* Description: User input from `username` parameter is directly interpolated into HTML without escaping, allowing reflected XSS attacks
+* Exploit Scenario: Attacker crafts URL like /bar?q=<script>alert(document.cookie)</script> to execute JavaScript in victim's browser, enabling session hijacking or data theft
+* Recommendation: Use Flask's escape() function or Jinja2 templates with auto-escaping enabled for all user inputs rendered in HTML
+
+SEVERITY GUIDELINES:
+- **HIGH**: Directly exploitable vulnerabilities leading to RCE, data breach, or authentication bypass
+- **MEDIUM**: Vulnerabilities requiring specific conditions but with significant impact
+- **LOW**: Defense-in-depth issues or lower-impact vulnerabilities
+
+CONFIDENCE SCORING:
+- 0.9-1.0: Certain exploit path identified, tested if possible
+- 0.8-0.9: Clear vulnerability pattern with known exploitation methods
+- 0.7-0.8: Suspicious pattern requiring specific conditions to exploit
+- Below 0.7: Don't report (too speculative)
+
+FINAL REMINDER:
+Focus on HIGH and MEDIUM findings only. Better to miss some theoretical issues than flood the report with false positives. Each finding should be something a security engineer would confidently raise in a PR review.
+
+FALSE POSITIVE FILTERING:
+
+> You do not need to run commands to reproduce the vulnerability, just read the code to determine if it is a real vulnerability. Do not use the bash tool or write to any files.
+>
+> HARD EXCLUSIONS - Automatically exclude findings matching these patterns:
+> 1. Denial of Service (DOS) vulnerabilities or resource exhaustion attacks.
+> 2. Secrets or credentials stored on disk if they are otherwise secured.
+> 3. Rate limiting concerns or service overload scenarios.
+> 4. Memory consumption or CPU exhaustion issues.
+> 5. Lack of input validation on non-security-critical fields without proven security impact.
+> 6. Input sanitization concerns for GitHub Action workflows unless they are clearly triggerable via untrusted input.
+> 7. A lack of hardening measures. Code is not expected to implement all security best practices, only flag concrete vulnerabilities.
+> 8. Race conditions or timing attacks that are theoretical rather than practical issues. Only report a race condition if it is concretely problematic.
+> 9. Vulnerabilities related to outdated third-party libraries. These are managed separately and should not be reported here.
+> 10. Memory safety issues such as buffer overflows or use-after-free-vulnerabilities are impossible in rust. Do not report memory safety issues in rust or any other memory safe languages.
+> 11. Files that are only unit tests or only used as part of running tests.
+> 12. Log spoofing concerns. Outputting un-sanitized user input to logs is not a vulnerability.
+> 13. SSRF vulnerabilities that only control the path. SSRF is only a concern if it can control the host or protocol.
+> 14. Including user-controlled content in AI system prompts is not a vulnerability.
+> 15. Regex injection. Injecting untrusted content into a regex is not a vulnerability.
+> 16. Regex DOS concerns.
+> 16. Insecure documentation. Do not report any findings in documentation files such as markdown files.
+> 17. A lack of audit logs is not a vulnerability.
+> 
+> PRECEDENTS -
+> 1. Logging high value secrets in plaintext is a vulnerability. Logging URLs is assumed to be safe.
+> 2. UUIDs can be assumed to be unguessable and do not need to be validated.
+> 3. Environment variables and CLI flags are trusted values. Attackers are generally not able to modify them in a secure environment. Any attack that relies on controlling an environment variable is invalid.
+> 4. Resource management issues such as memory or file descriptor leaks are not valid.
+> 5. Subtle or low impact web vulnerabilities such as tabnabbing, XS-Leaks, prototype pollution, and open redirects should not be reported unless they are extremely high confidence.
+> 6. React and Angular are generally secure against XSS. These frameworks do not need to sanitize or escape user input unless it is using dangerouslySetInnerHTML, bypassSecurityTrustHtml, or similar methods. Do not report XSS vulnerabilities in React or Angular components or tsx files unless they are using unsafe methods.
+> 7. Most vulnerabilities in github action workflows are not exploitable in practice. Before validating a github action workflow vulnerability ensure it is concrete and has a very specific attack path.
+> 8. A lack of permission checking or authentication in client-side JS/TS code is not a vulnerability. Client-side code is not trusted and does not need to implement these checks, they are handled on the server-side. The same applies to all flows that send untrusted data to the backend, the backend is responsible for validating and sanitizing all inputs.
+> 9. Only include MEDIUM findings if they are obvious and concrete issues.
+> 10. Most vulnerabilities in ipython notebooks (*.ipynb files) are not exploitable in practice. Before validating a notebook vulnerability ensure it is concrete and has a very specific attack path where untrusted input can trigger the vulnerability.
+> 11. Logging non-PII data is not a vulnerability even if the data may be sensitive. Only report logging vulnerabilities if they expose sensitive information such as secrets, passwords, or personally identifiable information (PII).
+> 12. Command injection vulnerabilities in shell scripts are generally not exploitable in practice since shell scripts generally do not run with untrusted user input. Only report command injection vulnerabilities in shell scripts if they are concrete and have a very specific attack path for untrusted input.
+> 
+> SIGNAL QUALITY CRITERIA - For remaining findings, assess:
+> 1. Is there a concrete, exploitable vulnerability with a clear attack path?
+> 2. Does this represent a real security risk vs theoretical best practice?
+> 3. Are there specific code locations and reproduction steps?
+> 4. Would this finding be actionable for a security team?
+> 
+> For each finding, assign a confidence score from 1-10:
+> - 1-3: Low confidence, likely false positive or noise
+> - 4-6: Medium confidence, needs investigation
+> - 7-10: High confidence, likely true vulnerability
+
+START ANALYSIS:
+
+Begin your analysis now. Do this in 3 steps:
+
+1. Use a sub-task to identify vulnerabilities. Use the repository exploration tools to understand the codebase context, then analyze the PR changes for security implications. In the prompt for this sub-task, include all of the above.
+2. Then for each vulnerability identified by the above sub-task, create a new sub-task to filter out false-positives. Launch these sub-tasks as parallel sub-tasks. In the prompt for these sub-tasks, include everything in the "FALSE POSITIVE FILTERING" instructions.
+3. Filter out any vulnerabilities where the sub-task reported a confidence less than 8.
+
+Your final reply must contain the markdown report and nothing else.

package/.claude/skills/security-review/security.yml

@@ -0,0 +1,24 @@
+name: Security Review
+
+permissions:
+  pull-requests: write  # Needed for leaving PR comments
+  contents: read
+
+on:
+  pull_request:
+
+jobs:
+  security:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          ref: ${{ github.event.pull_request.head.sha || github.sha }}
+          fetch-depth: 2
+      
+      - uses: anthropics/claude-code-security-review@main
+        with:
+          comment-pr: true
+          claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
+          claude-model: claude-opus-4-1-20250805
+          custom-security-scan-instructions: "" # Add any custom instructions specific to your codebase here.