scriptoriumadmin/awesome-claude-skills
1
0
Fork 0
mirror of https://github.com/ComposioHQ/awesome-claude-skills.git synced 2026-10-05 02:41:29 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge 1d6d43717a into 337b19e0ed

Browse source
This commit is contained in:
makladmk87-max 2026-04-30 09:30:41 +08:00 • committed by GitHub
commit bfc8820041
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
86 changed files with 5680 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

41
.claude/settings.local.json Normal file
View file

@ -0,0 +1,41 @@
{
"permissions": {
"allow": [
"Skill(connect-apps:setup)",
"Bash(python3 -c \"\nfrom composio import Composio\ncomposio = Composio\\(api_key='ak_KuIQ5_IMvfiOlKpSQjLS'\\)\nsession = composio.create\\(user_id='claude_user'\\)\nprint\\(session.mcp.url\\)\n\" 2>&1)",
"Bash(pip3 install:*)",
"Bash(pip3 show:*)",
"Bash(where pip3:*)",
"Bash(C:/Python314/python.exe -c \"\nfrom composio import Composio\ncomposio = Composio\\(api_key='ak_KuIQ5_IMvfiOlKpSQjLS'\\)\nsession = composio.create\\(user_id='claude_user'\\)\nprint\\(session.mcp.url\\)\n\" 2>&1)",
"Bash(ls *.md 2>/dev/null || ls *.yaml 2>/dev/null | head -20)",
"Bash(cd \"C:\\\\Users\\\\Mahmoud\\\\awesome-claude-skills\" && python send_test_email.py)",
"mcp__claude_ai_Notion__notion-create-pages",
"mcp__claude_ai_Notion__notion-search",
"mcp__claude_ai_Notion__notion-get-users",
"mcp__mcp-registry__search_mcp_registry",
"mcp__scheduled-tasks__list_scheduled_tasks",
"Bash(python3 -c \"import PyPDF2; print\\(''PyPDF2 available''\\)\")",
"Bash(python3 -c \"import pdfplumber; print\\(''pdfplumber available''\\)\")",
"Bash(python3 -c \"import fitz; print\\(''fitz available''\\)\")",
"Bash(pip install:*)",
"Bash(python3:*)",
"mcp__141e5e9d-c7b3-42a5-8bbe-29c926554ce8__notion-create-pages",
"Bash(node -e \":*)",
"Read(//c/Users/Mahmoud/.claude/**)",
"Bash(find ~/.claude/plugins -name *.json)",
"Bash(xargs grep:*)",
"Bash(find /c/Users/Mahmoud/.claude/plugins -name *.json -path */Notion/*)",
"Bash(ls /c/Users/Mahmoud/.claude/*.json)",
"Bash(find /c/Users/Mahmoud/.claude -name credentials*)",
"Bash(env)",
"Bash(find /c/Users/Mahmoud/.claude -name *.env -o -name .env)",
"Bash(find /c/Users/Mahmoud/.claude -name *.json -exec grep -l notion {})",
"Bash(2)",
"Bash(find /c/Users/Mahmoud -maxdepth 3 -name *.env -o -name .env)",
"Bash(head -10 grep -r NOTION /c/Users/Mahmoud/.claude/ --include=*.json -l)",
"Bash(grep -r \"ntn_\\\\|secret_\\\\|NOTION_TOKEN\\\\|notion_key\" /c/Users/Mahmoud/awesome-claude-skills/ --include=*.py --include=*.env --include=*.json -l)",
"Bash(head -5 find /c/Users/Mahmoud/awesome-claude-skills -name .env*)",
"Bash(cat ~/.claude/plugins/*/settings.json)"
]
}
}

11
.gitignore vendored Normal file
View file

@ -0,0 +1,11 @@
# Claude Code local files
.claude/settings.local.json
.claude/worktrees/
.claude/todos/
# OS
.DS_Store
Thumbs.db
# Node
node_modules/

1
README.md
View file

@ -111,6 +111,7 @@ Claude Skills are customizable workflows that teach Claude how to perform specif
### Development & Code Tools
- [artifacts-builder](https://github.com/anthropics/skills/tree/main/skills/web-artifacts-builder) - Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui).
- [frontend-design](./frontend-design/) - Create distinctive, production-grade frontend interfaces with high design quality. Generates creative, polished code that avoids generic AI aesthetics.
- [aws-skills](https://github.com/zxkane/aws-skills) - AWS development with CDK best practices, cost optimization MCP servers, and serverless/event-driven architecture patterns.
- [Changelog Generator](./changelog-generator/) - Automatically creates user-facing changelogs from git commits by analyzing history and transforming technical commits into customer-friendly release notes.
- [Chrome Relay](https://chrome-relay.kushalsm.com/) - Drives the user's already-open Chrome session — cookies, SSO, extensions, localhost — through a local CLI bridge. Real-Chrome counterpart to Playwright Browser Automation; install via `npx skills add chrome-relay` + a [Chrome Web Store extension](https://chromewebstore.google.com/detail/chrome-relay/cpdiapbifblhlcpnmlmfpgfjlacebokb). No remote relay, no Playwright fixtures, no MCP server needed.

22
adspirer-ad-campaign-best-practices/SKILL.md Normal file
View file

@ -0,0 +1,22 @@
---
name: adspirer-ads-agent:ad-campaign-best-practices
description: Best practices for creating and managing ad campaigns across Google Ads, Meta Ads, LinkedIn Ads, and TikTok Ads. Covers planning, budgets, targeting, and optimization.
---
## adspirer-ads-agent:ad-campaign-best-practices
**Category:** Adspirer Ads Agent
**What it does:**
Best practices for creating and managing ad campaigns across Google Ads, Meta Ads, LinkedIn Ads, and TikTok Ads. Covers planning campaigns, setting budgets, choosing targeting, and optimizing performance.
**When to trigger:**
- Planning any paid ad campaign
- Setting budgets or targeting
- Optimizing campaign performance
**How to install:**
```bash
npx claude install adspirer-ads-agent
```
**Trigger phrase:** Ask about ad campaign strategy, budgets, or targeting on any major ad platform.

21
adspirer-keyword-research/SKILL.md Normal file
View file

@ -0,0 +1,21 @@
---
name: adspirer-ads-agent:keyword-research
description: Researches Google Ads keywords with real CPC data, search volumes, and competition analysis. Gives you data-driven keyword intelligence for ad campaigns.
---
## adspirer-ads-agent:keyword-research
**Category:** Adspirer Ads Agent
**What it does:**
Researches Google Ads keywords with real CPC data, search volumes, and competition analysis. Gives you data-driven keyword intelligence for ad campaigns.
**When to trigger:**
- Planning Google Ads campaigns
- Researching keywords with real cost and volume data
**How to install:**
```bash
npx claude install adspirer-ads-agent
```
**Trigger phrase:** Ask Claude to research keywords for Google Ads, or invoke `/adspirer-ads-agent:keyword-research`.

123
adspirer/SKILL.md Normal file
View file

@ -0,0 +1,123 @@
---
name: adspirer
description: Manage Google Ads and Meta (Facebook/Instagram) advertising campaigns — create, analyze, and optimize ads. Use this skill when the user wants to work with Google Ads or Meta Ads: creating campaigns, analyzing performance, writing ad copy, optimizing budgets, or troubleshooting ad issues.
---
# Adspirer — Google & Meta Ads Management
Manage and optimize Google Ads and Meta Ads campaigns.
## Capabilities
- Analyze campaign performance and surface insights
- Write high-converting ad copy (headlines, descriptions, CTAs)
- Recommend targeting, bidding, and budget strategies
- Diagnose underperforming campaigns
- Build campaign structures for new products/promotions
- Interpret ad metrics and suggest optimizations
## Key Metrics Reference
### Google Ads
| Metric | Good benchmark |
|--------|---------------|
| CTR (Search) | > 3-5% |
| CTR (Display) | > 0.35% |
| Quality Score | 7-10 |
| Conversion Rate | Varies by industry; compare vs account average |
| ROAS | Depends on margins; typically target > 3x |
| CPA | Below target CPA set for campaign |
### Meta Ads
| Metric | Good benchmark |
|--------|---------------|
| CTR (Link) | > 1% |
| CPM | Varies by audience/placement |
| Frequency | Keep < 3-4 for conversion campaigns |
| ROAS | Target varies; compare vs blended |
| Relevance Score / Quality Ranking | Above average |
## Campaign Structure
### Google Ads
```
Account
└── Campaign (budget, bidding, location, device targets)
└── Ad Group (keyword/audience theme)
├── Keywords (match types: broad, phrase, exact)
└── Ads (RSA, Performance Max, Display)
```
### Meta Ads
```
Account
└── Campaign (objective: Awareness, Traffic, Conversions, etc.)
└── Ad Set (audience, budget, schedule, placement)
└── Ads (creative: image, video, carousel)
```
## Ad Copywriting
### Google Search Ad (RSA)
- **Headlines**: Up to 15 headlines (30 chars each) — include keyword, benefit, CTA
- **Descriptions**: Up to 4 descriptions (90 chars each) — expand on benefits, USP
- **Best practices**: Pin headline 1 to brand/keyword, use all 15 headlines
Example:
```
Headline 1: [Keyword-based] "Buy Running Shoes Online"
Headline 2: [Benefit] "Free Shipping on Orders $50+"
Headline 3: [CTA] "Shop Top Brands Today"
Headline 4: [Social proof] "50,000+ Happy Customers"
Description 1: "Discover our wide selection of running shoes from top brands. Find your perfect fit with free returns."
Description 2: "Shop Nike, Adidas, Brooks & more. Fast shipping available. Order by 3pm for same-day dispatch."
```
### Meta Ad
- **Primary text**: 125 chars visible before "See more" (key message first)
- **Headline**: 40 chars — punchy benefit or offer
- **Description**: 30 chars — supporting detail
- **CTA button**: Match to action (Shop Now, Learn More, Sign Up, etc.)
## Audience Targeting
### Google Ads
- **Search**: Keywords define audience intent — use negative keywords to exclude irrelevant traffic
- **Performance Max**: Asset-based; uses Google's signals
- **Audiences**: Remarketing, Customer Match, Similar Audiences, In-Market, Affinity
### Meta Ads
- **Core audiences**: Demographics, interests, behaviors
- **Custom audiences**: Website visitors (pixel), email lists, app users, video views
- **Lookalike audiences**: 1-10% lookalike from Custom Audience source
- **Best practice**: Start with 3-5% lookalike from buyers; narrow with interest stacking
## Optimization Workflow
When asked to optimize a campaign:
1. **Audit performance** — identify top/bottom performers at campaign, ad set, and ad level
2. **Budget allocation** — shift budget toward top performers
3. **Bid adjustments** — device, location, time-of-day adjustments
4. **Pause underperformers** — cut ad sets/ads below CPA threshold (after sufficient data)
5. **Test new creative** — if CTR low, test new headlines/images
6. **Audience refinement** — narrow or expand based on performance data
7. **Negative keywords** (Google) — review Search Terms report weekly
## Troubleshooting Common Issues
| Issue | Likely Cause | Fix |
|-------|-------------|-----|
| High CPC, low CTR | Low Quality Score / irrelevant audience | Improve ad relevance to keywords; tighten targeting |
| Good CTR, low conversions | Landing page issue | A/B test landing page; check tracking |
| Ads not delivering | Low budget, disapproved ads, narrow audience | Increase budget; fix policy issues; broaden audience |
| ROAS declining | Audience fatigue / increased competition | Refresh creative; test new audiences |
| Meta ads approved but no delivery | Audience too small, bid too low | Broaden audience; use Advantage+ placements |
## Notes for Claude
- Always ask for the user's goal before recommending (awareness vs leads vs sales vs ROAS)
- Ask for current metrics before optimization — don't recommend without data
- Budgets, bids, and targeting should be treated as hypotheses to test, not permanent decisions
- Follow platform policies — flag any creative that risks disapproval (misleading claims, restricted categories)

68
brainstorming/SKILL.md Normal file
View file

@ -0,0 +1,68 @@
---
name: brainstorming
description: Facilitate creative brainstorming sessions to generate ideas, explore possibilities, and unlock novel solutions. Use this skill when the user wants to generate ideas, explore options, think through a problem from multiple angles, or needs creative inspiration.
---
# Brainstorming
Facilitate high-quality brainstorming sessions that generate novel, diverse, and actionable ideas.
## Core Approach
Brainstorming works best when judgment is suspended during idea generation. Generate quantity first, then evaluate quality. Encourage divergent thinking before converging on solutions.
## Brainstorming Modes
### Mode 1: Open Exploration
When the user has a vague prompt or wants to explore broadly:
1. Reframe the problem in 2-3 different ways to unlock new angles
2. Generate ideas across different categories: conventional, unconventional, contrarian, and wild
3. Aim for at least 10-15 distinct ideas before filtering
4. Present ideas in clusters/themes, not just a flat list
### Mode 2: Constrained Generation
When the user has specific constraints (time, budget, tech, audience):
1. Acknowledge constraints explicitly upfront
2. Generate ideas that respect hard constraints
3. Flag which ideas push soft constraints — sometimes constraints are negotiable
4. Include at least one idea that challenges a stated constraint
### Mode 3: Build on Existing Ideas
When the user has partial ideas and wants to expand:
1. Extract the core insight from each existing idea
2. Generate variations: bigger, smaller, inverted, combined, applied elsewhere
3. Apply SCAMPER: Substitute, Combine, Adapt, Modify, Put to other uses, Eliminate, Reverse
## Framing Techniques
Use these to unlock stuck thinking:
- **Analogy**: "How would [unrelated industry/person] solve this?"
- **First principles**: "What's the most fundamental version of this problem?"
- **Inversion**: "What would make this maximally worse? Now invert."
- **Time travel**: "What would a solution from 10 years ago / 10 years future look like?"
- **Scale extremes**: "What if this needed to work for 1 person? 1 billion people?"
- **Resource extremes**: "What if budget were zero? Unlimited?"
## Output Format
Structure brainstorming output as:
1. **Reframed problem** (1-2 sentences) — confirm the real problem being solved
2. **Idea clusters** — group related ideas under themes
3. **Wild card** — one deliberately unconventional or counterintuitive idea
4. **Top 3 picks** — brief rationale for the most promising ideas
5. **Next step** — a concrete action to move from ideas to execution
## Facilitating Multi-Round Sessions
If the user wants to iterate:
- Ask "Which of these resonates most? Why?" to identify promising directions
- Drill deeper into selected ideas: risks, variations, prerequisites
- Combine ideas from different clusters
- Narrow to 1-3 actionable concepts with clear next steps
## Notes
- Never dismiss an idea during generation — defer evaluation to later
- If the user seems stuck on one approach, introduce deliberate constraints to force new thinking
- Brainstorming sessions should end with clarity, not just more options

29
claude-api/SKILL.md Normal file
View file

@ -0,0 +1,29 @@
---
name: claude-api
description: Guides building applications with the Claude API (Anthropic SDK) or Agent SDK. Covers API usage, tool use, streaming, and SDK patterns. Trigger when code imports anthropic or @anthropic-ai/sdk.
---
## claude-api
**Category:** Claude API / Anthropic SDK
**What it does:**
Guides you in building applications with the Claude API (Anthropic SDK) or Agent SDK. Covers API usage, tool use, streaming, and SDK patterns.
**When to trigger:**
- Your code imports `anthropic`, `@anthropic-ai/sdk`, or `claude_agent_sdk`
- You ask to use the Claude API or Anthropic SDK
- Building AI-powered apps with Claude as the backend
**Do NOT trigger when:** code uses `openai` or other AI SDKs.
**Latest model IDs:**
- Opus 4.6: `claude-opus-4-6`
- Sonnet 4.6: `claude-sonnet-4-6`
- Haiku 4.5: `claude-haiku-4-5-20251001`
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** Importing `anthropic` / asking to use the Claude or Anthropic API.

121
code-review/SKILL.md Normal file
View file

@ -0,0 +1,121 @@
---
name: code-review
description: Perform thorough, constructive code reviews covering correctness, security, performance, maintainability, and style. Use this skill when the user wants code reviewed, asks for feedback on their code, or needs a diff/PR reviewed.
---
# Code Review
Perform thorough, actionable code reviews that improve code quality, catch bugs, and share knowledge.
## Review Dimensions
Review code across these dimensions, in order of importance:
### 1. Correctness
Does the code do what it's supposed to do?
- Does it handle edge cases? (empty input, null/undefined, zero, large values)
- Are there off-by-one errors in loops or indices?
- Is the logic correct for all branches?
- Does error handling cover all failure paths?
- Are async operations handled correctly? (race conditions, unresolved promises)
- Are there any infinite loops or missing loop termination conditions?
### 2. Security
Does the code introduce security vulnerabilities?
- **Injection** — SQL injection, XSS, command injection, template injection
- **Authentication/Authorization** — are permissions checked? Can users access others' data?
- **Input validation** — is user input sanitized/validated before use?
- **Secrets** — are credentials, tokens, or keys hardcoded or leaked in logs?
- **Sensitive data** — is PII/sensitive data logged, exposed in errors, or stored insecurely?
- **Dependencies** — are new dependencies vetted for known vulnerabilities?
### 3. Performance
Does the code perform well at scale?
- **N+1 queries** — database queries inside loops
- **Unnecessary computation** — repeated calculations that could be cached
- **Memory leaks** — unreleased resources, growing collections
- **Blocking operations** — sync I/O in async contexts
- **Inefficient data structures** — O(n) lookups where O(1) is possible
### 4. Maintainability
Will this code be easy to understand and change?
- Is the code readable? Would another developer understand it quickly?
- Are variable/function names descriptive and accurate?
- Is there duplication that should be extracted?
- Are functions/methods doing too much? (single responsibility)
- Is complexity appropriate? (avoid over-engineering)
- Are there magic numbers or strings that should be named constants?
### 5. Tests
Is the change adequately tested?
- Are new features covered by tests?
- Are edge cases and error paths tested?
- Are tests meaningful? (not just asserting implementation details)
- Does test coverage actually test the behavior that matters?
### 6. Style and Conventions
Does the code follow team/project conventions?
- Naming conventions (camelCase, snake_case, etc.)
- File and module organization
- Comment style and quality
- Import ordering
## Review Output Format
Structure reviews as:
```
## Summary
[1-3 sentence overview of the change and overall assessment]
## Critical Issues (must fix)
- [issue]: [explanation] [line reference if applicable]
Suggestion: [how to fix]
## Minor Issues (should fix)
- [issue]: [explanation]
Suggestion: [how to fix]
## Nits (optional)
- [style/preference items]
## Positives
- [things done well — always include at least one]
```
## Tone and Approach
- **Be specific** — "this could be cleaner" is not useful; explain what and why
- **Explain the why** — don't just flag issues, explain why they matter
- **Suggest, don't dictate** — for style/preference: "consider X" not "do X"
- **Acknowledge good work** — point out what's done well, not just problems
- **Prioritize** — distinguish blocking issues from minor suggestions
## Review Checklist
Before submitting the review, verify:
- [ ] Correctness checked for all code paths
- [ ] Security vulnerabilities checked (injection, auth, input validation, secrets)
- [ ] Performance issues checked (N+1, unnecessary computation)
- [ ] Tests are present and meaningful
- [ ] Variable/function names are clear
- [ ] No debug code, console.logs, or TODOs left in
- [ ] Breaking changes identified
- [ ] Documentation updated if needed
## Common Issues Quick Reference
| Category | Pattern to Flag |
|----------|----------------|
| Security | `eval()`, string concatenation in SQL, `innerHTML =`, hardcoded credentials |
| Performance | Query inside loop, `.find()` in inner loop, sync file I/O |
| Correctness | Missing null check, uncaught promise, off-by-one in slice |
| Maintainability | Function >50 lines, nesting >3 levels, magic number |
| Tests | No error path test, mock returning wrong shape |
## Notes for Claude
- Read the full diff before commenting — context from other changes matters
- Check if tests were updated to cover the change
- Flag security issues as Critical regardless of other context
- If reviewing a PR, understand the PR description and intended goal first

117
debugging/SKILL.md Normal file
View file

@ -0,0 +1,117 @@
---
name: debugging
description: Systematically diagnose and fix bugs, errors, and unexpected behavior in code. Use this skill when the user has a bug, error message, unexpected behavior, or broken code that needs investigation and resolution.
---
# Debugging
Systematically diagnose and resolve bugs using structured investigation rather than random trial and error.
## Debugging Philosophy
Debugging is hypothesis-driven. Each step should:
1. Form a hypothesis about the root cause
2. Design a minimal test to confirm or refute it
3. Act on the result — fix or form the next hypothesis
Avoid random changes. Each change should test a specific hypothesis.
## Step 1: Understand the Bug
Before touching code, gather complete information:
- **What is the expected behavior?**
- **What is the actual behavior?**
- **When does it happen?** Always? Under specific conditions?
- **When did it start?** After a recent change? Always present?
- **What's the error?** Exact error message, stack trace, log output
- **What's the environment?** OS, runtime version, dependencies, config
Ask the user for any missing context before guessing.
## Step 2: Reproduce the Bug
Always reproduce before fixing:
- Find the minimal reproduction case
- Confirm the bug is reproducible consistently
- Rule out environment-specific issues (works on my machine?)
- If flaky: identify the conditions that trigger it
## Step 3: Locate the Source
Narrow down where the bug lives:
**Read the error message carefully:**
- Stack traces point to the line — but the bug may be higher up the call stack
- Error types (TypeError, KeyError, etc.) hint at the category of problem
**Bisect the problem:**
- Comment out / disable sections to isolate the faulty component
- Use binary search on recent commits if regression: `git bisect`
- Add logging/print statements to trace execution flow
**Check common culprits first:**
- Off-by-one errors in loops/indices
- Null/undefined/None not handled
- Type mismatches (string vs int, etc.)
- Async/timing issues (race conditions, unresolved promises)
- Scope issues (variable shadowing, closures)
- Mutation of shared state
- Wrong assumptions about external data shape
## Step 4: Fix and Verify
Once the root cause is identified:
1. Write the fix — targeted and minimal; avoid refactoring while debugging
2. Verify the original bug is gone with the reproduction case
3. Check for regressions — does anything else break?
4. Consider edge cases: what related inputs might also fail?
## Step 5: Document
After fixing:
- Add a comment explaining WHY the fix works (not just what it does)
- Add a test that would have caught this bug
- Note if there are related areas that might have the same issue
## Debugging Tools by Context
**JavaScript/TypeScript:**
```js
console.log(), console.error(), console.trace()
debugger; // pause in browser/Node
// Chrome DevTools, VS Code debugger
```
**Python:**
```python
print(), logging.debug()
import pdb; pdb.set_trace() # or breakpoint() in Python 3.7+
# VS Code debugger, pdb, ipdb
```
**Git bisect (for regressions):**
```bash
git bisect start
git bisect bad HEAD
git bisect good <last-known-good-commit>
# Run tests, mark good/bad, git will find the culprit commit
```
## Common Bug Patterns
| Symptom | Likely Cause |
|---------|-------------|
| Works sometimes, fails sometimes | Race condition, async issue, flaky dependency |
| Only fails on specific input | Edge case, boundary condition |
| Fails only in production | Environment difference, missing config, different data |
| Was working, now broken | Recent change introduced regression |
| Wrong output, no error | Logic error, wrong algorithm, off-by-one |
| Correct output but crash later | Side effect, state mutation |
## Notes for Claude
- Read the full stack trace — the error origin is often not where the exception is thrown
- If the user has tried things already, ask what they tried — avoid repeating dead ends
- Never guess and apply multiple changes at once — test one hypothesis at a time
- If unable to reproduce locally, ask the user to add logging/print statements and share output

24
figma-code-connect-components/SKILL.md Normal file
View file

@ -0,0 +1,24 @@
---
name: figma:code-connect-components
description: Connects Figma design components to code components using Code Connect. Creates mappings between Figma designs and code implementations so design tools show the real code.
---
## figma:code-connect-components
**Category:** Figma
**What it does:**
Connects Figma design components to code components using Code Connect. Creates mappings between Figma designs and code implementations so design tools show the real code.
**When to trigger:**
- "Code connect this component"
- "Connect Figma to code"
- "Map this component to code"
- "Create code connect mapping"
**How to install:**
```bash
npx claude install figma
```
Also requires the **Figma MCP server** connected.
**Trigger phrase:** Ask to connect or map a Figma component to its code equivalent.

169
figma-code-connect/SKILL.md Normal file
View file

@ -0,0 +1,169 @@
---
name: figma-code-connect
description: Set up and manage Figma Code Connect — link Figma components to real code components so devs see actual code snippets in Figma Dev Mode. Use this skill when the user wants to connect their Figma design system to their React/other framework component library using Figma's Code Connect feature.
---
# Figma: Code Connect
Link Figma components to real code components using Figma Code Connect.
## What is Code Connect?
Figma Code Connect maps Figma design components to their code implementations. When developers inspect a component in Figma Dev Mode, they see real code snippets from the actual codebase instead of generated CSS.
## Prerequisites
- Figma account with Dev Mode access
- Node.js project with a component library
- Figma personal access token
## Installation
```bash
npm install --save-dev @figma/code-connect
# or
npx figma connect
```
## Setup
### 1. Authenticate
```bash
npx figma connect login
# Enter your Figma personal access token when prompted
# Token: https://www.figma.com/settings → Personal access tokens
```
Or set via environment variable:
```bash
export FIGMA_ACCESS_TOKEN=figd_...
```
### 2. Initialize
```bash
npx figma connect create
```
This creates a `figma.config.json`:
```json
{
"codeConnect": {
"include": ["src/**/*.figma.tsx"],
"exclude": ["node_modules/**"]
}
}
```
## Creating Code Connect Files
For each Figma component, create a `.figma.tsx` (or `.figma.ts`) file:
### Basic Example — Button
```tsx
// src/components/Button/Button.figma.tsx
import figma from '@figma/code-connect'
import { Button } from './Button'
figma.connect(Button, 'https://www.figma.com/design/FILE_ID/DESIGN_NAME?node-id=COMPONENT_NODE_ID', {
props: {
variant: figma.enum('Variant', {
Default: 'default',
Primary: 'primary',
Destructive: 'destructive',
}),
size: figma.enum('Size', {
Small: 'sm',
Medium: 'md',
Large: 'lg',
}),
disabled: figma.boolean('Disabled'),
label: figma.string('Label'),
},
example: ({ variant, size, disabled, label }) => (
<Button variant={variant} size={size} disabled={disabled}>
{label}
</Button>
),
})
```
### Input Component Example
```tsx
import figma from '@figma/code-connect'
import { Input } from './Input'
figma.connect(Input, 'FIGMA_URL?node-id=NODE_ID', {
props: {
placeholder: figma.string('Placeholder'),
disabled: figma.boolean('Disabled'),
error: figma.boolean('Error'),
},
example: ({ placeholder, disabled, error }) => (
<Input
placeholder={placeholder}
disabled={disabled}
className={error ? 'input-error' : ''}
/>
),
})
```
## Figma URL Format
Get the component URL from Figma:
1. Open Figma file
2. Right-click the component in the canvas
3. "Copy link to selection"
4. URL format: `https://www.figma.com/design/FILE_ID/NAME?node-id=X-Y`
## Publishing Code Connect
```bash
# Preview what will be published
npx figma connect publish --dry-run
# Publish to Figma
npx figma connect publish
```
## Prop Mappers Reference
| Figma Prop Type | Code Connect Mapper |
|----------------|---------------------|
| Enum/Variant | `figma.enum('Prop Name', { FigmaOption: 'codeValue' })` |
| Boolean | `figma.boolean('Prop Name')` |
| String | `figma.string('Prop Name')` |
| Number | `figma.number('Prop Name')` |
| Instance swap | `figma.instance('Prop Name')` |
| Nested instance | `figma.nestedProps('Layer Name', { ... })` |
## CI Integration
Add to CI pipeline to keep Code Connect up to date:
```yaml
# .github/workflows/figma-code-connect.yml
- name: Publish Code Connect
run: npx figma connect publish
env:
FIGMA_ACCESS_TOKEN: ${{ secrets.FIGMA_ACCESS_TOKEN }}
```
## Process for Connecting a Component Library
1. Get component node IDs from Figma (right-click → copy link)
2. Create `.figma.tsx` file for each component
3. Map Figma property names to code prop names
4. Write the `example` render function
5. Run `npx figma connect publish --dry-run` to verify
6. Run `npx figma connect publish` to push live
## Notes
- Component node IDs change if components are moved between files
- Keep `.figma.tsx` files co-located with their components
- Test locally with `--dry-run` before publishing
- Figma Dev Mode must be enabled on the file to see Code Connect snippets

24
figma-create-design-system-rules/SKILL.md Normal file
View file

@ -0,0 +1,24 @@
---
name: figma:create-design-system-rules
description: Generates custom design system rules for your codebase. Establishes project-specific conventions for Figma-to-code workflows — tokens, component naming, spacing scales, etc.
---
## figma:create-design-system-rules
**Category:** Figma
**What it does:**
Generates custom design system rules for your codebase. Establishes project-specific conventions for Figma-to-code workflows — tokens, component naming, spacing scales, etc.
**When to trigger:**
- "Create design system rules"
- "Generate rules for my project"
- "Set up design rules"
- "Customize design system guidelines"
**How to install:**
```bash
npx claude install figma
```
Also requires the **Figma MCP server** connected.
**Trigger phrase:** Ask Claude to generate or set up design system rules for your project.

211
figma-design-system-rules/SKILL.md Normal file
View file

@ -0,0 +1,211 @@
---
name: figma-design-system-rules
description: Extract, document, and enforce design system rules from a Figma design system. Use this skill when the user wants to document their design system, create design tokens, establish component usage rules, or ensure code follows a Figma design system.
---
# Figma: Design System Rules
Extract and document design system rules from Figma for use in code implementation.
## When to Use
Use when the user:
- Wants to document their Figma design system for developers
- Needs to create a design tokens file from Figma specs
- Wants rules for how components should be used
- Is setting up a new codebase to match an existing Figma design system
## Design System Components to Document
### 1. Color Tokens
Extract all color styles from Figma:
```ts
// design-tokens/colors.ts
export const colors = {
// Brand
primary: {
50: '#EFF6FF',
100: '#DBEAFE',
500: '#3B82F6',
600: '#2563EB',
700: '#1D4ED8',
},
// Semantic
text: {
primary: '#111827',
secondary: '#6B7280',
disabled: '#D1D5DB',
},
background: {
default: '#FFFFFF',
subtle: '#F9FAFB',
muted: '#F3F4F6',
},
status: {
success: '#10B981',
warning: '#F59E0B',
error: '#EF4444',
info: '#3B82F6',
},
} as const;
```
### 2. Typography Tokens
```ts
export const typography = {
fonts: {
heading: '"Inter", system-ui, sans-serif',
body: '"Inter", system-ui, sans-serif',
mono: '"JetBrains Mono", monospace',
},
sizes: {
xs: '0.75rem', // 12px
sm: '0.875rem', // 14px
base: '1rem', // 16px
lg: '1.125rem', // 18px
xl: '1.25rem', // 20px
'2xl': '1.5rem', // 24px
'3xl': '1.875rem',// 30px
'4xl': '2.25rem', // 36px
},
weights: {
normal: 400,
medium: 500,
semibold: 600,
bold: 700,
},
lineHeights: {
tight: 1.25,
normal: 1.5,
relaxed: 1.75,
},
} as const;
```
### 3. Spacing Scale
```ts
export const spacing = {
0: '0',
1: '4px',
2: '8px',
3: '12px',
4: '16px',
5: '20px',
6: '24px',
8: '32px',
10: '40px',
12: '48px',
16: '64px',
20: '80px',
24: '96px',
} as const;
```
### 4. Border Radius
```ts
export const radius = {
none: '0',
sm: '4px',
md: '8px',
lg: '12px',
xl: '16px',
'2xl': '24px',
full: '9999px',
} as const;
```
### 5. Shadows
```ts
export const shadows = {
sm: '0 1px 2px 0 rgba(0, 0, 0, 0.05)',
md: '0 4px 6px -1px rgba(0, 0, 0, 0.1)',
lg: '0 10px 15px -3px rgba(0, 0, 0, 0.1)',
xl: '0 20px 25px -5px rgba(0, 0, 0, 0.1)',
} as const;
```
### 6. Breakpoints
```ts
export const breakpoints = {
sm: '640px',
md: '768px',
lg: '1024px',
xl: '1280px',
'2xl': '1536px',
} as const;
```
## Component Usage Rules
For each component in the design system, document:
### Component Rule Template
```md
## [ComponentName]
**Usage:** When to use this component
**Don't use when:** When NOT to use this component
### Variants
- `default` — Standard usage
- `primary` — Main CTA
- `destructive` — Dangerous actions
### Sizes
- `sm` — Compact layouts
- `md` — Default
- `lg` — Hero sections
### States
- `default`, `hover`, `focus`, `disabled`, `loading`
### Dos and Don'ts
✅ Do: [correct usage]
❌ Don't: [incorrect usage]
```
## CSS Custom Properties Export
For use in CSS/Tailwind projects:
```css
:root {
/* Colors */
--color-primary: #2563EB;
--color-primary-light: #DBEAFE;
--color-text: #111827;
--color-text-muted: #6B7280;
--color-bg: #FFFFFF;
--color-bg-subtle: #F9FAFB;
/* Typography */
--font-sans: 'Inter', system-ui, sans-serif;
--text-sm: 0.875rem;
--text-base: 1rem;
--text-lg: 1.125rem;
/* Spacing */
--space-4: 1rem;
--space-8: 2rem;
/* Radius */
--radius-md: 0.5rem;
--radius-lg: 0.75rem;
/* Shadows */
--shadow-md: 0 4px 6px -1px rgba(0, 0, 0, 0.1);
}
```
## Notes
- Ask the user to share Figma design system pages, color styles, and text styles
- Create tokens as a single source of truth — import everywhere
- Document rules that are NOT obvious from the tokens (e.g., "never use red for non-error states")
- For Tailwind projects, translate tokens into `tailwind.config.js` theme extensions

103
figma-implement-design/SKILL.md Normal file
View file

@ -0,0 +1,103 @@
---
name: figma-implement-design
description: Implement a Figma design as production-ready frontend code. Use this skill when the user shares a Figma design link or screenshot and wants it converted to HTML/CSS, React, or another frontend framework.
---
# Figma: Implement Design
Convert a Figma design into production-ready frontend code.
## When to Use
Use when the user:
- Shares a Figma link or screenshot and asks to "implement this"
- Says "build this design" / "code this mockup"
- Wants to convert a visual design to working code
## Process
### Step 1: Gather Design Information
The user must provide one of:
- **Figma URL**: `https://www.figma.com/design/...` or `https://www.figma.com/file/...`
- **Screenshot/image**: Visual of the design to implement
- **Figma Dev Mode export**: CSS properties, component specs
If only a URL is provided and no Figma MCP is configured, ask the user to:
1. Open Figma Dev Mode (Shift+D or bottom bar → Dev)
2. Share relevant CSS properties, spacing values, colors, and font specs
3. Export relevant assets (icons, images)
### Step 2: Extract Design Tokens
Before coding, identify and document:
- **Colors**: Background, text, border, accent colors (as hex/rgb)
- **Typography**: Font family, sizes, weights, line heights
- **Spacing**: Padding, margin, gap values
- **Border radius**: Corner radius values
- **Shadows**: Box shadow values
- **Breakpoints**: Responsive design specs if provided
Example CSS variables to set up:
```css
:root {
--color-primary: #2563EB;
--color-text: #1F2937;
--color-bg: #F9FAFB;
--font-heading: 'Inter', sans-serif;
--radius-md: 8px;
--spacing-md: 16px;
}
```
### Step 3: Identify Components
Break the design into reusable components:
- Identify repeated UI patterns
- Define component hierarchy (what contains what)
- Note interactive states: hover, active, focus, disabled
### Step 4: Implement
Implement using the stack the user specifies. Defaults:
- **No preference**: HTML + CSS (no framework)
- **React asked**: React with CSS modules or Tailwind
- **Vue asked**: Vue 3 SFCs
- **Tailwind available**: Use Tailwind utility classes
**Implementation priorities:**
1. Layout (flexbox/grid structure matches design)
2. Typography (font, size, weight, color)
3. Colors and backgrounds
4. Spacing (padding, margin, gaps)
5. Border radius and shadows
6. Hover/interactive states
7. Responsive behavior
### Step 5: Asset Handling
For images and icons:
- Use placeholder images if real assets aren't provided: `https://placehold.co/400x300`
- For icons: use Lucide React, Heroicons, or inline SVG
- Note which assets need to be replaced with real ones
## Code Quality Standards
- Semantic HTML (`<header>`, `<nav>`, `<main>`, `<section>`, `<button>`, not `<div>` for everything)
- Accessible (ARIA labels on interactive elements, alt text on images)
- Responsive (mobile-first or explicit breakpoints)
- Pixel-accurate where possible (spacing, sizing matching design)
## When Design is Partial or Unclear
If parts of the design are unclear:
- Make reasonable assumptions and note them
- Comment `/* TODO: Confirm with designer */` for uncertain parts
- Ask about critical ambiguities (interactions, responsive behavior)
## Notes
- Without Figma MCP integration, implement from screenshots or exported specs
- Always match the design's aesthetic intent, not just layout
- For complex designs, implement the most visible/important section first and iterate
- Use the `frontend-design` skill for creative freedom; use this skill when fidelity to a specific design is the goal

42
frontend-design/SKILL.md Normal file
View file

@ -0,0 +1,42 @@
---
name: frontend-design
description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
license: Complete terms in LICENSE.txt
---
This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
## Design Thinking
Before coding, understand the context and commit to a BOLD aesthetic direction:
- **Purpose**: What problem does this interface solve? Who uses it?
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
- **Constraints**: Technical requirements (framework, performance, accessibility).
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
- Production-grade and functional
- Visually striking and memorable
- Cohesive with a clear aesthetic point-of-view
- Meticulously refined in every detail
## Frontend Aesthetics Guidelines
Focus on:
- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.

162
git-worktrees/SKILL.md Normal file
View file

@ -0,0 +1,162 @@
---
name: git-worktrees
description: Manage multiple Git working trees to work on multiple branches simultaneously without stashing or switching. Use this skill when the user wants to work on multiple branches at the same time, review code in one branch while developing in another, or set up parallel development workflows.
---
# Git Worktrees
Work on multiple branches simultaneously using `git worktree` — each branch gets its own working directory.
## What is a Worktree?
A Git worktree is an additional working directory linked to the same repository. Each worktree:
- Has its own checked-out branch
- Has its own working directory and index
- Shares the same `.git` object store (efficient — no duplication)
Use case: work on a feature in one worktree while hotfixing in another, without stashing or losing context.
## Core Commands
### List existing worktrees
```bash
git worktree list
```
### Add a new worktree
```bash
# Checkout existing branch into new directory
git worktree add ../feature-branch feature-branch
# Create new branch and worktree together
git worktree add -b new-feature ../new-feature main
# Add worktree at a specific path
git worktree add /path/to/directory branch-name
```
### Remove a worktree
```bash
# After you're done with the worktree
git worktree remove ../feature-branch
# Force remove (if worktree has uncommitted changes)
git worktree remove --force ../feature-branch
# Prune stale worktree references
git worktree prune
```
### Move a worktree
```bash
git worktree move ../old-path ../new-path
```
## Common Workflows
### Workflow 1: Parallel Feature Development
```bash
# Main work: currently on feature-a
cd ~/projects/my-app
# Start working on feature-b in parallel
git worktree add ../my-app-feature-b feature-b
# Open feature-b in editor
code ../my-app-feature-b
# Later, clean up
git worktree remove ../my-app-feature-b
```
### Workflow 2: Hotfix While Feature is In Progress
```bash
# You're deep in feature work — don't stash, use a worktree
git worktree add ../hotfix-123 main
cd ../hotfix-123
git checkout -b hotfix/critical-bug-123
# Fix the bug, commit, push, open PR
git commit -am "fix: resolve critical login bug"
git push origin hotfix/critical-bug-123
# Back to feature work without losing context
cd ../my-app
```
### Workflow 3: Code Review Without Leaving Current Work
```bash
# Review a PR branch without disrupting your work
git fetch origin
git worktree add ../review-pr-456 origin/feature/some-feature
# Review the code in ../review-pr-456
# Run tests, inspect changes
# Clean up after review
git worktree remove ../review-pr-456
```
### Workflow 4: Testing Multiple Versions
```bash
# Compare behavior between main and a branch
git worktree add ../test-main main
git worktree add ../test-feature feature/new-algorithm
# Run both side by side
cd ../test-main && npm test
cd ../test-feature && npm test
```
## Directory Naming Convention
Keep worktrees organized with a consistent naming pattern:
```
~/projects/
my-app/ # main worktree (primary branch)
my-app-feature-x/ # feature worktree
my-app-hotfix/ # hotfix worktree
my-app-review/ # PR review worktree
```
Or use a subdirectory approach:
```
~/projects/
my-app/
.git/
src/
worktrees/
my-app-feature-x/
my-app-hotfix/
```
## Important Notes
- **One branch per worktree** — you cannot check out the same branch in two worktrees simultaneously
- **Shared objects** — all worktrees share the `.git` database; disk usage is minimal
- **Independent index** — each worktree has its own staging area (index)
- **Node modules / builds** — each worktree needs its own `node_modules`, `.venv`, build artifacts, etc. Run install commands after creating each worktree
- **IDE project files** — some IDEs may need to be opened separately for each worktree
## Cleanup Reminders
Orphaned worktrees (deleted directory without `git worktree remove`) leave stale metadata:
```bash
# Clean up stale references
git worktree prune
# View all worktrees including stale ones
git worktree list --porcelain
```
## Integration with Claude Code
When working in Claude Code across multiple worktrees:
- Each worktree is a separate project directory — open them independently
- Use `git worktree list` to see all active worktrees and their branches
- Prefer worktrees over stashing for context-switch heavy workflows

17
gsd-add-phase/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:add-phase
description: Adds a new phase to the end of the current milestone in your project roadmap. Use when you realize you need additional work that wasn't in the original plan.
---
## gsd:add-phase
**Category:** GSD (Get Stuff Done)
**What it does:**
Adds a new phase to the end of the current milestone in your project roadmap. Use this when you realize you need additional work that wasn't in the original plan.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:add-phase`

24
gsd-add-tests/SKILL.md Normal file
View file

@ -0,0 +1,24 @@
---
name: gsd:add-tests
description: Generates tests for a completed phase based on UAT criteria and the actual implementation. Ensures your code is properly covered after a phase finishes.
---
## gsd:add-tests
**Category:** GSD (Get Stuff Done)
**What it does:**
Generates tests for a completed phase based on UAT (User Acceptance Testing) criteria and the actual implementation. Ensures your code is properly covered after a phase finishes.
**When to trigger:**
After completing a GSD phase and wanting to add test coverage.
**How to install GSD:**
```bash
npx claude install superpowers
```
Then in Claude Code:
```
/gsd:update
```
**Trigger phrase:** `/gsd:add-tests` — run after a phase is done to generate tests.

17
gsd-add-todo/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:add-todo
description: Captures an idea or task as a todo directly from the current conversation context. Quick way to log something without losing it mid-session.
---
## gsd:add-todo
**Category:** GSD (Get Stuff Done)
**What it does:**
Captures an idea or task as a todo directly from the current conversation context. Quick way to log something without losing it mid-session.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:add-todo`

20
gsd-audit-milestone/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: gsd:audit-milestone
description: Audits a milestone's completion against its original intent before archiving it. Checks whether what was built actually matches what was planned, not just that tasks were checked off.
---
## gsd:audit-milestone
**Category:** GSD (Get Stuff Done)
**What it does:**
Audits a milestone's completion against its original intent before archiving it. Checks whether what was built actually matches what was planned, not just that tasks were checked off.
**When to trigger:**
Before archiving a milestone.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:audit-milestone`

17
gsd-check-todos/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:check-todos
description: Lists all pending todos and lets you select one to work on. Gives you a quick overview of outstanding items so you can prioritize what to tackle next.
---
## gsd:check-todos
**Category:** GSD (Get Stuff Done)
**What it does:**
Lists all pending todos and lets you select one to work on. Gives you a quick overview of outstanding items so you can prioritize what to tackle next.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:check-todos`

17
gsd-cleanup/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:cleanup
description: Archives accumulated phase directories from completed milestones, keeping your .planning/ directory tidy.
---
## gsd:cleanup
**Category:** GSD (Get Stuff Done)
**What it does:**
Archives accumulated phase directories from completed milestones, keeping your `.planning/` directory tidy.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:cleanup`

20
gsd-complete-milestone/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: gsd:complete-milestone
description: Archives a completed milestone and prepares the project for the next version. Wraps up loose ends and sets the stage for the next cycle.
---
## gsd:complete-milestone
**Category:** GSD (Get Stuff Done)
**What it does:**
Archives a completed milestone and prepares the project for the next version. Wraps up loose ends and sets the stage for the next cycle.
**When to trigger:**
After all phases in a milestone are done.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:complete-milestone`

97
gsd-debug/SKILL.md Normal file
View file

@ -0,0 +1,97 @@
---
name: gsd-debug
description: Run a focused GSD (Get Stuff Done) debugging session — identify the root cause of a specific bug and fix it systematically. Use this skill when actively working through a bug with a clear reproduce case, within a larger GSD workflow.
---
# GSD: Debug
Run a focused debugging session to identify and fix a specific bug.
## Quick Debug Process
This is a streamlined version of full debugging, optimized for speed within a GSD workflow.
### Phase 1: Lock Down the Bug (2-5 min)
Answer these before touching code:
1. **What is the exact error?** (message, stack trace, screenshot)
2. **What is the expected behavior?**
3. **Can you reproduce it consistently?** If not, what are the conditions?
4. **When did it start?** (recent change? always existed?)
```bash
# If it's a regression, find the culprit commit fast
git log --oneline -20
git bisect start
git bisect bad HEAD
git bisect good <last-known-good>
```
### Phase 2: Locate (5-10 min)
**Read the stack trace top-to-bottom.** The error message usually tells you exactly where.
```bash
# Find relevant code
grep -rn "functionName\|ErrorType\|error message" src/
# Check recent changes to relevant files
git log --oneline src/relevant-file.ts
git diff HEAD~3 src/relevant-file.ts
```
Add targeted logging to trace execution:
```js
console.log('[DEBUG] variable:', JSON.stringify(variable, null, 2))
```
```python
print(f"[DEBUG] variable: {variable!r}")
```
### Phase 3: Fix (5-15 min)
Once the root cause is known:
1. Write the smallest possible fix
2. Test the exact reproduction case
3. Remove all debug logging
4. Run the full test suite
```bash
npm test
# or pytest
```
### Phase 4: Commit
```bash
git add [specific files]
git commit -m "fix: [what was broken and why]"
```
## Common Bug Patterns (Quick Reference)
| Error | First thing to check |
|-------|---------------------|
| `TypeError: Cannot read properties of undefined` | Null check missing; trace where value comes from |
| `KeyError` / `AttributeError` (Python) | Check dict keys exist; check object shape |
| `404 Not Found` | API route path, trailing slash, method (GET vs POST) |
| Test passes locally, fails in CI | Environment variable missing, timezone difference, hardcoded path |
| Works once, breaks on retry | State not reset between calls; mutation of shared object |
| `CORS error` | Backend missing CORS headers for that origin |
| Async operation completes but result not used | Missing `await`, unhandled promise |
## If Stuck After 15 Minutes
Stop guessing. Do one of:
1. **Rubber duck** — explain the bug out loud step by step
2. **Minimal reproduction** — strip everything down to the smallest failing case
3. **Check git blame** — who changed the relevant code last?
4. **Search the error message** — exact message in quotes + technology name
5. **Ask for help** — provide: expected behavior, actual behavior, code, what was tried
## After Fixing
- Add a test that would have caught this bug
- Check if the same pattern exists elsewhere: `grep -rn "same-pattern" src/`
- Note in the commit message what caused the bug (helps future you)

20
gsd-discuss-phase/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: gsd:discuss-phase
description: Gathers phase context through adaptive questioning before planning begins. Ensures Claude fully understands the goals and constraints of a phase before writing a plan.
---
## gsd:discuss-phase
**Category:** GSD (Get Stuff Done)
**What it does:**
Gathers phase context through adaptive questioning before planning begins. Ensures Claude fully understands the goals and constraints of a phase before writing a plan.
**When to trigger:**
Before planning a phase, when you want to have a discussion first.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:discuss-phase`

139
gsd-execute-phase/SKILL.md Normal file
View file

@ -0,0 +1,139 @@
---
name: gsd-execute-phase
description: Execute a planned implementation — work through steps systematically, write code, run tests, and ship. Use this skill when the user has a plan (from gsd-plan-phase or similar) and is ready to implement it, or wants help executing a specific implementation task.
---
# GSD: Execute Phase
Work through an implementation plan systematically to produce working, tested code.
## Before Starting
Ensure there's a clear plan. If not, use `gsd-plan-phase` first. At minimum, know:
- What feature/change is being implemented?
- What are the steps?
- What files need to change?
## Execution Principles
- **One step at a time** — complete each step before moving to the next
- **Run tests frequently** — catch regressions early
- **Commit incrementally** — small, logical commits (not one giant commit at the end)
- **Don't scope-creep** — if you notice unrelated improvements, note them but don't do them now
## Execution Loop
For each step in the plan:
```
1. Read the relevant existing code
2. Implement the change
3. Run tests → fix if failing
4. Commit with a clear message
5. Mark the step done
6. Move to next step
```
## Step Execution Pattern
### Before writing code for each step:
- Re-read the plan step
- Read the files that will change
- Understand the existing patterns (follow them)
- Confirm the approach is still correct given what you've learned
### While writing code:
- Follow existing code style and patterns
- Write the simplest code that works
- Handle error cases
- Add/update types
### After writing code:
```bash
# Run tests
npm test
# or
pytest
# Run linter
npm run lint
# or
ruff check .
# Check types
npx tsc --noEmit
# or
mypy src/
```
### Commit pattern:
```bash
git add [specific files]
git commit -m "type: description"
```
Commit types: `feat`, `fix`, `refactor`, `test`, `chore`, `docs`
## Handling Blockers
If a step is blocked:
1. **Try to unblock** — investigate the issue, check docs, look for similar patterns
2. **Note the blocker** — write down what's blocking and what was tried
3. **Continue with other steps** if the blocker doesn't affect them
4. **Escalate** — if completely stuck, pause and ask/research
Never silently skip a step. Always explicitly note what was done and why.
## Progress Tracking
Use the `gsd-progress` skill to track which steps are done. Update the plan:
```
Steps:
1. [x] Set up X — done
2. [x] Implement Y — done
3. [ ] Add tests — IN PROGRESS
4. [ ] Update docs
```
## Testing Strategy During Execution
After each logical unit of work:
- Run the existing test suite — ensure no regressions
- Add tests for new behavior before or immediately after implementing it
- Test the happy path first, then edge cases
## Pre-Completion Checklist
Before calling a feature "done":
- [ ] All plan steps completed
- [ ] All tests pass
- [ ] Linter passes
- [ ] Types check out
- [ ] No debug code or console.logs left in
- [ ] Error cases handled
- [ ] README or docs updated if needed
- [ ] PR description written (if opening a PR)
## Git Workflow During Execution
```bash
# Start on a feature branch
git checkout -b feature/my-feature
# Commit often
git add src/specific-file.ts tests/specific-file.test.ts
git commit -m "feat: add X functionality"
# Push to remote regularly
git push origin feature/my-feature
# When done, open PR
gh pr create --title "feat: add X functionality" --body "..."
```
## Notes for Claude
- Read files before editing them — never make blind edits
- Prefer editing existing patterns over introducing new ones
- If the implementation diverges from the plan, note the deviation and why
- When multiple implementation steps are independent, they can be done in parallel (multiple file edits in one turn)

17
gsd-health/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:health
description: Diagnoses the health of your .planning/ directory and optionally repairs issues. Useful when something seems off with your project structure.
---
## gsd:health
**Category:** GSD (Get Stuff Done)
**What it does:**
Diagnoses the health of your `.planning/` directory and optionally repairs issues. Useful when something seems off with your project structure.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:health`

17
gsd-help/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:help
description: Shows all available GSD commands and a usage guide. Your starting point for learning the GSD workflow.
---
## gsd:help
**Category:** GSD (Get Stuff Done)
**What it does:**
Shows all available GSD commands and a usage guide. Your starting point for learning the GSD workflow.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:help`

17
gsd-insert-phase/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:insert-phase
description: Inserts urgent work as a decimal phase (e.g., 7.1) between two existing phases without renumbering the whole roadmap. Perfect for hotfixes or urgent additions.
---
## gsd:insert-phase
**Category:** GSD (Get Stuff Done)
**What it does:**
Inserts urgent work as a decimal phase (e.g., `7.1`) between two existing phases, without renumbering the whole roadmap. Perfect for hotfixes or urgent additions.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:insert-phase`

17
gsd-join-discord/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:join-discord
description: Joins you to the GSD Discord community — a place to get help, share projects, and connect with other GSD users.
---
## gsd:join-discord
**Category:** GSD (Get Stuff Done)
**What it does:**
Joins you to the GSD Discord community — a place to get help, share projects, and connect with other GSD users.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:join-discord`

20
gsd-list-phase-assumptions/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: gsd:list-phase-assumptions
description: Surfaces Claude's assumptions about how a phase will be approached before planning begins. Lets you catch and correct wrong assumptions early, before a bad plan is written.
---
## gsd:list-phase-assumptions
**Category:** GSD (Get Stuff Done)
**What it does:**
Surfaces Claude's assumptions about how a phase will be approached before planning begins. Lets you catch and correct wrong assumptions early, before a bad plan is written.
**When to trigger:**
Before planning a phase.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:list-phase-assumptions`

17
gsd-map-codebase/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:map-codebase
description: Analyzes your entire codebase using parallel mapper agents and produces structured documents in .planning/codebase/. Covers tech stack, architecture, quality, and concerns.
---
## gsd:map-codebase
**Category:** GSD (Get Stuff Done)
**What it does:**
Analyzes your entire codebase using parallel mapper agents and produces structured documents in `.planning/codebase/`. Covers tech stack, architecture, quality, and concerns. Gives Claude (and you) a comprehensive understanding of the project before major changes.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:map-codebase`

17
gsd-new-milestone/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:new-milestone
description: Starts a new milestone cycle by updating PROJECT.md and routing to requirements gathering. Use after completing one milestone and starting the next.
---
## gsd:new-milestone
**Category:** GSD (Get Stuff Done)
**What it does:**
Starts a new milestone cycle by updating `PROJECT.md` and routing to requirements gathering. Use after completing one milestone and starting the next.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:new-milestone`

184
gsd-new-project/SKILL.md Normal file
View file

@ -0,0 +1,184 @@
---
name: gsd-new-project
description: Bootstrap a new project from scratch — scaffold structure, set up tooling, configure environments, and get to a working first commit. Use this skill when the user wants to start a new software project and needs help with initial setup, structure, and configuration.
---
# GSD: New Project
Bootstrap a new project efficiently to reach a working, well-structured starting point.
## Philosophy
Get to a working state fast. Avoid over-engineering the foundation. The best new project setup is one that can be built on immediately.
## Step 1: Understand What's Being Built
Before scaffolding anything, clarify:
- **Type**: Web app? API? CLI? Library? Script? Mobile?
- **Stack**: Language, framework, runtime
- **Scale**: Solo project? Team? Production? Prototype?
- **Existing constraints**: Must use specific tools, deploy targets, org standards?
## Step 2: Initialize the Repository
```bash
# Create directory and initialize git
mkdir project-name && cd project-name
git init
# Set up .gitignore immediately
curl -sL https://www.gitignore.io/api/node,python,macos,vscode > .gitignore
# Or manually create based on stack
```
## Step 3: Project Structure
Establish a clear directory structure based on project type:
**Node.js / TypeScript:**
```
project/
src/
index.ts
tests/
dist/
package.json
tsconfig.json
.env.example
README.md
```
**Python:**
```
project/
src/
package_name/
__init__.py
tests/
pyproject.toml (or setup.py)
requirements.txt
.env.example
README.md
```
**Full-stack web:**
```
project/
client/ # frontend
server/ # backend API
shared/ # shared types/utils
docker-compose.yml
.env.example
README.md
```
## Step 4: Initialize Package Manager
**Node.js:**
```bash
npm init -y
# or
pnpm init
```
**Python:**
```bash
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
```
## Step 5: Configure Essential Tooling
At minimum, configure:
- **Linter**: ESLint, Flake8, Ruff
- **Formatter**: Prettier, Black
- **Type checking**: TypeScript, mypy
- **Testing**: Jest, pytest, Vitest
Add to `package.json` scripts:
```json
{
"scripts": {
"dev": "...",
"build": "...",
"test": "...",
"lint": "...",
"format": "..."
}
}
```
## Step 6: Environment Configuration
Create `.env.example` with all required variables (no values):
```env
DATABASE_URL=
API_KEY=
PORT=3000
NODE_ENV=development
```
Add `.env` to `.gitignore`. Never commit real secrets.
## Step 7: First Commit
```bash
git add .
git commit -m "chore: initial project setup"
```
## Step 8: Connect to Remote
```bash
# Create repo on GitHub/GitLab first, then:
git remote add origin https://github.com/user/project.git
git branch -M main
git push -u origin main
```
## Project README Template
Every project should have a README covering:
```md
# Project Name
One sentence description.
## Setup
## Usage
## Development
## Deployment
## Contributing
```
## Common Stacks Quick Setup
**Express + TypeScript API:**
```bash
npm init -y
npm install express
npm install -D typescript ts-node @types/node @types/express nodemon
npx tsc --init
```
**Next.js:**
```bash
npx create-next-app@latest project-name --typescript --tailwind --app
```
**FastAPI (Python):**
```bash
pip install fastapi uvicorn python-dotenv
```
**React + Vite:**
```bash
npm create vite@latest project-name -- --template react-ts
```
## Notes
- Resist adding dependencies that aren't immediately needed
- Set up CI/CD early — even a simple lint/test on push pays off
- Document the setup process in README as you go, not after

20
gsd-pause-work/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: gsd:pause-work
description: Creates a context handoff document when you need to pause work mid-phase. Saves your current state so you or Claude can resume exactly where you left off.
---
## gsd:pause-work
**Category:** GSD (Get Stuff Done)
**What it does:**
Creates a context handoff document when you need to pause work mid-phase. Saves your current state so you or Claude can resume exactly where you left off in a future session.
**When to trigger:**
When you need to stop working mid-phase.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:pause-work`

20
gsd-plan-milestone-gaps/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: gsd:plan-milestone-gaps
description: Creates phases to close all gaps identified by a milestone audit. After gsd:audit-milestone reveals missing work, this skill turns those gaps into actionable phases.
---
## gsd:plan-milestone-gaps
**Category:** GSD (Get Stuff Done)
**What it does:**
Creates phases to close all gaps identified by a milestone audit. After running `gsd:audit-milestone` reveals missing work, this skill turns those gaps into actionable phases.
**When to trigger:**
After `gsd:audit-milestone` finds gaps.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:plan-milestone-gaps`

137
gsd-plan-phase/SKILL.md Normal file
View file

@ -0,0 +1,137 @@
---
name: gsd-plan-phase
description: Run the planning phase of a GSD (Get Stuff Done) workflow — break down a feature or task into a concrete implementation plan before writing code. Use this skill when the user wants to plan how to implement a specific feature, task, or change before starting to code.
---
# GSD: Plan Phase
Transform a feature request or task into a concrete, actionable implementation plan.
## When to Use
Run the plan phase before any significant implementation:
- New features (more than a few lines of code)
- Architectural changes
- Refactors
- Bug fixes that require design decisions
Skip for truly trivial changes (typo fix, one-line change).
## Plan Phase Process
### 1. Understand the Requirement
Re-state the requirement in your own words. Identify:
- **Goal**: What user problem does this solve?
- **Scope**: What's in scope? What's explicitly out of scope?
- **Acceptance criteria**: How will you know it's done?
- **Constraints**: Performance targets, backward compatibility, deadlines
If anything is unclear, ask before planning.
### 2. Explore the Codebase
Before planning the implementation, understand the existing system:
- Where does the change live? Which files/modules?
- What existing code can be reused or extended?
- What are the relevant data models and APIs?
- Are there existing patterns to follow?
```bash
# Find relevant files
grep -r "relevant_term" src/
# or use Glob/search tools
```
### 3. Identify Approach Options
For non-trivial features, consider 2-3 implementation approaches:
- **Option A**: [approach] — pros, cons
- **Option B**: [approach] — pros, cons
- **Recommended**: [which and why]
### 4. Define Implementation Steps
Break the work into concrete, ordered steps. Each step should:
- Be completable in a single focused session
- Have a clear done state
- Be in dependency order (what must happen first?)
**Plan format:**
```
Feature: [name]
Approach: [chosen approach and why]
Steps:
1. [ ] [Specific task] — [files/components affected]
2. [ ] [Specific task] — [files/components affected]
3. [ ] [Write tests for X]
4. [ ] [Update docs/types if needed]
Edge cases to handle:
- [edge case 1]
- [edge case 2]
Open questions:
- [anything that needs decision before or during implementation]
```
### 5. Identify Risks and Unknowns
Flag before starting:
- **Breaking changes**: Will this affect existing functionality?
- **Dependencies**: Does this require other changes first?
- **Assumptions**: What are you assuming is true?
- **Unknowns**: What might you discover that changes the plan?
### 6. Estimate Complexity
Tag each plan with complexity:
- **S** (Small): <2 hours, straightforward
- **M** (Medium): 2-8 hours, some complexity
- **L** (Large): 1-3 days, significant work
- **XL** (X-Large): 3+ days, consider breaking down further
XL tasks should be broken into multiple M or L tasks.
## Output Format
Produce a plan document like:
```
# Plan: [Feature Name]
**Goal:** [one sentence]
**Complexity:** M
**Branch:** feature/[name]
## Approach
[1-2 paragraphs explaining the implementation approach]
## Steps
1. [ ] Set up [X] in [file]
2. [ ] Implement [Y] — extends existing [Z]
3. [ ] Add tests for [scenarios]
4. [ ] Update [types/docs/API]
## Files to Change
- `src/components/Foo.tsx` — add new prop
- `src/api/bar.ts` — new endpoint
- `tests/foo.test.ts` — new test cases
## Edge Cases
- Empty state
- Error state
- Concurrent requests
## Open Questions
- [ ] Should X be configurable or hardcoded?
```
## Transition to Execute Phase
After the plan is approved:
1. Create a feature branch: `git checkout -b feature/[name]`
2. Use `gsd-execute-phase` skill to work through the steps
3. Check off steps as completed

105
gsd-progress/SKILL.md Normal file
View file

@ -0,0 +1,105 @@
---
name: gsd-progress
description: Track and report progress on a GSD (Get Stuff Done) workflow — show what's done, what's in progress, and what's next. Use this skill when the user wants a status update on their current task or project, or needs to see where they are in a plan.
---
# GSD: Progress
Surface a clear, actionable progress snapshot of the current GSD workflow.
## Progress Report Format
When asked for progress, produce a report like:
```
## Progress: [Feature/Task Name]
**Status:** In Progress | Blocked | Review | Done
**Completed:** X/Y steps
### ✅ Done
- [Step 1] — [brief note if relevant]
- [Step 2]
### 🔄 In Progress
- [Current step] — [what's happening]
### ⏳ Up Next
- [Next step]
- [Step after that]
### ❌ Blocked
- [Blocked step] — [what's blocking it]
### 📝 Notes / Deviations from Plan
- [Any changes from original plan]
- [Decisions made]
- [Open questions]
### Next Action
[Single most important thing to do right now]
```
## How to Assess Progress
To generate an accurate progress report:
1. **Review the plan** — re-read the original plan steps
2. **Check completed work** — review git commits, file changes
3. **Check test status** — are tests passing?
4. **Identify blockers** — what (if anything) is stopping progress?
5. **Update the plan** — mark completed steps, flag new issues
```bash
# Review recent commits
git log --oneline -10
# See what files have changed
git diff --stat HEAD~5 HEAD
# Check test status
npm test 2>&1 | tail -20
```
## Keeping Progress Visible
Update progress inline in the plan document:
```
Steps:
1. [x] Initialize database schema — done
2. [x] Create API endpoint — done
3. [~] Add authentication — 50% done (middleware done, tests pending)
4. [ ] Write integration tests
5. [ ] Update API documentation
```
Legend:
- `[x]` — Done
- `[~]` — In progress
- `[ ]` — Not started
- `[!]` — Blocked
## When Progress is Stalled
If progress has stalled:
1. Identify the exact stall point
2. Determine if it's a blocker (external) or a struggle (internal)
3. For blockers: escalate or work around
4. For struggles: break the step into smaller sub-steps, get help
## End of Session Summary
At the end of a work session, produce a summary:
```
## Session Summary
**Time:** [duration]
**Completed today:** [list]
**State:** [where things stand]
**Next session start:** [exactly what to pick up with]
**Open questions:** [anything that needs a decision]
```
This makes it easy to resume work without context loss.

17
gsd-quick/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:quick
description: Executes a quick task with GSD guarantees (atomic commits, state tracking) but skips optional agents. Faster than a full phase execution — best for small, well-defined tasks.
---
## gsd:quick
**Category:** GSD (Get Stuff Done)
**What it does:**
Executes a quick task with GSD guarantees (atomic commits, state tracking) but skips optional agents like researchers and planners. Faster than a full phase execution — best for small, well-defined tasks.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:quick [task description]`

20
gsd-reapply-patches/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: gsd:reapply-patches
description: Reapplies your local modifications after a GSD update. When you update GSD and your customizations are overwritten, this skill restores them.
---
## gsd:reapply-patches
**Category:** GSD (Get Stuff Done)
**What it does:**
Reapplies your local modifications after a GSD update. When you update GSD and your customizations are overwritten, this skill restores them.
**When to trigger:**
After running `gsd:update` and losing local customizations.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:reapply-patches`

17
gsd-remove-phase/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:remove-phase
description: Removes a future phase from the roadmap and automatically renumbers subsequent phases. Safe way to cancel planned work.
---
## gsd:remove-phase
**Category:** GSD (Get Stuff Done)
**What it does:**
Removes a future phase from the roadmap and automatically renumbers subsequent phases. Safe way to cancel planned work.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:remove-phase`

17
gsd-research-phase/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:research-phase
description: Researches how to implement a phase before planning. Standalone research step — normally runs automatically inside gsd:plan-phase, but can be invoked separately for deeper investigation.
---
## gsd:research-phase
**Category:** GSD (Get Stuff Done)
**What it does:**
Researches how to implement a phase before planning. Standalone research step — normally this runs automatically inside `gsd:plan-phase`, but you can invoke it separately for deeper investigation.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:research-phase`

20
gsd-resume-work/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: gsd:resume-work
description: Resumes work from a previous session with full context restoration. Reads the handoff document created by gsd:pause-work and gets Claude back up to speed instantly.
---
## gsd:resume-work
**Category:** GSD (Get Stuff Done)
**What it does:**
Resumes work from a previous session with full context restoration. Reads the handoff document created by `gsd:pause-work` and gets Claude back up to speed instantly.
**When to trigger:**
At the start of a new session when you paused work previously.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:resume-work`

20
gsd-set-profile/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: gsd:set-profile
description: Switches the model profile used by GSD agents. Three profiles available — quality (best models), balanced (default), budget (faster/cheaper).
---
## gsd:set-profile
**Category:** GSD (Get Stuff Done)
**What it does:**
Switches the model profile used by GSD agents. Three profiles available:
- **quality** — uses the most capable models (slower, costlier)
- **balanced** — good default mix
- **budget** — faster and cheaper models
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:set-profile [quality|balanced|budget]`

17
gsd-settings/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:settings
description: Configures GSD workflow toggles and model profile settings. Adjust how GSD behaves — which agents run, what's skipped, and which AI model profile to use.
---
## gsd:settings
**Category:** GSD (Get Stuff Done)
**What it does:**
Configures GSD workflow toggles and model profile settings. Adjust how GSD behaves — which agents run, what's skipped, and which AI model profile to use.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:settings`

17
gsd-update/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:update
description: Updates GSD to the latest version and displays a changelog. Always run this on new machines or after a period away from GSD.
---
## gsd:update
**Category:** GSD (Get Stuff Done)
**What it does:**
Updates GSD to the latest version and displays a changelog. Always run this on new machines or after a period away from GSD.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:update`

17
gsd-validate-phase/SKILL.md Normal file
View file

@ -0,0 +1,17 @@
---
name: gsd:validate-phase
description: Retroactively audits and fills Nyquist validation gaps for a completed phase. Generates missing tests and verifies coverage for phase requirements.
---
## gsd:validate-phase
**Category:** GSD (Get Stuff Done)
**What it does:**
Retroactively audits and fills Nyquist validation gaps for a completed phase. Generates missing tests and verifies coverage for phase requirements. Use when a phase was completed but validation was skipped.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:validate-phase`

20
gsd-verify-work/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: gsd:verify-work
description: Validates built features through conversational UAT. Confirms that the phase goal was actually achieved, not just that tasks were completed.
---
## gsd:verify-work
**Category:** GSD (Get Stuff Done)
**What it does:**
Validates built features through conversational UAT (User Acceptance Testing). Confirms that the phase goal was actually achieved, not just that tasks were completed.
**When to trigger:**
After executing a phase.
**How to install GSD:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/gsd:verify-work`

147
instagram-prompt-extractor/SKILL.md Normal file
View file

@ -0,0 +1,147 @@
---
name: instagram-prompt-extractor
description: Extract the AI prompt or creative brief behind an Instagram post — reverse-engineer what prompt or concept was used to create AI-generated images, designs, or content. Use this skill when the user shares an Instagram post (image or caption) and wants to know the likely prompt or creative direction behind it.
---
# Instagram Prompt Extractor
Reverse-engineer the AI prompt or creative brief behind Instagram content.
## When to Use
Use when the user:
- Shares an Instagram image or post and asks "what prompt was used for this?"
- Wants to recreate a visual style they saw on Instagram
- Asks "how would I recreate this?" for AI-generated content
- Wants to understand the creative direction behind a post
## Process
### Step 1: Analyze the Visual Content
When an image is provided, analyze:
**Subject & Composition:**
- Main subject (person, object, scene, abstract)
- Composition style (rule of thirds, centered, symmetrical, dynamic)
- Foreground/background relationship
- Camera angle (eye-level, aerial, low-angle, POV)
**Lighting & Mood:**
- Lighting type (natural, studio, golden hour, neon, moody)
- Shadows and highlights
- Overall mood (dramatic, soft, cheerful, mysterious)
**Style & Aesthetic:**
- Photography style vs AI-generated vs illustration
- Art style if applicable (hyperrealistic, cinematic, anime, oil painting, etc.)
- Color grading (warm, cool, desaturated, high contrast, pastel)
- Post-processing style (film grain, vignette, sharp, soft focus)
**Technical Details:**
- Apparent camera/lens (wide angle, telephoto, macro, fisheye)
- Depth of field (shallow bokeh vs everything in focus)
- Resolution/clarity impression
### Step 2: Analyze the Caption (if provided)
Extract from caption:
- Key themes and concepts
- Brand voice and tone
- Hashtags as topic signals
- Product or service context
- Target audience cues
### Step 3: Construct the Likely Prompt
Build the reverse-engineered prompt in layers:
**For AI Image Generation (Midjourney, DALL-E, Stable Diffusion):**
```
[Subject description], [style/aesthetic], [lighting], [mood], [technical specs], [quality modifiers]
```
Example:
```
A young woman in a flowing white dress standing in a field of sunflowers at golden hour,
cinematic photography, warm soft lighting, bokeh background, shot on Canon 5D,
8k resolution, hyperrealistic, editorial style
```
**For Midjourney specifically:**
```
/imagine [subject] [style] [mood] [lighting] --ar 4:5 --style raw --v 6
```
**For content/caption prompts:**
```
Write an Instagram caption for [subject] with [tone] voice targeting [audience].
Include relevant hashtags for [niche]. Keep it [length].
```
### Step 4: Provide Recreation Instructions
Give the user:
1. **Extracted prompt** — ready to copy-paste into an AI image tool
2. **Style parameters** — specific settings for the tool (aspect ratio, style version)
3. **Key elements** — the most important visual elements to preserve
4. **Variations to try** — tweaks that might improve results
## Output Format
```
## Prompt Analysis: [Post description]
### Likely AI Tool
[Midjourney / DALL-E / Stable Diffusion / Not AI-generated / Unclear]
### Reverse-Engineered Prompt
**Ready to use:**
```
[Full prompt ready to copy-paste]
```
**For Midjourney:**
```
/imagine [prompt] --ar 4:5 --v 6
```
### Key Visual Elements
- **Subject**: [description]
- **Style**: [aesthetic description]
- **Lighting**: [lighting description]
- **Color**: [color grading]
- **Mood**: [emotional quality]
### Recreation Tips
1. [Specific tip for getting the same result]
2. [Another tip]
3. [Variation to try]
### Caption Prompt (if applicable)
```
[Prompt to generate a similar caption]
```
```
## Visual Style Vocabulary
Use these terms when constructing prompts:
**Photography styles:** editorial, documentary, fine art, street photography, fashion photography, product photography, portrait, landscape, macro
**Lighting:** golden hour, blue hour, studio lighting, rembrandt lighting, dramatic side lighting, flat lay, backlit, neon, cinematic
**Moods:** ethereal, moody, dark academia, cottagecore, minimalist, maximalist, retro, futuristic, dreamy, raw
**Technical:** bokeh, shallow depth of field, wide angle, telephoto compression, film grain, 35mm, medium format, drone shot, fisheye
**AI art styles:** hyperrealistic, photorealistic, cinematic, oil painting, watercolor, digital art, concept art, anime, illustration, 3D render
## Notes
- Be clear when a post is likely NOT AI-generated (real photography)
- For real photography, describe it as a "creative brief" rather than an "AI prompt"
- Include both the image generation prompt AND the caption prompt if both are relevant
- If image is not provided, work from caption and hashtag analysis only

65
install.sh Normal file
View file

@ -0,0 +1,65 @@
#!/bin/bash
# ================================================
# Claude Code Skills Setup - Android (Termux)
# Usage: bash install.sh
# ================================================
set -e
REPO="https://github.com/makladmk87-max/awesome-claude-skills"
SKILLS_DIR="$HOME/.claude/skills"
REPO_DIR="$HOME/awesome-claude-skills"
echo "==> Setting up Claude Code skills on Android..."
# ── 1. Install dependencies (Termux) ──────────────────────────────────────────
if command -v pkg &>/dev/null; then
echo "==> Installing packages via Termux..."
pkg update -y
pkg install -y git nodejs
elif command -v apt-get &>/dev/null; then
echo "==> Installing packages via apt..."
apt-get update -y
apt-get install -y git nodejs npm
fi
# ── 2. Install Claude Code CLI ─────────────────────────────────────────────────
if ! command -v claude &>/dev/null; then
echo "==> Installing Claude Code CLI..."
npm install -g @anthropic-ai/claude-code
else
echo "==> Claude Code already installed: $(claude --version)"
fi
# ── 3. Clone or update the skills repo ────────────────────────────────────────
if [ -d "$REPO_DIR/.git" ]; then
echo "==> Updating existing repo..."
git -C "$REPO_DIR" pull
else
echo "==> Cloning skills repo..."
git clone "$REPO" "$REPO_DIR"
fi
# ── 4. Link skills into ~/.claude/skills ──────────────────────────────────────
mkdir -p "$SKILLS_DIR"
echo "==> Installing skills..."
for skill_dir in "$REPO_DIR"/*/; do
skill_name=$(basename "$skill_dir")
skill_file="$skill_dir/SKILL.md"
# Skip non-skill directories
if [ ! -f "$skill_file" ]; then
continue
fi
target="$SKILLS_DIR/$skill_name.md"
cp "$skill_file" "$target"
echo " + $skill_name"
done
echo ""
echo "✓ Done! Skills installed to $SKILLS_DIR"
echo ""
echo "To use Claude Code, run: claude"
echo "To update skills later, run: bash $REPO_DIR/install.sh"

24
keybindings-help/SKILL.md Normal file
View file

@ -0,0 +1,24 @@
---
name: keybindings-help
description: Helps you customize keyboard shortcuts in Claude Code. Rebind keys, add chord bindings, change the submit key, or modify ~/.claude/keybindings.json.
---
## keybindings-help
**Category:** Utility
**What it does:**
Helps you customize keyboard shortcuts in Claude Code. You can rebind keys, add chord bindings (multi-key sequences), change the submit key, or modify `~/.claude/keybindings.json` directly.
**When to trigger:**
- "Rebind Ctrl+S"
- "Add a chord shortcut"
- "Change the submit key"
- "Customize keybindings"
**How to install:**
Bundled with Superpowers:
```bash
npx claude install superpowers
```
**Trigger phrase:** Ask Claude Code to customize, rebind, or modify keyboard shortcuts.

113
keybindings/SKILL.md Normal file
View file

@ -0,0 +1,113 @@
---
name: keybindings
description: Customize Claude Code keyboard shortcuts — add, change, or remove keybindings in ~/.claude/keybindings.json. Use this skill when the user wants to rebind keys, add chord shortcuts, change the submit key, or customize any Claude Code keyboard shortcuts.
---
# Keybindings
Customize Claude Code keyboard shortcuts by editing `~/.claude/keybindings.json`.
## Keybindings File Location
```
~/.claude/keybindings.json
```
Create it if it doesn't exist.
## File Format
```json
[
{
"key": "ctrl+enter",
"command": "sendMessage"
},
{
"key": "ctrl+shift+n",
"command": "newChat"
}
]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `sendMessage` | Send the current message |
| `newChat` | Start a new chat session |
| `clearChat` | Clear the current chat |
| `cancelMessage` | Cancel the current in-progress response |
| `focusInput` | Focus the message input |
| `toggleSidebar` | Toggle the sidebar |
## Key Format
Keys are specified as strings with modifiers separated by `+`:
**Modifiers:**
- `ctrl` — Control key
- `cmd` — Command key (macOS)
- `shift` — Shift key
- `alt` — Alt/Option key
- `meta` — Meta/Windows key
**Examples:**
- `"ctrl+enter"` — Ctrl + Enter
- `"cmd+shift+k"` — Cmd + Shift + K
- `"ctrl+k ctrl+c"` — Chord: Ctrl+K then Ctrl+C (two-key sequence)
## Common Customizations
### Change submit key to Ctrl+Enter (keep Enter for newlines)
```json
[
{
"key": "ctrl+enter",
"command": "sendMessage"
}
]
```
### Add chord shortcut
```json
[
{
"key": "ctrl+k n",
"command": "newChat"
}
]
```
### Multiple custom bindings
```json
[
{
"key": "ctrl+enter",
"command": "sendMessage"
},
{
"key": "escape",
"command": "cancelMessage"
},
{
"key": "ctrl+shift+c",
"command": "clearChat"
}
]
```
## Process for Updating Keybindings
1. Read the current `~/.claude/keybindings.json` (or note it doesn't exist)
2. Apply the requested changes
3. Write the updated file
4. Confirm with the user what was changed
## Notes
- Changes take effect after restarting Claude Code
- If the file doesn't exist, create it with just the new bindings
- Multiple keys can bind to the same command
- Chord bindings (two-key sequences) are supported with a space: `"ctrl+k n"`
- On macOS, prefer `cmd` over `ctrl` for Mac-native feel

109
loop/SKILL.md Normal file
View file

@ -0,0 +1,109 @@
---
name: loop
description: Run a prompt or slash command on a recurring interval. Use this skill when the user wants to set up a recurring task, poll for status, or run something repeatedly (e.g., "/loop 5m /foo", "check the deploy every 5 minutes", "keep running /babysit-prs"). Do NOT invoke for one-off tasks.
---
# Loop
Run a command or prompt repeatedly on a timed interval.
## Syntax
```
/loop [interval] [command or prompt]
```
**Examples:**
- `/loop 5m /check-deploy` — run `/check-deploy` every 5 minutes
- `/loop 10m check if any new PRs need review` — check for PRs every 10 minutes
- `/loop 30s run tests and report results` — run tests every 30 seconds
- `/loop /my-skill` — run `/my-skill` every 10 minutes (default interval)
## Interval Format
| Format | Example | Meaning |
|--------|---------|---------|
| `Xs` | `30s` | Every 30 seconds |
| `Xm` | `5m` | Every 5 minutes |
| `Xh` | `1h` | Every 1 hour |
| (none) | — | Default: 10 minutes |
## How to Run a Loop
When the user invokes `/loop`:
1. **Parse the interval** — extract time from the command (default 10m if not specified)
2. **Parse the command** — everything after the interval is the recurring task
3. **Execute the task** immediately (first run)
4. **Report results** from the first run
5. **Wait** for the specified interval
6. **Execute again** and report
7. **Continue** until the user stops it (Ctrl+C or says "stop")
## Loop Execution Pattern
```
[Loop started: every 5m]
━━━ Run 1 — 14:32:00 ━━━
[Execute command and report results]
━━━ Run 2 — 14:37:00 ━━━
[Execute command and report results]
━━━ Run 3 — 14:42:00 ━━━
[Execute command and report results — highlight any changes from previous run]
```
## Change Detection
On each run after the first:
- Compare results to the previous run
- Highlight **changes** clearly: new items, resolved items, status changes
- If nothing changed: report "No changes since last run"
## Common Use Cases
**Monitor CI/CD:**
```
/loop 2m check if the GitHub Actions build has finished
```
**Watch for PR reviews:**
```
/loop 15m check if any PRs are waiting for my review
```
**Monitor a deployment:**
```
/loop 1m check if the deployment to staging is complete
```
**Poll an API or service:**
```
/loop 30s check the status of the background job
```
**Run tests repeatedly:**
```
/loop 5m run the test suite and report any failures
```
## Stopping a Loop
The loop stops when:
- User types "stop", "cancel", or "quit"
- User presses Ctrl+C
- A completion condition is met (optional — specify in the prompt)
To add a stop condition:
```
/loop 1m check if deploy is done — stop when status is "success" or "failed"
```
## Notes
- Loops should be used for genuinely recurring monitoring tasks
- Do not use for one-time tasks (just run the command directly)
- Keep loop intervals reasonable — very short intervals (< 10s) may rate-limit APIs
- If the recurring task takes longer than the interval, skip the next scheduled run and warn the user

28
mintlify-mintlify/SKILL.md Normal file
View file

@ -0,0 +1,28 @@
---
name: mintlify:mintlify
description: Comprehensive reference for building Mintlify documentation sites. Covers creating pages, configuring docs.json, adding components, navigation, and API references.
---
## mintlify:mintlify
**Category:** Mintlify
**What it does:**
Comprehensive reference for building Mintlify documentation sites. Routes to detailed reference files for all components and configuration options. Covers:
- Creating pages
- Configuring `docs.json`
- Adding components
- Setting up navigation
- Working with API references
**When to trigger:**
- Working on a Mintlify docs site
- "How do I add X to Mintlify?"
- Configuring docs.json
- Building API reference pages
**How to install:**
```bash
npx claude install mintlify
```
**Trigger phrase:** Any Mintlify documentation work — building pages, configuring navigation, adding components.

254
mintlify/SKILL.md Normal file
View file

@ -0,0 +1,254 @@
---
name: mintlify
description: Build, manage, and optimize Mintlify documentation sites. Use this skill when the user wants to create or update documentation using Mintlify — adding pages, configuring navigation, writing MDX content, customizing themes, or deploying a Mintlify docs site.
---
# Mintlify
Build and manage documentation sites using Mintlify.
## What is Mintlify?
Mintlify is a modern documentation platform that:
- Converts MDX files into beautiful docs sites
- Supports API reference generation (OpenAPI)
- Has built-in search, analytics, and theming
- Deploys automatically from Git
## Project Structure
```
docs/
mint.json # Main configuration file
introduction.mdx # Pages as MDX files
quickstart.mdx
api-reference/
introduction.mdx
endpoint/
get-users.mdx
guides/
authentication.mdx
_snippets/ # Reusable content snippets
common-params.mdx
images/ # Static assets
logo/
light.svg
dark.svg
```
## mint.json Configuration
The `mint.json` file controls everything:
```json
{
"$schema": "https://mintlify.com/schema.json",
"name": "Your Docs",
"logo": {
"dark": "/logo/dark.svg",
"light": "/logo/light.svg"
},
"favicon": "/favicon.svg",
"colors": {
"primary": "#2563EB",
"light": "#3B82F6",
"dark": "#1D4ED8"
},
"topbarLinks": [
{ "name": "Support", "url": "mailto:support@yourcompany.com" }
],
"topbarCtaButton": {
"name": "Get Started",
"url": "https://yourapp.com/signup"
},
"navigation": [
{
"group": "Get Started",
"pages": ["introduction", "quickstart", "installation"]
},
{
"group": "Guides",
"pages": ["guides/authentication", "guides/webhooks"]
},
{
"group": "API Reference",
"pages": ["api-reference/introduction", "api-reference/endpoint/get-users"]
}
],
"footerSocials": {
"twitter": "https://twitter.com/yourcompany",
"github": "https://github.com/yourcompany"
}
}
```
## MDX Page Format
Every page is an MDX file with frontmatter:
```mdx
---
title: 'Page Title'
description: 'Short description for SEO and card previews'
icon: 'rocket'
---
# Introduction
Content goes here. MDX supports React components inline.
## Section Heading
Regular markdown works as expected.
<Note>
This is a callout note.
</Note>
<Warning>
This is a warning callout.
</Warning>
<Tip>
This is a tip callout.
</Tip>
<Info>
This is an info callout.
</Info>
```
## Mintlify Components
### Callouts
```mdx
<Note>Informational note</Note>
<Warning>Warning message</Warning>
<Tip>Helpful tip</Tip>
<Info>General info</Info>
```
### Code Blocks
````mdx
```python
def hello():
print("Hello, world!")
```
````
With filename:
````mdx
```python hello.py
def hello():
print("Hello, world!")
```
````
### Tabs
```mdx
<Tabs>
<Tab title="npm">
```bash
npm install package-name
```
</Tab>
<Tab title="yarn">
```bash
yarn add package-name
```
</Tab>
</Tabs>
```
### Cards
```mdx
<CardGroup cols={2}>
<Card title="Quickstart" icon="bolt" href="/quickstart">
Get up and running in 5 minutes.
</Card>
<Card title="API Reference" icon="code" href="/api-reference">
Explore the full API.
</Card>
</CardGroup>
```
### Steps
```mdx
<Steps>
<Step title="Install the SDK">
```bash
npm install @yourcompany/sdk
```
</Step>
<Step title="Initialize">
Create your client with your API key.
</Step>
<Step title="Make your first call">
Use the SDK to make your first API call.
</Step>
</Steps>
```
### API Reference Pages (OpenAPI)
```mdx
---
title: 'Get Users'
openapi: 'GET /users'
---
```
Configure OpenAPI source in mint.json:
```json
{
"openapi": "https://yourapi.com/openapi.json"
}
```
## Local Development
```bash
# Install Mintlify CLI
npm install -g mintlify
# Start local dev server (run from docs directory)
mintlify dev
# Opens at http://localhost:3000
```
## Deployment
Mintlify deploys automatically from Git:
1. Connect GitHub/GitLab repo at dashboard.mintlify.com
2. Point to docs directory in settings
3. Every push to main triggers a deploy
Manual deploy:
```bash
mintlify deploy
```
## Writing Good Documentation
Structure docs pages as:
1. **What it is** — one clear sentence
2. **Why use it** — the problem it solves
3. **Prerequisites** — what they need first
4. **Steps** — numbered, actionable
5. **Examples** — real code that works
6. **Troubleshooting** — common errors and solutions
7. **Next steps** — where to go from here
## Navigation Best Practices
- Group pages logically: "Get Started" → "Guides" → "API Reference"
- Keep navigation shallow (max 2 levels deep)
- Put the most important pages first
- Use clear, descriptive group names
## Notes for Claude
- Always check `mint.json` exists before adding pages — the page must be listed in `navigation`
- MDX files must be referenced in `mint.json` navigation or they won't appear
- Icons use Fontawesome names (e.g., `"rocket"`, `"code"`, `"database"`)
- Images go in the `/images/` or `/logo/` directory and are referenced with absolute paths

21
notion-create-database-row/SKILL.md Normal file
View file

@ -0,0 +1,21 @@
---
name: Notion:create-database-row
description: Inserts a new row into a specified Notion database using natural-language property values. You describe the row in plain English and Claude handles the property mapping.
---
## Notion:create-database-row
**Category:** Notion Integration
**What it does:**
Inserts a new row into a specified Notion database using natural-language property values. You describe the row in plain English and Claude handles the property mapping.
**When to trigger:**
- "Add a row to my [database name] in Notion"
**How to install:**
```bash
npx claude install superpowers
```
Also requires the **Notion MCP server** connected.
**Trigger phrase:** Ask Claude to add a row or entry to a specific Notion database.

113
notion-create-page/SKILL.md Normal file
View file

@ -0,0 +1,113 @@
---
name: notion-create-page
description: Create a new Notion page with content. Use this skill when the user wants to create a new page in Notion, add a document, write a note, or create a wiki entry.
---
# Notion: Create Page
Create a new Notion page with a title and content.
## When to Use
Use when the user:
- Says "create a page in Notion"
- Wants to add a new note, document, or wiki entry
- Needs to write content to Notion
- Wants to create a sub-page under an existing page
## Process
### Step 1: Determine Where to Create the Page
Ask or infer:
- **Parent page**: Should this live under an existing page? If yes, get the parent page ID using `notion-find`.
- **Workspace root**: If no parent is specified, create at the workspace level.
- **Database**: If it should be an entry in a database, use `notion-create-task` instead.
### Step 2: Prepare the Content
Gather from the user:
- **Title**: The page title (required)
- **Content**: Body text, structured content, etc.
### Step 3: Create the Page
Use `API-post-page`:
**Create at workspace root:**
```json
{
"parent": { "type": "workspace" },
"properties": {
"title": {
"title": [{ "type": "text", "text": { "content": "Page Title" } }]
}
}
}
```
**Create under a parent page:**
```json
{
"parent": { "page_id": "parent-page-id" },
"properties": {
"title": {
"title": [{ "type": "text", "text": { "content": "Page Title" } }]
}
}
}
```
### Step 4: Add Content (if any)
The `API-post-page` endpoint creates the page with a title. To add body content, use `API-patch-block-children` with the new page's ID:
**Add paragraph blocks:**
```json
{
"block_id": "new-page-id",
"children": [
{
"type": "paragraph",
"paragraph": {
"rich_text": [{ "type": "text", "text": { "content": "Your content here." } }]
}
}
]
}
```
**Add bulleted list:**
```json
{
"block_id": "new-page-id",
"children": [
{
"type": "bulleted_list_item",
"bulleted_list_item": {
"rich_text": [{ "type": "text", "text": { "content": "List item" } }]
}
}
]
}
```
## Response Format
On success:
```
✅ Page created: **[Title]**
URL: [notion url]
ID: [page-id]
```
## Multi-Block Content
For pages with multiple sections, append blocks sequentially. Keep each `API-patch-block-children` call to <100 blocks.
## Notes
- The Notion API only supports `paragraph` and `bulleted_list_item` block types in this integration
- For richer content (headings, code blocks, etc.), the page can be edited manually in Notion after creation
- Always confirm with the user before creating the page if the intent was ambiguous
- Page IDs are UUIDs — save them if the user will want to reference the page again

107
notion-create-task/SKILL.md Normal file
View file

@ -0,0 +1,107 @@
---
name: notion-create-task
description: Create a new task or entry in a Notion database. Use this skill when the user wants to add a task, to-do item, project entry, or any record to a Notion database.
---
# Notion: Create Task
Add a new entry (task, to-do, record) to a Notion database.
## When to Use
Use when the user:
- Says "add a task to Notion" or "create a to-do in Notion"
- Wants to add an entry to a specific Notion database
- Needs to log something (a bug, a lead, a project entry)
## Process
### Step 1: Identify the Target Database
Ask or infer which database the task should go into:
- "Which database should this go in? (e.g., Tasks, Projects, Backlog)"
- Or search for it: use `API-post-search` with `filter: { value: "data_source" }`
Get the database ID.
### Step 2: Retrieve Database Schema
Before creating an entry, understand what properties the database has:
```
API-retrieve-a-data-source: { "data_source_id": "database-id" }
```
This returns the database's `properties` object, which defines:
- Property names
- Property types (title, rich_text, select, multi_select, date, checkbox, number, etc.)
### Step 3: Gather Task Details
Collect from the user what's needed based on the database schema:
- **Title** (always required)
- **Status** (if the database has a status property)
- **Due date** (if relevant)
- **Assignee** (if relevant)
- **Priority** / **Tags** / other fields
### Step 4: Create the Entry
Use `API-post-page` with the database as parent:
```json
{
"parent": {
"type": "database_id",
"database_id": "database-id"
},
"properties": {
"Name": {
"title": [{ "type": "text", "text": { "content": "Task title" } }]
},
"Status": {
"select": { "name": "To Do" }
},
"Due Date": {
"date": { "start": "2025-03-20" }
},
"Priority": {
"select": { "name": "High" }
},
"Tags": {
"multi_select": [{ "name": "Engineering" }]
}
}
}
```
## Property Type Reference
| Type | Format |
|------|--------|
| `title` | `[{ "type": "text", "text": { "content": "..." } }]` |
| `rich_text` | `[{ "type": "text", "text": { "content": "..." } }]` |
| `select` | `{ "name": "option name" }` |
| `multi_select` | `[{ "name": "tag1" }, { "name": "tag2" }]` |
| `date` | `{ "start": "YYYY-MM-DD" }` |
| `checkbox` | `true` or `false` |
| `number` | `42` |
| `url` | `"https://..."` |
## Response Format
On success:
```
✅ Task created: **[Task Title]**
Database: [database name]
URL: [notion url]
```
Include any relevant properties that were set (status, due date, etc.).
## Notes
- Always retrieve the database schema first — property names are case-sensitive
- Select options must match existing options in the database (or will create new ones if allowed)
- If the user didn't provide required fields, ask before creating
- After creating, offer to add body content to the task page if needed

162
notion-database-query/SKILL.md Normal file
View file

@ -0,0 +1,162 @@
---
name: notion-database-query
description: Query a Notion database to retrieve, filter, and sort records. Use this skill when the user wants to list items in a Notion database, filter tasks by status/date/property, or get data out of a Notion database.
---
# Notion: Database Query
Retrieve and filter records from a Notion database.
## When to Use
Use when the user:
- Says "show me all my tasks in Notion"
- Wants to filter database entries ("show me tasks that are In Progress")
- Wants to sort database records
- Needs to read data out of a Notion database
## Process
### Step 1: Identify the Database
Find the database ID:
- Ask the user which database (by name)
- Use `API-post-search` with `filter: { value: "data_source" }` to find it
- Or use a known database ID if the user provides one
### Step 2: (Optional) Retrieve Schema
To understand what properties are filterable/sortable:
```
API-retrieve-a-data-source: { "data_source_id": "database-id" }
```
### Step 3: Query the Database
Use `API-query-data-source`:
**Basic query (all records):**
```json
{
"data_source_id": "database-id"
}
```
**Filter by select property:**
```json
{
"data_source_id": "database-id",
"filter": {
"property": "Status",
"select": { "equals": "In Progress" }
}
}
```
**Filter by checkbox:**
```json
{
"data_source_id": "database-id",
"filter": {
"property": "Done",
"checkbox": { "equals": false }
}
}
```
**Filter by date:**
```json
{
"data_source_id": "database-id",
"filter": {
"property": "Due Date",
"date": { "on_or_before": "2025-03-31" }
}
}
```
**Sort results:**
```json
{
"data_source_id": "database-id",
"sorts": [
{ "property": "Priority", "direction": "descending" },
{ "property": "Due Date", "direction": "ascending" }
]
}
```
**Combined filter and sort:**
```json
{
"data_source_id": "database-id",
"filter": {
"and": [
{ "property": "Status", "select": { "equals": "To Do" } },
{ "property": "Priority", "select": { "equals": "High" } }
]
},
"sorts": [{ "property": "Due Date", "direction": "ascending" }]
}
```
## Filter Types Reference
| Property Type | Filter Options |
|--------------|----------------|
| `select` | `equals`, `does_not_equal`, `is_empty`, `is_not_empty` |
| `multi_select` | `contains`, `does_not_contain`, `is_empty`, `is_not_empty` |
| `checkbox` | `equals: true/false` |
| `date` | `equals`, `before`, `after`, `on_or_before`, `on_or_after`, `is_empty`, `is_not_empty` |
| `title` / `rich_text` | `equals`, `contains`, `starts_with`, `ends_with`, `is_empty`, `is_not_empty` |
| `number` | `equals`, `greater_than`, `less_than`, `greater_than_or_equal_to`, `less_than_or_equal_to` |
## Parsing Results
Results are in `results[]`, each with `properties`:
```json
{
"results": [
{
"id": "page-id",
"url": "https://notion.so/...",
"properties": {
"Name": { "title": [{ "plain_text": "Task title" }] },
"Status": { "select": { "name": "In Progress" } },
"Due Date": { "date": { "start": "2025-03-20" } }
}
}
]
}
```
## Response Format
Present results as a clear list:
```
Found X records in [Database Name]:
1. **[Title]** — Status: [status] | Due: [date]
2. **[Title]** — Status: [status] | Due: [date]
...
[If filtered]: Showing tasks filtered by [filter description].
```
## Pagination
If `has_more: true`, use `next_cursor` to get more results:
```json
{
"data_source_id": "database-id",
"start_cursor": "cursor-from-previous-response"
}
```
## Notes
- Filter property names are case-sensitive — match exactly what's in the schema
- Maximum page_size is 100 per request
- Combine `and`/`or` arrays for complex filters
- If the user doesn't know filter values, retrieve a few records first to see what options exist

96
notion-find/SKILL.md Normal file
View file

@ -0,0 +1,96 @@
---
name: notion-find
description: Find a specific Notion page by title or partial title match. Use this skill when the user wants to locate a specific Notion page, asks "find my X page in Notion", or needs the page ID of a known page.
---
# Notion: Find Page
Locate a specific Notion page by title using the Notion MCP integration.
## When to Use
Use when the user:
- Says "find my [page name] in Notion"
- Needs to retrieve a specific page to read or update it
- Wants to confirm a page exists before creating a new one
## How to Find a Page
Use the `API-post-search` tool to search by title:
```json
{
"query": "page title or keywords",
"filter": {
"property": "object",
"value": "page"
}
}
```
## Process
1. **Extract the search query** from the user's request
2. **Call `API-post-search`** with the title keywords
3. **Review results** — check `results[].properties.title` or `results[].title` for matches
4. **Handle multiple results**:
- If one clear match: return the page ID and title
- If multiple matches: list them and ask the user to confirm which one
- If no match: inform the user and suggest searching with different terms
## Result Parsing
Notion search results have this structure:
```json
{
"results": [
{
"id": "page-id-here",
"object": "page",
"url": "https://notion.so/...",
"properties": {
"title": {
"title": [{ "plain_text": "Page Title" }]
}
}
}
]
}
```
Extract the page title with: `result.properties.title.title[0].plain_text`
## Response Format
When a page is found:
```
Found: **[Page Title]**
ID: `[page-id]`
URL: [notion url]
```
When multiple results:
```
Found multiple pages matching "[query]":
1. [Title 1] — [url]
2. [Title 2] — [url]
Which one did you mean?
```
When not found:
```
No page found matching "[query]".
Try:
- Different keywords
- Checking if the page is in a database (use notion-database-query)
- Using notion-search for broader content search
```
## Notes
- Notion search only covers pages the integration has access to
- Search matches against page titles, not content
- For content search, use the `notion-search` skill
- Always confirm the right page before making changes to it

124
notion-search/SKILL.md Normal file
View file

@ -0,0 +1,124 @@
---
name: notion-search
description: Search Notion for pages and databases matching a query. Use this skill when the user wants to search across their Notion workspace, find pages or databases by keyword, or explore what's available in their Notion.
---
# Notion: Search Workspace
Search across the Notion workspace for pages and databases matching a query.
## When to Use
Use when the user:
- Wants to search across all of Notion (not just find one specific page)
- Asks "search Notion for X" or "what's in my Notion about Y"
- Wants to find both pages and databases matching a term
- Is exploring what exists in their workspace
## How to Search
Use `API-post-search` with optional filters:
**Search everything:**
```json
{
"query": "search terms"
}
```
**Search only pages:**
```json
{
"query": "search terms",
"filter": { "property": "object", "value": "page" }
}
```
**Search only databases:**
```json
{
"query": "search terms",
"filter": { "property": "object", "value": "data_source" }
}
```
**Sort by most recently edited:**
```json
{
"query": "search terms",
"sort": { "direction": "descending", "timestamp": "last_edited_time" }
}
```
## Process
1. **Identify search intent** — does the user want pages, databases, or both?
2. **Run the search** with appropriate filters
3. **Parse results** — group by type (pages vs databases)
4. **Present results** clearly with titles, types, and URLs
5. **Offer next actions** — open a page, read content, etc.
## Result Parsing
```json
{
"results": [
{
"object": "page",
"id": "...",
"url": "...",
"properties": {
"title": {
"title": [{ "plain_text": "Page Title" }]
}
},
"last_edited_time": "2025-01-15T10:00:00Z"
},
{
"object": "database",
"id": "...",
"url": "...",
"title": [{ "plain_text": "Database Name" }]
}
]
}
```
For pages: `result.properties.title.title[0]?.plain_text`
For databases: `result.title[0]?.plain_text`
## Response Format
```
Search results for "[query]":
📄 Pages (X)
- [Title 1] — last edited [date] — [url]
- [Title 2] — last edited [date] — [url]
🗄 Databases (X)
- [Database Name] — [url]
No results? Try:
- Broader keywords
- Different spelling
- Checking workspace permissions
```
## Pagination
If there are many results, use `start_cursor` to paginate:
```json
{
"query": "...",
"start_cursor": "[cursor from previous result]",
"page_size": 10
}
```
## Notes
- Notion search works on page/database titles, not full content
- Results are limited to pages the integration has access to
- If the user has large workspaces, suggest more specific search terms
- After finding relevant pages, offer to read their content using `API-get-block-children`

21
notion-tasks-build/SKILL.md Normal file
View file

@ -0,0 +1,21 @@
---
name: Notion:tasks:build
description: Builds a task from a Notion page URL. Reads the page content and structures it into an actionable task with the right properties.
---
## Notion:tasks:build
**Category:** Notion Integration — Tasks
**What it does:**
Builds a task from a Notion page URL. Reads the page content and structures it into an actionable task with the right properties.
**When to trigger:**
- "Build a task from this Notion page: [URL]"
**How to install:**
```bash
npx claude install superpowers
```
Also requires the **Notion MCP server** connected.
**Trigger phrase:** Provide a Notion page URL and ask to build a task from it.

22
notion-tasks-explain-diff/SKILL.md Normal file
View file

@ -0,0 +1,22 @@
---
name: Notion:tasks:explain-diff
description: Makes a Notion doc explaining a code change (diff). Useful for documenting what changed and why, directly in Notion.
---
## Notion:tasks:explain-diff
**Category:** Notion Integration — Tasks
**What it does:**
Makes a Notion doc explaining a code change (diff). Useful for documenting what changed and why, directly in Notion.
**When to trigger:**
- "Document this code change in Notion"
- "Explain this diff and save it to Notion"
**How to install:**
```bash
npx claude install superpowers
```
Also requires the **Notion MCP server** connected.
**Trigger phrase:** Ask Claude to explain a code diff and create a Notion doc for it.

21
notion-tasks-plan/SKILL.md Normal file
View file

@ -0,0 +1,21 @@
---
name: Notion:tasks:plan
description: Plans a task from a Notion page URL. Reads the page and produces a structured implementation plan.
---
## Notion:tasks:plan
**Category:** Notion Integration — Tasks
**What it does:**
Plans a task from a Notion page URL. Reads the page and produces a structured implementation plan.
**When to trigger:**
- "Plan the task from this Notion page: [URL]"
**How to install:**
```bash
npx claude install superpowers
```
Also requires the **Notion MCP server** connected.
**Trigger phrase:** Provide a Notion page URL and ask to plan the task.

22
notion-tasks-setup/SKILL.md Normal file
View file

@ -0,0 +1,22 @@
---
name: Notion:tasks:setup
description: Sets up a Notion task board for tracking tasks. Creates the database structure, views, and properties needed for a Claude Code + Notion workflow.
---
## Notion:tasks:setup
**Category:** Notion Integration — Tasks
**What it does:**
Sets up a Notion task board for tracking tasks. Creates the database structure, views, and properties needed for a Claude Code + Notion workflow.
**When to trigger:**
- "Set up a Notion task board for me"
- First-time Notion integration setup
**How to install:**
```bash
npx claude install superpowers
```
Also requires the **Notion MCP server** connected.
**Trigger phrase:** Ask Claude to set up a Notion task board.

93
planning/SKILL.md Normal file
View file

@ -0,0 +1,93 @@
---
name: planning
description: Create structured, actionable plans for projects, tasks, or goals. Use this skill when the user needs to plan a project, break down a goal into steps, create a roadmap, or organize work before execution.
---
# Planning
Create clear, structured, and actionable plans that bridge goals and execution.
## Planning Philosophy
Good plans are:
- **Specific** — concrete actions, not vague intentions
- **Sequenced** — ordered by dependency and priority
- **Scoped** — right level of detail for the time horizon
- **Adaptable** — built with checkpoints for course correction
## Planning Process
### Step 1: Clarify the Goal
Before planning, ensure the goal is well-defined:
- What does success look like? Define the end state concretely.
- What are the hard constraints? (deadline, budget, resources, tech)
- What are the unknowns? Flag assumptions that need validation.
- What's the planning horizon? Day/week/month/quarter?
### Step 2: Decompose into Phases
Break the goal into logical phases:
- Each phase should have a clear deliverable or milestone
- Phases should be sequenced by dependency (what must come first?)
- Identify the critical path — what's blocking everything else?
### Step 3: Define Tasks
For each phase, define concrete tasks:
- Each task should be completable in a single focused session
- Tasks should have clear done criteria (not "work on X", but "complete X")
- Assign owners if multiple people are involved
- Add time estimates where helpful
### Step 4: Identify Risks
For each plan, surface:
- **Blockers** — things that would stop progress entirely
- **Dependencies** — external inputs or decisions needed
- **Assumptions** — things assumed true that could be wrong
- **Mitigations** — how to reduce or recover from each risk
### Step 5: Define Success Metrics
How will progress be tracked?
- What are the key milestones?
- What signals indicate the plan is on/off track?
- What are the go/no-go decision points?
## Output Formats
### Quick Plan (for shorter horizons)
```
Goal: [one sentence]
Phase 1: [Name] — [deliverable]
- [ ] Task 1
- [ ] Task 2
Phase 2: [Name] — [deliverable]
- [ ] Task 1
- [ ] Task 2
Risks: [top 2-3 risks]
First step: [the single next action]
```
### Full Project Plan (for complex projects)
Provide a structured document with:
- Executive summary
- Goals and success criteria
- Phased roadmap with milestones
- Task breakdown per phase
- Risk register
- Assumptions log
- Next immediate actions
## Common Planning Mistakes to Avoid
- **Planning too far ahead in detail** — only detail the next 1-2 phases; future phases should stay high-level until closer
- **Missing dependencies** — always ask "what needs to be true for this step to happen?"
- **Underestimating setup** — environment, research, and coordination tasks are real work
- **No review cadence** — build in checkpoints to reassess the plan itself
## After the Plan
Once the plan is ready:
1. Identify the single next action (SNA) — what happens in the next 30 minutes?
2. Set the first checkpoint — when will the plan be reviewed?
3. Communicate the plan to all stakeholders if applicable

20
send_test_email.py Normal file
View file

@ -0,0 +1,20 @@
import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
SENDER_EMAIL = "makladmk87@gmail.com"
APP_PASSWORD = "pzbk rryf zhsw vllu"
RECIPIENT = "dt23082411@gmail.com"
msg = MIMEMultipart()
msg["From"] = SENDER_EMAIL
msg["To"] = RECIPIENT
msg["Subject"] = "Test Email"
msg.attach(MIMEText("This is a test email sent via Python SMTP.", "plain"))
with smtplib.SMTP_SSL("smtp.gmail.com", 465) as server:
server.login(SENDER_EMAIL, APP_PASSWORD)
server.sendmail(SENDER_EMAIL, RECIPIENT, msg.as_string())
print("Email sent successfully!")

94
simplify/SKILL.md Normal file
View file

@ -0,0 +1,94 @@
---
name: simplify
description: Review recently changed code for reuse, quality, and efficiency — then fix any issues found. Use this skill when the user wants to simplify or improve code they just wrote, or asks for a quality pass on their changes.
---
# Simplify
Review changed code for quality, then apply targeted improvements.
## When to Use
Use after writing or changing code when:
- The user asks to "simplify this" or "clean this up"
- Code was written quickly and needs a quality pass
- Refactoring opportunities are visible but not worth a full rewrite
## Review Checklist
Run through this checklist on the changed code:
### Duplication
- [ ] Is similar logic repeated that could be extracted into a function?
- [ ] Are there copy-pasted blocks that differ only in a variable?
- [ ] Could a loop or `.map()` replace repeated statements?
### Complexity
- [ ] Is there nesting deeper than 3 levels that could be flattened?
- [ ] Could early returns reduce nesting (guard clauses)?
- [ ] Is there a simpler algorithm or built-in that achieves the same result?
- [ ] Are there unnecessary variables or intermediate values?
### Naming
- [ ] Do variable and function names clearly describe what they hold/do?
- [ ] Are there single-letter variables (outside loops/lambdas) that should be named?
- [ ] Are there misleading names (e.g., `data`, `result`, `temp`)?
### Reuse
- [ ] Does this reimplement something that already exists in the codebase?
- [ ] Does this reimplement a standard library function?
- [ ] Could an existing utility or helper be used?
### Efficiency
- [ ] Are there unnecessary loops (O(n²) where O(n) is possible)?
- [ ] Are expensive operations repeated inside a loop that could be hoisted?
- [ ] Are there unnecessary re-renders or recomputations?
### Dead Code
- [ ] Are there unused variables or imports?
- [ ] Are there commented-out code blocks that should be removed?
- [ ] Are there debug `console.log` / `print` statements left in?
## Fix Strategy
For each issue found:
1. Make the smallest change that addresses it
2. Verify the behavior is unchanged (run tests if available)
3. Don't refactor parts of the code that weren't changed
## Output Format
Present improvements as:
```
## Simplification Review
### Issues Found
**Duplication** (lines 12-24, 40-52):
The same validation logic is repeated. Extracted into `validateInput()`.
**Naming** (line 8):
`d` renamed to `dueDate` for clarity.
**Dead code** (line 67):
Removed commented-out code block.
### Changes Applied
[List of specific changes made]
### Not Changed
[Note anything that could be improved but was left alone to stay in scope]
```
## Scope Boundaries
Only modify:
- The code the user recently changed (not the whole file)
- Code directly related to the user's change
Do not:
- Refactor unrelated code
- Change architecture or add features
- Add error handling for scenarios not in scope
- Add comments or docstrings unless the logic is non-obvious

1135
skills-guide.html Normal file
View file

File diff suppressed because it is too large Load diff

BIN
skills-guide.pdf Normal file
View file

Binary file not shown.

24
superpowers-brainstorming/SKILL.md Normal file
View file

@ -0,0 +1,24 @@
---
name: superpowers:brainstorming
description: MUST be used before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design constraints before implementation begins.
---
## superpowers:brainstorming
**Category:** Superpowers — Core Workflow
**What it does:**
MUST be used before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design constraints before implementation begins. Prevents wasted effort by aligning on the right approach upfront.
**When to trigger:**
- Before building any new feature
- Before any `/gsd:plan-phase`
- Whenever entering plan mode
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** Automatically triggered before creative implementation work. Also: `/superpowers:brainstorming`
> **Note:** `superpowers:brainstorm` is the deprecated alias — use `superpowers:brainstorming` instead.

22
superpowers-dispatching-parallel-agents/SKILL.md Normal file
View file

@ -0,0 +1,22 @@
---
name: superpowers:dispatching-parallel-agents
description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies. Orchestrates multiple Claude subagents running in parallel to dramatically speed up execution.
---
## superpowers:dispatching-parallel-agents
**Category:** Superpowers — Core Workflow
**What it does:**
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies. Orchestrates multiple Claude subagents running in parallel, dramatically speeding up execution.
**When to trigger:**
- You have multiple independent tasks
- Research across several unrelated topics
- Building parallel features with no shared state
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:dispatching-parallel-agents`

22
superpowers-executing-plans/SKILL.md Normal file
View file

@ -0,0 +1,22 @@
---
name: superpowers:executing-plans
description: Use when you have a written implementation plan to execute in a separate session with review checkpoints. Ensures disciplined execution with steps, commit checkpoints, and review before proceeding.
---
## superpowers:executing-plans
**Category:** Superpowers — Core Workflow
**What it does:**
Use when you have a written implementation plan to execute in a separate session with review checkpoints. Ensures disciplined execution: work in steps, commit checkpoints, and review before proceeding.
**When to trigger:**
When you have a written plan and want to execute it.
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:executing-plans`
> **Note:** `superpowers:execute-plan` is the deprecated alias.

21
superpowers-finishing-a-development-branch/SKILL.md Normal file
View file

@ -0,0 +1,21 @@
---
name: superpowers:finishing-a-development-branch
description: Use when implementation is complete, all tests pass, and you need to decide how to integrate the work. Guides completion by presenting structured options — merge, PR, or cleanup.
---
## superpowers:finishing-a-development-branch
**Category:** Superpowers — Quality
**What it does:**
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work. Guides completion by presenting structured options: merge, PR, or cleanup.
**When to trigger:**
- Implementation done, tests passing
- Ready to integrate a feature branch
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:finishing-a-development-branch`

21
superpowers-receiving-code-review/SKILL.md Normal file
View file

@ -0,0 +1,21 @@
---
name: superpowers:receiving-code-review
description: Use when receiving code review feedback, before implementing suggestions — especially if feedback seems unclear or technically questionable. Requires technical rigor rather than blind implementation.
---
## superpowers:receiving-code-review
**Category:** Superpowers — Quality
**What it does:**
Use when receiving code review feedback, before implementing suggestions — especially if feedback seems unclear or technically questionable. Requires technical rigor and verification rather than performative agreement or blind implementation.
**When to trigger:**
- After getting code review comments
- Before implementing review suggestions
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:receiving-code-review`

22
superpowers-requesting-code-review/SKILL.md Normal file
View file

@ -0,0 +1,22 @@
---
name: superpowers:requesting-code-review
description: Use when completing tasks, implementing major features, or before merging — to verify work meets requirements. Structures the code review request to ensure meaningful feedback.
---
## superpowers:requesting-code-review
**Category:** Superpowers — Quality
**What it does:**
Use when completing tasks, implementing major features, or before merging — to verify work meets requirements. Structures the code review request to ensure meaningful feedback.
**When to trigger:**
- After completing a feature
- Before merging a branch
- After a major implementation step
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:requesting-code-review`

20
superpowers-subagent-driven-development/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: superpowers:subagent-driven-development
description: Use when executing implementation plans with independent tasks in the current session. Coordinates subagents within the current Claude Code session.
---
## superpowers:subagent-driven-development
**Category:** Superpowers — Core Workflow
**What it does:**
Use when executing implementation plans with independent tasks in the current session. Coordinates subagents within the current Claude Code session (unlike `dispatching-parallel-agents` which spawns external processes).
**When to trigger:**
When you have a plan with multiple independent implementation tasks.
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:subagent-driven-development`

22
superpowers-systematic-debugging/SKILL.md Normal file
View file

@ -0,0 +1,22 @@
---
name: superpowers:systematic-debugging
description: Use when encountering any bug, test failure, or unexpected behavior — before proposing fixes. Uses a structured scientific method to prevent jumping to the wrong fix.
---
## superpowers:systematic-debugging
**Category:** Superpowers — Core Workflow
**What it does:**
Use when encountering any bug, test failure, or unexpected behavior — before proposing fixes. Uses a structured scientific method: observe → hypothesize → test → conclude. Prevents jumping to the wrong fix.
**When to trigger:**
- Any bug or test failure
- Unexpected behavior in code
- Before running `gsd:debug`
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:systematic-debugging`

20
superpowers-test-driven-development/SKILL.md Normal file
View file

@ -0,0 +1,20 @@
---
name: superpowers:test-driven-development
description: Use when implementing any feature or bugfix, before writing implementation code. Follows strict TDD — write failing tests first, then make them pass. This is a rigid skill — follow it exactly.
---
## superpowers:test-driven-development
**Category:** Superpowers — Core Workflow
**What it does:**
Use when implementing any feature or bugfix, before writing implementation code. Follows strict TDD: write failing tests first, then make them pass. This is a **rigid skill** — follow it exactly.
**When to trigger:**
Before writing implementation code for any feature or fix.
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:test-driven-development`

21
superpowers-using-git-worktrees/SKILL.md Normal file
View file

@ -0,0 +1,21 @@
---
name: superpowers:using-git-worktrees
description: Use when starting feature work that needs isolation from the current workspace, or before executing implementation plans. Creates isolated git worktrees so experiments never pollute the main branch.
---
## superpowers:using-git-worktrees
**Category:** Superpowers — Core Workflow
**What it does:**
Use when starting feature work that needs isolation from the current workspace, or before executing implementation plans. Creates isolated git worktrees with smart directory selection and safety verification — so experiments never pollute the main branch.
**When to trigger:**
- Starting isolated feature work
- Before executing a large implementation plan
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:using-git-worktrees`

22
superpowers-using-superpowers/SKILL.md Normal file
View file

@ -0,0 +1,22 @@
---
name: superpowers:using-superpowers
description: The master skill — establishes how to find and use all other skills. Loaded at the start of every conversation. Defines when and how to invoke skills, skill priority order, and red flags for rationalizing away skill invocations.
---
## superpowers:using-superpowers
**Category:** Superpowers — Meta
**What it does:**
The master skill — establishes how to find and use all other skills. Loaded at the start of every conversation. Defines when and how to invoke skills, the skill priority order, and red flags that indicate you're rationalizing away a skill invocation.
**Key rules it enforces:**
- Invoke relevant skills BEFORE any response
- Even 1% chance a skill applies → invoke it
- Process skills (brainstorming, debugging) before implementation skills
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** Automatically loaded at session start.

22
superpowers-verification-before-completion/SKILL.md Normal file
View file

@ -0,0 +1,22 @@
---
name: superpowers:verification-before-completion
description: Use when about to claim work is complete, fixed, or passing — before committing or creating PRs. Requires running verification commands and confirming output before making any success claims.
---
## superpowers:verification-before-completion
**Category:** Superpowers — Quality
**What it does:**
Use when about to claim work is complete, fixed, or passing — before committing or creating PRs. Requires running verification commands and confirming output before making any success claims. Evidence before assertions, always.
**When to trigger:**
- Before saying "it works"
- Before committing
- Before creating a PR
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:verification-before-completion`

23
superpowers-writing-plans/SKILL.md Normal file
View file

@ -0,0 +1,23 @@
---
name: superpowers:writing-plans
description: Use when you have a spec or requirements for a multi-step task, before touching any code. Structures a detailed implementation plan covering architecture decisions, file changes, dependencies, and sequencing.
---
## superpowers:writing-plans
**Category:** Superpowers — Core Workflow
**What it does:**
Use when you have a spec or requirements for a multi-step task, before touching any code. Structures a detailed implementation plan covering architecture decisions, file changes, dependencies, and sequencing.
**When to trigger:**
- You have requirements and are about to start coding
- Before entering plan mode on a complex feature
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:writing-plans`
> **Note:** `superpowers:write-plan` is the deprecated alias.

22
superpowers-writing-skills/SKILL.md Normal file
View file

@ -0,0 +1,22 @@
---
name: superpowers:writing-skills
description: Use when creating new skills, editing existing skills, or verifying skills work before deployment. Guides the correct structure, frontmatter, trigger conditions, and testing methodology for Claude Code skills.
---
## superpowers:writing-skills
**Category:** Superpowers — Meta
**What it does:**
Use when creating new skills, editing existing skills, or verifying skills work before deployment. Guides the correct structure, frontmatter, trigger conditions, and testing methodology for Claude Code skills.
**When to trigger:**
- Writing a new skill
- Editing or improving an existing skill
- Verifying a skill's behavior
**How to install:**
```bash
npx claude install superpowers
```
**Trigger phrase:** `/superpowers:writing-skills`

138
tdd/SKILL.md Normal file
View file

@ -0,0 +1,138 @@
---
name: tdd
description: Guide test-driven development (TDD) workflows — write failing tests first, then implement code to make them pass. Use this skill when the user wants to practice TDD, write tests before code, or build features using the red-green-refactor cycle.
---
# Test-Driven Development (TDD)
Guide development using the TDD cycle: Red → Green → Refactor.
## TDD Cycle
```
Red → Write a failing test that defines desired behavior
Green → Write the minimal code to make the test pass
Refactor → Clean up code while keeping tests green
```
Each cycle should be small — a few minutes per iteration. Never skip the Red phase.
## Step 1: Red — Write a Failing Test
Before writing any implementation code:
1. **Define the behavior** — what should this unit do?
2. **Write a test** that asserts that behavior
3. **Run the test** — confirm it fails (not errors — fails)
4. If the test passes without implementation, the test is wrong or already covered
A good test:
- Tests one behavior (single assertion or related assertions)
- Has a descriptive name: `test_returns_error_when_input_is_empty`
- Is fast and isolated — no external dependencies (use mocks/stubs)
- Is deterministic — same result every run
**Test naming pattern:** `test_[unit]_[scenario]_[expected_result]`
## Step 2: Green — Write Minimal Implementation
Write the **simplest possible code** to make the test pass:
- Don't over-engineer
- Don't add features not covered by a test
- It's okay to write ugly code here — refactor comes next
- Return hardcoded values if that makes the test pass initially (triangulation)
Run the test — confirm it passes. If other tests break, fix them.
## Step 3: Refactor — Clean Without Breaking
Now improve the code:
- Remove duplication
- Improve naming
- Simplify logic
- Apply patterns and abstractions
- Run tests after every change — if they break, undo and try again
## When to Write Tests
TDD applies to:
- New features (write test first, always)
- Bug fixes (write a failing test that reproduces the bug, then fix it)
- Refactoring (tests provide safety net)
## Test Structure: Arrange-Act-Assert (AAA)
```python
def test_add_two_numbers():
# Arrange
calculator = Calculator()
# Act
result = calculator.add(2, 3)
# Assert
assert result == 5
```
## Mocking and Isolation
Tests should be isolated from external dependencies:
**JavaScript (Jest):**
```js
jest.mock('./api', () => ({
fetchUser: jest.fn().mockResolvedValue({ id: 1, name: 'Alice' })
}));
```
**Python (unittest.mock):**
```python
from unittest.mock import patch, MagicMock
@patch('module.requests.get')
def test_fetch_user(mock_get):
mock_get.return_value.json.return_value = {'id': 1}
result = fetch_user(1)
assert result['id'] == 1
```
## TDD Workflow with Claude
When building a feature with TDD:
1. **Describe the feature** — Claude will help identify testable units
2. **Write the first test** — Claude generates a failing test
3. **Run the test** — confirm it fails
4. **Write minimal implementation** — Claude writes just enough code
5. **Run tests** — confirm passing
6. **Refactor** — Claude suggests improvements
7. **Repeat** for the next behavior
## Test Organization
```
src/
feature/
feature.js
feature.test.js # co-located with source
tests/
unit/ # or organized by type
integration/
e2e/
```
## Common TDD Pitfalls
- **Writing tests after code** — this is not TDD, just testing
- **Tests that never fail** — always verify the red phase
- **Testing implementation details** — test behavior, not internals
- **Slow tests** — slow tests kill the TDD rhythm; mock I/O
- **Giant test methods** — one test per behavior
- **Skipping refactor phase** — green without refactor accumulates debt
## Notes for Claude
- Always start with the test file, never the implementation
- Generate tests that are specific about inputs and outputs
- After green, actively look for duplication and suggest refactors
- If the user writes tests after code, gently redirect to the TDD approach for future work