Compare commits

...

6 Commits

Author SHA1 Message Date
sck_0
56e2ccf719 docs: add 33 new skills to Full Skill Registry table 2026-01-20 08:56:40 +01:00
sck_0
c299e36360 chore: regenerate skills_index.json (223 skills) 2026-01-20 08:51:56 +01:00
sck_0
4e8e5069fa feat: add 33 skills from vudovn/antigravity-kit
- Added: api-patterns, app-builder, architecture, bash-linux, behavioral-modes,
  clean-code, code-review-checklist, database-design, deployment-procedures,
  docker-expert, documentation-templates, game-development, geo-fundamentals,
  i18n-localization, lint-and-validate, mobile-design, nestjs-expert,
  nextjs-best-practices, nodejs-best-practices, parallel-agents,
  performance-profiling, plan-writing, powershell-windows, prisma-expert,
  python-patterns, react-patterns, red-team-tactics, seo-fundamentals,
  server-management, tailwind-patterns, tdd-workflow, typescript-expert,
  vulnerability-scanner
- Updated README: skill count 179 → 223
- Added credit for vudovn/antigravity-kit (MIT License)

Source: https://github.com/vudovn/antigravity-kit
2026-01-20 08:51:02 +01:00
sck_0
36f99442fe fix: correct broken documentation links
- CONTRIBUTING_GUIDE.md → CONTRIBUTING.md (12 refs)
- QUICK_START_VISUAL.md → VISUAL_GUIDE.md (2 refs)
2026-01-20 08:39:30 +01:00
Mohammad Faiz
13f16b7585 docs: Add comprehensive beginner-friendly documentation (#7)
* Add files via upload

* Standardize section headers in CONTRIBUTING.md

* Remove emojis from GETTING_STARTED.md headings

* Update section headings in FAQ.md

* Remove emojis from example section headers

* Remove emoji from SKILL_ANATOMY.md headings

* Remove emojis from Visual Quick Start Guide
2026-01-20 08:37:50 +01:00
zebbern
ebb8f19937 feat: add author metadata to zebbern security skills (#8)
Added metadata block with author: zebbern and version: 1.1 to all 29 security skills originally from claude-code-guide repository:
- active-directory-attacks, api-fuzzing-bug-bounty, aws-penetration-testing
- broken-authentication, burp-suite-testing, cloud-penetration-testing
- ethical-hacking-methodology, file-path-traversal, html-injection-testing
- idor-testing, linux-privilege-escalation, linux-shell-scripting
- metasploit-framework, network-101, pentest-checklist, pentest-commands
- privilege-escalation-methods, red-team-tools, scanning-tools
- shodan-reconnaissance, smtp-penetration-testing, sql-injection-testing
- sqlmap-database-pentesting, ssh-penetration-testing, top-web-vulnerabilities
- windows-privilege-escalation, wireshark-analysis, wordpress-penetration-testing
- xss-html-injection
2026-01-20 08:27:53 +01:00
147 changed files with 23921 additions and 12 deletions

401
CONTRIBUTING.md Normal file
View File

@@ -0,0 +1,401 @@
# 🤝 Contributing Guide - Make It Easy for Everyone!
**Thank you for wanting to make this repo better!** This guide shows you exactly how to contribute, even if you're new to open source.
---
## Ways to Contribute
You don't need to be an expert! Here are ways anyone can help:
### 1. Improve Documentation (Easiest!)
- Fix typos or grammar
- Make explanations clearer
- Add examples to existing skills
- Translate documentation to other languages
### 2. Report Issues
- Found something confusing? Tell us!
- Skill not working? Let us know!
- Have suggestions? We want to hear them!
### 3. Create New Skills
- Share your expertise as a skill
- Fill gaps in the current collection
- Improve existing skills
### 4. Test and Validate
- Try skills and report what works/doesn't work
- Test on different AI tools
- Suggest improvements
---
## How to Improve Documentation
### Super Easy Method (No Git Knowledge Needed!)
1. **Find the file** you want to improve on GitHub
2. **Click the pencil icon** (✏️) to edit
3. **Make your changes** in the browser
4. **Click "Propose changes"** at the bottom
5. **Done!** We'll review and merge it
### Using Git (If You Know How)
```bash
# 1. Fork the repo on GitHub (click the Fork button)
# 2. Clone your fork
git clone https://github.com/YOUR-USERNAME/antigravity-awesome-skills.git
cd antigravity-awesome-skills
# 3. Create a branch
git checkout -b improve-docs
# 4. Make your changes
# Edit files in your favorite editor
# 5. Commit and push
git add .
git commit -m "docs: make XYZ clearer"
git push origin improve-docs
# 6. Open a Pull Request on GitHub
```
---
## How to Create a New Skill
### What Makes a Good Skill?
A skill should:
- ✅ Solve a specific problem
- ✅ Be reusable across projects
- ✅ Have clear instructions
- ✅ Include examples when possible
### Step-by-Step: Create Your First Skill
#### Step 1: Choose Your Skill Topic
Ask yourself:
- What am I good at?
- What do I wish my AI assistant knew better?
- What task do I do repeatedly?
**Examples:**
- "I'm good at Docker, let me create a Docker skill"
- "I wish AI understood Tailwind better"
- "I keep setting up the same testing patterns"
#### Step 2: Create the Folder Structure
```bash
# Navigate to the skills directory
cd skills/
# Create your skill folder (use lowercase with hyphens)
mkdir my-awesome-skill
# Create the SKILL.md file
cd my-awesome-skill
touch SKILL.md
```
#### Step 3: Write Your SKILL.md
Every skill needs this basic structure:
```markdown
---
name: my-awesome-skill
description: "Brief one-line description of what this skill does"
---
# Skill Title
## Overview
Explain what this skill does and when to use it.
## When to Use This Skill
- Use when [scenario 1]
- Use when [scenario 2]
- Use when [scenario 3]
## How It Works
### Step 1: [First Step]
Explain what to do first...
### Step 2: [Second Step]
Explain the next step...
### Step 3: [Final Step]
Explain how to finish...
## Examples
### Example 1: [Common Use Case]
\`\`\`
Show example code or commands here
\`\`\`
### Example 2: [Another Use Case]
\`\`\`
More examples...
\`\`\`
## Best Practices
- ✅ Do this
- ✅ Also do this
- ❌ Don't do this
- ❌ Avoid this
## Common Pitfalls
- **Problem:** Description of common issue
**Solution:** How to fix it
## Additional Resources
- [Link to documentation](https://example.com)
- [Tutorial](https://example.com)
```
#### Step 4: Test Your Skill
1. **Copy it to your AI tool's skills directory:**
```bash
cp -r skills/my-awesome-skill ~/.agent/skills/
```
2. **Try using it:**
```
@my-awesome-skill help me with [task]
```
3. **Does it work?** Great! If not, refine it.
#### Step 5: Validate Your Skill
Run the validation script:
```bash
python3 scripts/validate_skills.py
```
This checks:
- ✅ SKILL.md exists
- ✅ Frontmatter is correct
- ✅ Name matches folder name
- ✅ Description exists
#### Step 6: Submit Your Skill
```bash
# 1. Add your skill
git add skills/my-awesome-skill/
# 2. Commit with a clear message
git commit -m "feat: add my-awesome-skill for [purpose]"
# 3. Push to your fork
git push origin my-branch
# 4. Open a Pull Request on GitHub
```
---
## Skill Template (Copy & Paste)
Save time! Copy this template:
```markdown
---
name: your-skill-name
description: "One sentence describing what this skill does and when to use it"
---
# Your Skill Name
## Overview
[2-3 sentences explaining what this skill does]
## When to Use This Skill
- Use when you need to [scenario 1]
- Use when you want to [scenario 2]
- Use when working with [scenario 3]
## Core Concepts
### Concept 1
[Explain key concept]
### Concept 2
[Explain another key concept]
## Step-by-Step Guide
### 1. [First Step Name]
[Detailed instructions]
### 2. [Second Step Name]
[Detailed instructions]
### 3. [Third Step Name]
[Detailed instructions]
## Examples
### Example 1: [Use Case Name]
\`\`\`language
// Example code here
\`\`\`
**Explanation:** [What this example demonstrates]
### Example 2: [Another Use Case]
\`\`\`language
// More example code
\`\`\`
**Explanation:** [What this example demonstrates]
## Best Practices
-**Do:** [Good practice]
-**Do:** [Another good practice]
-**Don't:** [What to avoid]
-**Don't:** [Another thing to avoid]
## Troubleshooting
### Problem: [Common Issue]
**Symptoms:** [How you know this is the problem]
**Solution:** [How to fix it]
### Problem: [Another Issue]
**Symptoms:** [How you know this is the problem]
**Solution:** [How to fix it]
## Related Skills
- `@related-skill-1` - [When to use this instead]
- `@related-skill-2` - [How this complements your skill]
## Additional Resources
- [Official Documentation](https://example.com)
- [Tutorial](https://example.com)
- [Community Guide](https://example.com)
```
---
## How to Report Issues
### Found a Bug?
1. **Check existing issues** - Maybe it's already reported
2. **Open a new issue** with this info:
- What skill has the problem?
- What AI tool are you using?
- What did you expect to happen?
- What actually happened?
- Steps to reproduce
### Found Something Confusing?
1. **Open an issue** titled: "Documentation unclear: [topic]"
2. **Explain:**
- What part is confusing?
- What did you expect to find?
- How could it be clearer?
---
## Contribution Checklist
Before submitting your contribution:
- [ ] My skill has a clear, descriptive name
- [ ] The `SKILL.md` has proper frontmatter (name + description)
- [ ] I've included examples
- [ ] I've tested the skill with an AI assistant
- [ ] I've run `python3 scripts/validate_skills.py`
- [ ] My commit message is clear (e.g., "feat: add docker-compose skill")
- [ ] I've checked for typos and grammar
---
## Commit Message Guidelines
Use these prefixes:
- `feat:` - New skill or major feature
- `docs:` - Documentation improvements
- `fix:` - Bug fixes
- `refactor:` - Code improvements without changing functionality
- `test:` - Adding or updating tests
- `chore:` - Maintenance tasks
**Examples:**
```
feat: add kubernetes-deployment skill
docs: improve getting started guide
fix: correct typo in stripe-integration skill
docs: add examples to react-best-practices
```
---
## Learning Resources
### New to Git/GitHub?
- [GitHub's Hello World Guide](https://guides.github.com/activities/hello-world/)
- [Git Basics](https://git-scm.com/book/en/v2/Getting-Started-Git-Basics)
### New to Markdown?
- [Markdown Guide](https://www.markdownguide.org/basic-syntax/)
- [GitHub Markdown](https://guides.github.com/features/mastering-markdown/)
### New to Open Source?
- [First Contributions](https://github.com/firstcontributions/first-contributions)
- [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
---
## Need Help?
- **Questions?** Open a [Discussion](https://github.com/sickn33/antigravity-awesome-skills/discussions)
- **Stuck?** Open an [Issue](https://github.com/sickn33/antigravity-awesome-skills/issues)
- **Want feedback?** Open a [Draft Pull Request](https://github.com/sickn33/antigravity-awesome-skills/pulls)
---
## Recognition
All contributors are recognized in our [Contributors](https://github.com/sickn33/antigravity-awesome-skills/graphs/contributors) page!
---
## Code of Conduct
- Be respectful and inclusive
- Welcome newcomers
- Focus on constructive feedback
- Help others learn
---
**Thank you for making this project better for everyone!**
Every contribution, no matter how small, makes a difference. Whether you fix a typo, improve a sentence, or create a whole new skill - you're helping thousands of developers!

528
FAQ.md Normal file
View File

@@ -0,0 +1,528 @@
# ❓ Frequently Asked Questions (FAQ)
**Got questions?** You're not alone! Here are answers to the most common questions about Antigravity Awesome Skills.
---
## 🎯 General Questions
### What are "skills" exactly?
Skills are specialized instruction files that teach AI assistants how to handle specific tasks. Think of them as expert knowledge modules that your AI can load on-demand.
**Simple analogy:** Just like you might consult different experts (a lawyer, a doctor, a mechanic), skills let your AI become an expert in different areas when you need them.
---
### Do I need to install all 179 skills?
**No!** When you clone the repository, all skills are available, but your AI only loads them when you explicitly invoke them with `@skill-name` or `/skill-name`.
It's like having a library - all the books are there, but you only read the ones you need.
---
### Which AI tools work with these skills?
These skills work with any AI coding assistant that supports the `SKILL.md` format:
-**Claude Code** (Anthropic CLI)
-**Gemini CLI** (Google)
-**Codex CLI** (OpenAI)
-**Cursor** (AI IDE)
-**Antigravity IDE**
-**OpenCode**
- ⚠️ **GitHub Copilot** (partial support)
---
### Are these skills free to use?
**Yes!** This repository is licensed under MIT License, which means:
- ✅ Free for personal use
- ✅ Free for commercial use
- ✅ You can modify them
- ✅ You can redistribute them
---
### Do skills work offline?
The skill files themselves are stored locally on your computer, but your AI assistant needs an internet connection to function. So:
- ✅ Skills are local files
- ❌ AI assistant needs internet
---
## Installation & Setup
### Where should I install the skills?
The universal path that works with most tools is `.agent/skills/`:
```bash
git clone https://github.com/sickn33/antigravity-awesome-skills.git .agent/skills
```
**Tool-specific paths:**
- Claude Code: `.claude/skills/` or `.agent/skills/`
- Gemini CLI: `.gemini/skills/` or `.agent/skills/`
- Cursor: `.cursor/skills/` or project root
- Antigravity: `.agent/skills/`
---
### Can I install skills in multiple projects?
**Yes!** You have two options:
**Option 1: Global Installation** (recommended)
Install once in your home directory, works for all projects:
```bash
cd ~
git clone https://github.com/sickn33/antigravity-awesome-skills.git .agent/skills
```
**Option 2: Per-Project Installation**
Install in each project directory:
```bash
cd /path/to/your/project
git clone https://github.com/sickn33/antigravity-awesome-skills.git .agent/skills
```
---
### How do I update skills to the latest version?
Navigate to your skills directory and pull the latest changes:
```bash
cd .agent/skills
git pull origin main
```
---
### Can I install only specific skills?
**Yes!** You can manually copy individual skill folders:
```bash
# Clone the full repo first
git clone https://github.com/sickn33/antigravity-awesome-skills.git temp-skills
# Copy only the skills you want
mkdir -p .agent/skills
cp -r temp-skills/skills/brainstorming .agent/skills/
cp -r temp-skills/skills/stripe-integration .agent/skills/
# Clean up
rm -rf temp-skills
```
---
## Using Skills
### How do I invoke a skill?
Use the `@` symbol followed by the skill name:
```
@skill-name your request here
```
**Examples:**
```
@brainstorming help me design a todo app
@stripe-integration add subscription billing
@systematic-debugging fix this test failure
```
Some tools also support `/skill-name` syntax.
---
### How do I know which skill to use?
**Method 1: Browse the README**
Check the [Full Skill Registry](README.md#full-skill-registry-179179) organized by category
**Method 2: Search by keyword**
```bash
ls skills/ | grep "keyword"
```
**Method 3: Ask your AI**
```
What skills are available for [topic]?
```
---
### Can I use multiple skills at once?
**Yes!** You can invoke multiple skills in the same conversation:
```
@brainstorming help me design this feature
[After brainstorming...]
@test-driven-development now let's implement it with tests
```
---
### What if a skill doesn't work?
**Troubleshooting steps:**
1. **Check installation path**
```bash
ls .agent/skills/
```
2. **Verify skill exists**
```bash
ls .agent/skills/skill-name/
```
3. **Check SKILL.md exists**
```bash
cat .agent/skills/skill-name/SKILL.md
```
4. **Try restarting your AI assistant**
5. **Check for typos in skill name**
- Use `@brainstorming` not `@brain-storming`
- Names are case-sensitive in some tools
6. **Report the issue**
[Open an issue](https://github.com/sickn33/antigravity-awesome-skills/issues) with details
---
## 🤝 Contributing
### I'm new to open source. Can I still contribute?
**Absolutely!** Everyone starts somewhere. We welcome contributions from beginners:
- Fix typos or grammar
- Improve documentation clarity
- Add examples to existing skills
- Report issues or confusing parts
Check out [CONTRIBUTING.md](CONTRIBUTING.md) for step-by-step instructions.
---
### Do I need to know how to code to contribute?
**No!** Many valuable contributions don't require coding:
- **Documentation improvements** - Make things clearer
- **Examples** - Add real-world usage examples
- **Issue reporting** - Tell us what's confusing
- **Testing** - Try skills and report what works
---
### How do I create a new skill?
**Quick version:**
1. Create a folder: `skills/my-skill-name/`
2. Create `SKILL.md` with frontmatter and content
3. Test it with your AI assistant
4. Run validation: `python3 scripts/validate_skills.py`
5. Submit a Pull Request
**Detailed version:** See [CONTRIBUTING.md](CONTRIBUTING.md)
---
### What makes a good skill?
A good skill:
- ✅ Solves a specific problem
- ✅ Has clear, actionable instructions
- ✅ Includes examples
- ✅ Is reusable across projects
- ✅ Follows the standard structure
See [SKILL_ANATOMY.md](docs/SKILL_ANATOMY.md) for details.
---
### How long does it take for my contribution to be reviewed?
Review times vary, but typically:
- **Simple fixes** (typos, docs): 1-3 days
- **New skills**: 3-7 days
- **Major changes**: 1-2 weeks
You can speed this up by:
- Following the contribution guidelines
- Writing clear commit messages
- Testing your changes
- Responding to feedback quickly
---
## Technical Questions
### What's the difference between SKILL.md and README.md?
- **SKILL.md** (required): The actual skill definition that the AI reads
- **README.md** (optional): Human-readable documentation about the skill
The AI primarily uses `SKILL.md`, while developers read `README.md`.
---
### Can I use scripts or code in my skill?
**Yes!** Skills can include:
- `scripts/` - Helper scripts
- `examples/` - Example code
- `templates/` - Code templates
- `references/` - Documentation
Reference them in your `SKILL.md`:
```markdown
Run the setup script:
\`\`\`bash
bash scripts/setup.sh
\`\`\`
```
---
### What programming languages can skills cover?
**Any language!** Current skills cover:
- JavaScript/TypeScript
- Python
- Go
- Rust
- Swift
- Kotlin
- Shell scripting
- And many more...
---
### Can skills call other skills?
**Yes!** Skills can reference other skills:
```markdown
## Workflow
1. First, use `@brainstorming` to design
2. Then, use `@writing-plans` to plan
3. Finally, use `@test-driven-development` to implement
```
---
### How do I validate my skill before submitting?
Run the validation script:
```bash
python3 scripts/validate_skills.py
```
This checks:
- ✅ SKILL.md exists
- ✅ Frontmatter is valid
- ✅ Name matches folder name
- ✅ Description exists
---
## Learning & Best Practices
### Which skills should I try first?
**For beginners:**
- `@brainstorming` - Design before coding
- `@systematic-debugging` - Fix bugs methodically
- `@git-pushing` - Commit with good messages
**For developers:**
- `@test-driven-development` - Write tests first
- `@react-best-practices` - Modern React patterns
- `@senior-fullstack` - Full-stack development
**For security:**
- `@ethical-hacking-methodology` - Security basics
- `@burp-suite-testing` - Web app testing
---
### How do I learn to write good skills?
**Learning path:**
1. **Read existing skills** - Study 5-10 well-written skills
2. **Use skills** - Try them with your AI assistant
3. **Read guides** - Check [SKILL_ANATOMY.md](docs/SKILL_ANATOMY.md)
4. **Start simple** - Create a basic skill first
5. **Get feedback** - Submit and learn from reviews
6. **Iterate** - Improve based on feedback
**Recommended skills to study:**
- `skills/brainstorming/SKILL.md` - Clear structure
- `skills/systematic-debugging/SKILL.md` - Comprehensive
- `skills/git-pushing/SKILL.md` - Simple and focused
---
### Are there any skills for learning AI/ML?
**Yes!** Check out:
- `@rag-engineer` - RAG systems
- `@prompt-engineering` - Prompt design
- `@langgraph` - Multi-agent systems
- `@ai-agents-architect` - Agent architecture
- `@llm-app-patterns` - LLM application patterns
---
## Troubleshooting
### My AI assistant doesn't recognize skills
**Possible causes:**
1. **Wrong installation path**
- Check your tool's documentation for the correct path
- Try `.agent/skills/` as the universal path
2. **Skill name typo**
- Verify the exact skill name: `ls .agent/skills/`
- Use the exact name from the folder
3. **Tool doesn't support skills**
- Verify your tool supports the SKILL.md format
- Check the [Compatibility](#-compatibility) section
4. **Need to restart**
- Restart your AI assistant after installing skills
---
### A skill gives incorrect or outdated advice
**Please report it!**
1. [Open an issue](https://github.com/sickn33/antigravity-awesome-skills/issues)
2. Include:
- Which skill
- What's incorrect
- What should it say instead
- Links to correct documentation
We'll update it quickly!
---
### Can I modify skills for my own use?
**Yes!** The MIT License allows you to:
- ✅ Modify skills for your needs
- ✅ Create private versions
- ✅ Customize for your team
**To modify:**
1. Copy the skill to a new location
2. Edit the SKILL.md file
3. Use your modified version
**Consider contributing improvements back!**
---
## Statistics & Info
### How many skills are there?
**179 skills** across 10+ categories as of the latest update.
---
### How often are skills updated?
- **Bug fixes**: As soon as reported
- **New skills**: Added regularly by contributors
- **Updates**: When best practices change
**Stay updated:**
```bash
cd .agent/skills
git pull origin main
```
---
### Who maintains this repository?
This is a community-driven project with contributions from:
- Original creators
- Open source contributors
- AI coding assistant users worldwide
See [Credits & Sources](README.md#credits--sources) for attribution.
---
## Still Have Questions?
### Where can I get help?
- **[GitHub Discussions](https://github.com/sickn33/antigravity-awesome-skills/discussions)** - Ask questions
- **[GitHub Issues](https://github.com/sickn33/antigravity-awesome-skills/issues)** - Report bugs
- **Documentation** - Read the guides in this repo
- **Community** - Connect with other users
---
### How can I stay updated?
- **Star the repository** on GitHub
- **Watch the repository** for updates
- **Subscribe to releases** for notifications
- **Follow contributors** on social media
---
### Can I use these skills commercially?
**Yes!** The MIT License permits commercial use. You can:
- ✅ Use in commercial projects
- ✅ Use in client work
- ✅ Include in paid products
- ✅ Modify for commercial purposes
**Only requirement:** Keep the license notice.
---
## 💡 Pro Tips
- Start with `@brainstorming` before building anything new
- Use `@systematic-debugging` when stuck on bugs
- Try `@test-driven-development` for better code quality
- Explore `@skill-creator` to make your own skills
- Read skill descriptions to understand when to use them
---
**Question not answered?**
[Open a discussion](https://github.com/sickn33/antigravity-awesome-skills/discussions) and we'll help you out! 🙌

201
GETTING_STARTED.md Normal file
View File

@@ -0,0 +1,201 @@
# Getting Started with Antigravity Awesome Skills
**New here? This guide will help you understand and use this repository in 5 minutes!**
---
## 🤔 What Are "Skills"?
Think of skills as **specialized instruction manuals** for AI coding assistants.
**Simple analogy:** Just like you might hire different experts (a designer, a security expert, a marketer), these skills let your AI assistant become an expert in specific areas when you need them.
---
## 📦 What's Inside This Repository?
This repo contains **179 ready-to-use skills** organized in the `skills/` folder. Each skill is a folder with at least one file: `SKILL.md`
```
skills/
├── brainstorming/
│ └── SKILL.md ← The skill definition
├── stripe-integration/
│ └── SKILL.md
├── react-best-practices/
│ └── SKILL.md
└── ... (176 more skills)
```
---
## How Do Skills Work?
### Step 1: Install Skills
Copy the skills to your AI tool's directory:
```bash
# For most AI tools (Claude Code, Gemini CLI, etc.)
git clone https://github.com/sickn33/antigravity-awesome-skills.git .agent/skills
```
### Step 2: Use a Skill
In your AI chat, mention the skill:
```
@brainstorming help me design a todo app
```
or
```
/stripe-integration add payment processing to my app
```
### Step 3: The AI Becomes an Expert
The AI loads that skill's knowledge and helps you with specialized expertise!
---
## Which AI Tools Work With This?
| Tool | Works? | Installation Path |
|------|--------|-------------------|
| **Claude Code** | ✅ Yes | `.claude/skills/` or `.agent/skills/` |
| **Gemini CLI** | ✅ Yes | `.gemini/skills/` or `.agent/skills/` |
| **Cursor** | ✅ Yes | `.cursor/skills/` |
| **GitHub Copilot** | ⚠️ Partial | Copy to `.github/copilot/` |
| **Antigravity IDE** | ✅ Yes | `.agent/skills/` |
---
## Skill Categories (Simplified)
### **Creative & Design** (10 skills)
Make beautiful things: UI design, art, themes, web components
- Try: `@frontend-design`, `@canvas-design`, `@ui-ux-pro-max`
### **Development** (25 skills)
Write better code: testing, debugging, React patterns, architecture
- Try: `@test-driven-development`, `@systematic-debugging`, `@react-best-practices`
### **Security** (50 skills)
Ethical hacking and penetration testing tools
- Try: `@ethical-hacking-methodology`, `@burp-suite-testing`
### **AI & Agents** (30 skills)
Build AI apps: RAG, LangGraph, prompt engineering, voice agents
- Try: `@rag-engineer`, `@prompt-engineering`, `@langgraph`
### **Documents** (4 skills)
Work with Word, Excel, PowerPoint, PDF files
- Try: `@docx-official`, `@xlsx-official`, `@pdf-official`
### **Marketing** (23 skills)
Grow your product: SEO, copywriting, ads, email campaigns
- Try: `@copywriting`, `@seo-audit`, `@page-cro`
### **Integrations** (25 skills)
Connect to services: Stripe, Firebase, Twilio, Discord, Slack
- Try: `@stripe-integration`, `@firebase`, `@clerk-auth`
---
## Your First Skill: A Quick Example
Let's try the **brainstorming** skill:
1. **Open your AI assistant** (Claude Code, Cursor, etc.)
2. **Type this:**
```
@brainstorming I want to build a simple weather app
```
3. **What happens:**
- The AI loads the brainstorming skill
- It asks you questions one at a time
- It helps you design the app before coding
- It creates a design document for you
4. **Result:** You get a well-thought-out plan instead of jumping straight to code!
---
## How to Find the Right Skill
### Method 1: Browse by Category
Check the [Full Skill Registry](README.md#full-skill-registry-179179) in the main README
### Method 2: Search by Keyword
Use your file explorer or terminal:
```bash
# Find skills related to "testing"
ls skills/ | grep test
# Find skills related to "auth"
ls skills/ | grep auth
```
### Method 3: Look at the Index
Check `skills_index.json` for a machine-readable list
---
## 🤝 Want to Contribute?
Great! Here's how:
### Option 1: Improve Documentation
- Make READMEs clearer
- Add more examples
- Fix typos or confusing parts
### Option 2: Create a New Skill
See our [CONTRIBUTING.md](CONTRIBUTING.md) for step-by-step instructions
### Option 3: Report Issues
Found something confusing? [Open an issue](https://github.com/sickn33/antigravity-awesome-skills/issues)
---
## ❓ Common Questions
### Q: Do I need to install all 179 skills?
**A:** No! Clone the whole repo, and your AI will only load skills when you use them.
### Q: Can I create my own skills?
**A:** Yes! Check out the `@skill-creator` skill or read [CONTRIBUTING.md](CONTRIBUTING.md)
### Q: What if my AI tool isn't listed?
**A:** If it supports the `SKILL.md` format, try `.agent/skills/` - it's the universal path.
### Q: Are these skills free?
**A:** Yes! MIT License. Use them however you want.
### Q: Do skills work offline?
**A:** The skill files are local, but your AI assistant needs internet to function.
---
## Next Steps
1. ✅ Install the skills in your AI tool
2. ✅ Try 2-3 skills from different categories
3. ✅ Read [CONTRIBUTING.md](CONTRIBUTING.md) if you want to help
4. ✅ Star the repo if you find it useful! ⭐
---
## 💡 Pro Tips
- **Start with `@brainstorming`** before building anything new
- **Use `@systematic-debugging`** when you're stuck on a bug
- **Try `@test-driven-development`** to write better code
- **Explore `@skill-creator`** to make your own skills
---
**Still confused?** Open an issue and we'll help you out! 🙌
**Ready to dive deeper?** Check out the main [README.md](README.md) for the complete skill list.

View File

@@ -1,6 +1,6 @@
# 🌌 Antigravity Awesome Skills: 179+ Agentic Skills for Claude Code, Gemini CLI, Cursor, Copilot & More
# 🌌 Antigravity Awesome Skills: 223+ Agentic Skills for Claude Code, Gemini CLI, Cursor, Copilot & More
> **The Ultimate Collection of 179+ Universal Agentic Skills for AI Coding Assistants — Claude Code, Gemini CLI, Codex CLI, Antigravity IDE, GitHub Copilot, Cursor, OpenCode**
> **The Ultimate Collection of 223+ Universal Agentic Skills for AI Coding Assistants — Claude Code, Gemini CLI, Codex CLI, Antigravity IDE, GitHub Copilot, Cursor, OpenCode**
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
[![Claude Code](https://img.shields.io/badge/Claude%20Code-Anthropic-purple)](https://claude.ai)
@@ -11,7 +11,7 @@
[![OpenCode](https://img.shields.io/badge/OpenCode-CLI-gray)](https://github.com/opencode-ai/opencode)
[![Antigravity](https://img.shields.io/badge/Antigravity-DeepMind-red)](https://github.com/anthropics/antigravity)
**Antigravity Awesome Skills** is a curated, battle-tested library of **179 high-performance agentic skills** designed to work seamlessly across all major AI coding assistants:
**Antigravity Awesome Skills** is a curated, battle-tested library of **223 high-performance agentic skills** designed to work seamlessly across all major AI coding assistants:
- 🟣 **Claude Code** (Anthropic CLI)
- 🔵 **Gemini CLI** (Google DeepMind)
@@ -25,6 +25,7 @@ This repository provides essential skills to transform your AI assistant into a
## 📍 Table of Contents
- [🚀 New Here? Start Here!](#-new-here-start-here)
- [🔌 Compatibility](#-compatibility)
- [Features & Categories](#features--categories)
- [Full Skill Registry](#full-skill-registry-155155)
@@ -35,6 +36,34 @@ This repository provides essential skills to transform your AI assistant into a
---
## New Here? Start Here!
**First time using this repository?** We've created beginner-friendly guides to help you get started:
- **[GETTING_STARTED.md](GETTING_STARTED.md)** - Complete beginner's guide (5-minute read)
- **[CONTRIBUTING.md](CONTRIBUTING.md)** - How to contribute (step-by-step)
- **[SKILL_ANATOMY.md](docs/SKILL_ANATOMY.md)** - Understanding how skills work
- **[VISUAL_GUIDE.md](docs/VISUAL_GUIDE.md)** - Visual guide with diagrams
**Quick Start:**
```bash
# 1. Install skills
git clone https://github.com/sickn33/antigravity-awesome-skills.git .agent/skills
# 2. Use a skill in your AI assistant
@brainstorming help me design a todo app
```
That's it! Your AI assistant now has 223 specialized skills. 🎉
**Additional Resources:**
- 💡 **[Real-World Examples](docs/EXAMPLES.md)** - See skills in action
-**[FAQ](FAQ.md)** - Common questions answered
---
## 🔌 Compatibility
These skills follow the universal **SKILL.md** format and work with any AI coding assistant that supports agentic skills:
@@ -80,7 +109,7 @@ The repository is organized into several key areas of expertise:
---
## Full Skill Registry (179/179)
## Full Skill Registry (223/223)
Below is the complete list of available skills. Each skill folder contains a `SKILL.md` that can be imported into Antigravity or Claude Code.
@@ -103,13 +132,18 @@ Below is the complete list of available skills. Each skill folder contains a `SK
| **Algorithmic Art** | Creating algorithmic art using p5. | `skills/algorithmic-art` |
| **Analytics Tracking** | Set up analytics tracking with GA4, GTM, and custom event implementations for marketing measurement. | `skills/analytics-tracking` |
| **API Fuzzing for Bug Bounty** | This skill should be used when the user asks to "test API security", "fuzz APIs", "find IDOR vulnerabilities", "test REST API", "test GraphQL", "API penetration testing", "bug bounty API testing", or needs guidance on API security assessment techniques. | `skills/api-fuzzing-bug-bounty` |
| **API Patterns** | API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning. | `skills/api-patterns` |
| **App Builder** | Main application building orchestrator. Creates full-stack applications from natural language requests. | `skills/app-builder` |
| **App Store Optimization** | Complete App Store Optimization (ASO) toolkit for researching, optimizing, and tracking mobile app performance on Apple App Store and Google Play Store. | `skills/app-store-optimization` |
| **Architecture** | Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. | `skills/architecture` |
| **Autonomous Agent Patterns** | "Design patterns for building autonomous coding agents. | `skills/autonomous-agent-patterns` |
| **Autonomous Agents** | AI systems that independently decompose goals, plan actions, execute tools. ReAct, reflection. | `skills/autonomous-agents` |
| **AWS Penetration Testing** | This skill should be used when the user asks to "pentest AWS", "test AWS security", "enumerate IAM", "exploit cloud infrastructure", "AWS privilege escalation", "S3 bucket testing", "metadata SSRF", "Lambda exploitation", or needs guidance on Amazon Web Services security assessment. | `skills/aws-penetration-testing` |
| **AWS Serverless** | Serverless on AWS. Lambda, API Gateway, DynamoDB, SQS/SNS, SAM/CDK deployment. | `skills/aws-serverless` |
| **Azure Functions** | Azure Functions patterns. Isolated worker model, Durable Functions, cold start optimization. | `skills/azure-functions` |
| **Backend Guidelines** | Comprehensive backend development guide for Node. | `skills/backend-dev-guidelines` |
| **Bash Linux** | Bash/Linux terminal patterns. Critical commands, piping, error handling, scripting. | `skills/bash-linux` |
| **Behavioral Modes** | AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). | `skills/behavioral-modes` |
| **BlockRun** | Agent wallet for LLM micropayments. Use when user needs capabilities Claude lacks (image generation, real-time X/Twitter data) or explicitly requests external models ("blockrun", "use grok", "use gpt", "dall-e", "deepseek"). | `skills/blockrun` |
| **Brainstorming** | "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. | `skills/brainstorming` |
| **Brand Guidelines (Anthropic)** | Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. | `skills/brand-guidelines-anthropic` |
@@ -123,22 +157,28 @@ Below is the complete list of available skills. Each skill folder contains a `SK
| **Canvas Design** | Create beautiful visual art in . | `skills/canvas-design` |
| **Claude Code Guide** | Master guide for using Claude Code effectively. | `skills/claude-code-guide` |
| **Claude D3.js** | Creating interactive data visualisations using d3. | `skills/claude-d3js-skill` |
| **Clean Code** | Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments. | `skills/clean-code` |
| **Clerk Auth** | Clerk auth implementation, middleware, organizations, webhooks, user sync. | `skills/clerk-auth` |
| **Cloud Penetration Testing** | This skill should be used when the user asks to "perform cloud penetration testing", "assess Azure or AWS or GCP security", "enumerate cloud resources", "exploit cloud misconfigurations", "test O365 security", "extract secrets from cloud environments", or "audit cloud infrastructure". | `skills/cloud-penetration-testing` |
| **Code Review Checklist** | Code review guidelines covering code quality, security, and best practices. | `skills/code-review-checklist` |
| **Competitor Alternatives** | Create compelling competitor comparison and alternative pages for SEO and conversions. | `skills/competitor-alternatives` |
| **Computer Use Agents** | AI agents that interact with computers like humans. Screen control, sandboxing. | `skills/computer-use-agents` |
| **Concise Planning** | Use when a user asks for a plan for a coding task, to generate a clear, actionable, and atomic checklist. | `skills/concise-planning` |
| **Competitor Alternatives** | Create compelling competitor comparison and alternative pages for SEO and conversions. | `skills/competitor-alternatives` |
| **Content Creator** | Create SEO-optimized marketing content with consistent brand voice. | `skills/content-creator` |
| **Context Window Management** | Managing LLM context windows. Summarization, trimming, routing. | `skills/context-window-management` |
| **Conversation Memory** | Persistent memory for LLM conversations. Short-term, long-term, entity-based memory. | `skills/conversation-memory` |
| **Core Components** | Core component library and design system patterns. | `skills/core-components` |
| **Copy Editing** | Edit and polish existing marketing copy with a systematic seven-sweeps framework. | `skills/copy-editing` |
| **Copywriting** | Write compelling marketing copy for homepages, landing pages, pricing pages, and feature pages. | `skills/copywriting` |
| **Core Components** | Core component library and design system patterns. | `skills/core-components` |
| **CrewAI** | Role-based multi-agent framework. Agent design, task definition, crew orchestration. | `skills/crewai` |
| **Cross-Site Scripting and HTML Injection Testing** | This skill should be used when the user asks to "test for XSS vulnerabilities", "perform cross-site scripting attacks", "identify HTML injection flaws", "exploit client-side injection vulnerabilities", "steal cookies via XSS", or "bypass content security policies". | `skills/xss-html-injection` |
| **Database Design** | Database design principles. Schema design, indexing strategy, ORM selection, serverless databases. | `skills/database-design` |
| **Deployment Procedures** | Production deployment principles. Safe deployment workflows, rollback strategies, and verification. | `skills/deployment-procedures` |
| **Discord Bot Architect** | Production Discord bots. Discord.js, Pycord, slash commands, sharding. | `skills/discord-bot-architect` |
| **Dispatching Parallel Agents** | Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies. | `skills/dispatching-parallel-agents` |
| **Doc Co-authoring** | Guide users through a structured workflow for co-authoring documentation. | `skills/doc-coauthoring` |
| **Docker Expert** | Docker containerization expert. Multi-stage builds, image optimization, container security, Docker Compose. | `skills/docker-expert` |
| **Documentation Templates** | Documentation templates and structure guidelines. README, API docs, code comments. | `skills/documentation-templates` |
| **DOCX (Official)** | "Comprehensive document creation, editing, and analysis with support for tracked changes, comments, formatting preservation, and text extraction. | `skills/docx-official` |
| **Email Sequence** | Create and optimize email sequences, drip campaigns, and lifecycle email programs. | `skills/email-sequence` |
| **Email Systems** | Transactional email, marketing automation, deliverability, infrastructure. | `skills/email-systems` |
@@ -153,12 +193,15 @@ Below is the complete list of available skills. Each skill folder contains a `SK
| **Free Tool Strategy** | Plan and build free tools for marketing, lead generation, and SEO value. | `skills/free-tool-strategy` |
| **Frontend Design** | Create distinctive, production-grade frontend interfaces with high design quality. | `skills/frontend-design` |
| **Frontend Guidelines** | Frontend development guidelines for React/TypeScript applications. | `skills/frontend-dev-guidelines` |
| **Game Development** | Game development orchestrator. Routes to platform-specific skills based on project needs. | `skills/game-development` |
| **GCP Cloud Run** | Serverless on GCP. Cloud Run services and functions, Pub/Sub. | `skills/gcp-cloud-run` |
| **GEO Fundamentals** | Generative Engine Optimization for AI search engines (ChatGPT, Claude, Perplexity). | `skills/geo-fundamentals` |
| **Git Pushing** | Stage, commit, and push git changes with conventional commit messages. | `skills/git-pushing` |
| **GitHub Workflow Automation** | "Automate GitHub workflows with AI assistance. | `skills/github-workflow-automation` |
| **GraphQL** | Schema design, resolvers, DataLoader, federation, Apollo/urql integration. | `skills/graphql` |
| **HTML Injection Testing** | This skill should be used when the user asks to "test for HTML injection", "inject HTML into web pages", "perform HTML injection attacks", "deface web applications", or "test content injection vulnerabilities". | `skills/html-injection-testing` |
| **HubSpot Integration** | HubSpot CRM integration. OAuth, CRM objects, webhooks, custom objects. | `skills/hubspot-integration` |
| **i18n Localization** | Internationalization and localization patterns. Detecting hardcoded strings, managing translations. | `skills/i18n-localization` |
| **IDOR Vulnerability Testing** | This skill should be used when the user asks to "test for insecure direct object references," "find IDOR vulnerabilities," "exploit broken access control," "enumerate user IDs or object references," or "bypass authorization to access other users' data. | `skills/idor-testing` |
| **Inngest** | Inngest for serverless background jobs, event-driven workflows. | `skills/inngest` |
| **Interactive Portfolio** | Building portfolios that land jobs. Developer, designer portfolios. | `skills/interactive-portfolio` |
@@ -169,6 +212,7 @@ Below is the complete list of available skills. Each skill folder contains a `SK
| **Langfuse** | Open-source LLM observability. Tracing, prompt management, evaluation. | `skills/langfuse` |
| **LangGraph** | Stateful, multi-actor AI applications. Graph construction, persistence. | `skills/langgraph` |
| **Launch Strategy** | Plan product launches, feature announcements, and go-to-market strategies. | `skills/launch-strategy` |
| **Lint and Validate** | Automatic quality control, linting, and static analysis procedures. | `skills/lint-and-validate` |
| **Linux Privilege Escalation** | This skill should be used when the user asks to "escalate privileges on Linux", "find privesc vectors on Linux systems", "exploit sudo misconfigurations", "abuse SUID binaries", "exploit cron jobs for root access", "enumerate Linux systems for privilege escalation", or "gain root access from low-privilege shell". | `skills/linux-privilege-escalation` |
| **Linux Shell Scripting** | This skill should be used when the user asks to "create bash scripts", "automate Linux tasks", "monitor system resources", "backup files", "manage users", or "write production shell scripts". | `skills/linux-shell-scripting` |
| **LLM App Patterns** | "Production-ready patterns for building LLM applications. | `skills/llm-app-patterns` |
@@ -177,39 +221,51 @@ Below is the complete list of available skills. Each skill folder contains a `SK
| **Marketing Psychology** | 70+ mental models and psychological principles for marketing and persuasion. | `skills/marketing-psychology` |
| **MCP Builder** | Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. | `skills/mcp-builder` |
| **Metasploit Framework** | This skill should be used when the user asks to "use Metasploit for penetration testing", "exploit vulnerabilities with msfconsole", "create payloads with msfvenom", "perform post-exploitation", "use auxiliary modules for scanning", or "develop custom exploits". | `skills/metasploit-framework` |
| **Moodle External API Development** | Create custom external web service APIs for Moodle LMS. Use when implementing web services for course management, user tracking, quiz operations, or custom plugin functionality. Covers parameter validation, database operations, error handling, service registration, and Moodle coding standards. | `skills/moodle-external-api-development` |
| **Micro-SaaS Launcher** | Launching small SaaS products fast. Idea validation, MVP, pricing. | `skills/micro-saas-launcher` |
| **Mobile Design** | Mobile-first design thinking for iOS and Android apps. Touch interaction, performance patterns. | `skills/mobile-design` |
| **Moodle External API Development** | Create custom external web service APIs for Moodle LMS. Use when implementing web services for course management, user tracking, quiz operations, or custom plugin functionality. Covers parameter validation, database operations, error handling, service registration, and Moodle coding standards. | `skills/moodle-external-api-development` |
| **Neon Postgres** | Neon serverless Postgres, branching, connection pooling, Prisma integration. | `skills/neon-postgres` |
| **NestJS Expert** | Nest.js framework expert. Module architecture, dependency injection, middleware, guards, interceptors. | `skills/nestjs-expert` |
| **Network 101** | This skill should be used when the user asks to "set up a web server", "configure HTTP or HTTPS", "perform SNMP enumeration", "configure SMB shares", "test network services", or needs guidance on configuring and testing network services for penetration testing labs. | `skills/network-101` |
| **Next.js Best Practices** | Next.js App Router principles. Server Components, data fetching, routing patterns. | `skills/nextjs-best-practices` |
| **Next.js Supabase Auth** | Supabase Auth with Next.js App Router. Auth middleware. | `skills/nextjs-supabase-auth` |
| **Node.js Best Practices** | Node.js development principles. Framework selection, async patterns, security, architecture. | `skills/nodejs-best-practices` |
| **NotebookLM** | Use this skill to query your Google NotebookLM notebooks directly from Claude Code for source-grounded, citation-backed answers from Gemini. | `skills/notebooklm` |
| **Notion Template Business** | Building and selling Notion templates. Design, pricing, marketing. | `skills/notion-template-business` |
| **Onboarding CRO** | Optimize post-signup onboarding, user activation, and time-to-value. | `skills/onboarding-cro` |
| **Page CRO** | Conversion rate optimization for marketing pages - homepages, landing pages, pricing pages. | `skills/page-cro` |
| **Paid Ads** | Create and optimize paid ad campaigns on Google Ads, Meta, LinkedIn, and other platforms. | `skills/paid-ads` |
| **Parallel Agents** | Multi-agent orchestration patterns. Use when multiple independent tasks can run with different domain expertise. | `skills/parallel-agents` |
| **Paywall Upgrade CRO** | Optimize in-app paywalls, upgrade screens, and freemium conversion moments. | `skills/paywall-upgrade-cro` |
| **PDF (Official)** | Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms. | `skills/pdf-official` |
| **Pentest Checklist** | This skill should be used when the user asks to "plan a penetration test", "create a security assessment checklist", "prepare for penetration testing", "define pentest scope", "follow security testing best practices", or needs a structured methodology for penetration testing engagements. | `skills/pentest-checklist` |
| **Pentest Commands** | This skill should be used when the user asks to "run pentest commands", "scan with nmap", "use metasploit exploits", "crack passwords with hydra or john", "scan web vulnerabilities with nikto", "enumerate networks", or needs essential penetration testing command references. | `skills/pentest-commands` |
| **Page CRO** | Conversion rate optimization for marketing pages - homepages, landing pages, pricing pages. | `skills/page-cro` |
| **Paid Ads** | Create and optimize paid ad campaigns on Google Ads, Meta, LinkedIn, and other platforms. | `skills/paid-ads` |
| **Paywall Upgrade CRO** | Optimize in-app paywalls, upgrade screens, and freemium conversion moments. | `skills/paywall-upgrade-cro` |
| **Performance Profiling** | Performance profiling principles. Measurement, analysis, and optimization techniques. | `skills/performance-profiling` |
| **Personal Tool Builder** | Building custom tools. Rapid prototyping, local-first apps, CLI tools. | `skills/personal-tool-builder` |
| **Plaid Fintech** | Plaid API for banking. Link token flows, transactions, ACH. | `skills/plaid-fintech` |
| **Plan Writing** | Structured task planning with clear breakdowns, dependencies, and verification criteria. | `skills/plan-writing` |
| **Planning With Files** | Implements Manus-style file-based planning for complex tasks. | `skills/planning-with-files` |
| **Playwright Automation** | Complete browser automation with Playwright. | `skills/playwright-skill` |
| **Popup CRO** | Create and optimize popups, modals, and overlays for conversion. | `skills/popup-cro` |
| **PowerShell Windows** | PowerShell Windows patterns. Critical pitfalls, operator syntax, error handling. | `skills/powershell-windows` |
| **PPTX (Official)** | "Presentation creation, editing, and analysis. | `skills/pptx-official` |
| **Privilege Escalation Methods** | This skill should be used when the user asks to "escalate privileges", "get root access", "become administrator", "privesc techniques", "abuse sudo", "exploit SUID binaries", "Kerberoasting", "pass-the-ticket", "token impersonation", or needs guidance on post-exploitation privilege escalation for Linux or Windows systems. | `skills/privilege-escalation-methods` |
| **Pricing Strategy** | Design pricing, packaging, and monetization strategy for SaaS products. | `skills/pricing-strategy` |
| **Prisma Expert** | Prisma ORM expert for schema design, migrations, query optimization, relations modeling. | `skills/prisma-expert` |
| **Privilege Escalation Methods** | This skill should be used when the user asks to "escalate privileges", "get root access", "become administrator", "privesc techniques", "abuse sudo", "exploit SUID binaries", "Kerberoasting", "pass-the-ticket", "token impersonation", or needs guidance on post-exploitation privilege escalation for Linux or Windows systems. | `skills/privilege-escalation-methods` |
| **Product Toolkit** | Comprehensive toolkit for product managers including RICE prioritization, customer interview analysis, PRD templates, discovery frameworks, and go-to-market strategies. | `skills/product-manager-toolkit` |
| **Programmatic SEO** | Build SEO-driven pages at scale using templates and data. | `skills/programmatic-seo` |
| **Prompt Caching** | Caching strategies for LLM prompts. Anthropic caching, CAG. | `skills/prompt-caching` |
| **Prompt Engineer** | Designing prompts for LLM applications. Structure, evaluation. | `skills/prompt-engineer` |
| **Prompt Engineering** | Expert guide on prompt engineering patterns, best practices, and optimization techniques. | `skills/prompt-engineering` |
| **Prompt Library** | "Curated collection of high-quality prompts for various use cases. | `skills/prompt-library` |
| **Programmatic SEO** | Build SEO-driven pages at scale using templates and data. | `skills/programmatic-seo` |
| **Python Patterns** | Python development principles. Framework selection, async patterns, type hints, project structure. | `skills/python-patterns` |
| **RAG Engineer** | Building RAG systems. Embedding models, vector databases, chunking. | `skills/rag-engineer` |
| **RAG Implementation** | RAG patterns. Chunking, embeddings, vector stores. | `skills/rag-implementation` |
| **React Best Practices** | React and Next. | `skills/react-best-practices` |
| **React Patterns** | Modern React patterns and principles. Hooks, composition, performance, TypeScript best practices. | `skills/react-patterns` |
| **React UI Patterns** | Modern React UI patterns for loading states, error handling, and data fetching. | `skills/react-ui-patterns` |
| **Receiving Code Review** | Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation. | `skills/receiving-code-review` |
| **Red Team Tactics** | Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting. | `skills/red-team-tactics` |
| **Red Team Tools and Methodology** | This skill should be used when the user asks to "follow red team methodology", "perform bug bounty hunting", "automate reconnaissance", "hunt for XSS vulnerabilities", "enumerate subdomains", or needs security researcher techniques and tool configurations from top bug bounty hunters. | `skills/red-team-tools` |
| **Referral Program** | Design referral programs, affiliate programs, and word-of-mouth strategies. | `skills/referral-program` |
| **Requesting Code Review** | Use when completing tasks, implementing major features, or before merging to verify work meets requirements. | `skills/requesting-code-review` |
@@ -221,6 +277,8 @@ Below is the complete list of available skills. Each skill folder contains a `SK
| **Senior Architect** | Comprehensive software architecture skill for designing scalable, maintainable systems using ReactJS, NextJS, NodeJS, Express, React Native, Swift, Kotlin, Flutter, Postgres, GraphQL, Go, Python. | `skills/senior-architect` |
| **Senior Fullstack** | Comprehensive fullstack development skill for building complete web applications with React, Next. | `skills/senior-fullstack` |
| **SEO Audit** | Audit technical and on-page SEO issues for better search rankings. | `skills/seo-audit` |
| **SEO Fundamentals** | SEO fundamentals, E-E-A-T, Core Web Vitals, and Google algorithm principles. | `skills/seo-fundamentals` |
| **Server Management** | Server management principles. Process management, monitoring strategy, and scaling decisions. | `skills/server-management` |
| **Shodan Reconnaissance and Pentesting** | This skill should be used when the user asks to "search for exposed devices on the internet," "perform Shodan reconnaissance," "find vulnerable services using Shodan," "scan IP ranges with Shodan," or "discover IoT devices and open ports. | `skills/shodan-reconnaissance` |
| **Shopify Apps** | Building Shopify apps. App Bridge, Polaris, webhooks. | `skills/shopify-apps` |
| **Shopify Development** | Build Shopify apps, extensions, themes using GraphQL Admin API, Shopify CLI, Polaris UI, and Liquid. Use when user asks about "shopify app", "checkout extension", "shopify theme", "liquid template", "polaris", "shopify graphql", "shopify webhook", or "metafields". | `skills/shopify-development` |
@@ -238,7 +296,9 @@ Below is the complete list of available skills. Each skill folder contains a `SK
| **Stripe Integration** | Stripe patterns. Checkout, subscriptions, payment intents, webhooks. | `skills/stripe-integration` |
| **Subagent Driven Dev** | Use when executing implementation plans with independent tasks in the current session. | `skills/subagent-driven-development` |
| **Systematic Debugging** | Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes. | `skills/systematic-debugging` |
| **Tailwind Patterns** | Tailwind CSS v4 principles. CSS-first configuration, container queries, design token architecture. | `skills/tailwind-patterns` |
| **TDD** | Use when implementing any feature or bugfix, before writing implementation code. | `skills/test-driven-development` |
| **TDD Workflow** | Test-Driven Development workflow principles. RED-GREEN-REFACTOR cycle. | `skills/tdd-workflow` |
| **Telegram Bot Builder** | Building Telegram bots. Bot API, inline mode, payments, Mini Apps. | `skills/telegram-bot-builder` |
| **Telegram Mini App** | TON Connect, Telegram Mini Apps, wallet integration. | `skills/telegram-mini-app` |
| **Test Fixing** | Run tests and systematically fix all failing tests using smart error grouping. | `skills/test-fixing` |
@@ -247,6 +307,7 @@ Below is the complete list of available skills. Each skill folder contains a `SK
| **Top 100 Vulnerabilities** | This skill should be used when the user asks to "identify web application vulnerabilities", "explain common security flaws", "understand vulnerability categories", "learn about injection attacks", "review access control weaknesses", "analyze API security issues", "assess security misconfigurations", "understand client-side vulnerabilities", "examine mobile and IoT security flaws", or "reference the OWASP-aligned vulnerability taxonomy". | `skills/top-web-vulnerabilities` |
| **Trigger.dev** | Trigger.dev for serverless background jobs. Long-running tasks. | `skills/trigger-dev` |
| **Twilio Communications** | Twilio for SMS, voice, video. Programmable messaging, OTP. | `skills/twilio-communications` |
| **TypeScript Expert** | TypeScript expert with deep knowledge of type-level programming, performance optimization, migration strategies. | `skills/typescript-expert` |
| **UI/UX Pro Max** | "UI/UX design intelligence. | `skills/ui-ux-pro-max` |
| **Upstash QStash** | Upstash QStash for serverless message queues. | `skills/upstash-qstash` |
| **Using Git Worktrees** | Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification. | `skills/using-git-worktrees` |
@@ -256,6 +317,7 @@ Below is the complete list of available skills. Each skill folder contains a `SK
| **Viral Generator Builder** | Building shareable generators that go viral. | `skills/viral-generator-builder` |
| **Voice Agents** | Voice-based AI assistants. Speech-to-text, real-time conversation. | `skills/voice-agents` |
| **Voice AI Development** | Voice AI patterns. Wake words, streaming ASR, emotional TTS. | `skills/voice-ai-development` |
| **Vulnerability Scanner** | Advanced vulnerability analysis principles. OWASP 2025, Supply Chain Security, attack surface mapping. | `skills/vulnerability-scanner` |
| **Web Artifacts** | Suite of tools for creating elaborate, multi-component claude. | `skills/web-artifacts-builder` |
| **Web Design Guidelines** | Review UI code for Web Interface Guidelines compliance. | `skills/web-design-guidelines` |
| **Webapp Testing** | Toolkit for interacting with and testing local web applications using Playwright. | `skills/webapp-testing` |
@@ -331,6 +393,7 @@ This collection would not be possible without the incredible work of the Claude
- **[zircote/.claude](https://github.com/zircote/.claude)**: Shopify development skill reference.
- **[vibeforge1111/vibeship-spawner-skills](https://github.com/vibeforge1111/vibeship-spawner-skills)**: AI Agents, Integrations, Maker Tools (57 skills, Apache 2.0).
- **[coreyhaines31/marketingskills](https://github.com/coreyhaines31/marketingskills)**: Marketing skills for CRO, copywriting, SEO, paid ads, and growth (23 skills, MIT).
- **[vudovn/antigravity-kit](https://github.com/vudovn/antigravity-kit)**: AI Agent templates with Skills, Agents, and Workflows (33 skills, MIT).
### Inspirations

760
docs/EXAMPLES.md Normal file
View File

@@ -0,0 +1,760 @@
# 💡 Real-World Examples - See Skills in Action
**Learn by example!** This guide shows you real conversations using different skills.
---
## Example 1: Designing a Feature with @brainstorming
### The Scenario
You want to add a "dark mode" feature to your app, but you're not sure how to approach it.
### The Conversation
```
You: @brainstorming I want to add dark mode to my React app
AI: Great! Let me help you think through this. First, let me check your
current project structure...
[AI examines your files]
I see you're using React with Tailwind CSS. Now, let's understand
your requirements:
What's your primary goal for dark mode?
a) User preference (toggle in settings)
b) System preference (follow OS setting)
c) Both (with manual override)
You: c) Both
AI: Perfect! That's the best user experience. Next question:
Where should the dark mode toggle be located?
a) In the main navigation
b) In a settings page
c) In a dropdown menu
d) Multiple locations
You: a) In the main navigation
AI: Good choice for accessibility. One more question:
Should dark mode preference persist across sessions?
a) Yes, save to localStorage
b) Yes, save to user account (requires backend)
c) No, reset each session
You: a) Yes, save to localStorage
AI: Excellent! Now I have a clear picture. Let me present the design...
## Dark Mode Implementation Design
### Architecture Overview
We'll use React Context for state management, Tailwind's dark mode
utilities, and localStorage for persistence. The system will:
1. Check OS preference on first visit
2. Allow manual override via toggle
3. Persist preference in localStorage
Does this approach look good so far?
You: Yes, continue
AI: [Continues with detailed design sections...]
[After design is complete]
I've saved the design to docs/plans/2026-01-20-dark-mode-design.md
Ready to set up for implementation?
You: Yes
AI: I'll create an isolated workspace using git worktrees and write an
implementation plan. One moment...
```
### What Happened
- ✅ AI asked focused questions one at a time
- ✅ Explored your specific context
- ✅ Presented design in sections
- ✅ Saved documentation
- ✅ Prepared for implementation
---
## Example 2: Debugging with @systematic-debugging
### The Scenario
Your tests are failing, but you're not sure why.
### The Conversation
```
You: @systematic-debugging My tests are failing with "Cannot read property
'map' of undefined"
AI: Let me help you debug this systematically. First, I'll gather information:
1. Running the failing test to see the full error...
[AI runs: npm test]
I see the error occurs in UserList.test.tsx at line 45. Let me examine
the test file and the component...
[AI reads both files]
## Hypothesis
The test is failing because `users` prop is undefined when the component
renders. This suggests the mock data isn't being passed correctly.
## Verification
Let me check the test setup...
[AI examines test]
Found it! The test is calling:
```typescript
render(<UserList />)
```
But UserList requires a `users` prop. The component expects:
```typescript
interface UserListProps {
users: User[];
}
```
## Solution
The test should pass the users prop:
```typescript
const mockUsers = [
{ id: 1, name: 'Alice' },
{ id: 2, name: 'Bob' }
];
render(<UserList users={mockUsers} />)
```
Should I apply this fix?
You: Yes
AI: [Applies fix and runs tests]
✅ All tests passing!
## Root Cause
The test was missing required props. This is a common issue when
components are refactored to require props that were previously optional.
## Prevention
Consider adding TypeScript strict mode to catch these at compile time:
```json
"strict": true,
"strictNullChecks": true
```
Would you like me to add this to your tsconfig.json?
```
### What Happened
- ✅ Systematic investigation
- ✅ Clear hypothesis
- ✅ Verification before fixing
- ✅ Root cause analysis
- ✅ Prevention suggestions
---
## Example 3: Adding Payments with @stripe-integration
### The Scenario
You need to add subscription billing to your SaaS app.
### The Conversation
```
You: @stripe-integration I need to add monthly subscription billing
AI: I'll help you implement Stripe subscriptions. Let me understand your
requirements:
Current stack detected:
- Next.js 14 (App Router)
- TypeScript
- Prisma with PostgreSQL
For subscription billing, we'll need:
1. **Stripe Setup**
- Stripe account and API keys
- Webhook endpoint for events
- Product and price IDs
2. **Backend Implementation**
- API routes for checkout
- Webhook handler
- Database schema for subscriptions
3. **Frontend Implementation**
- Pricing page
- Checkout flow
- Subscription management
Let's start with the backend. First, install dependencies:
```bash
npm install stripe @stripe/stripe-js
```
Now, let's create the database schema...
[AI provides Prisma schema]
```prisma
model User {
id String @id @default(cuid())
email String @unique
stripeCustomerId String? @unique
subscriptions Subscription[]
}
model Subscription {
id String @id @default(cuid())
userId String
user User @relation(fields: [userId], references: [id])
stripeSubscriptionId String @unique
status String
priceId String
currentPeriodEnd DateTime
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
```
Next, let's create the checkout API route...
[AI provides complete implementation with:]
- API route for creating checkout sessions
- Webhook handler for subscription events
- Helper functions for Stripe operations
- Error handling and logging
- TypeScript types
Now for the frontend...
[AI provides:]
- Pricing page component
- Checkout button component
- Subscription status display
- Tailwind styling
Finally, let's set up the webhook:
1. In Stripe Dashboard, add webhook endpoint:
`https://yourdomain.com/api/webhooks/stripe`
2. Select these events:
- customer.subscription.created
- customer.subscription.updated
- customer.subscription.deleted
- invoice.payment_succeeded
- invoice.payment_failed
3. Copy the webhook secret to your .env:
```
STRIPE_WEBHOOK_SECRET=whsec_...
```
## Testing
Test locally with Stripe CLI:
```bash
stripe listen --forward-to localhost:3000/api/webhooks/stripe
stripe trigger customer.subscription.created
```
## Security Checklist
- ✅ API keys in environment variables
- ✅ Webhook signature verification
- ✅ Server-side price validation
- ✅ Idempotency keys for operations
Ready to test the implementation?
```
### What Happened
- ✅ Detected existing stack
- ✅ Provided complete implementation
- ✅ Included database schema
- ✅ Added security best practices
- ✅ Included testing instructions
---
## Example 4: Writing Copy with @copywriting
### The Scenario
You need compelling copy for your SaaS landing page.
### The Conversation
```
You: @copywriting Write homepage copy for my project management tool
AI: I'll help you create compelling homepage copy. First, let me understand
your product:
What makes your project management tool different from competitors
like Asana, Trello, or Monday.com?
You: It's specifically built for remote teams with built-in video standups
and async communication features
AI: Excellent differentiator! Who is your primary target audience?
a) Startups and small teams (2-20 people)
b) Mid-size companies (20-200 people)
c) Enterprise (200+ people)
d) Freelancers and agencies
You: a) Startups and small teams
AI: Perfect. What's the main pain point you solve?
You: Remote teams waste time in unnecessary meetings and lose context
in async communication
AI: Great! Now I have what I need. Here's your homepage copy:
---
## Hero Section
**Headline:**
Run Your Remote Team Without the Meeting Overload
**Subheadline:**
The project management tool built for distributed teams. Replace
status meetings with async video standups and keep everyone in sync
without the Zoom fatigue.
**CTA:**
Start Free Trial → (No credit card required)
---
## Problem Section
**Headline:**
Remote Work Shouldn't Mean More Meetings
**Body:**
Your team is distributed across time zones. You're spending hours in
status meetings just to stay aligned. Async updates get lost in Slack.
Context disappears. Productivity suffers.
Sound familiar?
---
## Solution Section
**Headline:**
Stay Aligned Without the Meeting Marathon
**Features:**
📹 **Async Video Standups**
Record quick video updates on your schedule. Your team watches when
it works for them. No more 9am calls for your teammate in Tokyo.
💬 **Context-Rich Communication**
Every task, comment, and decision stays connected. No more hunting
through Slack threads or email chains.
📊 **Visual Progress Tracking**
See what's happening at a glance. Kanban boards, timelines, and
dashboards that actually make sense.
🔔 **Smart Notifications**
Get notified about what matters. Ignore the rest. Your focus time
is sacred.
---
## Social Proof Section
**Headline:**
Trusted by Remote Teams Worldwide
[Testimonial placeholders with structure]
---
## CTA Section
**Headline:**
Ready to Reclaim Your Calendar?
**Body:**
Join 500+ remote teams who've cut meeting time by 60% while staying
more aligned than ever.
**CTA:**
Start Your Free 14-Day Trial →
No credit card required. Cancel anytime.
---
## Copy Notes
**Tone:** Professional but conversational
**Focus:** Pain point (too many meetings) → Solution (async video)
**Differentiation:** Built specifically for remote teams
**Social proof:** Quantified benefit (60% fewer meetings)
Would you like me to:
1. Write alternative versions for A/B testing?
2. Create copy for specific feature pages?
3. Write email sequences for onboarding?
```
### What Happened
- ✅ Asked clarifying questions
- ✅ Identified unique value proposition
- ✅ Created benefit-focused copy
- ✅ Included clear CTAs
- ✅ Provided copy notes for consistency
---
## Example 5: Test-Driven Development with @test-driven-development
### The Scenario
You need to implement a new feature: user authentication.
### The Conversation
```
You: @test-driven-development I need to implement user login functionality
AI: Perfect! Let's use TDD to build this. Following the Red-Green-Refactor
cycle, we'll write tests first, then implement.
## Step 1: Write the First Test (RED)
Let's start with the simplest case - successful login:
```typescript
// auth.test.ts
import { login } from './auth';
describe('login', () => {
it('should return user data for valid credentials', async () => {
const result = await login({
email: 'user@example.com',
password: 'correct-password'
});
expect(result.success).toBe(true);
expect(result.user).toHaveProperty('id');
expect(result.user).toHaveProperty('email');
expect(result.token).toBeDefined();
});
});
```
Let's run this test to see it fail:
[AI runs: npm test]
✅ Test fails as expected (auth.ts doesn't exist yet)
## Step 2: Write Minimal Implementation (GREEN)
Now let's write just enough code to make this test pass:
```typescript
// auth.ts
interface LoginCredentials {
email: string;
password: string;
}
interface LoginResult {
success: boolean;
user?: {
id: string;
email: string;
};
token?: string;
}
export async function login(
credentials: LoginCredentials
): Promise<LoginResult> {
// Minimal implementation to pass the test
return {
success: true,
user: {
id: '1',
email: credentials.email
},
token: 'fake-token'
};
}
```
[AI runs: npm test]
✅ Test passes!
## Step 3: Add Next Test (RED)
Now let's test the failure case:
```typescript
it('should return error for invalid credentials', async () => {
const result = await login({
email: 'user@example.com',
password: 'wrong-password'
});
expect(result.success).toBe(false);
expect(result.error).toBe('Invalid credentials');
expect(result.user).toBeUndefined();
expect(result.token).toBeUndefined();
});
```
[AI runs: npm test]
❌ Test fails (always returns success)
## Step 4: Implement Real Logic (GREEN)
Now let's add actual authentication:
```typescript
import bcrypt from 'bcrypt';
import jwt from 'jsonwebtoken';
import { db } from './db';
export async function login(
credentials: LoginCredentials
): Promise<LoginResult> {
// Find user
const user = await db.user.findUnique({
where: { email: credentials.email }
});
if (!user) {
return {
success: false,
error: 'Invalid credentials'
};
}
// Verify password
const validPassword = await bcrypt.compare(
credentials.password,
user.passwordHash
);
if (!validPassword) {
return {
success: false,
error: 'Invalid credentials'
};
}
// Generate token
const token = jwt.sign(
{ userId: user.id },
process.env.JWT_SECRET!,
{ expiresIn: '7d' }
);
return {
success: true,
user: {
id: user.id,
email: user.email
},
token
};
}
```
[AI runs: npm test]
✅ All tests pass!
## Step 5: Add Edge Cases
Let's add more tests for edge cases:
```typescript
it('should handle missing email', async () => {
const result = await login({
email: '',
password: 'password'
});
expect(result.success).toBe(false);
expect(result.error).toBe('Email is required');
});
it('should handle missing password', async () => {
const result = await login({
email: 'user@example.com',
password: ''
});
expect(result.success).toBe(false);
expect(result.error).toBe('Password is required');
});
it('should handle database errors gracefully', async () => {
// Mock database error
jest.spyOn(db.user, 'findUnique').mockRejectedValue(
new Error('Database connection failed')
);
const result = await login({
email: 'user@example.com',
password: 'password'
});
expect(result.success).toBe(false);
expect(result.error).toBe('An error occurred');
});
```
[AI implements validation and error handling]
## Step 6: Refactor (REFACTOR)
Now that all tests pass, let's refactor for better code quality:
```typescript
// Extract validation
function validateCredentials(credentials: LoginCredentials): string | null {
if (!credentials.email) return 'Email is required';
if (!credentials.password) return 'Password is required';
return null;
}
// Extract user verification
async function verifyUser(
email: string,
password: string
): Promise<User | null> {
const user = await db.user.findUnique({ where: { email } });
if (!user) return null;
const valid = await bcrypt.compare(password, user.passwordHash);
return valid ? user : null;
}
// Main function is now cleaner
export async function login(
credentials: LoginCredentials
): Promise<LoginResult> {
try {
const validationError = validateCredentials(credentials);
if (validationError) {
return { success: false, error: validationError };
}
const user = await verifyUser(
credentials.email,
credentials.password
);
if (!user) {
return { success: false, error: 'Invalid credentials' };
}
const token = generateToken(user.id);
return {
success: true,
user: { id: user.id, email: user.email },
token
};
} catch (error) {
console.error('Login error:', error);
return { success: false, error: 'An error occurred' };
}
}
```
[AI runs: npm test]
✅ All tests still pass after refactoring!
## Summary
We've implemented login functionality using TDD:
- ✅ 5 tests covering happy path, errors, and edge cases
- ✅ Clean, testable code
- ✅ Proper error handling
- ✅ Type safety with TypeScript
Next steps:
1. Add rate limiting tests
2. Add session management tests
3. Add logout functionality
Should I continue with these?
```
### What Happened
- ✅ Followed Red-Green-Refactor cycle
- ✅ Wrote tests before implementation
- ✅ Covered edge cases
- ✅ Refactored with confidence
- ✅ Maintained test coverage
---
## Key Takeaways
### What Makes These Examples Effective?
1. **Skills ask clarifying questions** before jumping to solutions
2. **Skills provide context-aware help** based on your project
3. **Skills follow best practices** for their domain
4. **Skills include complete examples** not just snippets
5. **Skills explain the "why"** not just the "how"
### How to Get Similar Results
1. **Be specific** in your requests
2. **Provide context** about your project
3. **Answer questions** the skill asks
4. **Review suggestions** before applying
5. **Iterate** based on results
---
## Try These Yourself!
Pick a skill and try it with your own project:
- **Planning:** `@brainstorming` or `@writing-plans`
- **Development:** `@test-driven-development` or `@react-best-practices`
- **Debugging:** `@systematic-debugging` or `@test-fixing`
- **Integration:** `@stripe-integration` or `@firebase`
- **Marketing:** `@copywriting` or `@seo-audit`
---
**Want more examples?** Check individual skill folders for additional examples and use cases!

545
docs/SKILL_ANATOMY.md Normal file
View File

@@ -0,0 +1,545 @@
# Anatomy of a Skill - Understanding the Structure
**Want to understand how skills work under the hood?** This guide breaks down every part of a skill file.
---
## 📁 Basic Folder Structure
```
skills/
└── my-skill-name/
├── SKILL.md ← Required: The main skill definition
├── examples/ ← Optional: Example files
│ ├── example1.js
│ └── example2.py
├── scripts/ ← Optional: Helper scripts
│ └── helper.sh
├── templates/ ← Optional: Code templates
│ └── template.tsx
├── references/ ← Optional: Reference documentation
│ └── api-docs.md
└── README.md ← Optional: Additional documentation
```
**Key Rule:** Only `SKILL.md` is required. Everything else is optional!
---
## SKILL.md Structure
Every `SKILL.md` file has two main parts:
### 1. Frontmatter (Metadata)
### 2. Content (Instructions)
Let's break down each part:
---
## Part 1: Frontmatter
The frontmatter is at the very top, wrapped in `---`:
```markdown
---
name: my-skill-name
description: "Brief description of what this skill does"
---
```
### Required Fields
#### `name`
- **What it is:** The skill's identifier
- **Format:** lowercase-with-hyphens
- **Must match:** The folder name exactly
- **Example:** `stripe-integration`
#### `description`
- **What it is:** One-sentence summary
- **Format:** String in quotes
- **Length:** Keep it under 150 characters
- **Example:** `"Stripe payment integration patterns including checkout, subscriptions, and webhooks"`
### Optional Fields
Some skills include additional metadata:
```markdown
---
name: my-skill-name
description: "Brief description"
version: "1.0.0"
author: "Your Name"
tags: ["react", "typescript", "testing"]
---
```
---
## Part 2: Content
After the frontmatter comes the actual skill content. Here's the recommended structure:
### Recommended Sections
#### 1. Title (H1)
```markdown
# Skill Title
```
- Use a clear, descriptive title
- Usually matches or expands on the skill name
#### 2. Overview
```markdown
## Overview
A brief explanation of what this skill does and why it exists.
2-4 sentences is perfect.
```
#### 3. When to Use
```markdown
## When to Use This Skill
- Use when you need to [scenario 1]
- Use when working with [scenario 2]
- Use when the user asks about [scenario 3]
```
**Why this matters:** Helps the AI know when to activate this skill
#### 4. Core Instructions
```markdown
## How It Works
### Step 1: [Action]
Detailed instructions...
### Step 2: [Action]
More instructions...
```
**This is the heart of your skill** - clear, actionable steps
#### 5. Examples
```markdown
## Examples
### Example 1: [Use Case]
\`\`\`javascript
// Example code
\`\`\`
### Example 2: [Another Use Case]
\`\`\`javascript
// More code
\`\`\`
```
**Why examples matter:** They show the AI exactly what good output looks like
#### 6. Best Practices
```markdown
## Best Practices
- ✅ Do this
- ✅ Also do this
- ❌ Don't do this
- ❌ Avoid this
```
#### 7. Common Pitfalls
```markdown
## Common Pitfalls
- **Problem:** Description
**Solution:** How to fix it
```
#### 8. Related Skills
```markdown
## Related Skills
- `@other-skill` - When to use this instead
- `@complementary-skill` - How this works together
```
---
## Writing Effective Instructions
### Use Clear, Direct Language
**❌ Bad:**
```markdown
You might want to consider possibly checking if the user has authentication.
```
**✅ Good:**
```markdown
Check if the user is authenticated before proceeding.
```
### Use Action Verbs
**❌ Bad:**
```markdown
The file should be created...
```
**✅ Good:**
```markdown
Create the file...
```
### Be Specific
**❌ Bad:**
```markdown
Set up the database properly.
```
**✅ Good:**
```markdown
1. Create a PostgreSQL database
2. Run migrations: `npm run migrate`
3. Seed initial data: `npm run seed`
```
---
## Optional Components
### Scripts Directory
If your skill needs helper scripts:
```
scripts/
├── setup.sh ← Setup automation
├── validate.py ← Validation tools
└── generate.js ← Code generators
```
**Reference them in SKILL.md:**
```markdown
Run the setup script:
\`\`\`bash
bash scripts/setup.sh
\`\`\`
```
### Examples Directory
Real-world examples that demonstrate the skill:
```
examples/
├── basic-usage.js
├── advanced-pattern.ts
└── full-implementation/
├── index.js
└── config.json
```
### Templates Directory
Reusable code templates:
```
templates/
├── component.tsx
├── test.spec.ts
└── config.json
```
**Reference in SKILL.md:**
```markdown
Use this template as a starting point:
\`\`\`typescript
{{#include templates/component.tsx}}
\`\`\`
```
### References Directory
External documentation or API references:
```
references/
├── api-docs.md
├── best-practices.md
└── troubleshooting.md
```
---
## Skill Size Guidelines
### Minimum Viable Skill
- **Frontmatter:** name + description
- **Content:** 100-200 words
- **Sections:** Overview + Instructions
### Standard Skill
- **Frontmatter:** name + description
- **Content:** 300-800 words
- **Sections:** Overview + When to Use + Instructions + Examples
### Comprehensive Skill
- **Frontmatter:** name + description + optional fields
- **Content:** 800-2000 words
- **Sections:** All recommended sections
- **Extras:** Scripts, examples, templates
**Rule of thumb:** Start small, expand based on feedback
---
## Formatting Best Practices
### Use Markdown Effectively
#### Code Blocks
Always specify the language:
```markdown
\`\`\`javascript
const example = "code";
\`\`\`
```
#### Lists
Use consistent formatting:
```markdown
- Item 1
- Item 2
- Sub-item 2.1
- Sub-item 2.2
```
#### Emphasis
- **Bold** for important terms: `**important**`
- *Italic* for emphasis: `*emphasis*`
- `Code` for commands/code: `` `code` ``
#### Links
```markdown
[Link text](https://example.com)
```
---
## ✅ Quality Checklist
Before finalizing your skill:
### Content Quality
- [ ] Instructions are clear and actionable
- [ ] Examples are realistic and helpful
- [ ] No typos or grammar errors
- [ ] Technical accuracy verified
### Structure
- [ ] Frontmatter is valid YAML
- [ ] Name matches folder name
- [ ] Sections are logically organized
- [ ] Headings follow hierarchy (H1 → H2 → H3)
### Completeness
- [ ] Overview explains the "why"
- [ ] Instructions explain the "how"
- [ ] Examples show the "what"
- [ ] Edge cases are addressed
### Usability
- [ ] A beginner could follow this
- [ ] An expert would find it useful
- [ ] The AI can parse it correctly
- [ ] It solves a real problem
---
## 🔍 Real-World Example Analysis
Let's analyze a real skill: `brainstorming`
```markdown
---
name: brainstorming
description: "You MUST use this before any creative work..."
---
```
**Analysis:**
- ✅ Clear name
- ✅ Strong description with urgency ("MUST use")
- ✅ Explains when to use it
```markdown
# Brainstorming Ideas Into Designs
## Overview
Help turn ideas into fully formed designs...
```
**Analysis:**
- ✅ Clear title
- ✅ Concise overview
- ✅ Explains the value proposition
```markdown
## The Process
**Understanding the idea:**
- Check out the current project state first
- Ask questions one at a time
```
**Analysis:**
- ✅ Broken into clear phases
- ✅ Specific, actionable steps
- ✅ Easy to follow
---
## Advanced Patterns
### Conditional Logic
```markdown
## Instructions
If the user is working with React:
- Use functional components
- Prefer hooks over class components
If the user is working with Vue:
- Use Composition API
- Follow Vue 3 patterns
```
### Progressive Disclosure
```markdown
## Basic Usage
[Simple instructions for common cases]
## Advanced Usage
[Complex patterns for power users]
```
### Cross-References
```markdown
## Related Workflows
1. First, use `@brainstorming` to design
2. Then, use `@writing-plans` to plan
3. Finally, use `@test-driven-development` to implement
```
---
## Skill Effectiveness Metrics
How to know if your skill is good:
### Clarity Test
- Can someone unfamiliar with the topic follow it?
- Are there any ambiguous instructions?
### Completeness Test
- Does it cover the happy path?
- Does it handle edge cases?
- Are error scenarios addressed?
### Usefulness Test
- Does it solve a real problem?
- Would you use this yourself?
- Does it save time or improve quality?
---
## Learning from Existing Skills
### Study These Examples
**For Beginners:**
- `skills/brainstorming/SKILL.md` - Clear structure
- `skills/git-pushing/SKILL.md` - Simple and focused
- `skills/copywriting/SKILL.md` - Good examples
**For Advanced:**
- `skills/systematic-debugging/SKILL.md` - Comprehensive
- `skills/react-best-practices/SKILL.md` - Multiple files
- `skills/loki-mode/SKILL.md` - Complex workflows
---
## 💡 Pro Tips
1. **Start with the "When to Use" section** - This clarifies the skill's purpose
2. **Write examples first** - They help you understand what you're teaching
3. **Test with an AI** - See if it actually works before submitting
4. **Get feedback** - Ask others to review your skill
5. **Iterate** - Skills improve over time based on usage
---
## Common Mistakes to Avoid
### ❌ Mistake 1: Too Vague
```markdown
## Instructions
Make the code better.
```
**✅ Fix:**
```markdown
## Instructions
1. Extract repeated logic into functions
2. Add error handling for edge cases
3. Write unit tests for core functionality
```
### ❌ Mistake 2: Too Complex
```markdown
## Instructions
[5000 words of dense technical jargon]
```
**✅ Fix:**
Break into multiple skills or use progressive disclosure
### ❌ Mistake 3: No Examples
```markdown
## Instructions
[Instructions without any code examples]
```
**✅ Fix:**
Add at least 2-3 realistic examples
### ❌ Mistake 4: Outdated Information
```markdown
Use React class components...
```
**✅ Fix:**
Keep skills updated with current best practices
---
## 🎯 Next Steps
1. **Read 3-5 existing skills** to see different styles
2. **Try the skill template** from CONTRIBUTING.md
3. **Create a simple skill** for something you know well
4. **Test it** with your AI assistant
5. **Share it** via Pull Request
---
**Remember:** Every expert was once a beginner. Start simple, learn from feedback, and improve over time! 🚀

504
docs/VISUAL_GUIDE.md Normal file
View File

@@ -0,0 +1,504 @@
# Visual Quick Start Guide
**Learn by seeing!** This guide uses diagrams and visual examples to help you understand skills.
---
## The Big Picture
```
┌─────────────────────────────────────────────────────────────┐
│ YOU (Developer) │
│ ↓ │
│ "Help me build a payment system" │
│ ↓ │
├─────────────────────────────────────────────────────────────┤
│ AI ASSISTANT │
│ ↓ │
│ Loads @stripe-integration skill │
│ ↓ │
│ Becomes an expert in Stripe payments │
│ ↓ │
│ Provides specialized help with code examples │
└─────────────────────────────────────────────────────────────┘
```
---
## 📦 Repository Structure (Visual)
```
antigravity-awesome-skills/
├── 📄 README.md ← Overview & skill list
├── 📄 GETTING_STARTED.md ← Start here! (NEW)
├── 📄 CONTRIBUTING.md ← How to contribute (NEW)
├── 📁 skills/ ← All 179 skills live here
│ │
│ ├── 📁 brainstorming/
│ │ └── 📄 SKILL.md ← Skill definition
│ │
│ ├── 📁 stripe-integration/
│ │ ├── 📄 SKILL.md
│ │ └── 📁 examples/ ← Optional extras
│ │
│ ├── 📁 react-best-practices/
│ │ ├── 📄 SKILL.md
│ │ ├── 📁 rules/
│ │ └── 📄 README.md
│ │
│ └── ... (176 more skills)
├── 📁 scripts/ ← Validation & management
│ ├── validate_skills.py
│ └── generate_index.py
└── 📁 docs/ ← Documentation (NEW)
├── 📄 SKILL_ANATOMY.md ← How skills work
└── 📄 VISUAL_GUIDE.md ← This file!
```
---
## How Skills Work (Flow Diagram)
```
┌──────────────┐
│ 1. INSTALL │ Copy skills to .agent/skills/
└──────┬───────┘
┌──────────────┐
│ 2. INVOKE │ Type: @skill-name in AI chat
└──────┬───────┘
┌──────────────┐
│ 3. LOAD │ AI reads SKILL.md file
└──────┬───────┘
┌──────────────┐
│ 4. EXECUTE │ AI follows skill instructions
└──────┬───────┘
┌──────────────┐
│ 5. RESULT │ You get specialized help!
└──────────────┘
```
---
## 🎯 Skill Categories (Visual Map)
```
┌─────────────────────────┐
│ 179 AWESOME SKILLS │
└────────────┬────────────┘
┌────────────────────────┼────────────────────────┐
│ │ │
┌────▼────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ CREATIVE│ │ DEVELOPMENT │ │ SECURITY │
│ (10) │ │ (25) │ │ (50) │
└────┬────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
• UI/UX Design • TDD • Ethical Hacking
• Canvas Art • Debugging • Metasploit
• Themes • React Patterns • Burp Suite
• SQLMap
│ │ │
└────────────────────────┼────────────────────────┘
┌────────────────────────┼────────────────────────┐
│ │ │
┌────▼────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ AI │ │ DOCUMENTS │ │ MARKETING │
│ (30) │ │ (4) │ │ (23) │
└────┬────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
• RAG Systems • DOCX • SEO
• LangGraph • PDF • Copywriting
• Prompt Eng. • PPTX • CRO
• Voice Agents • XLSX • Paid Ads
```
---
## Skill File Anatomy (Visual)
```
┌─────────────────────────────────────────────────────────┐
│ SKILL.md │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────┐ │
│ │ FRONTMATTER (Metadata) │ │
│ │ ───────────────────────────────────────────── │ │
│ │ --- │ │
│ │ name: my-skill │ │
│ │ description: "What this skill does" │ │
│ │ --- │ │
│ └───────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────┐ │
│ │ CONTENT (Instructions) │ │
│ │ ───────────────────────────────────────────── │ │
│ │ │ │
│ │ # Skill Title │ │
│ │ │ │
│ │ ## Overview │ │
│ │ What this skill does... │ │
│ │ │ │
│ │ ## When to Use │ │
│ │ - Use when... │ │
│ │ │ │
│ │ ## Instructions │ │
│ │ 1. First step... │ │
│ │ 2. Second step... │ │
│ │ │ │
│ │ ## Examples │ │
│ │ ```javascript │ │
│ │ // Example code │ │
│ │ ``` │ │
│ │ │ │
│ └───────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Installation (Visual Steps)
### Step 1: Clone the Repository
```
┌─────────────────────────────────────────┐
│ Terminal │
├─────────────────────────────────────────┤
│ $ git clone https://github.com/ │
│ sickn33/antigravity-awesome-skills │
│ .agent/skills │
│ │
│ ✓ Cloning into '.agent/skills'... │
│ ✓ Done! │
└─────────────────────────────────────────┘
```
### Step 2: Verify Installation
```
┌─────────────────────────────────────────┐
│ File Explorer │
├─────────────────────────────────────────┤
│ 📁 .agent/ │
│ └── 📁 skills/ │
│ ├── 📁 brainstorming/ │
│ ├── 📁 stripe-integration/ │
│ ├── 📁 react-best-practices/ │
│ └── ... (176 more) │
└─────────────────────────────────────────┘
```
### Step 3: Use a Skill
```
┌─────────────────────────────────────────┐
│ AI Assistant Chat │
├─────────────────────────────────────────┤
│ You: @brainstorming help me design │
│ a todo app │
│ │
│ AI: Great! Let me help you think │
│ through this. First, let's │
│ understand your requirements... │
│ │
│ What's the primary use case? │
│ a) Personal task management │
│ b) Team collaboration │
│ c) Project planning │
└─────────────────────────────────────────┘
```
---
## Example: Using a Skill (Step-by-Step)
### Scenario: You want to add Stripe payments to your app
```
┌─────────────────────────────────────────────────────────────┐
│ STEP 1: Identify the Need │
├─────────────────────────────────────────────────────────────┤
│ "I need to add payment processing to my app" │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ STEP 2: Find the Right Skill │
├─────────────────────────────────────────────────────────────┤
│ Search: "payment" or "stripe" │
│ Found: @stripe-integration │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ STEP 3: Invoke the Skill │
├─────────────────────────────────────────────────────────────┤
│ You: @stripe-integration help me add subscription billing │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ STEP 4: AI Loads Skill Knowledge │
├─────────────────────────────────────────────────────────────┤
│ • Stripe API patterns │
│ • Webhook handling │
│ • Subscription management │
│ • Best practices │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ STEP 5: Get Expert Help │
├─────────────────────────────────────────────────────────────┤
│ AI provides: │
│ • Code examples │
│ • Setup instructions │
│ • Security considerations │
│ • Testing strategies │
└─────────────────────────────────────────────────────────────┘
```
---
## Finding Skills (Visual Guide)
### Method 1: Browse by Category
```
README.md → Scroll to "Full Skill Registry" → Find category → Pick skill
```
### Method 2: Search by Keyword
```
Terminal → ls skills/ | grep "keyword" → See matching skills
```
### Method 3: Use the Index
```
Open skills_index.json → Search for keyword → Find skill path
```
---
## Creating Your First Skill (Visual Workflow)
```
┌──────────────┐
│ 1. IDEA │ "I want to share my Docker knowledge"
└──────┬───────┘
┌──────────────┐
│ 2. CREATE │ mkdir skills/docker-mastery
└──────┬───────┘ touch skills/docker-mastery/SKILL.md
┌──────────────┐
│ 3. WRITE │ Add frontmatter + content
└──────┬───────┘ (Use template from CONTRIBUTING.md)
┌──────────────┐
│ 4. TEST │ Copy to .agent/skills/
└──────┬───────┘ Try: @docker-mastery
┌──────────────┐
│ 5. VALIDATE │ python3 scripts/validate_skills.py
└──────┬───────┘
┌──────────────┐
│ 6. SUBMIT │ git commit + push + Pull Request
└──────────────┘
```
---
## Skill Complexity Levels
```
┌─────────────────────────────────────────────────────────────┐
│ SKILL COMPLEXITY │
├─────────────────────────────────────────────────────────────┤
│ │
│ SIMPLE STANDARD COMPLEX │
│ ────── ──────── ─────── │
│ │
│ • 1 file • 1 file • Multiple │
│ • 100-200 words • 300-800 words • 800-2000 │
│ • Basic structure • Full structure • Scripts │
│ • No extras • Examples • Examples │
│ • Best practices • Templates│
│ • Docs │
│ Example: Example: Example: │
│ git-pushing brainstorming loki-mode │
│ │
└─────────────────────────────────────────────────────────────┘
```
---
## 🎯 Contribution Impact (Visual)
```
Your Contribution
├─→ Improves Documentation
│ │
│ └─→ Helps 1000s of developers understand
├─→ Creates New Skill
│ │
│ └─→ Enables new capabilities for everyone
├─→ Fixes Bug/Typo
│ │
│ └─→ Prevents confusion for future users
└─→ Adds Example
└─→ Makes learning easier for beginners
```
---
## Learning Path (Visual Roadmap)
```
START HERE
┌─────────────────┐
│ Read │
│ GETTING_STARTED │
└────────┬────────┘
┌─────────────────┐
│ Try 2-3 Skills │
│ in AI Assistant │
└────────┬────────┘
┌─────────────────┐
│ Read │
│ SKILL_ANATOMY │
└────────┬────────┘
┌─────────────────┐
│ Study Existing │
│ Skills │
└────────┬────────┘
┌─────────────────┐
│ Create Simple │
│ Skill │
└────────┬────────┘
┌─────────────────┐
│ Read │
│ CONTRIBUTING │
└────────┬────────┘
┌─────────────────┐
│ Submit PR │
└────────┬────────┘
CONTRIBUTOR! 🎉
```
---
## 💡 Quick Tips (Visual Cheatsheet)
```
┌─────────────────────────────────────────────────────────────┐
│ QUICK REFERENCE │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📥 INSTALL │
│ git clone [repo] .agent/skills │
│ │
│ 🎯 USE │
│ @skill-name [your request] │
│ │
│ 🔍 FIND │
│ ls skills/ | grep "keyword" │
│ │
│ ✅ VALIDATE │
│ python3 scripts/validate_skills.py │
│ │
│ 📝 CREATE │
│ 1. mkdir skills/my-skill │
│ 2. Create SKILL.md with frontmatter │
│ 3. Add content │
│ 4. Test & validate │
│ 5. Submit PR │
│ │
│ 🆘 HELP │
│ • GETTING_STARTED.md - Basics │
│ • CONTRIBUTING.md - How to contribute │
│ • SKILL_ANATOMY.md - Deep dive │
│ • GitHub Issues - Ask questions │
│ │
└─────────────────────────────────────────────────────────────┘
```
---
## Success Stories (Visual Timeline)
```
Day 1: Install skills
└─→ "Wow, @brainstorming helped me design my app!"
Day 3: Use 5 different skills
└─→ "These skills save me so much time!"
Week 1: Create first skill
└─→ "I shared my expertise as a skill!"
Week 2: Skill gets merged
└─→ "My skill is helping others! 🎉"
Month 1: Regular contributor
└─→ "I've contributed 5 skills and improved docs!"
```
---
## Next Steps
1.**Understand** the visual structure
2.**Install** skills in your AI tool
3.**Try** 2-3 skills from different categories
4.**Read** CONTRIBUTING.md
5.**Create** your first skill
6.**Share** with the community
---
**Visual learner?** This guide should help! Still have questions? Check out:
- [GETTING_STARTED.md](../GETTING_STARTED.md) - Text-based intro
- [SKILL_ANATOMY.md](SKILL_ANATOMY.md) - Detailed breakdown
- [CONTRIBUTING.md](../CONTRIBUTING.md) - How to contribute
**Ready to contribute?** You've got this! 💪

View File

@@ -1,6 +1,9 @@
---
name: Active Directory Attacks
description: This skill should be used when the user asks to "attack Active Directory", "exploit AD", "Kerberoasting", "DCSync", "pass-the-hash", "BloodHound enumeration", "Golden Ticket", "Silver Ticket", "AS-REP roasting", "NTLM relay", or needs guidance on Windows domain penetration testing.
metadata:
author: zebbern
version: "1.1"
---
# Active Directory Attacks

View File

@@ -1,6 +1,9 @@
---
name: API Fuzzing for Bug Bounty
description: This skill should be used when the user asks to "test API security", "fuzz APIs", "find IDOR vulnerabilities", "test REST API", "test GraphQL", "API penetration testing", "bug bounty API testing", or needs guidance on API security assessment techniques.
metadata:
author: zebbern
version: "1.1"
---
# API Fuzzing for Bug Bounty

View File

@@ -0,0 +1,81 @@
---
name: api-patterns
description: API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination.
allowed-tools: Read, Write, Edit, Glob, Grep
---
# API Patterns
> API design principles and decision-making for 2025.
> **Learn to THINK, not copy fixed patterns.**
## 🎯 Selective Reading Rule
**Read ONLY files relevant to the request!** Check the content map, find what you need.
---
## 📑 Content Map
| File | Description | When to Read |
|------|-------------|--------------|
| `api-style.md` | REST vs GraphQL vs tRPC decision tree | Choosing API type |
| `rest.md` | Resource naming, HTTP methods, status codes | Designing REST API |
| `response.md` | Envelope pattern, error format, pagination | Response structure |
| `graphql.md` | Schema design, when to use, security | Considering GraphQL |
| `trpc.md` | TypeScript monorepo, type safety | TS fullstack projects |
| `versioning.md` | URI/Header/Query versioning | API evolution planning |
| `auth.md` | JWT, OAuth, Passkey, API Keys | Auth pattern selection |
| `rate-limiting.md` | Token bucket, sliding window | API protection |
| `documentation.md` | OpenAPI/Swagger best practices | Documentation |
| `security-testing.md` | OWASP API Top 10, auth/authz testing | Security audits |
---
## 🔗 Related Skills
| Need | Skill |
|------|-------|
| API implementation | `@[skills/backend-development]` |
| Data structure | `@[skills/database-design]` |
| Security details | `@[skills/security-hardening]` |
---
## ✅ Decision Checklist
Before designing an API:
- [ ] **Asked user about API consumers?**
- [ ] **Chosen API style for THIS context?** (REST/GraphQL/tRPC)
- [ ] **Defined consistent response format?**
- [ ] **Planned versioning strategy?**
- [ ] **Considered authentication needs?**
- [ ] **Planned rate limiting?**
- [ ] **Documentation approach defined?**
---
## ❌ Anti-Patterns
**DON'T:**
- Default to REST for everything
- Use verbs in REST endpoints (/getUsers)
- Return inconsistent response formats
- Expose internal errors to clients
- Skip rate limiting
**DO:**
- Choose API style based on context
- Ask about client requirements
- Document thoroughly
- Use appropriate status codes
---
## Script
| Script | Purpose | Command |
|--------|---------|---------|
| `scripts/api_validator.py` | API endpoint validation | `python scripts/api_validator.py <project_path>` |

View File

@@ -0,0 +1,42 @@
# API Style Selection (2025)
> REST vs GraphQL vs tRPC - Hangi durumda hangisi?
## Decision Tree
```
Who are the API consumers?
├── Public API / Multiple platforms
│ └── REST + OpenAPI (widest compatibility)
├── Complex data needs / Multiple frontends
│ └── GraphQL (flexible queries)
├── TypeScript frontend + backend (monorepo)
│ └── tRPC (end-to-end type safety)
├── Real-time / Event-driven
│ └── WebSocket + AsyncAPI
└── Internal microservices
└── gRPC (performance) or REST (simplicity)
```
## Comparison
| Factor | REST | GraphQL | tRPC |
|--------|------|---------|------|
| **Best for** | Public APIs | Complex apps | TS monorepos |
| **Learning curve** | Low | Medium | Low (if TS) |
| **Over/under fetching** | Common | Solved | Solved |
| **Type safety** | Manual (OpenAPI) | Schema-based | Automatic |
| **Caching** | HTTP native | Complex | Client-based |
## Selection Questions
1. Who are the API consumers?
2. Is the frontend TypeScript?
3. How complex are the data relationships?
4. Is caching critical?
5. Public or internal API?

View File

@@ -0,0 +1,24 @@
# Authentication Patterns
> Choose auth pattern based on use case.
## Selection Guide
| Pattern | Best For |
|---------|----------|
| **JWT** | Stateless, microservices |
| **Session** | Traditional web, simple |
| **OAuth 2.0** | Third-party integration |
| **API Keys** | Server-to-server, public APIs |
| **Passkey** | Modern passwordless (2025+) |
## JWT Principles
```
Important:
├── Always verify signature
├── Check expiration
├── Include minimal claims
├── Use short expiry + refresh tokens
└── Never store sensitive data in JWT
```

View File

@@ -0,0 +1,26 @@
# API Documentation Principles
> Good docs = happy developers = API adoption.
## OpenAPI/Swagger Essentials
```
Include:
├── All endpoints with examples
├── Request/response schemas
├── Authentication requirements
├── Error response formats
└── Rate limiting info
```
## Good Documentation Has
```
Essentials:
├── Quick start / Getting started
├── Authentication guide
├── Complete API reference
├── Error handling guide
├── Code examples (multiple languages)
└── Changelog
```

View File

@@ -0,0 +1,41 @@
# GraphQL Principles
> Flexible queries for complex, interconnected data.
## When to Use
```
✅ Good fit:
├── Complex, interconnected data
├── Multiple frontend platforms
├── Clients need flexible queries
├── Evolving data requirements
└── Reducing over-fetching matters
❌ Poor fit:
├── Simple CRUD operations
├── File upload heavy
├── HTTP caching important
└── Team unfamiliar with GraphQL
```
## Schema Design Principles
```
Principles:
├── Think in graphs, not endpoints
├── Design for evolvability (no versions)
├── Use connections for pagination
├── Be specific with types (not generic "data")
└── Handle nullability thoughtfully
```
## Security Considerations
```
Protect against:
├── Query depth attacks → Set max depth
├── Query complexity → Calculate cost
├── Batching abuse → Limit batch size
├── Introspection → Disable in production
```

View File

@@ -0,0 +1,31 @@
# Rate Limiting Principles
> Protect your API from abuse and overload.
## Why Rate Limit
```
Protect against:
├── Brute force attacks
├── Resource exhaustion
├── Cost overruns (if pay-per-use)
└── Unfair usage
```
## Strategy Selection
| Type | How | When |
|------|-----|------|
| **Token bucket** | Burst allowed, refills over time | Most APIs |
| **Sliding window** | Smooth distribution | Strict limits |
| **Fixed window** | Simple counters per window | Basic needs |
## Response Headers
```
Include in headers:
├── X-RateLimit-Limit (max requests)
├── X-RateLimit-Remaining (requests left)
├── X-RateLimit-Reset (when limit resets)
└── Return 429 when exceeded
```

View File

@@ -0,0 +1,37 @@
# Response Format Principles
> Consistency is key - choose a format and stick to it.
## Common Patterns
```
Choose one:
├── Envelope pattern ({ success, data, error })
├── Direct data (just return the resource)
└── HAL/JSON:API (hypermedia)
```
## Error Response
```
Include:
├── Error code (for programmatic handling)
├── User message (for display)
├── Details (for debugging, field-level errors)
├── Request ID (for support)
└── NOT internal details (security!)
```
## Pagination Types
| Type | Best For | Trade-offs |
|------|----------|------------|
| **Offset** | Simple, jumpable | Performance on large datasets |
| **Cursor** | Large datasets | Can't jump to page |
| **Keyset** | Performance critical | Requires sortable key |
### Selection Questions
1. How large is the dataset?
2. Do users need to jump to specific pages?
3. Is data frequently changing?

View File

@@ -0,0 +1,40 @@
# REST Principles
> Resource-based API design - nouns not verbs.
## Resource Naming Rules
```
Principles:
├── Use NOUNS, not verbs (resources, not actions)
├── Use PLURAL forms (/users not /user)
├── Use lowercase with hyphens (/user-profiles)
├── Nest for relationships (/users/123/posts)
└── Keep shallow (max 3 levels deep)
```
## HTTP Method Selection
| Method | Purpose | Idempotent? | Body? |
|--------|---------|-------------|-------|
| **GET** | Read resource(s) | Yes | No |
| **POST** | Create new resource | No | Yes |
| **PUT** | Replace entire resource | Yes | Yes |
| **PATCH** | Partial update | No | Yes |
| **DELETE** | Remove resource | Yes | No |
## Status Code Selection
| Situation | Code | Why |
|-----------|------|-----|
| Success (read) | 200 | Standard success |
| Created | 201 | New resource created |
| No content | 204 | Success, nothing to return |
| Bad request | 400 | Malformed request |
| Unauthorized | 401 | Missing/invalid auth |
| Forbidden | 403 | Valid auth, no permission |
| Not found | 404 | Resource doesn't exist |
| Conflict | 409 | State conflict (duplicate) |
| Validation error | 422 | Valid syntax, invalid data |
| Rate limited | 429 | Too many requests |
| Server error | 500 | Our fault |

View File

@@ -0,0 +1,211 @@
#!/usr/bin/env python3
"""
API Validator - Checks API endpoints for best practices.
Validates OpenAPI specs, response formats, and common issues.
"""
import sys
import json
import re
from pathlib import Path
# Fix Windows console encoding for Unicode output
try:
sys.stdout.reconfigure(encoding='utf-8', errors='replace')
sys.stderr.reconfigure(encoding='utf-8', errors='replace')
except AttributeError:
pass # Python < 3.7
def find_api_files(project_path: Path) -> list:
"""Find API-related files."""
patterns = [
"**/*api*.ts", "**/*api*.js", "**/*api*.py",
"**/routes/*.ts", "**/routes/*.js", "**/routes/*.py",
"**/controllers/*.ts", "**/controllers/*.js",
"**/endpoints/*.ts", "**/endpoints/*.py",
"**/*.openapi.json", "**/*.openapi.yaml",
"**/swagger.json", "**/swagger.yaml",
"**/openapi.json", "**/openapi.yaml"
]
files = []
for pattern in patterns:
files.extend(project_path.glob(pattern))
# Exclude node_modules, etc.
return [f for f in files if not any(x in str(f) for x in ['node_modules', '.git', 'dist', 'build', '__pycache__'])]
def check_openapi_spec(file_path: Path) -> dict:
"""Check OpenAPI/Swagger specification."""
issues = []
passed = []
try:
content = file_path.read_text(encoding='utf-8')
if file_path.suffix == '.json':
spec = json.loads(content)
else:
# Basic YAML check
if 'openapi:' in content or 'swagger:' in content:
passed.append("[OK] OpenAPI/Swagger version defined")
else:
issues.append("[X] No OpenAPI version found")
if 'paths:' in content:
passed.append("[OK] Paths section exists")
else:
issues.append("[X] No paths defined")
if 'components:' in content or 'definitions:' in content:
passed.append("[OK] Schema components defined")
return {'file': str(file_path), 'passed': passed, 'issues': issues, 'type': 'openapi'}
# JSON OpenAPI checks
if 'openapi' in spec or 'swagger' in spec:
passed.append("[OK] OpenAPI version defined")
if 'info' in spec:
if 'title' in spec['info']:
passed.append("[OK] API title defined")
if 'version' in spec['info']:
passed.append("[OK] API version defined")
if 'description' not in spec['info']:
issues.append("[!] API description missing")
if 'paths' in spec:
path_count = len(spec['paths'])
passed.append(f"[OK] {path_count} endpoints defined")
# Check each path
for path, methods in spec['paths'].items():
for method, details in methods.items():
if method in ['get', 'post', 'put', 'patch', 'delete']:
if 'responses' not in details:
issues.append(f"[X] {method.upper()} {path}: No responses defined")
if 'summary' not in details and 'description' not in details:
issues.append(f"[!] {method.upper()} {path}: No description")
except Exception as e:
issues.append(f"[X] Parse error: {e}")
return {'file': str(file_path), 'passed': passed, 'issues': issues, 'type': 'openapi'}
def check_api_code(file_path: Path) -> dict:
"""Check API code for common issues."""
issues = []
passed = []
try:
content = file_path.read_text(encoding='utf-8')
# Check for error handling
error_patterns = [
r'try\s*{', r'try:', r'\.catch\(',
r'except\s+', r'catch\s*\('
]
has_error_handling = any(re.search(p, content) for p in error_patterns)
if has_error_handling:
passed.append("[OK] Error handling present")
else:
issues.append("[X] No error handling found")
# Check for status codes
status_patterns = [
r'status\s*\(\s*\d{3}\s*\)', r'statusCode\s*[=:]\s*\d{3}',
r'HttpStatus\.', r'status_code\s*=\s*\d{3}',
r'\.status\(\d{3}\)', r'res\.status\('
]
has_status = any(re.search(p, content) for p in status_patterns)
if has_status:
passed.append("[OK] HTTP status codes used")
else:
issues.append("[!] No explicit HTTP status codes")
# Check for validation
validation_patterns = [
r'validate', r'schema', r'zod', r'joi', r'yup',
r'pydantic', r'@Body\(', r'@Query\('
]
has_validation = any(re.search(p, content, re.I) for p in validation_patterns)
if has_validation:
passed.append("[OK] Input validation present")
else:
issues.append("[!] No input validation detected")
# Check for auth middleware
auth_patterns = [
r'auth', r'jwt', r'bearer', r'token',
r'middleware', r'guard', r'@Authenticated'
]
has_auth = any(re.search(p, content, re.I) for p in auth_patterns)
if has_auth:
passed.append("[OK] Authentication/authorization detected")
# Check for rate limiting
rate_patterns = [r'rateLimit', r'throttle', r'rate.?limit']
has_rate = any(re.search(p, content, re.I) for p in rate_patterns)
if has_rate:
passed.append("[OK] Rate limiting present")
# Check for logging
log_patterns = [r'console\.log', r'logger\.', r'logging\.', r'log\.']
has_logging = any(re.search(p, content) for p in log_patterns)
if has_logging:
passed.append("[OK] Logging present")
except Exception as e:
issues.append(f"[X] Read error: {e}")
return {'file': str(file_path), 'passed': passed, 'issues': issues, 'type': 'code'}
def main():
target = sys.argv[1] if len(sys.argv) > 1 else "."
project_path = Path(target)
print("\n" + "=" * 60)
print(" API VALIDATOR - Endpoint Best Practices Check")
print("=" * 60 + "\n")
api_files = find_api_files(project_path)
if not api_files:
print("[!] No API files found.")
print(" Looking for: routes/, controllers/, api/, openapi.json/yaml")
sys.exit(0)
results = []
for file_path in api_files[:15]: # Limit
if 'openapi' in file_path.name.lower() or 'swagger' in file_path.name.lower():
result = check_openapi_spec(file_path)
else:
result = check_api_code(file_path)
results.append(result)
# Print results
total_issues = 0
total_passed = 0
for result in results:
print(f"\n[FILE] {result['file']} [{result['type']}]")
for item in result['passed']:
print(f" {item}")
total_passed += 1
for item in result['issues']:
print(f" {item}")
if item.startswith("[X]"):
total_issues += 1
print("\n" + "=" * 60)
print(f"[RESULTS] {total_passed} passed, {total_issues} critical issues")
print("=" * 60)
if total_issues == 0:
print("[OK] API validation passed")
sys.exit(0)
else:
print("[X] Fix critical issues before deployment")
sys.exit(1)
if __name__ == "__main__":
main()

View File

@@ -0,0 +1,122 @@
# API Security Testing
> Principles for testing API security. OWASP API Top 10, authentication, authorization testing.
---
## OWASP API Security Top 10
| Vulnerability | Test Focus |
|---------------|------------|
| **API1: BOLA** | Access other users' resources |
| **API2: Broken Auth** | JWT, session, credentials |
| **API3: Property Auth** | Mass assignment, data exposure |
| **API4: Resource Consumption** | Rate limiting, DoS |
| **API5: Function Auth** | Admin endpoints, role bypass |
| **API6: Business Flow** | Logic abuse, automation |
| **API7: SSRF** | Internal network access |
| **API8: Misconfiguration** | Debug endpoints, CORS |
| **API9: Inventory** | Shadow APIs, old versions |
| **API10: Unsafe Consumption** | Third-party API trust |
---
## Authentication Testing
### JWT Testing
| Check | What to Test |
|-------|--------------|
| Algorithm | None, algorithm confusion |
| Secret | Weak secrets, brute force |
| Claims | Expiration, issuer, audience |
| Signature | Manipulation, key injection |
### Session Testing
| Check | What to Test |
|-------|--------------|
| Generation | Predictability |
| Storage | Client-side security |
| Expiration | Timeout enforcement |
| Invalidation | Logout effectiveness |
---
## Authorization Testing
| Test Type | Approach |
|-----------|----------|
| **Horizontal** | Access peer users' data |
| **Vertical** | Access higher privilege functions |
| **Context** | Access outside allowed scope |
### BOLA/IDOR Testing
1. Identify resource IDs in requests
2. Capture request with user A's session
3. Replay with user B's session
4. Check for unauthorized access
---
## Input Validation Testing
| Injection Type | Test Focus |
|----------------|------------|
| SQL | Query manipulation |
| NoSQL | Document queries |
| Command | System commands |
| LDAP | Directory queries |
**Approach:** Test all parameters, try type coercion, test boundaries, check error messages.
---
## Rate Limiting Testing
| Aspect | Check |
|--------|-------|
| Existence | Is there any limit? |
| Bypass | Headers, IP rotation |
| Scope | Per-user, per-IP, global |
**Bypass techniques:** X-Forwarded-For, different HTTP methods, case variations, API versioning.
---
## GraphQL Security
| Test | Focus |
|------|-------|
| Introspection | Schema disclosure |
| Batching | Query DoS |
| Nesting | Depth-based DoS |
| Authorization | Field-level access |
---
## Security Testing Checklist
**Authentication:**
- [ ] Test for bypass
- [ ] Check credential strength
- [ ] Verify token security
**Authorization:**
- [ ] Test BOLA/IDOR
- [ ] Check privilege escalation
- [ ] Verify function access
**Input:**
- [ ] Test all parameters
- [ ] Check for injection
**Config:**
- [ ] Check CORS
- [ ] Verify headers
- [ ] Test error handling
---
> **Remember:** APIs are the backbone of modern apps. Test them like attackers will.

View File

@@ -0,0 +1,41 @@
# tRPC Principles
> End-to-end type safety for TypeScript monorepos.
## When to Use
```
✅ Perfect fit:
├── TypeScript on both ends
├── Monorepo structure
├── Internal tools
├── Rapid development
└── Type safety critical
❌ Poor fit:
├── Non-TypeScript clients
├── Public API
├── Need REST conventions
└── Multiple language backends
```
## Key Benefits
```
Why tRPC:
├── Zero schema maintenance
├── End-to-end type inference
├── IDE autocomplete across stack
├── Instant API changes reflected
└── No code generation step
```
## Integration Patterns
```
Common setups:
├── Next.js + tRPC (most common)
├── Monorepo with shared types
├── Remix + tRPC
└── Any TS frontend + backend
```

View File

@@ -0,0 +1,22 @@
# Versioning Strategies
> Plan for API evolution from day one.
## Decision Factors
| Strategy | Implementation | Trade-offs |
|----------|---------------|------------|
| **URI** | /v1/users | Clear, easy caching |
| **Header** | Accept-Version: 1 | Cleaner URLs, harder discovery |
| **Query** | ?version=1 | Easy to add, messy |
| **None** | Evolve carefully | Best for internal, risky for public |
## Versioning Philosophy
```
Consider:
├── Public API? → Version in URI
├── Internal only? → May not need versioning
├── GraphQL? → Typically no versions (evolve schema)
├── tRPC? → Types enforce compatibility
```

View File

@@ -0,0 +1,75 @@
---
name: app-builder
description: Main application building orchestrator. Creates full-stack applications from natural language requests. Determines project type, selects tech stack, coordinates agents.
allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent
---
# App Builder - Application Building Orchestrator
> Analyzes user's requests, determines tech stack, plans structure, and coordinates agents.
## 🎯 Selective Reading Rule
**Read ONLY files relevant to the request!** Check the content map, find what you need.
| File | Description | When to Read |
|------|-------------|--------------|
| `project-detection.md` | Keyword matrix, project type detection | Starting new project |
| `tech-stack.md` | 2025 default stack, alternatives | Choosing technologies |
| `agent-coordination.md` | Agent pipeline, execution order | Coordinating multi-agent work |
| `scaffolding.md` | Directory structure, core files | Creating project structure |
| `feature-building.md` | Feature analysis, error handling | Adding features to existing project |
| `templates/SKILL.md` | **Project templates** | Scaffolding new project |
---
## 📦 Templates (13)
Quick-start scaffolding for new projects. **Read the matching template only!**
| Template | Tech Stack | When to Use |
|----------|------------|-------------|
| [nextjs-fullstack](templates/nextjs-fullstack/TEMPLATE.md) | Next.js + Prisma | Full-stack web app |
| [nextjs-saas](templates/nextjs-saas/TEMPLATE.md) | Next.js + Stripe | SaaS product |
| [nextjs-static](templates/nextjs-static/TEMPLATE.md) | Next.js + Framer | Landing page |
| [nuxt-app](templates/nuxt-app/TEMPLATE.md) | Nuxt 3 + Pinia | Vue full-stack app |
| [express-api](templates/express-api/TEMPLATE.md) | Express + JWT | REST API |
| [python-fastapi](templates/python-fastapi/TEMPLATE.md) | FastAPI | Python API |
| [react-native-app](templates/react-native-app/TEMPLATE.md) | Expo + Zustand | Mobile app |
| [flutter-app](templates/flutter-app/TEMPLATE.md) | Flutter + Riverpod | Cross-platform mobile |
| [electron-desktop](templates/electron-desktop/TEMPLATE.md) | Electron + React | Desktop app |
| [chrome-extension](templates/chrome-extension/TEMPLATE.md) | Chrome MV3 | Browser extension |
| [cli-tool](templates/cli-tool/TEMPLATE.md) | Node.js + Commander | CLI app |
| [monorepo-turborepo](templates/monorepo-turborepo/TEMPLATE.md) | Turborepo + pnpm | Monorepo |
---
## 🔗 Related Agents
| Agent | Role |
|-------|------|
| `project-planner` | Task breakdown, dependency graph |
| `frontend-specialist` | UI components, pages |
| `backend-specialist` | API, business logic |
| `database-architect` | Schema, migrations |
| `devops-engineer` | Deployment, preview |
---
## Usage Example
```
User: "Make an Instagram clone with photo sharing and likes"
App Builder Process:
1. Project type: Social Media App
2. Tech stack: Next.js + Prisma + Cloudinary + Clerk
3. Create plan:
├─ Database schema (users, posts, likes, follows)
├─ API routes (12 endpoints)
├─ Pages (feed, profile, upload)
└─ Components (PostCard, Feed, LikeButton)
4. Coordinate agents
5. Report progress
6. Start preview
```

View File

@@ -0,0 +1,71 @@
# Agent Coordination
> How App Builder orchestrates specialist agents.
## Agent Pipeline
```
┌─────────────────────────────────────────────────────────────┐
│ APP BUILDER (Orchestrator) │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ PROJECT PLANNER │
│ • Task breakdown │
│ • Dependency graph │
│ • File structure planning │
│ • Create {task-slug}.md in project root (MANDATORY) │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ CHECKPOINT: PLAN VERIFICATION │
│ 🔴 VERIFY: Does {task-slug}.md exist in project root? │
│ 🔴 If NO → STOP → Create plan file first │
│ 🔴 If YES → Proceed to specialist agents │
└─────────────────────────────────────────────────────────────┘
┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ DATABASE │ │ BACKEND │ │ FRONTEND │
│ ARCHITECT │ │ SPECIALIST │ │ SPECIALIST │
│ │ │ │ │ │
│ • Schema design │ │ • API routes │ │ • Components │
│ • Migrations │ │ • Controllers │ │ • Pages │
│ • Seed data │ │ • Middleware │ │ • Styling │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
└───────────────────┼───────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ PARALLEL PHASE (Optional) │
│ • Security Auditor → Vulnerability check │
│ • Test Engineer → Unit tests │
│ • Performance Optimizer → Bundle analysis │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ DEVOPS ENGINEER │
│ • Environment setup │
│ • Preview deployment │
│ • Health check │
└─────────────────────────────────────────────────────────────┘
```
## Execution Order
| Phase | Agent(s) | Parallel? | Prerequisite | CHECKPOINT |
|-------|----------|-----------|--------------|------------|
| 0 | Socratic Gate | ❌ | - | ✅ Ask 3 questions |
| 1 | Project Planner | ❌ | Questions answered | ✅ **PLAN.md created** |
| 1.5 | **PLAN VERIFICATION** | ❌ | PLAN.md exists | ✅ **File exists in root** |
| 2 | Database Architect | ❌ | Plan ready | Schema defined |
| 3 | Backend Specialist | ❌ | Schema ready | API routes created |
| 4 | Frontend Specialist | ✅ | API ready (partial) | UI components ready |
| 5 | Security Auditor, Test Engineer | ✅ | Code ready | Tests & audit pass |
| 6 | DevOps Engineer | ❌ | All code ready | Deployment ready |
> 🔴 **CRITICAL:** Phase 1.5 is MANDATORY. No specialist agents proceed without PLAN.md verification.

View File

@@ -0,0 +1,53 @@
# Feature Building
> How to analyze and implement new features.
## Feature Analysis
```
Request: "add payment system"
Analysis:
├── Required Changes:
│ ├── Database: orders, payments tables
│ ├── Backend: /api/checkout, /api/webhooks/stripe
│ ├── Frontend: CheckoutForm, PaymentSuccess
│ └── Config: Stripe API keys
├── Dependencies:
│ ├── stripe package
│ └── Existing user authentication
└── Estimated Time: 15-20 minutes
```
## Iterative Enhancement Process
```
1. Analyze existing project
2. Create change plan
3. Present plan to user
4. Get approval
5. Apply changes
6. Test
7. Show preview
```
## Error Handling
| Error Type | Solution Strategy |
|------------|-------------------|
| TypeScript Error | Fix type, add missing import |
| Missing Dependency | Run npm install |
| Port Conflict | Suggest alternative port |
| Database Error | Check migration, validate connection |
## Recovery Strategy
```
1. Detect error
2. Try automatic fix
3. If failed, report to user
4. Suggest alternative
5. Rollback if necessary
```

View File

@@ -0,0 +1,34 @@
# Project Type Detection
> Analyze user requests to determine project type and template.
## Keyword Matrix
| Keywords | Project Type | Template |
|----------|--------------|----------|
| blog, post, article | Blog | astro-static |
| e-commerce, product, cart, payment | E-commerce | nextjs-saas |
| dashboard, panel, management | Admin Dashboard | nextjs-fullstack |
| api, backend, service, rest | API Service | express-api |
| python, fastapi, django | Python API | python-fastapi |
| mobile, android, ios, react native | Mobile App (RN) | react-native-app |
| flutter, dart | Mobile App (Flutter) | flutter-app |
| portfolio, personal, cv | Portfolio | nextjs-static |
| crm, customer, sales | CRM | nextjs-fullstack |
| saas, subscription, stripe | SaaS | nextjs-saas |
| landing, promotional, marketing | Landing Page | nextjs-static |
| docs, documentation | Documentation | astro-static |
| extension, plugin, chrome | Browser Extension | chrome-extension |
| desktop, electron | Desktop App | electron-desktop |
| cli, command line, terminal | CLI Tool | cli-tool |
| monorepo, workspace | Monorepo | monorepo-turborepo |
## Detection Process
```
1. Tokenize user request
2. Extract keywords
3. Determine project type
4. Detect missing information → forward to conversation-manager
5. Suggest tech stack
```

View File

@@ -0,0 +1,118 @@
# Project Scaffolding
> Directory structure and core files for new projects.
---
## Next.js Full-Stack Structure (2025 Optimized)
```
project-name/
├── src/
│ ├── app/ # Routes only (thin layer)
│ │ ├── layout.tsx
│ │ ├── page.tsx
│ │ ├── globals.css
│ │ ├── (auth)/ # Route group - auth pages
│ │ │ ├── login/page.tsx
│ │ │ └── register/page.tsx
│ │ ├── (dashboard)/ # Route group - dashboard layout
│ │ │ ├── layout.tsx
│ │ │ └── page.tsx
│ │ └── api/
│ │ └── [resource]/route.ts
│ │
│ ├── features/ # Feature-based modules
│ │ ├── auth/
│ │ │ ├── components/
│ │ │ ├── hooks/
│ │ │ ├── actions.ts # Server Actions
│ │ │ ├── queries.ts # Data fetching
│ │ │ └── types.ts
│ │ ├── products/
│ │ │ ├── components/
│ │ │ ├── actions.ts
│ │ │ └── queries.ts
│ │ └── cart/
│ │ └── ...
│ │
│ ├── shared/ # Shared utilities
│ │ ├── components/ui/ # Reusable UI components
│ │ ├── lib/ # Utils, helpers
│ │ └── hooks/ # Global hooks
│ │
│ └── server/ # Server-only code
│ ├── db/ # Database client (Prisma)
│ ├── auth/ # Auth config
│ └── services/ # External API integrations
├── prisma/
│ ├── schema.prisma
│ ├── migrations/
│ └── seed.ts
├── public/
├── .env.example
├── .env.local
├── package.json
├── tailwind.config.ts
├── tsconfig.json
└── README.md
```
---
## Structure Principles
| Principle | Implementation |
|-----------|----------------|
| **Feature isolation** | Each feature in `features/` with its own components, hooks, actions |
| **Server/Client separation** | Server-only code in `server/`, prevents accidental client imports |
| **Thin routes** | `app/` only for routing, logic lives in `features/` |
| **Route groups** | `(groupName)/` for layout sharing without URL impact |
| **Shared code** | `shared/` for truly reusable UI and utilities |
---
## Core Files
| File | Purpose |
|------|---------|
| `package.json` | Dependencies |
| `tsconfig.json` | TypeScript + path aliases (`@/features/*`) |
| `tailwind.config.ts` | Tailwind config |
| `.env.example` | Environment template |
| `README.md` | Project documentation |
| `.gitignore` | Git ignore rules |
| `prisma/schema.prisma` | Database schema |
---
## Path Aliases (tsconfig.json)
```json
{
"compilerOptions": {
"paths": {
"@/*": ["./src/*"],
"@/features/*": ["./src/features/*"],
"@/shared/*": ["./src/shared/*"],
"@/server/*": ["./src/server/*"]
}
}
}
```
---
## When to Use What
| Need | Location |
|------|----------|
| New page/route | `app/(group)/page.tsx` |
| Feature component | `features/[name]/components/` |
| Server action | `features/[name]/actions.ts` |
| Data fetching | `features/[name]/queries.ts` |
| Reusable button/input | `shared/components/ui/` |
| Database query | `server/db/` |
| External API call | `server/services/` |

View File

@@ -0,0 +1,40 @@
# Tech Stack Selection (2025)
> Default and alternative technology choices for web applications.
## Default Stack (Web App - 2025)
```yaml
Frontend:
framework: Next.js 16 (Stable)
language: TypeScript 5.7+
styling: Tailwind CSS v4
state: React 19 Actions / Server Components
bundler: Turbopack (Stable for Dev)
Backend:
runtime: Node.js 23
framework: Next.js API Routes / Hono (for Edge)
validation: Zod / TypeBox
Database:
primary: PostgreSQL
orm: Prisma / Drizzle
hosting: Supabase / Neon
Auth:
provider: Auth.js (v5) / Clerk
Monorepo:
tool: Turborepo 2.0
```
## Alternative Options
| Need | Default | Alternative |
|------|---------|-------------|
| Real-time | - | Supabase Realtime, Socket.io |
| File storage | - | Cloudinary, S3 |
| Payment | Stripe | LemonSqueezy, Paddle |
| Email | - | Resend, SendGrid |
| Search | - | Algolia, Typesense |

View File

@@ -0,0 +1,39 @@
---
name: templates
description: Project scaffolding templates for new applications. Use when creating new projects from scratch. Contains 12 templates for various tech stacks.
allowed-tools: Read, Glob, Grep
---
# Project Templates
> Quick-start templates for scaffolding new projects.
---
## 🎯 Selective Reading Rule
**Read ONLY the template matching user's project type!**
| Template | Tech Stack | When to Use |
|----------|------------|-------------|
| [nextjs-fullstack](nextjs-fullstack/TEMPLATE.md) | Next.js + Prisma | Full-stack web app |
| [nextjs-saas](nextjs-saas/TEMPLATE.md) | Next.js + Stripe | SaaS product |
| [nextjs-static](nextjs-static/TEMPLATE.md) | Next.js + Framer | Landing page |
| [express-api](express-api/TEMPLATE.md) | Express + JWT | REST API |
| [python-fastapi](python-fastapi/TEMPLATE.md) | FastAPI | Python API |
| [react-native-app](react-native-app/TEMPLATE.md) | Expo + Zustand | Mobile app |
| [flutter-app](flutter-app/TEMPLATE.md) | Flutter + Riverpod | Cross-platform |
| [electron-desktop](electron-desktop/TEMPLATE.md) | Electron + React | Desktop app |
| [chrome-extension](chrome-extension/TEMPLATE.md) | Chrome MV3 | Browser extension |
| [cli-tool](cli-tool/TEMPLATE.md) | Node.js + Commander | CLI app |
| [monorepo-turborepo](monorepo-turborepo/TEMPLATE.md) | Turborepo + pnpm | Monorepo |
| [astro-static](astro-static/TEMPLATE.md) | Astro + MDX | Blog / Docs |
---
## Usage
1. User says "create [type] app"
2. Match to appropriate template
3. Read ONLY that template's TEMPLATE.md
4. Follow its tech stack and structure

View File

@@ -0,0 +1,76 @@
---
name: astro-static
description: Astro static site template principles. Content-focused websites, blogs, documentation.
---
# Astro Static Site Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Framework | Astro 4.x |
| Content | MDX + Content Collections |
| Styling | Tailwind CSS |
| Integrations | Sitemap, RSS, SEO |
| Output | Static/SSG |
---
## Directory Structure
```
project-name/
├── src/
│ ├── components/ # .astro components
│ ├── content/ # MDX content
│ │ ├── blog/
│ │ └── config.ts # Collection schemas
│ ├── layouts/ # Page layouts
│ ├── pages/ # File-based routing
│ └── styles/
├── public/ # Static assets
├── astro.config.mjs
└── package.json
```
---
## Key Concepts
| Concept | Description |
|---------|-------------|
| Content Collections | Type-safe content with Zod schemas |
| Islands Architecture | Partial hydration for interactivity |
| Zero JS by default | Static HTML unless needed |
| MDX Support | Markdown with components |
---
## Setup Steps
1. `npm create astro@latest {{name}}`
2. Add integrations: `npx astro add mdx tailwind sitemap`
3. Configure `astro.config.mjs`
4. Create content collections
5. `npm run dev`
---
## Deployment
| Platform | Method |
|----------|--------|
| Vercel | Auto-detected |
| Netlify | Auto-detected |
| Cloudflare Pages | Auto-detected |
| GitHub Pages | Build + deploy action |
---
## Best Practices
- Use Content Collections for type safety
- Leverage static generation
- Add islands only where needed
- Optimize images with Astro Image

View File

@@ -0,0 +1,92 @@
---
name: chrome-extension
description: Chrome Extension template principles. Manifest V3, React, TypeScript.
---
# Chrome Extension Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Manifest | V3 |
| UI | React 18 |
| Language | TypeScript |
| Styling | Tailwind CSS |
| Bundler | Vite |
| Storage | Chrome Storage API |
---
## Directory Structure
```
project-name/
├── src/
│ ├── popup/ # Extension popup
│ ├── options/ # Options page
│ ├── background/ # Service worker
│ ├── content/ # Content scripts
│ ├── components/
│ ├── hooks/
│ └── lib/
│ ├── storage.ts # Chrome storage helpers
│ └── messaging.ts # Message passing
├── public/
│ ├── icons/
│ └── manifest.json
└── package.json
```
---
## Manifest V3 Concepts
| Component | Purpose |
|-----------|---------|
| Service Worker | Background processing |
| Content Scripts | Page injection |
| Popup | User interface |
| Options Page | Settings |
---
## Permissions
| Permission | Use |
|------------|-----|
| storage | Save user data |
| activeTab | Current tab access |
| scripting | Inject scripts |
| host_permissions | Site access |
---
## Setup Steps
1. `npm create vite {{name}} -- --template react-ts`
2. Add Chrome types: `npm install -D @types/chrome`
3. Configure Vite for multi-entry
4. Create manifest.json
5. `npm run dev` (watch mode)
6. Load in Chrome: `chrome://extensions` → Load unpacked
---
## Development Tips
| Task | Method |
|------|--------|
| Debug Popup | Right-click icon → Inspect |
| Debug Background | Extensions page → Service worker |
| Debug Content | DevTools console on page |
| Hot Reload | `npm run dev` with watch |
---
## Best Practices
- Use type-safe messaging
- Wrap Chrome APIs in promises
- Minimize permissions
- Handle offline gracefully

View File

@@ -0,0 +1,88 @@
---
name: cli-tool
description: Node.js CLI tool template principles. Commander.js, interactive prompts.
---
# CLI Tool Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Runtime | Node.js 20+ |
| Language | TypeScript |
| CLI Framework | Commander.js |
| Prompts | Inquirer.js |
| Output | chalk + ora |
| Config | cosmiconfig |
---
## Directory Structure
```
project-name/
├── src/
│ ├── index.ts # Entry point
│ ├── cli.ts # CLI setup
│ ├── commands/ # Command handlers
│ ├── lib/
│ │ ├── config.ts # Config loader
│ │ └── logger.ts # Styled output
│ └── types/
├── bin/
│ └── cli.js # Executable
└── package.json
```
---
## CLI Design Principles
| Principle | Description |
|-----------|-------------|
| Subcommands | Group related actions |
| Options | Flags with defaults |
| Interactive | Prompts when needed |
| Non-interactive | Support --yes flags |
---
## Key Components
| Component | Purpose |
|-----------|---------|
| Commander | Command parsing |
| Inquirer | Interactive prompts |
| Chalk | Colored output |
| Ora | Spinners/loading |
| Cosmiconfig | Config file discovery |
---
## Setup Steps
1. Create project directory
2. `npm init -y`
3. Install deps: `npm install commander @inquirer/prompts chalk ora cosmiconfig`
4. Configure bin in package.json
5. `npm link` for local testing
---
## Publishing
```bash
npm login
npm publish
```
---
## Best Practices
- Provide helpful error messages
- Support both interactive and non-interactive modes
- Use consistent output styling
- Validate inputs with Zod
- Exit with proper codes (0 success, 1 error)

View File

@@ -0,0 +1,88 @@
---
name: electron-desktop
description: Electron desktop app template principles. Cross-platform, React, TypeScript.
---
# Electron Desktop App Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Framework | Electron 28+ |
| UI | React 18 |
| Language | TypeScript |
| Styling | Tailwind CSS |
| Bundler | Vite + electron-builder |
| IPC | Type-safe communication |
---
## Directory Structure
```
project-name/
├── electron/
│ ├── main.ts # Main process
│ ├── preload.ts # Preload script
│ └── ipc/ # IPC handlers
├── src/
│ ├── App.tsx
│ ├── components/
│ │ ├── TitleBar.tsx # Custom title bar
│ │ └── ...
│ └── hooks/
├── public/
└── package.json
```
---
## Process Model
| Process | Role |
|---------|------|
| Main | Node.js, system access |
| Renderer | Chromium, React UI |
| Preload | Bridge, context isolation |
---
## Key Concepts
| Concept | Purpose |
|---------|---------|
| contextBridge | Safe API exposure |
| ipcMain/ipcRenderer | Process communication |
| nodeIntegration: false | Security |
| contextIsolation: true | Security |
---
## Setup Steps
1. `npm create vite {{name}} -- --template react-ts`
2. Install: `npm install -D electron electron-builder vite-plugin-electron`
3. Create electron/ directory
4. Configure main process
5. `npm run electron:dev`
---
## Build Targets
| Platform | Output |
|----------|--------|
| Windows | NSIS, Portable |
| macOS | DMG, ZIP |
| Linux | AppImage, DEB |
---
## Best Practices
- Use preload script for main/renderer bridge
- Type-safe IPC with typed handlers
- Custom title bar for native feel
- Handle window state (maximize, minimize)
- Auto-updates with electron-updater

View File

@@ -0,0 +1,83 @@
---
name: express-api
description: Express.js REST API template principles. TypeScript, Prisma, JWT.
---
# Express.js API Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Runtime | Node.js 20+ |
| Framework | Express.js |
| Language | TypeScript |
| Database | PostgreSQL + Prisma |
| Validation | Zod |
| Auth | JWT + bcrypt |
---
## Directory Structure
```
project-name/
├── prisma/
│ └── schema.prisma
├── src/
│ ├── app.ts # Express setup
│ ├── config/ # Environment
│ ├── routes/ # Route handlers
│ ├── controllers/ # Business logic
│ ├── services/ # Data access
│ ├── middleware/
│ │ ├── auth.ts # JWT verify
│ │ ├── error.ts # Error handler
│ │ └── validate.ts # Zod validation
│ ├── schemas/ # Zod schemas
│ └── utils/
└── package.json
```
---
## Middleware Stack
| Order | Middleware |
|-------|------------|
| 1 | helmet (security) |
| 2 | cors |
| 3 | morgan (logging) |
| 4 | body parsing |
| 5 | routes |
| 6 | error handler |
---
## API Response Format
| Type | Structure |
|------|-----------|
| Success | `{ success: true, data: {...} }` |
| Error | `{ error: "message", details: [...] }` |
---
## Setup Steps
1. Create project directory
2. `npm init -y`
3. Install deps: `npm install express prisma zod bcrypt jsonwebtoken`
4. Configure Prisma
5. `npm run db:push`
6. `npm run dev`
---
## Best Practices
- Layer architecture (routes → controllers → services)
- Validate all inputs with Zod
- Centralized error handling
- Environment-based config
- Use Prisma for type-safe DB access

View File

@@ -0,0 +1,90 @@
---
name: flutter-app
description: Flutter mobile app template principles. Riverpod, Go Router, clean architecture.
---
# Flutter App Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Framework | Flutter 3.x |
| Language | Dart 3.x |
| State | Riverpod 2.0 |
| Navigation | Go Router |
| HTTP | Dio |
| Storage | Hive |
---
## Directory Structure
```
project_name/
├── lib/
│ ├── main.dart
│ ├── app.dart
│ ├── core/
│ │ ├── constants/
│ │ ├── theme/
│ │ ├── router/
│ │ └── utils/
│ ├── features/
│ │ ├── auth/
│ │ │ ├── data/
│ │ │ ├── domain/
│ │ │ └── presentation/
│ │ └── home/
│ ├── shared/
│ │ ├── widgets/
│ │ └── providers/
│ └── services/
│ ├── api/
│ └── storage/
├── test/
└── pubspec.yaml
```
---
## Architecture Layers
| Layer | Contents |
|-------|----------|
| Presentation | Screens, Widgets, Providers |
| Domain | Entities, Use Cases |
| Data | Repositories, Models |
---
## Key Packages
| Package | Purpose |
|---------|---------|
| flutter_riverpod | State management |
| riverpod_annotation | Code generation |
| go_router | Navigation |
| dio | HTTP client |
| freezed | Immutable models |
| hive | Local storage |
---
## Setup Steps
1. `flutter create {{name}} --org com.{{bundle}}`
2. Update `pubspec.yaml`
3. `flutter pub get`
4. Run code generation: `dart run build_runner build`
5. `flutter run`
---
## Best Practices
- Feature-first folder structure
- Riverpod for state, React Query pattern for server state
- Freezed for immutable data classes
- Go Router for declarative navigation
- Material 3 theming

View File

@@ -0,0 +1,90 @@
---
name: monorepo-turborepo
description: Turborepo monorepo template principles. pnpm workspaces, shared packages.
---
# Turborepo Monorepo Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Build System | Turborepo |
| Package Manager | pnpm |
| Apps | Next.js, Express |
| Packages | Shared UI, Config, Types |
| Language | TypeScript |
---
## Directory Structure
```
project-name/
├── apps/
│ ├── web/ # Next.js app
│ ├── api/ # Express API
│ └── docs/ # Documentation
├── packages/
│ ├── ui/ # Shared components
│ ├── config/ # ESLint, TS, Tailwind
│ ├── types/ # Shared types
│ └── utils/ # Shared utilities
├── turbo.json
├── pnpm-workspace.yaml
└── package.json
```
---
## Key Concepts
| Concept | Description |
|---------|-------------|
| Workspaces | pnpm-workspace.yaml |
| Pipeline | turbo.json task graph |
| Caching | Remote/local task caching |
| Dependencies | `workspace:*` protocol |
---
## Turbo Pipeline
| Task | Depends On |
|------|------------|
| build | ^build (dependencies first) |
| dev | cache: false, persistent |
| lint | ^build |
| test | ^build |
---
## Setup Steps
1. Create root directory
2. `pnpm init`
3. Create pnpm-workspace.yaml
4. Create turbo.json
5. Add apps and packages
6. `pnpm install`
7. `pnpm dev`
---
## Common Commands
| Command | Description |
|---------|-------------|
| `pnpm dev` | Run all apps |
| `pnpm build` | Build all |
| `pnpm --filter @name/web dev` | Run specific app |
| `pnpm --filter @name/web add axios` | Add dep to app |
---
## Best Practices
- Shared configs in packages/config
- Shared types in packages/types
- Internal packages with `workspace:*`
- Use Turbo remote caching for CI

View File

@@ -0,0 +1,82 @@
---
name: nextjs-fullstack
description: Next.js full-stack template principles. App Router, Prisma, Tailwind.
---
# Next.js Full-Stack Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Framework | Next.js 14 (App Router) |
| Language | TypeScript |
| Database | PostgreSQL + Prisma |
| Styling | Tailwind CSS |
| Auth | Clerk (optional) |
| Validation | Zod |
---
## Directory Structure
```
project-name/
├── prisma/
│ └── schema.prisma
├── src/
│ ├── app/
│ │ ├── layout.tsx
│ │ ├── page.tsx
│ │ ├── globals.css
│ │ └── api/
│ ├── components/
│ │ └── ui/
│ ├── lib/
│ │ ├── db.ts # Prisma client
│ │ └── utils.ts
│ └── types/
├── .env.example
└── package.json
```
---
## Key Concepts
| Concept | Description |
|---------|-------------|
| Server Components | Default, fetch data |
| Server Actions | Form mutations |
| Route Handlers | API endpoints |
| Prisma | Type-safe ORM |
---
## Environment Variables
| Variable | Purpose |
|----------|---------|
| DATABASE_URL | Prisma connection |
| NEXT_PUBLIC_APP_URL | Public URL |
---
## Setup Steps
1. `npx create-next-app {{name}} --typescript --tailwind --app`
2. `npm install prisma @prisma/client zod`
3. `npx prisma init`
4. Configure schema
5. `npm run db:push`
6. `npm run dev`
---
## Best Practices
- Server Components by default
- Server Actions for mutations
- Prisma for type-safe DB
- Zod for validation
- Edge runtime where possible

View File

@@ -0,0 +1,100 @@
---
name: nextjs-saas
description: Next.js SaaS template principles. Auth, payments, email.
---
# Next.js SaaS Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Framework | Next.js 14 (App Router) |
| Auth | NextAuth.js v5 |
| Payments | Stripe |
| Database | PostgreSQL + Prisma |
| Email | Resend |
| UI | Tailwind (ASK USER: shadcn/Headless UI/Custom?) |
---
## Directory Structure
```
project-name/
├── prisma/
├── src/
│ ├── app/
│ │ ├── (auth)/ # Login, register
│ │ ├── (dashboard)/ # Protected routes
│ │ ├── (marketing)/ # Landing, pricing
│ │ └── api/
│ │ ├── auth/[...nextauth]/
│ │ └── webhooks/stripe/
│ ├── components/
│ │ ├── auth/
│ │ ├── billing/
│ │ └── dashboard/
│ ├── lib/
│ │ ├── auth.ts # NextAuth config
│ │ ├── stripe.ts # Stripe client
│ │ └── email.ts # Resend client
│ └── config/
│ └── subscriptions.ts
└── package.json
```
---
## SaaS Features
| Feature | Implementation |
|---------|---------------|
| Auth | NextAuth + OAuth |
| Subscriptions | Stripe Checkout |
| Billing Portal | Stripe Portal |
| Webhooks | Stripe events |
| Email | Transactional via Resend |
---
## Database Schema
| Model | Fields |
|-------|--------|
| User | id, email, stripeCustomerId, subscriptionId |
| Account | OAuth provider data |
| Session | User sessions |
---
## Environment Variables
| Variable | Purpose |
|----------|---------|
| DATABASE_URL | Prisma |
| NEXTAUTH_SECRET | Auth |
| STRIPE_SECRET_KEY | Payments |
| STRIPE_WEBHOOK_SECRET | Webhooks |
| RESEND_API_KEY | Email |
---
## Setup Steps
1. `npx create-next-app {{name}} --typescript --tailwind --app`
2. Install: `npm install next-auth @auth/prisma-adapter stripe resend`
3. Setup Stripe products/prices
4. Configure environment
5. `npm run db:push`
6. `npm run stripe:listen` (webhooks)
7. `npm run dev`
---
## Best Practices
- Route groups for layout separation
- Stripe webhooks for subscription sync
- NextAuth with Prisma adapter
- Email templates with React Email

View File

@@ -0,0 +1,106 @@
---
name: nextjs-static
description: Next.js static site template principles. Landing pages, portfolios, marketing.
---
# Next.js Static Site Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Framework | Next.js 14 (Static Export) |
| Language | TypeScript |
| Styling | Tailwind CSS |
| Animations | Framer Motion |
| Icons | Lucide React |
| SEO | Next SEO |
---
## Directory Structure
```
project-name/
├── src/
│ ├── app/
│ │ ├── layout.tsx
│ │ ├── page.tsx # Landing
│ │ ├── about/
│ │ ├── contact/
│ │ └── blog/
│ ├── components/
│ │ ├── layout/ # Header, Footer
│ │ ├── sections/ # Hero, Features, CTA
│ │ └── ui/
│ └── lib/
├── content/ # Markdown content
├── public/
└── next.config.js
```
---
## Static Export Config
```javascript
// next.config.js
const nextConfig = {
output: 'export',
images: { unoptimized: true },
trailingSlash: true,
};
```
---
## Landing Page Sections
| Section | Purpose |
|---------|---------|
| Hero | Main headline, CTA |
| Features | Product benefits |
| Testimonials | Social proof |
| Pricing | Plans |
| CTA | Final conversion |
---
## Animation Patterns
| Pattern | Use |
|---------|-----|
| Fade up | Content entry |
| Stagger | List items |
| Scroll reveal | On viewport |
| Hover | Interactive feedback |
---
## Setup Steps
1. `npx create-next-app {{name}} --typescript --tailwind --app`
2. Install: `npm install framer-motion lucide-react next-seo`
3. Configure static export
4. Create sections
5. `npm run dev`
---
## Deployment
| Platform | Method |
|----------|--------|
| Vercel | Auto |
| Netlify | Auto |
| GitHub Pages | gh-pages branch |
| Any host | Upload `out` folder |
---
## Best Practices
- Static export for maximum performance
- Framer Motion for premium animations
- Responsive mobile-first design
- SEO metadata on every page

View File

@@ -0,0 +1,101 @@
---
name: nuxt-app
description: Nuxt 3 full-stack template. Vue 3, Pinia, Tailwind, Prisma.
---
# Nuxt 3 Full-Stack Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Framework | Nuxt 3 |
| Language | TypeScript |
| UI | Vue 3 (Composition API) |
| State | Pinia |
| Database | PostgreSQL + Prisma |
| Styling | Tailwind CSS |
| Validation | Zod |
---
## Directory Structure
```
project-name/
├── prisma/
│ └── schema.prisma
├── server/
│ ├── api/
│ │ └── [resource]/
│ │ └── index.ts
│ └── utils/
│ └── db.ts # Prisma client
├── composables/
│ └── useAuth.ts
├── stores/
│ └── user.ts # Pinia store
├── components/
│ └── ui/
├── pages/
│ ├── index.vue
│ └── [...slug].vue
├── layouts/
│ └── default.vue
├── assets/
│ └── css/
│ └── main.css
├── .env.example
├── nuxt.config.ts
└── package.json
```
---
## Key Concepts
| Concept | Description |
|---------|-------------|
| Auto-imports | Components, composables, utils |
| File-based routing | pages/ → routes |
| Server Routes | server/api/ → API endpoints |
| Composables | Reusable reactive logic |
| Pinia | State management |
---
## Environment Variables
| Variable | Purpose |
|----------|---------|
| DATABASE_URL | Prisma connection |
| NUXT_PUBLIC_APP_URL | Public URL |
---
## Setup Steps
1. `npx nuxi@latest init {{name}}`
2. `cd {{name}}`
3. `npm install @pinia/nuxt @prisma/client prisma zod`
4. `npm install -D @nuxtjs/tailwindcss`
5. Add modules to `nuxt.config.ts`:
```ts
modules: ['@pinia/nuxt', '@nuxtjs/tailwindcss']
```
6. `npx prisma init`
7. Configure schema
8. `npx prisma db push`
9. `npm run dev`
---
## Best Practices
- Use `<script setup>` for components
- Composables for reusable logic
- Pinia stores in `stores/` folder
- Server routes for API logic
- Auto-import for clean code
- TypeScript for type safety
- See `@[skills/vue-expert]` for Vue patterns

View File

@@ -0,0 +1,83 @@
---
name: python-fastapi
description: FastAPI REST API template principles. SQLAlchemy, Pydantic, Alembic.
---
# FastAPI API Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Framework | FastAPI |
| Language | Python 3.11+ |
| ORM | SQLAlchemy 2.0 |
| Validation | Pydantic v2 |
| Migrations | Alembic |
| Auth | JWT + passlib |
---
## Directory Structure
```
project-name/
├── alembic/ # Migrations
├── app/
│ ├── main.py # FastAPI app
│ ├── config.py # Settings
│ ├── database.py # DB connection
│ ├── models/ # SQLAlchemy models
│ ├── schemas/ # Pydantic schemas
│ ├── routers/ # API routes
│ ├── services/ # Business logic
│ ├── dependencies/ # DI
│ └── utils/
├── tests/
├── .env.example
└── requirements.txt
```
---
## Key Concepts
| Concept | Description |
|---------|-------------|
| Async | async/await throughout |
| Dependency Injection | FastAPI Depends |
| Pydantic v2 | Validation + serialization |
| SQLAlchemy 2.0 | Async sessions |
---
## API Structure
| Layer | Responsibility |
|-------|---------------|
| Routers | HTTP handling |
| Dependencies | Auth, validation |
| Services | Business logic |
| Models | Database entities |
| Schemas | Request/response |
---
## Setup Steps
1. `python -m venv venv`
2. `source venv/bin/activate`
3. `pip install fastapi uvicorn sqlalchemy alembic pydantic`
4. Create `.env`
5. `alembic upgrade head`
6. `uvicorn app.main:app --reload`
---
## Best Practices
- Use async everywhere
- Pydantic v2 for validation
- SQLAlchemy 2.0 async sessions
- Alembic for migrations
- pytest-asyncio for tests

View File

@@ -0,0 +1,93 @@
---
name: react-native-app
description: React Native mobile app template principles. Expo, TypeScript, navigation.
---
# React Native App Template
## Tech Stack
| Component | Technology |
|-----------|------------|
| Framework | React Native + Expo |
| Language | TypeScript |
| Navigation | Expo Router |
| State | Zustand + React Query |
| Styling | NativeWind |
| Testing | Jest + RNTL |
---
## Directory Structure
```
project-name/
├── app/ # Expo Router (file-based)
│ ├── _layout.tsx # Root layout
│ ├── index.tsx # Home
│ ├── (tabs)/ # Tab navigation
│ └── [id].tsx # Dynamic route
├── components/
│ ├── ui/ # Reusable
│ └── features/
├── hooks/
├── lib/
│ ├── api.ts
│ └── storage.ts
├── store/
├── constants/
└── app.json
```
---
## Navigation Patterns
| Pattern | Use |
|---------|-----|
| Stack | Page hierarchy |
| Tabs | Bottom navigation |
| Drawer | Side menu |
| Modal | Overlay screens |
---
## State Management
| Type | Tool |
|------|------|
| Local | Zustand |
| Server | React Query |
| Forms | React Hook Form |
| Storage | Expo SecureStore |
---
## Key Packages
| Package | Purpose |
|---------|---------|
| expo-router | File-based routing |
| zustand | Local state |
| @tanstack/react-query | Server state |
| nativewind | Tailwind styling |
| expo-secure-store | Secure storage |
---
## Setup Steps
1. `npx create-expo-app {{name}} -t expo-template-blank-typescript`
2. `npx expo install expo-router react-native-safe-area-context`
3. Install state: `npm install zustand @tanstack/react-query`
4. `npx expo start`
---
## Best Practices
- Expo Router for navigation
- Zustand for local, React Query for server state
- NativeWind for consistent styling
- Expo SecureStore for tokens
- Test on both iOS and Android

View File

@@ -0,0 +1,55 @@
---
name: architecture
description: Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.
allowed-tools: Read, Glob, Grep
---
# Architecture Decision Framework
> "Requirements drive architecture. Trade-offs inform decisions. ADRs capture rationale."
## 🎯 Selective Reading Rule
**Read ONLY files relevant to the request!** Check the content map, find what you need.
| File | Description | When to Read |
|------|-------------|--------------|
| `context-discovery.md` | Questions to ask, project classification | Starting architecture design |
| `trade-off-analysis.md` | ADR templates, trade-off framework | Documenting decisions |
| `pattern-selection.md` | Decision trees, anti-patterns | Choosing patterns |
| `examples.md` | MVP, SaaS, Enterprise examples | Reference implementations |
| `patterns-reference.md` | Quick lookup for patterns | Pattern comparison |
---
## 🔗 Related Skills
| Skill | Use For |
|-------|---------|
| `@[skills/database-design]` | Database schema design |
| `@[skills/api-patterns]` | API design patterns |
| `@[skills/deployment-procedures]` | Deployment architecture |
---
## Core Principle
**"Simplicity is the ultimate sophistication."**
- Start simple
- Add complexity ONLY when proven necessary
- You can always add patterns later
- Removing complexity is MUCH harder than adding it
---
## Validation Checklist
Before finalizing architecture:
- [ ] Requirements clearly understood
- [ ] Constraints identified
- [ ] Each decision has trade-off analysis
- [ ] Simpler alternatives considered
- [ ] ADRs written for significant decisions
- [ ] Team expertise matches chosen patterns

View File

@@ -0,0 +1,43 @@
# Context Discovery
> Before suggesting any architecture, gather context.
## Question Hierarchy (Ask User FIRST)
1. **Scale**
- How many users? (10, 1K, 100K, 1M+)
- Data volume? (MB, GB, TB)
- Transaction rate? (per second/minute)
2. **Team**
- Solo developer or team?
- Team size and expertise?
- Distributed or co-located?
3. **Timeline**
- MVP/Prototype or long-term product?
- Time to market pressure?
4. **Domain**
- CRUD-heavy or business logic complex?
- Real-time requirements?
- Compliance/regulations?
5. **Constraints**
- Budget limitations?
- Legacy systems to integrate?
- Technology stack preferences?
## Project Classification Matrix
```
MVP SaaS Enterprise
┌─────────────────────────────────────────────────────────────┐
│ Scale │ <1K │ 1K-100K │ 100K+ │
│ Team │ Solo │ 2-10 │ 10+ │
│ Timeline │ Fast (weeks) │ Medium (months)│ Long (years)│
│ Architecture │ Simple │ Modular │ Distributed │
│ Patterns │ Minimal │ Selective │ Comprehensive│
│ Example │ Next.js API │ NestJS │ Microservices│
└─────────────────────────────────────────────────────────────┘
```

View File

@@ -0,0 +1,94 @@
# Architecture Examples
> Real-world architecture decisions by project type.
---
## Example 1: MVP E-commerce (Solo Developer)
```yaml
Requirements:
- <1000 users initially
- Solo developer
- Fast to market (8 weeks)
- Budget-conscious
Architecture Decisions:
App Structure: Monolith (simpler for solo)
Framework: Next.js (full-stack, fast)
Data Layer: Prisma direct (no over-abstraction)
Authentication: JWT (simpler than OAuth)
Payment: Stripe (hosted solution)
Database: PostgreSQL (ACID for orders)
Trade-offs Accepted:
- Monolith → Can't scale independently (team doesn't justify it)
- No Repository → Less testable (simple CRUD doesn't need it)
- JWT → No social login initially (can add later)
Future Migration Path:
- Users > 10K → Extract payment service
- Team > 3 → Add Repository pattern
- Social login requested → Add OAuth
```
---
## Example 2: SaaS Product (5-10 Developers)
```yaml
Requirements:
- 1K-100K users
- 5-10 developers
- Long-term (12+ months)
- Multiple domains (billing, users, core)
Architecture Decisions:
App Structure: Modular Monolith (team size optimal)
Framework: NestJS (modular by design)
Data Layer: Repository pattern (testing, flexibility)
Domain Model: Partial DDD (rich entities)
Authentication: OAuth + JWT
Caching: Redis
Database: PostgreSQL
Trade-offs Accepted:
- Modular Monolith → Some module coupling (microservices not justified)
- Partial DDD → No full aggregates (no domain experts)
- RabbitMQ later → Initial synchronous (add when proven needed)
Migration Path:
- Team > 10 → Consider microservices
- Domains conflict → Extract bounded contexts
- Read performance issues → Add CQRS
```
---
## Example 3: Enterprise (100K+ Users)
```yaml
Requirements:
- 100K+ users
- 10+ developers
- Multiple business domains
- Different scaling needs
- 24/7 availability
Architecture Decisions:
App Structure: Microservices (independent scale)
API Gateway: Kong/AWS API GW
Domain Model: Full DDD
Consistency: Event-driven (eventual OK)
Message Bus: Kafka
Authentication: OAuth + SAML (enterprise SSO)
Database: Polyglot (right tool per job)
CQRS: Selected services
Operational Requirements:
- Service mesh (Istio/Linkerd)
- Distributed tracing (Jaeger/Tempo)
- Centralized logging (ELK/Loki)
- Circuit breakers (Resilience4j)
- Kubernetes/Helm
```

View File

@@ -0,0 +1,68 @@
# Pattern Selection Guidelines
> Decision trees for choosing architectural patterns.
## Main Decision Tree
```
START: What's your MAIN concern?
┌─ Data Access Complexity?
│ ├─ HIGH (complex queries, testing needed)
│ │ → Repository Pattern + Unit of Work
│ │ VALIDATE: Will data source change frequently?
│ │ ├─ YES → Repository worth the indirection
│ │ └─ NO → Consider simpler ORM direct access
│ └─ LOW (simple CRUD, single database)
│ → ORM directly (Prisma, Drizzle)
│ Simpler = Better, Faster
├─ Business Rules Complexity?
│ ├─ HIGH (domain logic, rules vary by context)
│ │ → Domain-Driven Design
│ │ VALIDATE: Do you have domain experts on team?
│ │ ├─ YES → Full DDD (Aggregates, Value Objects)
│ │ └─ NO → Partial DDD (rich entities, clear boundaries)
│ └─ LOW (mostly CRUD, simple validation)
│ → Transaction Script pattern
│ Simpler = Better, Faster
├─ Independent Scaling Needed?
│ ├─ YES (different components scale differently)
│ │ → Microservices WORTH the complexity
│ │ REQUIREMENTS (ALL must be true):
│ │ - Clear domain boundaries
│ │ - Team > 10 developers
│ │ - Different scaling needs per service
│ │ IF NOT ALL MET → Modular Monolith instead
│ └─ NO (everything scales together)
│ → Modular Monolith
│ Can extract services later when proven needed
└─ Real-time Requirements?
├─ HIGH (immediate updates, multi-user sync)
│ → Event-Driven Architecture
│ → Message Queue (RabbitMQ, Redis, Kafka)
│ VALIDATE: Can you handle eventual consistency?
│ ├─ YES → Event-driven valid
│ └─ NO → Synchronous with polling
└─ LOW (eventual consistency acceptable)
→ Synchronous (REST/GraphQL)
Simpler = Better, Faster
```
## The 3 Questions (Before ANY Pattern)
1. **Problem Solved**: What SPECIFIC problem does this pattern solve?
2. **Simpler Alternative**: Is there a simpler solution?
3. **Deferred Complexity**: Can we add this LATER when needed?
## Red Flags (Anti-patterns)
| Pattern | Anti-pattern | Simpler Alternative |
|---------|-------------|-------------------|
| Microservices | Premature splitting | Start monolith, extract later |
| Clean/Hexagonal | Over-abstraction | Concrete first, interfaces later |
| Event Sourcing | Over-engineering | Append-only audit log |
| CQRS | Unnecessary complexity | Single model |
| Repository | YAGNI for simple CRUD | ORM direct access |

View File

@@ -0,0 +1,50 @@
# Architecture Patterns Reference
> Quick reference for common patterns with usage guidance.
## Data Access Patterns
| Pattern | When to Use | When NOT to Use | Complexity |
|---------|-------------|-----------------|------------|
| **Active Record** | Simple CRUD, rapid prototyping | Complex queries, multiple sources | Low |
| **Repository** | Testing needed, multiple sources | Simple CRUD, single database | Medium |
| **Unit of Work** | Complex transactions | Simple operations | High |
| **Data Mapper** | Complex domain, performance | Simple CRUD, rapid dev | High |
## Domain Logic Patterns
| Pattern | When to Use | When NOT to Use | Complexity |
|---------|-------------|-----------------|------------|
| **Transaction Script** | Simple CRUD, procedural | Complex business rules | Low |
| **Table Module** | Record-based logic | Rich behavior needed | Low |
| **Domain Model** | Complex business logic | Simple CRUD | Medium |
| **DDD (Full)** | Complex domain, domain experts | Simple domain, no experts | High |
## Distributed System Patterns
| Pattern | When to Use | When NOT to Use | Complexity |
|---------|-------------|-----------------|------------|
| **Modular Monolith** | Small teams, unclear boundaries | Clear contexts, different scales | Medium |
| **Microservices** | Different scales, large teams | Small teams, simple domain | Very High |
| **Event-Driven** | Real-time, loose coupling | Simple workflows, strong consistency | High |
| **CQRS** | Read/write performance diverges | Simple CRUD, same model | High |
| **Saga** | Distributed transactions | Single database, simple ACID | High |
## API Patterns
| Pattern | When to Use | When NOT to Use | Complexity |
|---------|-------------|-----------------|------------|
| **REST** | Standard CRUD, resources | Real-time, complex queries | Low |
| **GraphQL** | Flexible queries, multiple clients | Simple CRUD, caching needs | Medium |
| **gRPC** | Internal services, performance | Public APIs, browser clients | Medium |
| **WebSocket** | Real-time updates | Simple request/response | Medium |
---
## Simplicity Principle
**"Start simple, add complexity only when proven necessary."**
- You can always add patterns later
- Removing complexity is MUCH harder than adding it
- When in doubt, choose simpler option

View File

@@ -0,0 +1,77 @@
# Trade-off Analysis & ADR
> Document every architectural decision with trade-offs.
## Decision Framework
For EACH architectural component, document:
```markdown
## Architecture Decision Record
### Context
- **Problem**: [What problem are we solving?]
- **Constraints**: [Team size, scale, timeline, budget]
### Options Considered
| Option | Pros | Cons | Complexity | When Valid |
|--------|------|------|------------|-----------|
| Option A | Benefit 1 | Cost 1 | Low | [Conditions] |
| Option B | Benefit 2 | Cost 2 | High | [Conditions] |
### Decision
**Chosen**: [Option B]
### Rationale
1. [Reason 1 - tied to constraints]
2. [Reason 2 - tied to requirements]
### Trade-offs Accepted
- [What we're giving up]
- [Why this is acceptable]
### Consequences
- **Positive**: [Benefits we gain]
- **Negative**: [Costs/risks we accept]
- **Mitigation**: [How we'll address negatives]
### Revisit Trigger
- [When to reconsider this decision]
```
## ADR Template
```markdown
# ADR-[XXX]: [Decision Title]
## Status
Proposed | Accepted | Deprecated | Superseded by [ADR-YYY]
## Context
[What problem? What constraints?]
## Decision
[What we chose - be specific]
## Rationale
[Why - tie to requirements and constraints]
## Trade-offs
[What we're giving up - be honest]
## Consequences
- **Positive**: [Benefits]
- **Negative**: [Costs]
- **Mitigation**: [How to address]
```
## ADR Storage
```
docs/
└── architecture/
├── adr-001-use-nextjs.md
├── adr-002-postgresql-over-mongodb.md
└── adr-003-adopt-repository-pattern.md
```

View File

@@ -1,6 +1,9 @@
---
name: AWS Penetration Testing
description: This skill should be used when the user asks to "pentest AWS", "test AWS security", "enumerate IAM", "exploit cloud infrastructure", "AWS privilege escalation", "S3 bucket testing", "metadata SSRF", "Lambda exploitation", or needs guidance on Amazon Web Services security assessment.
metadata:
author: zebbern
version: "1.1"
---
# AWS Penetration Testing

199
skills/bash-linux/SKILL.md Normal file
View File

@@ -0,0 +1,199 @@
---
name: bash-linux
description: Bash/Linux terminal patterns. Critical commands, piping, error handling, scripting. Use when working on macOS or Linux systems.
allowed-tools: Read, Write, Edit, Glob, Grep, Bash
---
# Bash Linux Patterns
> Essential patterns for Bash on Linux/macOS.
---
## 1. Operator Syntax
### Chaining Commands
| Operator | Meaning | Example |
|----------|---------|---------|
| `;` | Run sequentially | `cmd1; cmd2` |
| `&&` | Run if previous succeeded | `npm install && npm run dev` |
| `\|\|` | Run if previous failed | `npm test \|\| echo "Tests failed"` |
| `\|` | Pipe output | `ls \| grep ".js"` |
---
## 2. File Operations
### Essential Commands
| Task | Command |
|------|---------|
| List all | `ls -la` |
| Find files | `find . -name "*.js" -type f` |
| File content | `cat file.txt` |
| First N lines | `head -n 20 file.txt` |
| Last N lines | `tail -n 20 file.txt` |
| Follow log | `tail -f log.txt` |
| Search in files | `grep -r "pattern" --include="*.js"` |
| File size | `du -sh *` |
| Disk usage | `df -h` |
---
## 3. Process Management
| Task | Command |
|------|---------|
| List processes | `ps aux` |
| Find by name | `ps aux \| grep node` |
| Kill by PID | `kill -9 <PID>` |
| Find port user | `lsof -i :3000` |
| Kill port | `kill -9 $(lsof -t -i :3000)` |
| Background | `npm run dev &` |
| Jobs | `jobs -l` |
| Bring to front | `fg %1` |
---
## 4. Text Processing
### Core Tools
| Tool | Purpose | Example |
|------|---------|---------|
| `grep` | Search | `grep -rn "TODO" src/` |
| `sed` | Replace | `sed -i 's/old/new/g' file.txt` |
| `awk` | Extract columns | `awk '{print $1}' file.txt` |
| `cut` | Cut fields | `cut -d',' -f1 data.csv` |
| `sort` | Sort lines | `sort -u file.txt` |
| `uniq` | Unique lines | `sort file.txt \| uniq -c` |
| `wc` | Count | `wc -l file.txt` |
---
## 5. Environment Variables
| Task | Command |
|------|---------|
| View all | `env` or `printenv` |
| View one | `echo $PATH` |
| Set temporary | `export VAR="value"` |
| Set in script | `VAR="value" command` |
| Add to PATH | `export PATH="$PATH:/new/path"` |
---
## 6. Network
| Task | Command |
|------|---------|
| Download | `curl -O https://example.com/file` |
| API request | `curl -X GET https://api.example.com` |
| POST JSON | `curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' URL` |
| Check port | `nc -zv localhost 3000` |
| Network info | `ifconfig` or `ip addr` |
---
## 7. Script Template
```bash
#!/bin/bash
set -euo pipefail # Exit on error, undefined var, pipe fail
# Colors (optional)
RED='\033[0;31m'
GREEN='\033[0;32m'
NC='\033[0m'
# Script directory
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# Functions
log_info() { echo -e "${GREEN}[INFO]${NC} $1"; }
log_error() { echo -e "${RED}[ERROR]${NC} $1" >&2; }
# Main
main() {
log_info "Starting..."
# Your logic here
log_info "Done!"
}
main "$@"
```
---
## 8. Common Patterns
### Check if command exists
```bash
if command -v node &> /dev/null; then
echo "Node is installed"
fi
```
### Default variable value
```bash
NAME=${1:-"default_value"}
```
### Read file line by line
```bash
while IFS= read -r line; do
echo "$line"
done < file.txt
```
### Loop over files
```bash
for file in *.js; do
echo "Processing $file"
done
```
---
## 9. Differences from PowerShell
| Task | PowerShell | Bash |
|------|------------|------|
| List files | `Get-ChildItem` | `ls -la` |
| Find files | `Get-ChildItem -Recurse` | `find . -type f` |
| Environment | `$env:VAR` | `$VAR` |
| String concat | `"$a$b"` | `"$a$b"` (same) |
| Null check | `if ($x)` | `if [ -n "$x" ]` |
| Pipeline | Object-based | Text-based |
---
## 10. Error Handling
### Set options
```bash
set -e # Exit on error
set -u # Exit on undefined variable
set -o pipefail # Exit on pipe failure
set -x # Debug: print commands
```
### Trap for cleanup
```bash
cleanup() {
echo "Cleaning up..."
rm -f /tmp/tempfile
}
trap cleanup EXIT
```
---
> **Remember:** Bash is text-based. Use `&&` for success chains, `set -e` for safety, and quote your variables!

View File

@@ -0,0 +1,242 @@
---
name: behavioral-modes
description: AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type.
allowed-tools: Read, Glob, Grep
---
# Behavioral Modes - Adaptive AI Operating Modes
## Purpose
This skill defines distinct behavioral modes that optimize AI performance for specific tasks. Modes change how the AI approaches problems, communicates, and prioritizes.
---
## Available Modes
### 1. 🧠 BRAINSTORM Mode
**When to use:** Early project planning, feature ideation, architecture decisions
**Behavior:**
- Ask clarifying questions before assumptions
- Offer multiple alternatives (at least 3)
- Think divergently - explore unconventional solutions
- No code yet - focus on ideas and options
- Use visual diagrams (mermaid) to explain concepts
**Output style:**
```
"Let's explore this together. Here are some approaches:
Option A: [description]
✅ Pros: ...
❌ Cons: ...
Option B: [description]
✅ Pros: ...
❌ Cons: ...
What resonates with you? Or should we explore a different direction?"
```
---
### 2. ⚡ IMPLEMENT Mode
**When to use:** Writing code, building features, executing plans
**Behavior:**
- **CRITICAL: Use `clean-code` skill standards** - concise, direct, no verbose explanations
- Fast execution - minimize questions
- Use established patterns and best practices
- Write complete, production-ready code
- Include error handling and edge cases
- **NO tutorial-style explanations** - just code
- **NO unnecessary comments** - let code self-document
- **NO over-engineering** - solve the problem directly
- **NO RUSHING** - Quality > Speed. Read ALL references before coding.
**Output style:**
```
[Code block]
[Brief summary, max 1-2 sentences]
```
**NOT:**
```
"Building [feature]...
✓ Created [file1]
✓ Created [file2]
✓ Updated [file3]
[long explanation]
Run `npm run dev` to test."
```
---
### 3. 🔍 DEBUG Mode
**When to use:** Fixing bugs, troubleshooting errors, investigating issues
**Behavior:**
- Ask for error messages and reproduction steps
- Think systematically - check logs, trace data flow
- Form hypothesis → test → verify
- Explain the root cause, not just the fix
- Prevent future occurrences
**Output style:**
```
"Investigating...
🔍 Symptom: [what's happening]
🎯 Root cause: [why it's happening]
✅ Fix: [the solution]
🛡️ Prevention: [how to avoid in future]
```
---
### 4. 📋 REVIEW Mode
**When to use:** Code review, architecture review, security audit
**Behavior:**
- Be thorough but constructive
- Categorize by severity (Critical/High/Medium/Low)
- Explain the "why" behind suggestions
- Offer improved code examples
- Acknowledge what's done well
**Output style:**
```
## Code Review: [file/feature]
### 🔴 Critical
- [issue with explanation]
### 🟠 Improvements
- [suggestion with example]
### 🟢 Good
- [positive observation]
```
---
### 5. 📚 TEACH Mode
**When to use:** Explaining concepts, documentation, onboarding
**Behavior:**
- Explain from fundamentals
- Use analogies and examples
- Progress from simple to complex
- Include practical exercises
- Check understanding
**Output style:**
```
## Understanding [Concept]
### What is it?
[Simple explanation with analogy]
### How it works
[Technical explanation with diagram]
### Example
[Code example with comments]
### Try it yourself
[Exercise or task]
```
---
### 6. 🚀 SHIP Mode
**When to use:** Production deployment, final polish, release preparation
**Behavior:**
- Focus on stability over features
- Check for missing error handling
- Verify environment configs
- Run all tests
- Create deployment checklist
**Output style:**
```
## Pre-Ship Checklist
### ✅ Code Quality
- [ ] No TypeScript errors
- [ ] ESLint passing
- [ ] All tests passing
### ✅ Security
- [ ] No exposed secrets
- [ ] Input validation complete
### ✅ Performance
- [ ] Bundle size acceptable
- [ ] No console.logs
### 🚀 Ready to deploy
```
---
## Mode Detection
The AI should automatically detect the appropriate mode based on:
| Trigger | Mode |
|---------|------|
| "what if", "ideas", "options" | BRAINSTORM |
| "build", "create", "add" | IMPLEMENT |
| "not working", "error", "bug" | DEBUG |
| "review", "check", "audit" | REVIEW |
| "explain", "how does", "learn" | TEACH |
| "deploy", "release", "production" | SHIP |
---
## Multi-Agent Collaboration Patterns (2025)
Modern architectures optimized for agent-to-agent collaboration:
### 1. 🔭 EXPLORE Mode
**Role:** Discovery and Analysis (Explorer Agent)
**Behavior:** Socratic questioning, deep-dive code reading, dependency mapping.
**Output:** `discovery-report.json`, architectural visualization.
### 2. 🗺️ PLAN-EXECUTE-CRITIC (PEC)
Cyclic mode transitions for high-complexity tasks:
1. **Planner:** Decomposes the task into atomic steps (`task.md`).
2. **Executor:** Performs the actual coding (`IMPLEMENT`).
3. **Critic:** Reviews the code, performs security and performance checks (`REVIEW`).
### 3. 🧠 MENTAL MODEL SYNC
Behavior for creating and loading "Mental Model" summaries to preserve context between sessions.
---
## Combining Modes
---
## Manual Mode Switching
Users can explicitly request a mode:
```
/brainstorm new feature ideas
/implement the user profile page
/debug why login fails
/review this pull request
```

View File

@@ -1,6 +1,9 @@
---
name: Broken Authentication Testing
description: This skill should be used when the user asks to "test for broken authentication vulnerabilities", "assess session management security", "perform credential stuffing tests", "evaluate password policies", "test for session fixation", or "identify authentication bypass flaws". It provides comprehensive techniques for identifying authentication and session management weaknesses in web applications.
metadata:
author: zebbern
version: "1.1"
---
# Broken Authentication Testing

View File

@@ -1,6 +1,9 @@
---
name: Burp Suite Web Application Testing
description: This skill should be used when the user asks to "intercept HTTP traffic", "modify web requests", "use Burp Suite for testing", "perform web vulnerability scanning", "test with Burp Repeater", "analyze HTTP history", or "configure proxy for web testing". It provides comprehensive guidance for using Burp Suite's core features for web application security testing.
metadata:
author: zebbern
version: "1.1"
---
# Burp Suite Web Application Testing

201
skills/clean-code/SKILL.md Normal file
View File

@@ -0,0 +1,201 @@
---
name: clean-code
description: Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments
allowed-tools: Read, Write, Edit
version: 2.0
priority: CRITICAL
---
# Clean Code - Pragmatic AI Coding Standards
> **CRITICAL SKILL** - Be **concise, direct, and solution-focused**.
---
## Core Principles
| Principle | Rule |
|-----------|------|
| **SRP** | Single Responsibility - each function/class does ONE thing |
| **DRY** | Don't Repeat Yourself - extract duplicates, reuse |
| **KISS** | Keep It Simple - simplest solution that works |
| **YAGNI** | You Aren't Gonna Need It - don't build unused features |
| **Boy Scout** | Leave code cleaner than you found it |
---
## Naming Rules
| Element | Convention |
|---------|------------|
| **Variables** | Reveal intent: `userCount` not `n` |
| **Functions** | Verb + noun: `getUserById()` not `user()` |
| **Booleans** | Question form: `isActive`, `hasPermission`, `canEdit` |
| **Constants** | SCREAMING_SNAKE: `MAX_RETRY_COUNT` |
> **Rule:** If you need a comment to explain a name, rename it.
---
## Function Rules
| Rule | Description |
|------|-------------|
| **Small** | Max 20 lines, ideally 5-10 |
| **One Thing** | Does one thing, does it well |
| **One Level** | One level of abstraction per function |
| **Few Args** | Max 3 arguments, prefer 0-2 |
| **No Side Effects** | Don't mutate inputs unexpectedly |
---
## Code Structure
| Pattern | Apply |
|---------|-------|
| **Guard Clauses** | Early returns for edge cases |
| **Flat > Nested** | Avoid deep nesting (max 2 levels) |
| **Composition** | Small functions composed together |
| **Colocation** | Keep related code close |
---
## AI Coding Style
| Situation | Action |
|-----------|--------|
| User asks for feature | Write it directly |
| User reports bug | Fix it, don't explain |
| No clear requirement | Ask, don't assume |
---
## Anti-Patterns (DON'T)
| ❌ Pattern | ✅ Fix |
|-----------|-------|
| Comment every line | Delete obvious comments |
| Helper for one-liner | Inline the code |
| Factory for 2 objects | Direct instantiation |
| utils.ts with 1 function | Put code where used |
| "First we import..." | Just write code |
| Deep nesting | Guard clauses |
| Magic numbers | Named constants |
| God functions | Split by responsibility |
---
## 🔴 Before Editing ANY File (THINK FIRST!)
**Before changing a file, ask yourself:**
| Question | Why |
|----------|-----|
| **What imports this file?** | They might break |
| **What does this file import?** | Interface changes |
| **What tests cover this?** | Tests might fail |
| **Is this a shared component?** | Multiple places affected |
**Quick Check:**
```
File to edit: UserService.ts
└── Who imports this? → UserController.ts, AuthController.ts
└── Do they need changes too? → Check function signatures
```
> 🔴 **Rule:** Edit the file + all dependent files in the SAME task.
> 🔴 **Never leave broken imports or missing updates.**
---
## Summary
| Do | Don't |
|----|-------|
| Write code directly | Write tutorials |
| Let code self-document | Add obvious comments |
| Fix bugs immediately | Explain the fix first |
| Inline small things | Create unnecessary files |
| Name things clearly | Use abbreviations |
| Keep functions small | Write 100+ line functions |
> **Remember: The user wants working code, not a programming lesson.**
---
## 🔴 Self-Check Before Completing (MANDATORY)
**Before saying "task complete", verify:**
| Check | Question |
|-------|----------|
| ✅ **Goal met?** | Did I do exactly what user asked? |
| ✅ **Files edited?** | Did I modify all necessary files? |
| ✅ **Code works?** | Did I test/verify the change? |
| ✅ **No errors?** | Lint and TypeScript pass? |
| ✅ **Nothing forgotten?** | Any edge cases missed? |
> 🔴 **Rule:** If ANY check fails, fix it before completing.
---
## Verification Scripts (MANDATORY)
> 🔴 **CRITICAL:** Each agent runs ONLY their own skill's scripts after completing work.
### Agent → Script Mapping
| Agent | Script | Command |
|-------|--------|---------|
| **frontend-specialist** | UX Audit | `python ~/.claude/skills/frontend-design/scripts/ux_audit.py .` |
| **frontend-specialist** | A11y Check | `python ~/.claude/skills/frontend-design/scripts/accessibility_checker.py .` |
| **backend-specialist** | API Validator | `python ~/.claude/skills/api-patterns/scripts/api_validator.py .` |
| **mobile-developer** | Mobile Audit | `python ~/.claude/skills/mobile-design/scripts/mobile_audit.py .` |
| **database-architect** | Schema Validate | `python ~/.claude/skills/database-design/scripts/schema_validator.py .` |
| **security-auditor** | Security Scan | `python ~/.claude/skills/vulnerability-scanner/scripts/security_scan.py .` |
| **seo-specialist** | SEO Check | `python ~/.claude/skills/seo-fundamentals/scripts/seo_checker.py .` |
| **seo-specialist** | GEO Check | `python ~/.claude/skills/geo-fundamentals/scripts/geo_checker.py .` |
| **performance-optimizer** | Lighthouse | `python ~/.claude/skills/performance-profiling/scripts/lighthouse_audit.py <url>` |
| **test-engineer** | Test Runner | `python ~/.claude/skills/testing-patterns/scripts/test_runner.py .` |
| **test-engineer** | Playwright | `python ~/.claude/skills/webapp-testing/scripts/playwright_runner.py <url>` |
| **Any agent** | Lint Check | `python ~/.claude/skills/lint-and-validate/scripts/lint_runner.py .` |
| **Any agent** | Type Coverage | `python ~/.claude/skills/lint-and-validate/scripts/type_coverage.py .` |
| **Any agent** | i18n Check | `python ~/.claude/skills/i18n-localization/scripts/i18n_checker.py .` |
> ❌ **WRONG:** `test-engineer` running `ux_audit.py`
> ✅ **CORRECT:** `frontend-specialist` running `ux_audit.py`
---
### 🔴 Script Output Handling (READ → SUMMARIZE → ASK)
**When running a validation script, you MUST:**
1. **Run the script** and capture ALL output
2. **Parse the output** - identify errors, warnings, and passes
3. **Summarize to user** in this format:
```markdown
## Script Results: [script_name.py]
### ❌ Errors Found (X items)
- [File:Line] Error description 1
- [File:Line] Error description 2
### ⚠️ Warnings (Y items)
- [File:Line] Warning description
### ✅ Passed (Z items)
- Check 1 passed
- Check 2 passed
**Should I fix the X errors?**
```
4. **Wait for user confirmation** before fixing
5. **After fixing** → Re-run script to confirm
> 🔴 **VIOLATION:** Running script and ignoring output = FAILED task.
> 🔴 **VIOLATION:** Auto-fixing without asking = Not allowed.
> 🔴 **Rule:** Always READ output → SUMMARIZE → ASK → then fix.

View File

@@ -1,6 +1,9 @@
---
name: Cloud Penetration Testing
description: This skill should be used when the user asks to "perform cloud penetration testing", "assess Azure or AWS or GCP security", "enumerate cloud resources", "exploit cloud misconfigurations", "test O365 security", "extract secrets from cloud environments", or "audit cloud infrastructure". It provides comprehensive techniques for security assessment across major cloud platforms.
metadata:
author: zebbern
version: "1.1"
---
# Cloud Penetration Testing

View File

@@ -0,0 +1,109 @@
---
name: code-review-checklist
description: Code review guidelines covering code quality, security, and best practices.
allowed-tools: Read, Glob, Grep
---
# Code Review Checklist
## Quick Review Checklist
### Correctness
- [ ] Code does what it's supposed to do
- [ ] Edge cases handled
- [ ] Error handling in place
- [ ] No obvious bugs
### Security
- [ ] Input validated and sanitized
- [ ] No SQL/NoSQL injection vulnerabilities
- [ ] No XSS or CSRF vulnerabilities
- [ ] No hardcoded secrets or sensitive credentials
- [ ] **AI-Specific:** Protection against Prompt Injection (if applicable)
- [ ] **AI-Specific:** Outputs are sanitized before being used in critical sinks
### Performance
- [ ] No N+1 queries
- [ ] No unnecessary loops
- [ ] Appropriate caching
- [ ] Bundle size impact considered
### Code Quality
- [ ] Clear naming
- [ ] DRY - no duplicate code
- [ ] SOLID principles followed
- [ ] Appropriate abstraction level
### Testing
- [ ] Unit tests for new code
- [ ] Edge cases tested
- [ ] Tests readable and maintainable
### Documentation
- [ ] Complex logic commented
- [ ] Public APIs documented
- [ ] README updated if needed
## AI & LLM Review Patterns (2025)
### Logic & Hallucinations
- [ ] **Chain of Thought:** Does the logic follow a verifiable path?
- [ ] **Edge Cases:** Did the AI account for empty states, timeouts, and partial failures?
- [ ] **External State:** Is the code making safe assumptions about file systems or networks?
### Prompt Engineering Review
```markdown
// ❌ Vague prompt in code
const response = await ai.generate(userInput);
// ✅ Structured & Safe prompt
const response = await ai.generate({
system: "You are a specialized parser...",
input: sanitize(userInput),
schema: ResponseSchema
});
```
## Anti-Patterns to Flag
```typescript
// ❌ Magic numbers
if (status === 3) { ... }
// ✅ Named constants
if (status === Status.ACTIVE) { ... }
// ❌ Deep nesting
if (a) { if (b) { if (c) { ... } } }
// ✅ Early returns
if (!a) return;
if (!b) return;
if (!c) return;
// do work
// ❌ Long functions (100+ lines)
// ✅ Small, focused functions
// ❌ any type
const data: any = ...
// ✅ Proper types
const data: UserData = ...
```
## Review Comments Guide
```
// Blocking issues use 🔴
🔴 BLOCKING: SQL injection vulnerability here
// Important suggestions use 🟡
🟡 SUGGESTION: Consider using useMemo for performance
// Minor nits use 🟢
🟢 NIT: Prefer const over let for immutable variable
// Questions use ❓
❓ QUESTION: What happens if user is null here?
```

View File

@@ -0,0 +1,52 @@
---
name: database-design
description: Database design principles and decision-making. Schema design, indexing strategy, ORM selection, serverless databases.
allowed-tools: Read, Write, Edit, Glob, Grep
---
# Database Design
> **Learn to THINK, not copy SQL patterns.**
## 🎯 Selective Reading Rule
**Read ONLY files relevant to the request!** Check the content map, find what you need.
| File | Description | When to Read |
|------|-------------|--------------|
| `database-selection.md` | PostgreSQL vs Neon vs Turso vs SQLite | Choosing database |
| `orm-selection.md` | Drizzle vs Prisma vs Kysely | Choosing ORM |
| `schema-design.md` | Normalization, PKs, relationships | Designing schema |
| `indexing.md` | Index types, composite indexes | Performance tuning |
| `optimization.md` | N+1, EXPLAIN ANALYZE | Query optimization |
| `migrations.md` | Safe migrations, serverless DBs | Schema changes |
---
## ⚠️ Core Principle
- ASK user for database preferences when unclear
- Choose database/ORM based on CONTEXT
- Don't default to PostgreSQL for everything
---
## Decision Checklist
Before designing schema:
- [ ] Asked user about database preference?
- [ ] Chosen database for THIS context?
- [ ] Considered deployment environment?
- [ ] Planned index strategy?
- [ ] Defined relationship types?
---
## Anti-Patterns
❌ Default to PostgreSQL for simple apps (SQLite may suffice)
❌ Skip indexing
❌ Use SELECT * in production
❌ Store JSON when structured data is better
❌ Ignore N+1 queries

View File

@@ -0,0 +1,43 @@
# Database Selection (2025)
> Choose database based on context, not default.
## Decision Tree
```
What are your requirements?
├── Full relational features needed
│ ├── Self-hosted → PostgreSQL
│ └── Serverless → Neon, Supabase
├── Edge deployment / Ultra-low latency
│ └── Turso (edge SQLite)
├── AI / Vector search
│ └── PostgreSQL + pgvector
├── Simple / Embedded / Local
│ └── SQLite
└── Global distribution
└── PlanetScale, CockroachDB, Turso
```
## Comparison
| Database | Best For | Trade-offs |
|----------|----------|------------|
| **PostgreSQL** | Full features, complex queries | Needs hosting |
| **Neon** | Serverless PG, branching | PG complexity |
| **Turso** | Edge, low latency | SQLite limitations |
| **SQLite** | Simple, embedded, local | Single-writer |
| **PlanetScale** | MySQL, global scale | No foreign keys |
## Questions to Ask
1. What's the deployment environment?
2. How complex are the queries?
3. Is edge/serverless important?
4. Vector search needed?
5. Global distribution required?

View File

@@ -0,0 +1,39 @@
# Indexing Principles
> When and how to create indexes effectively.
## When to Create Indexes
```
Index these:
├── Columns in WHERE clauses
├── Columns in JOIN conditions
├── Columns in ORDER BY
├── Foreign key columns
└── Unique constraints
Don't over-index:
├── Write-heavy tables (slower inserts)
├── Low-cardinality columns
├── Columns rarely queried
```
## Index Type Selection
| Type | Use For |
|------|---------|
| **B-tree** | General purpose, equality & range |
| **Hash** | Equality only, faster |
| **GIN** | JSONB, arrays, full-text |
| **GiST** | Geometric, range types |
| **HNSW/IVFFlat** | Vector similarity (pgvector) |
## Composite Index Principles
```
Order matters for composite indexes:
├── Equality columns first
├── Range columns last
├── Most selective first
└── Match query pattern
```

View File

@@ -0,0 +1,48 @@
# Migration Principles
> Safe migration strategy for zero-downtime changes.
## Safe Migration Strategy
```
For zero-downtime changes:
├── Adding column
│ └── Add as nullable → backfill → add NOT NULL
├── Removing column
│ └── Stop using → deploy → remove column
├── Adding index
│ └── CREATE INDEX CONCURRENTLY (non-blocking)
└── Renaming column
└── Add new → migrate data → deploy → drop old
```
## Migration Philosophy
- Never make breaking changes in one step
- Test migrations on data copy first
- Have rollback plan
- Run in transaction when possible
## Serverless Databases
### Neon (Serverless PostgreSQL)
| Feature | Benefit |
|---------|---------|
| Scale to zero | Cost savings |
| Instant branching | Dev/preview |
| Full PostgreSQL | Compatibility |
| Autoscaling | Traffic handling |
### Turso (Edge SQLite)
| Feature | Benefit |
|---------|---------|
| Edge locations | Ultra-low latency |
| SQLite compatible | Simple |
| Generous free tier | Cost |
| Global distribution | Performance |

View File

@@ -0,0 +1,36 @@
# Query Optimization
> N+1 problem, EXPLAIN ANALYZE, optimization priorities.
## N+1 Problem
```
What is N+1?
├── 1 query to get parent records
├── N queries to get related records
└── Very slow!
Solutions:
├── JOIN → Single query with all data
├── Eager loading → ORM handles JOIN
├── DataLoader → Batch and cache (GraphQL)
└── Subquery → Fetch related in one query
```
## Query Analysis Mindset
```
Before optimizing:
├── EXPLAIN ANALYZE the query
├── Look for Seq Scan (full table scan)
├── Check actual vs estimated rows
└── Identify missing indexes
```
## Optimization Priorities
1. **Add missing indexes** (most common issue)
2. **Select only needed columns** (not SELECT *)
3. **Use proper JOINs** (avoid subqueries when possible)
4. **Limit early** (pagination at database level)
5. **Cache** (when appropriate)

View File

@@ -0,0 +1,30 @@
# ORM Selection (2025)
> Choose ORM based on deployment and DX needs.
## Decision Tree
```
What's the context?
├── Edge deployment / Bundle size matters
│ └── Drizzle (smallest, SQL-like)
├── Best DX / Schema-first
│ └── Prisma (migrations, studio)
├── Maximum control
│ └── Raw SQL with query builder
└── Python ecosystem
└── SQLAlchemy 2.0 (async support)
```
## Comparison
| ORM | Best For | Trade-offs |
|-----|----------|------------|
| **Drizzle** | Edge, TypeScript | Newer, less examples |
| **Prisma** | DX, schema management | Heavier, not edge-ready |
| **Kysely** | Type-safe SQL builder | Manual migrations |
| **Raw SQL** | Complex queries, control | Manual type safety |

View File

@@ -0,0 +1,56 @@
# Schema Design Principles
> Normalization, primary keys, timestamps, relationships.
## Normalization Decision
```
When to normalize (separate tables):
├── Data is repeated across rows
├── Updates would need multiple changes
├── Relationships are clear
└── Query patterns benefit
When to denormalize (embed/duplicate):
├── Read performance critical
├── Data rarely changes
├── Always fetched together
└── Simpler queries needed
```
## Primary Key Selection
| Type | Use When |
|------|----------|
| **UUID** | Distributed systems, security |
| **ULID** | UUID + sortable by time |
| **Auto-increment** | Simple apps, single database |
| **Natural key** | Rarely (business meaning) |
## Timestamp Strategy
```
For every table:
├── created_at → When created
├── updated_at → Last modified
└── deleted_at → Soft delete (if needed)
Use TIMESTAMPTZ (with timezone) not TIMESTAMP
```
## Relationship Types
| Type | When | Implementation |
|------|------|----------------|
| **One-to-One** | Extension data | Separate table with FK |
| **One-to-Many** | Parent-children | FK on child table |
| **Many-to-Many** | Both sides have many | Junction table |
## Foreign Key ON DELETE
```
├── CASCADE → Delete children with parent
├── SET NULL → Children become orphans
├── RESTRICT → Prevent delete if children exist
└── SET DEFAULT → Children get default value
```

View File

@@ -0,0 +1,172 @@
#!/usr/bin/env python3
"""
Schema Validator - Database schema validation
Validates Prisma schemas and checks for common issues.
Usage:
python schema_validator.py <project_path>
Checks:
- Prisma schema syntax
- Missing relations
- Index recommendations
- Naming conventions
"""
import sys
import json
import re
from pathlib import Path
from datetime import datetime
# Fix Windows console encoding
try:
sys.stdout.reconfigure(encoding='utf-8', errors='replace')
except:
pass
def find_schema_files(project_path: Path) -> list:
"""Find database schema files."""
schemas = []
# Prisma schema
prisma_files = list(project_path.glob('**/prisma/schema.prisma'))
schemas.extend([('prisma', f) for f in prisma_files])
# Drizzle schema files
drizzle_files = list(project_path.glob('**/drizzle/*.ts'))
drizzle_files.extend(project_path.glob('**/schema/*.ts'))
for f in drizzle_files:
if 'schema' in f.name.lower() or 'table' in f.name.lower():
schemas.append(('drizzle', f))
return schemas[:10] # Limit
def validate_prisma_schema(file_path: Path) -> list:
"""Validate Prisma schema file."""
issues = []
try:
content = file_path.read_text(encoding='utf-8', errors='ignore')
# Find all models
models = re.findall(r'model\s+(\w+)\s*{([^}]+)}', content, re.DOTALL)
for model_name, model_body in models:
# Check naming convention (PascalCase)
if not model_name[0].isupper():
issues.append(f"Model '{model_name}' should be PascalCase")
# Check for id field
if '@id' not in model_body and 'id' not in model_body.lower():
issues.append(f"Model '{model_name}' might be missing @id field")
# Check for createdAt/updatedAt
if 'createdAt' not in model_body and 'created_at' not in model_body:
issues.append(f"Model '{model_name}' missing createdAt field (recommended)")
# Check for @relation without fields
relations = re.findall(r'@relation\([^)]*\)', model_body)
for rel in relations:
if 'fields:' not in rel and 'references:' not in rel:
pass # Implicit relation, ok
# Check for @@index suggestions
foreign_keys = re.findall(r'(\w+Id)\s+\w+', model_body)
for fk in foreign_keys:
if f'@@index([{fk}])' not in content and f'@@index(["{fk}"])' not in content:
issues.append(f"Consider adding @@index([{fk}]) for better query performance in {model_name}")
# Check for enum definitions
enums = re.findall(r'enum\s+(\w+)\s*{', content)
for enum_name in enums:
if not enum_name[0].isupper():
issues.append(f"Enum '{enum_name}' should be PascalCase")
except Exception as e:
issues.append(f"Error reading schema: {str(e)[:50]}")
return issues
def main():
project_path = Path(sys.argv[1] if len(sys.argv) > 1 else ".").resolve()
print(f"\n{'='*60}")
print(f"[SCHEMA VALIDATOR] Database Schema Validation")
print(f"{'='*60}")
print(f"Project: {project_path}")
print(f"Time: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
print("-"*60)
# Find schema files
schemas = find_schema_files(project_path)
print(f"Found {len(schemas)} schema files")
if not schemas:
output = {
"script": "schema_validator",
"project": str(project_path),
"schemas_checked": 0,
"issues_found": 0,
"passed": True,
"message": "No schema files found"
}
print(json.dumps(output, indent=2))
sys.exit(0)
# Validate each schema
all_issues = []
for schema_type, file_path in schemas:
print(f"\nValidating: {file_path.name} ({schema_type})")
if schema_type == 'prisma':
issues = validate_prisma_schema(file_path)
else:
issues = [] # Drizzle validation could be added
if issues:
all_issues.append({
"file": str(file_path.name),
"type": schema_type,
"issues": issues
})
# Summary
print("\n" + "="*60)
print("SCHEMA ISSUES")
print("="*60)
if all_issues:
for item in all_issues:
print(f"\n{item['file']} ({item['type']}):")
for issue in item["issues"][:5]: # Limit per file
print(f" - {issue}")
if len(item["issues"]) > 5:
print(f" ... and {len(item['issues']) - 5} more issues")
else:
print("No schema issues found!")
total_issues = sum(len(item["issues"]) for item in all_issues)
# Schema issues are warnings, not failures
passed = True
output = {
"script": "schema_validator",
"project": str(project_path),
"schemas_checked": len(schemas),
"issues_found": total_issues,
"passed": passed,
"issues": all_issues
}
print("\n" + json.dumps(output, indent=2))
sys.exit(0)
if __name__ == "__main__":
main()

View File

@@ -0,0 +1,241 @@
---
name: deployment-procedures
description: Production deployment principles and decision-making. Safe deployment workflows, rollback strategies, and verification. Teaches thinking, not scripts.
allowed-tools: Read, Glob, Grep, Bash
---
# Deployment Procedures
> Deployment principles and decision-making for safe production releases.
> **Learn to THINK, not memorize scripts.**
---
## ⚠️ How to Use This Skill
This skill teaches **deployment principles**, not bash scripts to copy.
- Every deployment is unique
- Understand the WHY behind each step
- Adapt procedures to your platform
---
## 1. Platform Selection
### Decision Tree
```
What are you deploying?
├── Static site / JAMstack
│ └── Vercel, Netlify, Cloudflare Pages
├── Simple web app
│ ├── Managed → Railway, Render, Fly.io
│ └── Control → VPS + PM2/Docker
├── Microservices
│ └── Container orchestration
└── Serverless
└── Edge functions, Lambda
```
### Each Platform Has Different Procedures
| Platform | Deployment Method |
|----------|------------------|
| **Vercel/Netlify** | Git push, auto-deploy |
| **Railway/Render** | Git push or CLI |
| **VPS + PM2** | SSH + manual steps |
| **Docker** | Image push + orchestration |
| **Kubernetes** | kubectl apply |
---
## 2. Pre-Deployment Principles
### The 4 Verification Categories
| Category | What to Check |
|----------|--------------|
| **Code Quality** | Tests passing, linting clean, reviewed |
| **Build** | Production build works, no warnings |
| **Environment** | Env vars set, secrets current |
| **Safety** | Backup done, rollback plan ready |
### Pre-Deployment Checklist
- [ ] All tests passing
- [ ] Code reviewed and approved
- [ ] Production build successful
- [ ] Environment variables verified
- [ ] Database migrations ready (if any)
- [ ] Rollback plan documented
- [ ] Team notified
- [ ] Monitoring ready
---
## 3. Deployment Workflow Principles
### The 5-Phase Process
```
1. PREPARE
└── Verify code, build, env vars
2. BACKUP
└── Save current state before changing
3. DEPLOY
└── Execute with monitoring open
4. VERIFY
└── Health check, logs, key flows
5. CONFIRM or ROLLBACK
└── All good? Confirm. Issues? Rollback.
```
### Phase Principles
| Phase | Principle |
|-------|-----------|
| **Prepare** | Never deploy untested code |
| **Backup** | Can't rollback without backup |
| **Deploy** | Watch it happen, don't walk away |
| **Verify** | Trust but verify |
| **Confirm** | Have rollback trigger ready |
---
## 4. Post-Deployment Verification
### What to Verify
| Check | Why |
|-------|-----|
| **Health endpoint** | Service is running |
| **Error logs** | No new errors |
| **Key user flows** | Critical features work |
| **Performance** | Response times acceptable |
### Verification Window
- **First 5 minutes**: Active monitoring
- **15 minutes**: Confirm stable
- **1 hour**: Final verification
- **Next day**: Review metrics
---
## 5. Rollback Principles
### When to Rollback
| Symptom | Action |
|---------|--------|
| Service down | Rollback immediately |
| Critical errors | Rollback |
| Performance >50% degraded | Consider rollback |
| Minor issues | Fix forward if quick |
### Rollback Strategy by Platform
| Platform | Rollback Method |
|----------|----------------|
| **Vercel/Netlify** | Redeploy previous commit |
| **Railway/Render** | Rollback in dashboard |
| **VPS + PM2** | Restore backup, restart |
| **Docker** | Previous image tag |
| **K8s** | kubectl rollout undo |
### Rollback Principles
1. **Speed over perfection**: Rollback first, debug later
2. **Don't compound errors**: One rollback, not multiple changes
3. **Communicate**: Tell team what happened
4. **Post-mortem**: Understand why after stable
---
## 6. Zero-Downtime Deployment
### Strategies
| Strategy | How It Works |
|----------|--------------|
| **Rolling** | Replace instances one by one |
| **Blue-Green** | Switch traffic between environments |
| **Canary** | Gradual traffic shift |
### Selection Principles
| Scenario | Strategy |
|----------|----------|
| Standard release | Rolling |
| High-risk change | Blue-green (easy rollback) |
| Need validation | Canary (test with real traffic) |
---
## 7. Emergency Procedures
### Service Down Priority
1. **Assess**: What's the symptom?
2. **Quick fix**: Restart if unclear
3. **Rollback**: If restart doesn't help
4. **Investigate**: After stable
### Investigation Order
| Check | Common Issues |
|-------|--------------|
| **Logs** | Errors, exceptions |
| **Resources** | Disk full, memory |
| **Network** | DNS, firewall |
| **Dependencies** | Database, APIs |
---
## 8. Anti-Patterns
| ❌ Don't | ✅ Do |
|----------|-------|
| Deploy on Friday | Deploy early in week |
| Rush deployment | Follow the process |
| Skip staging | Always test first |
| Deploy without backup | Backup before deploy |
| Walk away after deploy | Monitor for 15+ min |
| Multiple changes at once | One change at a time |
---
## 9. Decision Checklist
Before deploying:
- [ ] **Platform-appropriate procedure?**
- [ ] **Backup strategy ready?**
- [ ] **Rollback plan documented?**
- [ ] **Monitoring configured?**
- [ ] **Team notified?**
- [ ] **Time to monitor after?**
---
## 10. Best Practices
1. **Small, frequent deploys** over big releases
2. **Feature flags** for risky changes
3. **Automate** repetitive steps
4. **Document** every deployment
5. **Review** what went wrong after issues
6. **Test rollback** before you need it
---
> **Remember:** Every deployment is a risk. Minimize risk through preparation, not speed.

View File

@@ -0,0 +1,409 @@
---
name: docker-expert
description: Docker containerization expert with deep knowledge of multi-stage builds, image optimization, container security, Docker Compose orchestration, and production deployment patterns. Use PROACTIVELY for Dockerfile optimization, container issues, image size problems, security hardening, networking, and orchestration challenges.
category: devops
color: blue
displayName: Docker Expert
---
# Docker Expert
You are an advanced Docker containerization expert with comprehensive, practical knowledge of container optimization, security hardening, multi-stage builds, orchestration patterns, and production deployment strategies based on current industry best practices.
## When invoked:
0. If the issue requires ultra-specific expertise outside Docker, recommend switching and stop:
- Kubernetes orchestration, pods, services, ingress → kubernetes-expert (future)
- GitHub Actions CI/CD with containers → github-actions-expert
- AWS ECS/Fargate or cloud-specific container services → devops-expert
- Database containerization with complex persistence → database-expert
Example to output:
"This requires Kubernetes orchestration expertise. Please invoke: 'Use the kubernetes-expert subagent.' Stopping here."
1. Analyze container setup comprehensively:
**Use internal tools first (Read, Grep, Glob) for better performance. Shell commands are fallbacks.**
```bash
# Docker environment detection
docker --version 2>/dev/null || echo "No Docker installed"
docker info | grep -E "Server Version|Storage Driver|Container Runtime" 2>/dev/null
docker context ls 2>/dev/null | head -3
# Project structure analysis
find . -name "Dockerfile*" -type f | head -10
find . -name "*compose*.yml" -o -name "*compose*.yaml" -type f | head -5
find . -name ".dockerignore" -type f | head -3
# Container status if running
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}" 2>/dev/null | head -10
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" 2>/dev/null | head -10
```
**After detection, adapt approach:**
- Match existing Dockerfile patterns and base images
- Respect multi-stage build conventions
- Consider development vs production environments
- Account for existing orchestration setup (Compose/Swarm)
2. Identify the specific problem category and complexity level
3. Apply the appropriate solution strategy from my expertise
4. Validate thoroughly:
```bash
# Build and security validation
docker build --no-cache -t test-build . 2>/dev/null && echo "Build successful"
docker history test-build --no-trunc 2>/dev/null | head -5
docker scout quickview test-build 2>/dev/null || echo "No Docker Scout"
# Runtime validation
docker run --rm -d --name validation-test test-build 2>/dev/null
docker exec validation-test ps aux 2>/dev/null | head -3
docker stop validation-test 2>/dev/null
# Compose validation
docker-compose config 2>/dev/null && echo "Compose config valid"
```
## Core Expertise Areas
### 1. Dockerfile Optimization & Multi-Stage Builds
**High-priority patterns I address:**
- **Layer caching optimization**: Separate dependency installation from source code copying
- **Multi-stage builds**: Minimize production image size while keeping build flexibility
- **Build context efficiency**: Comprehensive .dockerignore and build context management
- **Base image selection**: Alpine vs distroless vs scratch image strategies
**Key techniques:**
```dockerfile
# Optimized multi-stage pattern
FROM node:18-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force
FROM node:18-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npm prune --production
FROM node:18-alpine AS runtime
RUN addgroup -g 1001 -S nodejs && adduser -S nextjs -u 1001
WORKDIR /app
COPY --from=deps --chown=nextjs:nodejs /app/node_modules ./node_modules
COPY --from=build --chown=nextjs:nodejs /app/dist ./dist
COPY --from=build --chown=nextjs:nodejs /app/package*.json ./
USER nextjs
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
CMD curl -f http://localhost:3000/health || exit 1
CMD ["node", "dist/index.js"]
```
### 2. Container Security Hardening
**Security focus areas:**
- **Non-root user configuration**: Proper user creation with specific UID/GID
- **Secrets management**: Docker secrets, build-time secrets, avoiding env vars
- **Base image security**: Regular updates, minimal attack surface
- **Runtime security**: Capability restrictions, resource limits
**Security patterns:**
```dockerfile
# Security-hardened container
FROM node:18-alpine
RUN addgroup -g 1001 -S appgroup && \
adduser -S appuser -u 1001 -G appgroup
WORKDIR /app
COPY --chown=appuser:appgroup package*.json ./
RUN npm ci --only=production
COPY --chown=appuser:appgroup . .
USER 1001
# Drop capabilities, set read-only root filesystem
```
### 3. Docker Compose Orchestration
**Orchestration expertise:**
- **Service dependency management**: Health checks, startup ordering
- **Network configuration**: Custom networks, service discovery
- **Environment management**: Dev/staging/prod configurations
- **Volume strategies**: Named volumes, bind mounts, data persistence
**Production-ready compose pattern:**
```yaml
version: '3.8'
services:
app:
build:
context: .
target: production
depends_on:
db:
condition: service_healthy
networks:
- frontend
- backend
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
deploy:
resources:
limits:
cpus: '0.5'
memory: 512M
reservations:
cpus: '0.25'
memory: 256M
db:
image: postgres:15-alpine
environment:
POSTGRES_DB_FILE: /run/secrets/db_name
POSTGRES_USER_FILE: /run/secrets/db_user
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
secrets:
- db_name
- db_user
- db_password
volumes:
- postgres_data:/var/lib/postgresql/data
networks:
- backend
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
interval: 10s
timeout: 5s
retries: 5
networks:
frontend:
driver: bridge
backend:
driver: bridge
internal: true
volumes:
postgres_data:
secrets:
db_name:
external: true
db_user:
external: true
db_password:
external: true
```
### 4. Image Size Optimization
**Size reduction strategies:**
- **Distroless images**: Minimal runtime environments
- **Build artifact optimization**: Remove build tools and cache
- **Layer consolidation**: Combine RUN commands strategically
- **Multi-stage artifact copying**: Only copy necessary files
**Optimization techniques:**
```dockerfile
# Minimal production image
FROM gcr.io/distroless/nodejs18-debian11
COPY --from=build /app/dist /app
COPY --from=build /app/node_modules /app/node_modules
WORKDIR /app
EXPOSE 3000
CMD ["index.js"]
```
### 5. Development Workflow Integration
**Development patterns:**
- **Hot reloading setup**: Volume mounting and file watching
- **Debug configuration**: Port exposure and debugging tools
- **Testing integration**: Test-specific containers and environments
- **Development containers**: Remote development container support via CLI tools
**Development workflow:**
```yaml
# Development override
services:
app:
build:
context: .
target: development
volumes:
- .:/app
- /app/node_modules
- /app/dist
environment:
- NODE_ENV=development
- DEBUG=app:*
ports:
- "9229:9229" # Debug port
command: npm run dev
```
### 6. Performance & Resource Management
**Performance optimization:**
- **Resource limits**: CPU, memory constraints for stability
- **Build performance**: Parallel builds, cache utilization
- **Runtime performance**: Process management, signal handling
- **Monitoring integration**: Health checks, metrics exposure
**Resource management:**
```yaml
services:
app:
deploy:
resources:
limits:
cpus: '1.0'
memory: 1G
reservations:
cpus: '0.5'
memory: 512M
restart_policy:
condition: on-failure
delay: 5s
max_attempts: 3
window: 120s
```
## Advanced Problem-Solving Patterns
### Cross-Platform Builds
```bash
# Multi-architecture builds
docker buildx create --name multiarch-builder --use
docker buildx build --platform linux/amd64,linux/arm64 \
-t myapp:latest --push .
```
### Build Cache Optimization
```dockerfile
# Mount build cache for package managers
FROM node:18-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm \
npm ci --only=production
```
### Secrets Management
```dockerfile
# Build-time secrets (BuildKit)
FROM alpine
RUN --mount=type=secret,id=api_key \
API_KEY=$(cat /run/secrets/api_key) && \
# Use API_KEY for build process
```
### Health Check Strategies
```dockerfile
# Sophisticated health monitoring
COPY health-check.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/health-check.sh
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
CMD ["/usr/local/bin/health-check.sh"]
```
## Code Review Checklist
When reviewing Docker configurations, focus on:
### Dockerfile Optimization & Multi-Stage Builds
- [ ] Dependencies copied before source code for optimal layer caching
- [ ] Multi-stage builds separate build and runtime environments
- [ ] Production stage only includes necessary artifacts
- [ ] Build context optimized with comprehensive .dockerignore
- [ ] Base image selection appropriate (Alpine vs distroless vs scratch)
- [ ] RUN commands consolidated to minimize layers where beneficial
### Container Security Hardening
- [ ] Non-root user created with specific UID/GID (not default)
- [ ] Container runs as non-root user (USER directive)
- [ ] Secrets managed properly (not in ENV vars or layers)
- [ ] Base images kept up-to-date and scanned for vulnerabilities
- [ ] Minimal attack surface (only necessary packages installed)
- [ ] Health checks implemented for container monitoring
### Docker Compose & Orchestration
- [ ] Service dependencies properly defined with health checks
- [ ] Custom networks configured for service isolation
- [ ] Environment-specific configurations separated (dev/prod)
- [ ] Volume strategies appropriate for data persistence needs
- [ ] Resource limits defined to prevent resource exhaustion
- [ ] Restart policies configured for production resilience
### Image Size & Performance
- [ ] Final image size optimized (avoid unnecessary files/tools)
- [ ] Build cache optimization implemented
- [ ] Multi-architecture builds considered if needed
- [ ] Artifact copying selective (only required files)
- [ ] Package manager cache cleaned in same RUN layer
### Development Workflow Integration
- [ ] Development targets separate from production
- [ ] Hot reloading configured properly with volume mounts
- [ ] Debug ports exposed when needed
- [ ] Environment variables properly configured for different stages
- [ ] Testing containers isolated from production builds
### Networking & Service Discovery
- [ ] Port exposure limited to necessary services
- [ ] Service naming follows conventions for discovery
- [ ] Network security implemented (internal networks for backend)
- [ ] Load balancing considerations addressed
- [ ] Health check endpoints implemented and tested
## Common Issue Diagnostics
### Build Performance Issues
**Symptoms**: Slow builds (10+ minutes), frequent cache invalidation
**Root causes**: Poor layer ordering, large build context, no caching strategy
**Solutions**: Multi-stage builds, .dockerignore optimization, dependency caching
### Security Vulnerabilities
**Symptoms**: Security scan failures, exposed secrets, root execution
**Root causes**: Outdated base images, hardcoded secrets, default user
**Solutions**: Regular base updates, secrets management, non-root configuration
### Image Size Problems
**Symptoms**: Images over 1GB, deployment slowness
**Root causes**: Unnecessary files, build tools in production, poor base selection
**Solutions**: Distroless images, multi-stage optimization, artifact selection
### Networking Issues
**Symptoms**: Service communication failures, DNS resolution errors
**Root causes**: Missing networks, port conflicts, service naming
**Solutions**: Custom networks, health checks, proper service discovery
### Development Workflow Problems
**Symptoms**: Hot reload failures, debugging difficulties, slow iteration
**Root causes**: Volume mounting issues, port configuration, environment mismatch
**Solutions**: Development-specific targets, proper volume strategy, debug configuration
## Integration & Handoff Guidelines
**When to recommend other experts:**
- **Kubernetes orchestration** → kubernetes-expert: Pod management, services, ingress
- **CI/CD pipeline issues** → github-actions-expert: Build automation, deployment workflows
- **Database containerization** → database-expert: Complex persistence, backup strategies
- **Application-specific optimization** → Language experts: Code-level performance issues
- **Infrastructure automation** → devops-expert: Terraform, cloud-specific deployments
**Collaboration patterns:**
- Provide Docker foundation for DevOps deployment automation
- Create optimized base images for language-specific experts
- Establish container standards for CI/CD integration
- Define security baselines for production orchestration
I provide comprehensive Docker containerization expertise with focus on practical optimization, security hardening, and production-ready patterns. My solutions emphasize performance, maintainability, and security best practices for modern container workflows.

View File

@@ -0,0 +1,194 @@
---
name: documentation-templates
description: Documentation templates and structure guidelines. README, API docs, code comments, and AI-friendly documentation.
allowed-tools: Read, Glob, Grep
---
# Documentation Templates
> Templates and structure guidelines for common documentation types.
---
## 1. README Structure
### Essential Sections (Priority Order)
| Section | Purpose |
|---------|---------|
| **Title + One-liner** | What is this? |
| **Quick Start** | Running in <5 min |
| **Features** | What can I do? |
| **Configuration** | How to customize |
| **API Reference** | Link to detailed docs |
| **Contributing** | How to help |
| **License** | Legal |
### README Template
```markdown
# Project Name
Brief one-line description.
## Quick Start
[Minimum steps to run]
## Features
- Feature 1
- Feature 2
## Configuration
| Variable | Description | Default |
|----------|-------------|---------|
| PORT | Server port | 3000 |
## Documentation
- [API Reference](./docs/api.md)
- [Architecture](./docs/architecture.md)
## License
MIT
```
---
## 2. API Documentation Structure
### Per-Endpoint Template
```markdown
## GET /users/:id
Get a user by ID.
**Parameters:**
| Name | Type | Required | Description |
|------|------|----------|-------------|
| id | string | Yes | User ID |
**Response:**
- 200: User object
- 404: User not found
**Example:**
[Request and response example]
```
---
## 3. Code Comment Guidelines
### JSDoc/TSDoc Template
```typescript
/**
* Brief description of what the function does.
*
* @param paramName - Description of parameter
* @returns Description of return value
* @throws ErrorType - When this error occurs
*
* @example
* const result = functionName(input);
*/
```
### When to Comment
| ✅ Comment | ❌ Don't Comment |
|-----------|-----------------|
| Why (business logic) | What (obvious) |
| Complex algorithms | Every line |
| Non-obvious behavior | Self-explanatory code |
| API contracts | Implementation details |
---
## 4. Changelog Template (Keep a Changelog)
```markdown
# Changelog
## [Unreleased]
### Added
- New feature
## [1.0.0] - 2025-01-01
### Added
- Initial release
### Changed
- Updated dependency
### Fixed
- Bug fix
```
---
## 5. Architecture Decision Record (ADR)
```markdown
# ADR-001: [Title]
## Status
Accepted / Deprecated / Superseded
## Context
Why are we making this decision?
## Decision
What did we decide?
## Consequences
What are the trade-offs?
```
---
## 6. AI-Friendly Documentation (2025)
### llms.txt Template
For AI crawlers and agents:
```markdown
# Project Name
> One-line objective.
## Core Files
- [src/index.ts]: Main entry
- [src/api/]: API routes
- [docs/]: Documentation
## Key Concepts
- Concept 1: Brief explanation
- Concept 2: Brief explanation
```
### MCP-Ready Documentation
For RAG indexing:
- Clear H1-H3 hierarchy
- JSON/YAML examples for data structures
- Mermaid diagrams for flows
- Self-contained sections
---
## 7. Structure Principles
| Principle | Why |
|-----------|-----|
| **Scannable** | Headers, lists, tables |
| **Examples first** | Show, don't just tell |
| **Progressive detail** | Simple → Complex |
| **Up to date** | Outdated = misleading |
---
> **Remember:** Templates are starting points. Adapt to your project's needs.

View File

@@ -1,6 +1,9 @@
---
name: Ethical Hacking Methodology
description: This skill should be used when the user asks to "learn ethical hacking", "understand penetration testing lifecycle", "perform reconnaissance", "conduct security scanning", "exploit vulnerabilities", or "write penetration test reports". It provides comprehensive ethical hacking methodology and techniques.
metadata:
author: zebbern
version: "1.1"
---
# Ethical Hacking Methodology

View File

@@ -1,6 +1,9 @@
---
name: File Path Traversal Testing
description: This skill should be used when the user asks to "test for directory traversal", "exploit path traversal vulnerabilities", "read arbitrary files through web applications", "find LFI vulnerabilities", or "access files outside web root". It provides comprehensive file path traversal attack and testing methodologies.
metadata:
author: zebbern
version: "1.1"
---
# File Path Traversal Testing

View File

@@ -0,0 +1,119 @@
---
name: 2d-games
description: 2D game development principles. Sprites, tilemaps, physics, camera.
allowed-tools: Read, Write, Edit, Glob, Grep
---
# 2D Game Development
> Principles for 2D game systems.
---
## 1. Sprite Systems
### Sprite Organization
| Component | Purpose |
|-----------|---------|
| **Atlas** | Combine textures, reduce draw calls |
| **Animation** | Frame sequences |
| **Pivot** | Rotation/scale origin |
| **Layering** | Z-order control |
### Animation Principles
- Frame rate: 8-24 FPS typical
- Squash and stretch for impact
- Anticipation before action
- Follow-through after action
---
## 2. Tilemap Design
### Tile Considerations
| Factor | Recommendation |
|--------|----------------|
| **Size** | 16x16, 32x32, 64x64 |
| **Auto-tiling** | Use for terrain |
| **Collision** | Simplified shapes |
### Layers
| Layer | Content |
|-------|---------|
| Background | Non-interactive scenery |
| Terrain | Walkable ground |
| Props | Interactive objects |
| Foreground | Parallax overlay |
---
## 3. 2D Physics
### Collision Shapes
| Shape | Use Case |
|-------|----------|
| Box | Rectangular objects |
| Circle | Balls, rounded |
| Capsule | Characters |
| Polygon | Complex shapes |
### Physics Considerations
- Pixel-perfect vs physics-based
- Fixed timestep for consistency
- Layers for filtering
---
## 4. Camera Systems
### Camera Types
| Type | Use |
|------|-----|
| **Follow** | Track player |
| **Look-ahead** | Anticipate movement |
| **Multi-target** | Two-player |
| **Room-based** | Metroidvania |
### Screen Shake
- Short duration (50-200ms)
- Diminishing intensity
- Use sparingly
---
## 5. Genre Patterns
### Platformer
- Coyote time (leniency after edge)
- Jump buffering
- Variable jump height
### Top-down
- 8-directional or free movement
- Aim-based or auto-aim
- Consider rotation or not
---
## 6. Anti-Patterns
| ❌ Don't | ✅ Do |
|----------|-------|
| Separate textures | Use atlases |
| Complex collision shapes | Simplified collision |
| Jittery camera | Smooth following |
| Pixel-perfect on physics | Choose one approach |
---
> **Remember:** 2D is about clarity. Every pixel should communicate.

View File

@@ -0,0 +1,135 @@
---
name: 3d-games
description: 3D game development principles. Rendering, shaders, physics, cameras.
allowed-tools: Read, Write, Edit, Glob, Grep
---
# 3D Game Development
> Principles for 3D game systems.
---
## 1. Rendering Pipeline
### Stages
```
1. Vertex Processing → Transform geometry
2. Rasterization → Convert to pixels
3. Fragment Processing → Color pixels
4. Output → To screen
```
### Optimization Principles
| Technique | Purpose |
|-----------|---------|
| **Frustum culling** | Don't render off-screen |
| **Occlusion culling** | Don't render hidden |
| **LOD** | Less detail at distance |
| **Batching** | Combine draw calls |
---
## 2. Shader Principles
### Shader Types
| Type | Purpose |
|------|---------|
| **Vertex** | Position, normals |
| **Fragment/Pixel** | Color, lighting |
| **Compute** | General computation |
### When to Write Custom Shaders
- Special effects (water, fire, portals)
- Stylized rendering (toon, sketch)
- Performance optimization
- Unique visual identity
---
## 3. 3D Physics
### Collision Shapes
| Shape | Use Case |
|-------|----------|
| **Box** | Buildings, crates |
| **Sphere** | Balls, quick checks |
| **Capsule** | Characters |
| **Mesh** | Terrain (expensive) |
### Principles
- Simple colliders, complex visuals
- Layer-based filtering
- Raycasting for line-of-sight
---
## 4. Camera Systems
### Camera Types
| Type | Use |
|------|-----|
| **Third-person** | Action, adventure |
| **First-person** | Immersive, FPS |
| **Isometric** | Strategy, RPG |
| **Orbital** | Inspection, editors |
### Camera Feel
- Smooth following (lerp)
- Collision avoidance
- Look-ahead for movement
- FOV changes for speed
---
## 5. Lighting
### Light Types
| Type | Use |
|------|-----|
| **Directional** | Sun, moon |
| **Point** | Lamps, torches |
| **Spot** | Flashlight, stage |
| **Ambient** | Base illumination |
### Performance Consideration
- Real-time shadows are expensive
- Bake when possible
- Shadow cascades for large worlds
---
## 6. Level of Detail (LOD)
### LOD Strategy
| Distance | Model |
|----------|-------|
| Near | Full detail |
| Medium | 50% triangles |
| Far | 25% or billboard |
---
## 7. Anti-Patterns
| ❌ Don't | ✅ Do |
|----------|-------|
| Mesh colliders everywhere | Simple shapes |
| Real-time shadows on mobile | Baked or blob shadows |
| One LOD for all distances | Distance-based LOD |
| Unoptimized shaders | Profile and simplify |
---
> **Remember:** 3D is about illusion. Create the impression of detail, not the detail itself.

View File

@@ -0,0 +1,167 @@
---
name: game-development
description: Game development orchestrator. Routes to platform-specific skills based on project needs.
allowed-tools: Read, Write, Edit, Glob, Grep, Bash
---
# Game Development
> **Orchestrator skill** that provides core principles and routes to specialized sub-skills.
---
## When to Use This Skill
You are working on a game development project. This skill teaches the PRINCIPLES of game development and directs you to the right sub-skill based on context.
---
## Sub-Skill Routing
### Platform Selection
| If the game targets... | Use Sub-Skill |
|------------------------|---------------|
| Web browsers (HTML5, WebGL) | `game-development/web-games` |
| Mobile (iOS, Android) | `game-development/mobile-games` |
| PC (Steam, Desktop) | `game-development/pc-games` |
| VR/AR headsets | `game-development/vr-ar` |
### Dimension Selection
| If the game is... | Use Sub-Skill |
|-------------------|---------------|
| 2D (sprites, tilemaps) | `game-development/2d-games` |
| 3D (meshes, shaders) | `game-development/3d-games` |
### Specialty Areas
| If you need... | Use Sub-Skill |
|----------------|---------------|
| GDD, balancing, player psychology | `game-development/game-design` |
| Multiplayer, networking | `game-development/multiplayer` |
| Visual style, asset pipeline, animation | `game-development/game-art` |
| Sound design, music, adaptive audio | `game-development/game-audio` |
---
## Core Principles (All Platforms)
### 1. The Game Loop
Every game, regardless of platform, follows this pattern:
```
INPUT → Read player actions
UPDATE → Process game logic (fixed timestep)
RENDER → Draw the frame (interpolated)
```
**Fixed Timestep Rule:**
- Physics/logic: Fixed rate (e.g., 50Hz)
- Rendering: As fast as possible
- Interpolate between states for smooth visuals
---
### 2. Pattern Selection Matrix
| Pattern | Use When | Example |
|---------|----------|---------|
| **State Machine** | 3-5 discrete states | Player: Idle→Walk→Jump |
| **Object Pooling** | Frequent spawn/destroy | Bullets, particles |
| **Observer/Events** | Cross-system communication | Health→UI updates |
| **ECS** | Thousands of similar entities | RTS units, particles |
| **Command** | Undo, replay, networking | Input recording |
| **Behavior Tree** | Complex AI decisions | Enemy AI |
**Decision Rule:** Start with State Machine. Add ECS only when performance demands.
---
### 3. Input Abstraction
Abstract input into ACTIONS, not raw keys:
```
"jump" → Space, Gamepad A, Touch tap
"move" → WASD, Left stick, Virtual joystick
```
**Why:** Enables multi-platform, rebindable controls.
---
### 4. Performance Budget (60 FPS = 16.67ms)
| System | Budget |
|--------|--------|
| Input | 1ms |
| Physics | 3ms |
| AI | 2ms |
| Game Logic | 4ms |
| Rendering | 5ms |
| Buffer | 1.67ms |
**Optimization Priority:**
1. Algorithm (O(n²) → O(n log n))
2. Batching (reduce draw calls)
3. Pooling (avoid GC spikes)
4. LOD (detail by distance)
5. Culling (skip invisible)
---
### 5. AI Selection by Complexity
| AI Type | Complexity | Use When |
|---------|------------|----------|
| **FSM** | Simple | 3-5 states, predictable behavior |
| **Behavior Tree** | Medium | Modular, designer-friendly |
| **GOAP** | High | Emergent, planning-based |
| **Utility AI** | High | Scoring-based decisions |
---
### 6. Collision Strategy
| Type | Best For |
|------|----------|
| **AABB** | Rectangles, fast checks |
| **Circle** | Round objects, cheap |
| **Spatial Hash** | Many similar-sized objects |
| **Quadtree** | Large worlds, varying sizes |
---
## Anti-Patterns (Universal)
| Don't | Do |
|-------|-----|
| Update everything every frame | Use events, dirty flags |
| Create objects in hot loops | Object pooling |
| Cache nothing | Cache references |
| Optimize without profiling | Profile first |
| Mix input with logic | Abstract input layer |
---
## Routing Examples
### Example 1: "I want to make a browser-based 2D platformer"
→ Start with `game-development/web-games` for framework selection
→ Then `game-development/2d-games` for sprite/tilemap patterns
→ Reference `game-development/game-design` for level design
### Example 2: "Mobile puzzle game for iOS and Android"
→ Start with `game-development/mobile-games` for touch input and stores
→ Use `game-development/game-design` for puzzle balancing
### Example 3: "Multiplayer VR shooter"
`game-development/vr-ar` for comfort and immersion
`game-development/3d-games` for rendering
`game-development/multiplayer` for networking
---
> **Remember:** Great games come from iteration, not perfection. Prototype fast, then polish.

View File

@@ -0,0 +1,185 @@
---
name: game-art
description: Game art principles. Visual style selection, asset pipeline, animation workflow.
allowed-tools: Read, Glob, Grep
---
# Game Art Principles
> Visual design thinking for games - style selection, asset pipelines, and art direction.
---
## 1. Art Style Selection
### Decision Tree
```
What feeling should the game evoke?
├── Nostalgic / Retro
│ ├── Limited palette? → Pixel Art
│ └── Hand-drawn feel? → Vector / Flash style
├── Realistic / Immersive
│ ├── High budget? → PBR 3D
│ └── Stylized realism? → Hand-painted textures
├── Approachable / Casual
│ ├── Clean shapes? → Flat / Minimalist
│ └── Soft feel? → Gradient / Soft shadows
└── Unique / Experimental
└── Define custom style guide
```
### Style Comparison Matrix
| Style | Production Speed | Skill Floor | Scalability | Best For |
|-------|------------------|-------------|-------------|----------|
| **Pixel Art** | Medium | Medium | Hard to hire | Indie, retro |
| **Vector/Flat** | Fast | Low | Easy | Mobile, casual |
| **Hand-painted** | Slow | High | Medium | Fantasy, stylized |
| **PBR 3D** | Slow | High | AAA pipeline | Realistic games |
| **Low-poly** | Fast | Medium | Easy | Indie 3D |
| **Cel-shaded** | Medium | Medium | Medium | Anime, cartoon |
---
## 2. Asset Pipeline Decisions
### 2D Pipeline
| Phase | Tool Options | Output |
|-------|--------------|--------|
| **Concept** | Paper, Procreate, Photoshop | Reference sheet |
| **Creation** | Aseprite, Photoshop, Krita | Individual sprites |
| **Atlas** | TexturePacker, Aseprite | Spritesheet |
| **Animation** | Spine, DragonBones, Frame-by-frame | Animation data |
| **Integration** | Engine import | Game-ready assets |
### 3D Pipeline
| Phase | Tool Options | Output |
|-------|--------------|--------|
| **Concept** | 2D art, Blockout | Reference |
| **Modeling** | Blender, Maya, 3ds Max | High-poly mesh |
| **Retopology** | Blender, ZBrush | Game-ready mesh |
| **UV/Texturing** | Substance Painter, Blender | Texture maps |
| **Rigging** | Blender, Maya | Skeletal rig |
| **Animation** | Blender, Maya, Mixamo | Animation clips |
| **Export** | FBX, glTF | Engine-ready |
---
## 3. Color Theory Decisions
### Palette Selection
| Goal | Strategy | Example |
|------|----------|---------|
| **Harmony** | Complementary or analogous | Nature games |
| **Contrast** | High saturation differences | Action games |
| **Mood** | Warm/cool temperature | Horror, cozy |
| **Readability** | Value contrast over hue | Gameplay clarity |
### Color Principles
- **Hierarchy:** Important elements should pop
- **Consistency:** Same object = same color family
- **Context:** Colors read differently on backgrounds
- **Accessibility:** Don't rely only on color
---
## 4. Animation Principles
### The 12 Principles (Applied to Games)
| Principle | Game Application |
|-----------|------------------|
| **Squash & Stretch** | Jump arcs, impacts |
| **Anticipation** | Wind-up before attack |
| **Staging** | Clear silhouettes |
| **Follow-through** | Hair, capes after movement |
| **Slow in/out** | Easing on transitions |
| **Arcs** | Natural movement paths |
| **Secondary Action** | Breathing, blinking |
| **Timing** | Frame count = weight/speed |
| **Exaggeration** | Readable from distance |
| **Appeal** | Memorable design |
### Frame Count Guidelines
| Action Type | Typical Frames | Feel |
|-------------|----------------|------|
| Idle breathing | 4-8 | Subtle |
| Walk cycle | 6-12 | Smooth |
| Run cycle | 4-8 | Energetic |
| Attack | 3-6 | Snappy |
| Death | 8-16 | Dramatic |
---
## 5. Resolution & Scale Decisions
### 2D Resolution by Platform
| Platform | Base Resolution | Sprite Scale |
|----------|-----------------|--------------|
| Mobile | 1080p | 64-128px characters |
| Desktop | 1080p-4K | 128-256px characters |
| Pixel art | 320x180 to 640x360 | 16-32px characters |
### Consistency Rule
Choose a base unit and stick to it:
- Pixel art: Work at 1x, scale up (never down)
- HD art: Define DPI, maintain ratio
- 3D: 1 unit = 1 meter (industry standard)
---
## 6. Asset Organization
### Naming Convention
```
[type]_[object]_[variant]_[state].[ext]
Examples:
spr_player_idle_01.png
tex_stone_wall_normal.png
mesh_tree_oak_lod2.fbx
```
### Folder Structure Principle
```
assets/
├── characters/
│ ├── player/
│ └── enemies/
├── environment/
│ ├── props/
│ └── tiles/
├── ui/
├── effects/
└── audio/
```
---
## 7. Anti-Patterns
| Don't | Do |
|-------|-----|
| Mix art styles randomly | Define and follow style guide |
| Work at final resolution only | Create at source resolution |
| Ignore silhouette readability | Test at gameplay distance |
| Over-detail background | Focus detail on player area |
| Skip color testing | Test on target display |
---
> **Remember:** Art serves gameplay. If it doesn't help the player, it's decoration.

View File

@@ -0,0 +1,190 @@
---
name: game-audio
description: Game audio principles. Sound design, music integration, adaptive audio systems.
allowed-tools: Read, Glob, Grep
---
# Game Audio Principles
> Sound design and music integration for immersive game experiences.
---
## 1. Audio Category System
### Category Definitions
| Category | Behavior | Examples |
|----------|----------|----------|
| **Music** | Looping, crossfade, ducking | BGM, combat music |
| **SFX** | One-shot, 3D positioned | Footsteps, impacts |
| **Ambient** | Looping, background layer | Wind, crowd, forest |
| **UI** | Immediate, non-3D | Button clicks, notifications |
| **Voice** | Priority, ducking trigger | Dialogue, announcer |
### Priority Hierarchy
```
When sounds compete for channels:
1. Voice (highest - always audible)
2. Player SFX (feedback critical)
3. Enemy SFX (gameplay important)
4. Music (mood, but duckable)
5. Ambient (lowest - can drop)
```
---
## 2. Sound Design Decisions
### SFX Creation Approach
| Approach | When to Use | Trade-offs |
|----------|-------------|------------|
| **Recording** | Realistic needs | High quality, time intensive |
| **Synthesis** | Sci-fi, retro, UI | Unique, requires skill |
| **Library samples** | Fast production | Common sounds, licensing |
| **Layering** | Complex sounds | Best results, more work |
### Layering Structure
| Layer | Purpose | Example: Gunshot |
|-------|---------|------------------|
| **Attack** | Initial transient | Click, snap |
| **Body** | Main character | Boom, blast |
| **Tail** | Decay, room | Reverb, echo |
| **Sweetener** | Special sauce | Shell casing, mechanical |
---
## 3. Music Integration
### Music State System
```
Game State → Music Response
├── Menu → Calm, loopable theme
├── Exploration → Ambient, atmospheric
├── Combat detected → Transition to tension
├── Combat engaged → Full battle music
├── Victory → Stinger + calm transition
├── Defeat → Somber stinger
└── Boss → Unique, multi-phase track
```
### Transition Techniques
| Technique | Use When | Feel |
|-----------|----------|------|
| **Crossfade** | Smooth mood shift | Gradual |
| **Stinger** | Immediate event | Dramatic |
| **Stem mixing** | Dynamic intensity | Seamless |
| **Beat-synced** | Rhythmic gameplay | Musical |
| **Queue point** | Next natural break | Clean |
---
## 4. Adaptive Audio Decisions
### Intensity Parameters
| Parameter | Affects | Example |
|-----------|---------|---------|
| **Threat level** | Music intensity | Enemy count |
| **Health** | Filter, reverb | Low health = muffled |
| **Speed** | Tempo, energy | Racing speed |
| **Environment** | Reverb, EQ | Cave vs outdoor |
| **Time of day** | Mood, volume | Night = quieter |
### Vertical vs Horizontal
| System | What Changes | Best For |
|--------|--------------|----------|
| **Vertical (layers)** | Add/remove instrument layers | Intensity scaling |
| **Horizontal (segments)** | Different music sections | State changes |
| **Combined** | Both | AAA adaptive scores |
---
## 5. 3D Audio Decisions
### Spatialization
| Element | 3D Positioned? | Reason |
|---------|----------------|--------|
| Player footsteps | No (or subtle) | Always audible |
| Enemy footsteps | Yes | Directional awareness |
| Gunfire | Yes | Combat awareness |
| Music | No | Mood, non-diegetic |
| Ambient zone | Yes (area) | Environmental |
| UI sounds | No | Interface feedback |
### Distance Behavior
| Distance | Sound Behavior |
|----------|----------------|
| **Near** | Full volume, full frequency |
| **Medium** | Volume falloff, high-freq rolloff |
| **Far** | Low volume, low-pass filter |
| **Max** | Silent or ambient hint |
---
## 6. Platform Considerations
### Format Selection
| Platform | Recommended Format | Reason |
|----------|-------------------|--------|
| PC | OGG Vorbis, WAV | Quality, no licensing |
| Console | Platform-specific | Certification |
| Mobile | MP3, AAC | Size, compatibility |
| Web | WebM/Opus, MP3 fallback | Browser support |
### Memory Budget
| Game Type | Audio Budget | Strategy |
|-----------|--------------|----------|
| Mobile casual | 10-50 MB | Compressed, fewer variants |
| PC indie | 100-500 MB | Quality focus |
| AAA | 1+ GB | Full quality, many variants |
---
## 7. Mix Hierarchy
### Volume Balance Reference
| Category | Relative Level | Notes |
|----------|----------------|-------|
| **Voice** | 0 dB (reference) | Always clear |
| **Player SFX** | -3 to -6 dB | Prominent but not harsh |
| **Music** | -6 to -12 dB | Foundation, ducks for voice |
| **Enemy SFX** | -6 to -9 dB | Important but not dominant |
| **Ambient** | -12 to -18 dB | Subtle background |
### Ducking Rules
| When | Duck What | Amount |
|------|-----------|--------|
| Voice plays | Music, Ambient | -6 to -9 dB |
| Explosion | All except explosion | Brief duck |
| Menu open | Gameplay audio | -3 to -6 dB |
---
## 8. Anti-Patterns
| Don't | Do |
|-------|-----|
| Play same sound repeatedly | Use variations (3-5 per sound) |
| Max volume everything | Use proper mix hierarchy |
| Ignore silence | Silence creates contrast |
| One music track loops forever | Provide variety, transitions |
| Skip audio in prototype | Placeholder audio matters |
---
> **Remember:** 50% of the game experience is audio. A muted game loses half its soul.

View File

@@ -0,0 +1,129 @@
---
name: game-design
description: Game design principles. GDD structure, balancing, player psychology, progression.
allowed-tools: Read, Glob, Grep
---
# Game Design Principles
> Design thinking for engaging games.
---
## 1. Core Loop Design
### The 30-Second Test
```
Every game needs a fun 30-second loop:
1. ACTION → Player does something
2. FEEDBACK → Game responds
3. REWARD → Player feels good
4. REPEAT
```
### Loop Examples
| Genre | Core Loop |
|-------|-----------|
| Platformer | Run → Jump → Land → Collect |
| Shooter | Aim → Shoot → Kill → Loot |
| Puzzle | Observe → Think → Solve → Advance |
| RPG | Explore → Fight → Level → Gear |
---
## 2. Game Design Document (GDD)
### Essential Sections
| Section | Content |
|---------|---------|
| **Pitch** | One-sentence description |
| **Core Loop** | 30-second gameplay |
| **Mechanics** | How systems work |
| **Progression** | How player advances |
| **Art Style** | Visual direction |
| **Audio** | Sound direction |
### Principles
- Keep it living (update regularly)
- Visuals help communicate
- Less is more (start small)
---
## 3. Player Psychology
### Motivation Types
| Type | Driven By |
|------|-----------|
| **Achiever** | Goals, completion |
| **Explorer** | Discovery, secrets |
| **Socializer** | Interaction, community |
| **Killer** | Competition, dominance |
### Reward Schedules
| Schedule | Effect | Use |
|----------|--------|-----|
| **Fixed** | Predictable | Milestone rewards |
| **Variable** | Addictive | Loot drops |
| **Ratio** | Effort-based | Grind games |
---
## 4. Difficulty Balancing
### Flow State
```
Too Hard → Frustration → Quit
Too Easy → Boredom → Quit
Just Right → Flow → Engagement
```
### Balancing Strategies
| Strategy | How |
|----------|-----|
| **Dynamic** | Adjust to player skill |
| **Selection** | Let player choose |
| **Accessibility** | Options for all |
---
## 5. Progression Design
### Progression Types
| Type | Example |
|------|---------|
| **Skill** | Player gets better |
| **Power** | Character gets stronger |
| **Content** | New areas unlock |
| **Story** | Narrative advances |
### Pacing Principles
- Early wins (hook quickly)
- Gradually increase challenge
- Rest beats between intensity
- Meaningful choices
---
## 6. Anti-Patterns
| ❌ Don't | ✅ Do |
|----------|-------|
| Design in isolation | Playtest constantly |
| Polish before fun | Prototype first |
| Force one way to play | Allow player expression |
| Punish excessively | Reward progress |
---
> **Remember:** Fun is discovered through iteration, not designed on paper.

View File

@@ -0,0 +1,108 @@
---
name: mobile-games
description: Mobile game development principles. Touch input, battery, performance, app stores.
allowed-tools: Read, Write, Edit, Glob, Grep
---
# Mobile Game Development
> Platform constraints and optimization principles.
---
## 1. Platform Considerations
### Key Constraints
| Constraint | Strategy |
|------------|----------|
| **Touch input** | Large hit areas, gestures |
| **Battery** | Limit CPU/GPU usage |
| **Thermal** | Throttle when hot |
| **Screen size** | Responsive UI |
| **Interruptions** | Pause on background |
---
## 2. Touch Input Principles
### Touch vs Controller
| Touch | Desktop/Console |
|-------|-----------------|
| Imprecise | Precise |
| Occludes screen | No occlusion |
| Limited buttons | Many buttons |
| Gestures available | Buttons/sticks |
### Best Practices
- Minimum touch target: 44x44 points
- Visual feedback on touch
- Avoid precise timing requirements
- Support both portrait and landscape
---
## 3. Performance Targets
### Thermal Management
| Action | Trigger |
|--------|---------|
| Reduce quality | Device warm |
| Limit FPS | Device hot |
| Pause effects | Critical temp |
### Battery Optimization
- 30 FPS often sufficient
- Sleep when paused
- Minimize GPS/network
- Dark mode saves OLED battery
---
## 4. App Store Requirements
### iOS (App Store)
| Requirement | Note |
|-------------|------|
| Privacy labels | Required |
| Account deletion | If account creation exists |
| Screenshots | For all device sizes |
### Android (Google Play)
| Requirement | Note |
|-------------|------|
| Target API | Current year's SDK |
| 64-bit | Required |
| App bundles | Recommended |
---
## 5. Monetization Models
| Model | Best For |
|-------|----------|
| **Premium** | Quality games, loyal audience |
| **Free + IAP** | Casual, progression-based |
| **Ads** | Hyper-casual, high volume |
| **Subscription** | Content updates, multiplayer |
---
## 6. Anti-Patterns
| ❌ Don't | ✅ Do |
|----------|-------|
| Desktop controls on mobile | Design for touch |
| Ignore battery drain | Monitor thermals |
| Force landscape | Support player preference |
| Always-on network | Cache and sync |
---
> **Remember:** Mobile is the most constrained platform. Respect battery and attention.

View File

@@ -0,0 +1,132 @@
---
name: multiplayer
description: Multiplayer game development principles. Architecture, networking, synchronization.
allowed-tools: Read, Write, Edit, Glob, Grep, Bash
---
# Multiplayer Game Development
> Networking architecture and synchronization principles.
---
## 1. Architecture Selection
### Decision Tree
```
What type of multiplayer?
├── Competitive / Real-time
│ └── Dedicated Server (authoritative)
├── Cooperative / Casual
│ └── Host-based (one player is server)
├── Turn-based
│ └── Client-server (simple)
└── Massive (MMO)
└── Distributed servers
```
### Comparison
| Architecture | Latency | Cost | Security |
|--------------|---------|------|----------|
| **Dedicated** | Low | High | Strong |
| **P2P** | Variable | Low | Weak |
| **Host-based** | Medium | Low | Medium |
---
## 2. Synchronization Principles
### State vs Input
| Approach | Sync What | Best For |
|----------|-----------|----------|
| **State Sync** | Game state | Simple, few objects |
| **Input Sync** | Player inputs | Action games |
| **Hybrid** | Both | Most games |
### Lag Compensation
| Technique | Purpose |
|-----------|---------|
| **Prediction** | Client predicts server |
| **Interpolation** | Smooth remote players |
| **Reconciliation** | Fix mispredictions |
| **Lag compensation** | Rewind for hit detection |
---
## 3. Network Optimization
### Bandwidth Reduction
| Technique | Savings |
|-----------|---------|
| **Delta compression** | Send only changes |
| **Quantization** | Reduce precision |
| **Priority** | Important data first |
| **Area of interest** | Only nearby entities |
### Update Rates
| Type | Rate |
|------|------|
| Position | 20-60 Hz |
| Health | On change |
| Inventory | On change |
| Chat | On send |
---
## 4. Security Principles
### Server Authority
```
Client: "I hit the enemy"
Server: Validate → did projectile actually hit?
→ was player in valid state?
→ was timing possible?
```
### Anti-Cheat
| Cheat | Prevention |
|-------|------------|
| Speed hack | Server validates movement |
| Aimbot | Server validates sight line |
| Item dupe | Server owns inventory |
| Wall hack | Don't send hidden data |
---
## 5. Matchmaking
### Considerations
| Factor | Impact |
|--------|--------|
| **Skill** | Fair matches |
| **Latency** | Playable connection |
| **Wait time** | Player patience |
| **Party size** | Group play |
---
## 6. Anti-Patterns
| ❌ Don't | ✅ Do |
|----------|-------|
| Trust the client | Server is authority |
| Send everything | Send only necessary |
| Ignore latency | Design for 100-200ms |
| Sync exact positions | Interpolate/predict |
---
> **Remember:** Never trust the client. The server is the source of truth.

View File

@@ -0,0 +1,144 @@
---
name: pc-games
description: PC and console game development principles. Engine selection, platform features, optimization strategies.
allowed-tools: Read, Write, Edit, Glob, Grep
---
# PC/Console Game Development
> Engine selection and platform-specific principles.
---
## 1. Engine Selection
### Decision Tree
```
What are you building?
├── 2D Game
│ ├── Open source important? → Godot
│ └── Large team/assets? → Unity
├── 3D Game
│ ├── AAA visual quality? → Unreal
│ ├── Cross-platform priority? → Unity
│ └── Indie/open source? → Godot 4
└── Specific Needs
├── DOTS performance? → Unity
├── Nanite/Lumen? → Unreal
└── Lightweight? → Godot
```
### Comparison
| Factor | Unity 6 | Godot 4 | Unreal 5 |
|--------|---------|---------|----------|
| 2D | Good | Excellent | Limited |
| 3D | Good | Good | Excellent |
| Learning | Medium | Easy | Hard |
| Cost | Revenue share | Free | 5% after $1M |
| Team | Any | Solo-Medium | Medium-Large |
---
## 2. Platform Features
### Steam Integration
| Feature | Purpose |
|---------|---------|
| Achievements | Player goals |
| Cloud Saves | Cross-device progress |
| Leaderboards | Competition |
| Workshop | User mods |
| Rich Presence | Show in-game status |
### Console Requirements
| Platform | Certification |
|----------|--------------|
| PlayStation | TRC compliance |
| Xbox | XR compliance |
| Nintendo | Lotcheck |
---
## 3. Controller Support
### Input Abstraction
```
Map ACTIONS, not buttons:
- "confirm" → A (Xbox), Cross (PS), B (Nintendo)
- "cancel" → B (Xbox), Circle (PS), A (Nintendo)
```
### Haptic Feedback
| Intensity | Use |
|-----------|-----|
| Light | UI feedback |
| Medium | Impacts |
| Heavy | Major events |
---
## 4. Performance Optimization
### Profiling First
| Engine | Tool |
|--------|------|
| Unity | Profiler Window |
| Godot | Debugger → Profiler |
| Unreal | Unreal Insights |
### Common Bottlenecks
| Bottleneck | Solution |
|------------|----------|
| Draw calls | Batching, atlases |
| GC spikes | Object pooling |
| Physics | Simpler colliders |
| Shaders | LOD shaders |
---
## 5. Engine-Specific Principles
### Unity 6
- DOTS for performance-critical systems
- Burst compiler for hot paths
- Addressables for asset streaming
### Godot 4
- GDScript for rapid iteration
- C# for complex logic
- Signals for decoupling
### Unreal 5
- Blueprint for designers
- C++ for performance
- Nanite for high-poly environments
- Lumen for dynamic lighting
---
## 6. Anti-Patterns
| ❌ Don't | ✅ Do |
|----------|-------|
| Choose engine by hype | Choose by project needs |
| Ignore platform guidelines | Study certification requirements |
| Hardcode input buttons | Abstract to actions |
| Skip profiling | Profile early and often |
---
> **Remember:** Engine is a tool. Master the principles, then adapt to any engine.

View File

@@ -0,0 +1,123 @@
---
name: vr-ar
description: VR/AR development principles. Comfort, interaction, performance requirements.
allowed-tools: Read, Write, Edit, Glob, Grep
---
# VR/AR Development
> Immersive experience principles.
---
## 1. Platform Selection
### VR Platforms
| Platform | Use Case |
|----------|----------|
| **Quest** | Standalone, wireless |
| **PCVR** | High fidelity |
| **PSVR** | Console market |
| **WebXR** | Browser-based |
### AR Platforms
| Platform | Use Case |
|----------|----------|
| **ARKit** | iOS devices |
| **ARCore** | Android devices |
| **WebXR** | Browser AR |
| **HoloLens** | Enterprise |
---
## 2. Comfort Principles
### Motion Sickness Prevention
| Cause | Solution |
|-------|----------|
| **Locomotion** | Teleport, snap turn |
| **Low FPS** | Maintain 90 FPS |
| **Camera shake** | Avoid or minimize |
| **Rapid acceleration** | Gradual movement |
### Comfort Settings
- Vignette during movement
- Snap vs smooth turning
- Seated vs standing modes
- Height calibration
---
## 3. Performance Requirements
### Target Metrics
| Platform | FPS | Resolution |
|----------|-----|------------|
| Quest 2 | 72-90 | 1832x1920 |
| Quest 3 | 90-120 | 2064x2208 |
| PCVR | 90 | 2160x2160+ |
| PSVR2 | 90-120 | 2000x2040 |
### Frame Budget
- VR requires consistent frame times
- Single dropped frame = visible judder
- 90 FPS = 11.11ms budget
---
## 4. Interaction Principles
### Controller Interaction
| Type | Use |
|------|-----|
| **Point + click** | UI, distant objects |
| **Grab** | Manipulation |
| **Gesture** | Magic, special actions |
| **Physical** | Throwing, swinging |
### Hand Tracking
- More immersive but less precise
- Good for: social, casual
- Challenging for: action, precision
---
## 5. Spatial Design
### World Scale
- 1 unit = 1 meter (critical)
- Objects must feel right size
- Test with real measurements
### Depth Cues
| Cue | Importance |
|-----|------------|
| Stereo | Primary depth |
| Motion parallax | Secondary |
| Shadows | Grounding |
| Occlusion | Layering |
---
## 6. Anti-Patterns
| ❌ Don't | ✅ Do |
|----------|-------|
| Move camera without player | Player controls camera |
| Drop below 90 FPS | Maintain frame rate |
| Use tiny UI text | Large, readable text |
| Ignore arm length | Scale to player reach |
---
> **Remember:** Comfort is not optional. Sick players don't play.

View File

@@ -0,0 +1,150 @@
---
name: web-games
description: Web browser game development principles. Framework selection, WebGPU, optimization, PWA.
allowed-tools: Read, Write, Edit, Glob, Grep
---
# Web Browser Game Development
> Framework selection and browser-specific principles.
---
## 1. Framework Selection
### Decision Tree
```
What type of game?
├── 2D Game
│ ├── Full game engine features? → Phaser
│ └── Raw rendering power? → PixiJS
├── 3D Game
│ ├── Full engine (physics, XR)? → Babylon.js
│ └── Rendering focused? → Three.js
└── Hybrid / Canvas
└── Custom → Raw Canvas/WebGL
```
### Comparison (2025)
| Framework | Type | Best For |
|-----------|------|----------|
| **Phaser 4** | 2D | Full game features |
| **PixiJS 8** | 2D | Rendering, UI |
| **Three.js** | 3D | Visualizations, lightweight |
| **Babylon.js 7** | 3D | Full engine, XR |
---
## 2. WebGPU Adoption
### Browser Support (2025)
| Browser | Support |
|---------|---------|
| Chrome | ✅ Since v113 |
| Edge | ✅ Since v113 |
| Firefox | ✅ Since v131 |
| Safari | ✅ Since 18.0 |
| **Total** | **~73%** global |
### Decision
- **New projects**: Use WebGPU with WebGL fallback
- **Legacy support**: Start with WebGL
- **Feature detection**: Check `navigator.gpu`
---
## 3. Performance Principles
### Browser Constraints
| Constraint | Strategy |
|------------|----------|
| No local file access | Asset bundling, CDN |
| Tab throttling | Pause when hidden |
| Mobile data limits | Compress assets |
| Audio autoplay | Require user interaction |
### Optimization Priority
1. **Asset compression** - KTX2, Draco, WebP
2. **Lazy loading** - Load on demand
3. **Object pooling** - Avoid GC
4. **Draw call batching** - Reduce state changes
5. **Web Workers** - Offload heavy computation
---
## 4. Asset Strategy
### Compression Formats
| Type | Format |
|------|--------|
| Textures | KTX2 + Basis Universal |
| Audio | WebM/Opus (fallback: MP3) |
| 3D Models | glTF + Draco/Meshopt |
### Loading Strategy
| Phase | Load |
|-------|------|
| Startup | Core assets, <2MB |
| Gameplay | Stream on demand |
| Background | Prefetch next level |
---
## 5. PWA for Games
### Benefits
- Offline play
- Install to home screen
- Full screen mode
- Push notifications
### Requirements
- Service worker for caching
- Web app manifest
- HTTPS
---
## 6. Audio Handling
### Browser Requirements
- Audio context requires user interaction
- Create AudioContext on first click/tap
- Resume context if suspended
### Best Practices
- Use Web Audio API
- Pool audio sources
- Preload common sounds
- Compress with WebM/Opus
---
## 7. Anti-Patterns
| ❌ Don't | ✅ Do |
|----------|-------|
| Load all assets upfront | Progressive loading |
| Ignore tab visibility | Pause when hidden |
| Block on audio load | Lazy load audio |
| Skip compression | Compress everything |
| Assume fast connection | Handle slow networks |
---
> **Remember:** Browser is the most accessible platform. Respect its constraints.

View File

@@ -0,0 +1,156 @@
---
name: geo-fundamentals
description: Generative Engine Optimization for AI search engines (ChatGPT, Claude, Perplexity).
allowed-tools: Read, Glob, Grep
---
# GEO Fundamentals
> Optimization for AI-powered search engines.
---
## 1. What is GEO?
**GEO** = Generative Engine Optimization
| Goal | Platform |
|------|----------|
| Be cited in AI responses | ChatGPT, Claude, Perplexity, Gemini |
### SEO vs GEO
| Aspect | SEO | GEO |
|--------|-----|-----|
| Goal | #1 ranking | AI citations |
| Platform | Google | AI engines |
| Metrics | Rankings, CTR | Citation rate |
| Focus | Keywords | Entities, data |
---
## 2. AI Engine Landscape
| Engine | Citation Style | Opportunity |
|--------|----------------|-------------|
| **Perplexity** | Numbered [1][2] | Highest citation rate |
| **ChatGPT** | Inline/footnotes | Custom GPTs |
| **Claude** | Contextual | Long-form content |
| **Gemini** | Sources section | SEO crossover |
---
## 3. RAG Retrieval Factors
How AI engines select content to cite:
| Factor | Weight |
|--------|--------|
| Semantic relevance | ~40% |
| Keyword match | ~20% |
| Authority signals | ~15% |
| Freshness | ~10% |
| Source diversity | ~15% |
---
## 4. Content That Gets Cited
| Element | Why It Works |
|---------|--------------|
| **Original statistics** | Unique, citable data |
| **Expert quotes** | Authority transfer |
| **Clear definitions** | Easy to extract |
| **Step-by-step guides** | Actionable value |
| **Comparison tables** | Structured info |
| **FAQ sections** | Direct answers |
---
## 5. GEO Content Checklist
### Content Elements
- [ ] Question-based titles
- [ ] Summary/TL;DR at top
- [ ] Original data with sources
- [ ] Expert quotes (name, title)
- [ ] FAQ section (3-5 Q&A)
- [ ] Clear definitions
- [ ] "Last updated" timestamp
- [ ] Author with credentials
### Technical Elements
- [ ] Article schema with dates
- [ ] Person schema for author
- [ ] FAQPage schema
- [ ] Fast loading (< 2.5s)
- [ ] Clean HTML structure
---
## 6. Entity Building
| Action | Purpose |
|--------|---------|
| Google Knowledge Panel | Entity recognition |
| Wikipedia (if notable) | Authority source |
| Consistent info across web | Entity consolidation |
| Industry mentions | Authority signals |
---
## 7. AI Crawler Access
### Key AI User-Agents
| Crawler | Engine |
|---------|--------|
| GPTBot | ChatGPT/OpenAI |
| Claude-Web | Claude |
| PerplexityBot | Perplexity |
| Googlebot | Gemini (shared) |
### Access Decision
| Strategy | When |
|----------|------|
| Allow all | Want AI citations |
| Block GPTBot | Don't want OpenAI training |
| Selective | Allow some, block others |
---
## 8. Measurement
| Metric | How to Track |
|--------|--------------|
| AI citations | Manual monitoring |
| "According to [Brand]" mentions | Search in AI |
| Competitor citations | Compare share |
| AI-referred traffic | UTM parameters |
---
## 9. Anti-Patterns
| ❌ Don't | ✅ Do |
|----------|-------|
| Publish without dates | Add timestamps |
| Vague attributions | Name sources |
| Skip author info | Show credentials |
| Thin content | Comprehensive coverage |
---
> **Remember:** AI cites content that's clear, authoritative, and easy to extract. Be the best answer.
---
## Script
| Script | Purpose | Command |
|--------|---------|---------|
| `scripts/geo_checker.py` | GEO audit (AI citation readiness) | `python scripts/geo_checker.py <project_path>` |

View File

@@ -0,0 +1,289 @@
#!/usr/bin/env python3
"""
GEO Checker - Generative Engine Optimization Audit
Checks PUBLIC WEB CONTENT for AI citation readiness.
PURPOSE:
- Analyze pages that will be INDEXED by AI engines (ChatGPT, Perplexity, etc.)
- Check for structured data, author info, dates, FAQ sections
- Help content rank in AI-generated answers
WHAT IT CHECKS:
- HTML files (actual web pages)
- JSX/TSX files (React page components)
- NOT markdown files (those are developer docs, not public content)
Usage:
python geo_checker.py <project_path>
"""
import sys
import re
import json
from pathlib import Path
# Fix Windows console encoding
try:
sys.stdout.reconfigure(encoding='utf-8', errors='replace')
sys.stderr.reconfigure(encoding='utf-8', errors='replace')
except AttributeError:
pass
# Directories to skip (not public content)
SKIP_DIRS = {
'node_modules', '.next', 'dist', 'build', '.git', '.github',
'__pycache__', '.vscode', '.idea', 'coverage', 'test', 'tests',
'__tests__', 'spec', 'docs', 'documentation'
}
# Files to skip (not public pages)
SKIP_FILES = {
'jest.config', 'webpack.config', 'vite.config', 'tsconfig',
'package.json', 'package-lock', 'yarn.lock', '.eslintrc',
'tailwind.config', 'postcss.config', 'next.config'
}
def is_page_file(file_path: Path) -> bool:
"""Check if this file is likely a public-facing page."""
name = file_path.stem.lower()
# Skip config/utility files
if any(skip in name for skip in SKIP_FILES):
return False
# Skip test files
if name.endswith('.test') or name.endswith('.spec'):
return False
if name.startswith('test_') or name.startswith('spec_'):
return False
# Likely page indicators
page_indicators = ['page', 'index', 'home', 'about', 'contact', 'blog',
'post', 'article', 'product', 'service', 'landing']
# Check if it's in a pages/app directory (Next.js, etc.)
parts = [p.lower() for p in file_path.parts]
if 'pages' in parts or 'app' in parts or 'routes' in parts:
return True
# Check filename indicators
if any(ind in name for ind in page_indicators):
return True
# HTML files are usually pages
if file_path.suffix.lower() == '.html':
return True
return False
def find_web_pages(project_path: Path) -> list:
"""Find public-facing web pages only."""
patterns = ['**/*.html', '**/*.htm', '**/*.jsx', '**/*.tsx']
files = []
for pattern in patterns:
for f in project_path.glob(pattern):
# Skip excluded directories
if any(skip in f.parts for skip in SKIP_DIRS):
continue
# Check if it's likely a page
if is_page_file(f):
files.append(f)
return files[:30] # Limit to 30 pages
def check_page(file_path: Path) -> dict:
"""Check a single web page for GEO elements."""
try:
content = file_path.read_text(encoding='utf-8', errors='ignore')
except Exception as e:
return {'file': str(file_path.name), 'passed': [], 'issues': [f"Error: {e}"], 'score': 0}
issues = []
passed = []
# 1. JSON-LD Structured Data (Critical for AI)
if 'application/ld+json' in content:
passed.append("JSON-LD structured data found")
if '"@type"' in content:
if 'Article' in content:
passed.append("Article schema present")
if 'FAQPage' in content:
passed.append("FAQ schema present")
if 'Organization' in content or 'Person' in content:
passed.append("Entity schema present")
else:
issues.append("No JSON-LD structured data (AI engines prefer structured content)")
# 2. Heading Structure
h1_count = len(re.findall(r'<h1[^>]*>', content, re.I))
h2_count = len(re.findall(r'<h2[^>]*>', content, re.I))
if h1_count == 1:
passed.append("Single H1 heading (clear topic)")
elif h1_count == 0:
issues.append("No H1 heading - page topic unclear")
else:
issues.append(f"Multiple H1 headings ({h1_count}) - confusing for AI")
if h2_count >= 2:
passed.append(f"{h2_count} H2 subheadings (good structure)")
else:
issues.append("Add more H2 subheadings for scannable content")
# 3. Author Attribution (E-E-A-T signal)
author_patterns = ['author', 'byline', 'written-by', 'contributor', 'rel="author"']
has_author = any(p in content.lower() for p in author_patterns)
if has_author:
passed.append("Author attribution found")
else:
issues.append("No author info (AI prefers attributed content)")
# 4. Publication Date (Freshness signal)
date_patterns = ['datePublished', 'dateModified', 'datetime=', 'pubdate', 'article:published']
has_date = any(re.search(p, content, re.I) for p in date_patterns)
if has_date:
passed.append("Publication date found")
else:
issues.append("No publication date (freshness matters for AI)")
# 5. FAQ Section (Highly citable)
faq_patterns = [r'<details', r'faq', r'frequently.?asked', r'"FAQPage"']
has_faq = any(re.search(p, content, re.I) for p in faq_patterns)
if has_faq:
passed.append("FAQ section detected (highly citable)")
# 6. Lists (Structured content)
list_count = len(re.findall(r'<(ul|ol)[^>]*>', content, re.I))
if list_count >= 2:
passed.append(f"{list_count} lists (structured content)")
# 7. Tables (Comparison data)
table_count = len(re.findall(r'<table[^>]*>', content, re.I))
if table_count >= 1:
passed.append(f"{table_count} table(s) (comparison data)")
# 8. Entity Recognition (E-E-A-T signal) - NEW 2025
entity_patterns = [
r'"@type"\s*:\s*"Organization"',
r'"@type"\s*:\s*"LocalBusiness"',
r'"@type"\s*:\s*"Brand"',
r'itemtype.*schema\.org/(Organization|Person|Brand)',
r'rel="author"'
]
has_entity = any(re.search(p, content, re.I) for p in entity_patterns)
if has_entity:
passed.append("Entity/Brand recognition (E-E-A-T)")
# 9. Original Statistics/Data (AI citation magnet) - NEW 2025
stat_patterns = [
r'\d+%', # Percentages
r'\$[\d,]+', # Dollar amounts
r'study\s+(shows|found)', # Research citations
r'according to', # Source attribution
r'data\s+(shows|reveals)', # Data-backed claims
r'\d+x\s+(faster|better|more)', # Comparison stats
r'(million|billion|trillion)', # Large numbers
]
stat_matches = sum(1 for p in stat_patterns if re.search(p, content, re.I))
if stat_matches >= 2:
passed.append("Original statistics/data (citation magnet)")
# 10. Conversational/Direct answers - NEW 2025
direct_answer_patterns = [
r'is defined as',
r'refers to',
r'means that',
r'the answer is',
r'in short,',
r'simply put,',
r'<dfn'
]
has_direct = any(re.search(p, content, re.I) for p in direct_answer_patterns)
if has_direct:
passed.append("Direct answer patterns (LLM-friendly)")
# Calculate score
total = len(passed) + len(issues)
score = (len(passed) / total * 100) if total > 0 else 0
return {
'file': str(file_path.name),
'passed': passed,
'issues': issues,
'score': round(score)
}
def main():
target = sys.argv[1] if len(sys.argv) > 1 else "."
target_path = Path(target).resolve()
print("\n" + "=" * 60)
print(" GEO CHECKER - AI Citation Readiness Audit")
print("=" * 60)
print(f"Project: {target_path}")
print("-" * 60)
# Find web pages only
pages = find_web_pages(target_path)
if not pages:
print("\n[!] No public web pages found.")
print(" Looking for: HTML, JSX, TSX files in pages/app directories")
print(" Skipping: docs, tests, config files, node_modules")
output = {"script": "geo_checker", "pages_found": 0, "passed": True}
print("\n" + json.dumps(output, indent=2))
sys.exit(0)
print(f"Found {len(pages)} public pages to analyze\n")
# Check each page
results = []
for page in pages:
result = check_page(page)
results.append(result)
# Print results
for result in results:
status = "[OK]" if result['score'] >= 60 else "[!]"
print(f"{status} {result['file']}: {result['score']}%")
if result['issues'] and result['score'] < 60:
for issue in result['issues'][:2]: # Show max 2 issues
print(f" - {issue}")
# Average score
avg_score = sum(r['score'] for r in results) / len(results) if results else 0
print("\n" + "=" * 60)
print(f"AVERAGE GEO SCORE: {avg_score:.0f}%")
print("=" * 60)
if avg_score >= 80:
print("[OK] Excellent - Content well-optimized for AI citations")
elif avg_score >= 60:
print("[OK] Good - Some improvements recommended")
elif avg_score >= 40:
print("[!] Needs work - Add structured elements")
else:
print("[X] Poor - Content needs GEO optimization")
# JSON output
output = {
"script": "geo_checker",
"project": str(target_path),
"pages_checked": len(results),
"average_score": round(avg_score),
"passed": avg_score >= 60
}
print("\n" + json.dumps(output, indent=2))
sys.exit(0 if avg_score >= 60 else 1)
if __name__ == "__main__":
main()

View File

@@ -1,6 +1,9 @@
---
name: HTML Injection Testing
description: This skill should be used when the user asks to "test for HTML injection", "inject HTML into web pages", "perform HTML injection attacks", "deface web applications", or "test content injection vulnerabilities". It provides comprehensive HTML injection attack techniques and testing methodologies.
metadata:
author: zebbern
version: "1.1"
---
# HTML Injection Testing

View File

@@ -0,0 +1,154 @@
---
name: i18n-localization
description: Internationalization and localization patterns. Detecting hardcoded strings, managing translations, locale files, RTL support.
allowed-tools: Read, Glob, Grep
---
# i18n & Localization
> Internationalization (i18n) and Localization (L10n) best practices.
---
## 1. Core Concepts
| Term | Meaning |
|------|---------|
| **i18n** | Internationalization - making app translatable |
| **L10n** | Localization - actual translations |
| **Locale** | Language + Region (en-US, tr-TR) |
| **RTL** | Right-to-left languages (Arabic, Hebrew) |
---
## 2. When to Use i18n
| Project Type | i18n Needed? |
|--------------|--------------|
| Public web app | ✅ Yes |
| SaaS product | ✅ Yes |
| Internal tool | ⚠️ Maybe |
| Single-region app | ⚠️ Consider future |
| Personal project | ❌ Optional |
---
## 3. Implementation Patterns
### React (react-i18next)
```tsx
import { useTranslation } from 'react-i18next';
function Welcome() {
const { t } = useTranslation();
return <h1>{t('welcome.title')}</h1>;
}
```
### Next.js (next-intl)
```tsx
import { useTranslations } from 'next-intl';
export default function Page() {
const t = useTranslations('Home');
return <h1>{t('title')}</h1>;
}
```
### Python (gettext)
```python
from gettext import gettext as _
print(_("Welcome to our app"))
```
---
## 4. File Structure
```
locales/
├── en/
│ ├── common.json
│ ├── auth.json
│ └── errors.json
├── tr/
│ ├── common.json
│ ├── auth.json
│ └── errors.json
└── ar/ # RTL
└── ...
```
---
## 5. Best Practices
### DO ✅
- Use translation keys, not raw text
- Namespace translations by feature
- Support pluralization
- Handle date/number formats per locale
- Plan for RTL from the start
- Use ICU message format for complex strings
### DON'T ❌
- Hardcode strings in components
- Concatenate translated strings
- Assume text length (German is 30% longer)
- Forget about RTL layout
- Mix languages in same file
---
## 6. Common Issues
| Issue | Solution |
|-------|----------|
| Missing translation | Fallback to default language |
| Hardcoded strings | Use linter/checker script |
| Date format | Use Intl.DateTimeFormat |
| Number format | Use Intl.NumberFormat |
| Pluralization | Use ICU message format |
---
## 7. RTL Support
```css
/* CSS Logical Properties */
.container {
margin-inline-start: 1rem; /* Not margin-left */
padding-inline-end: 1rem; /* Not padding-right */
}
[dir="rtl"] .icon {
transform: scaleX(-1);
}
```
---
## 8. Checklist
Before shipping:
- [ ] All user-facing strings use translation keys
- [ ] Locale files exist for all supported languages
- [ ] Date/number formatting uses Intl API
- [ ] RTL layout tested (if applicable)
- [ ] Fallback language configured
- [ ] No hardcoded strings in components
---
## Script
| Script | Purpose | Command |
|--------|---------|---------|
| `scripts/i18n_checker.py` | Detect hardcoded strings & missing translations | `python scripts/i18n_checker.py <project_path>` |

View File

@@ -0,0 +1,241 @@
#!/usr/bin/env python3
"""
i18n Checker - Detects hardcoded strings and missing translations.
Scans for untranslated text in React, Vue, and Python files.
"""
import sys
import re
import json
from pathlib import Path
# Fix Windows console encoding for Unicode output
try:
sys.stdout.reconfigure(encoding='utf-8', errors='replace')
sys.stderr.reconfigure(encoding='utf-8', errors='replace')
except AttributeError:
pass # Python < 3.7
# Patterns that indicate hardcoded strings (should be translated)
HARDCODED_PATTERNS = {
'jsx': [
# Text directly in JSX: <div>Hello World</div>
r'>\s*[A-Z][a-zA-Z\s]{3,30}\s*</',
# JSX attribute strings: title="Welcome"
r'(title|placeholder|label|alt|aria-label)="[A-Z][a-zA-Z\s]{2,}"',
# Button/heading text
r'<(button|h[1-6]|p|span|label)[^>]*>\s*[A-Z][a-zA-Z\s!?.,]{3,}\s*</',
],
'vue': [
# Vue template text
r'>\s*[A-Z][a-zA-Z\s]{3,30}\s*</',
r'(placeholder|label|title)="[A-Z][a-zA-Z\s]{2,}"',
],
'python': [
# print/raise with string literals
r'(print|raise\s+\w+)\s*\(\s*["\'][A-Z][^"\']{5,}["\']',
# Flask flash messages
r'flash\s*\(\s*["\'][A-Z][^"\']{5,}["\']',
]
}
# Patterns that indicate proper i18n usage
I18N_PATTERNS = [
r't\(["\']', # t('key') - react-i18next
r'useTranslation', # React hook
r'\$t\(', # Vue i18n
r'_\(["\']', # Python gettext
r'gettext\(', # Python gettext
r'useTranslations', # next-intl
r'FormattedMessage', # react-intl
r'i18n\.', # Generic i18n
]
def find_locale_files(project_path: Path) -> list:
"""Find translation/locale files."""
patterns = [
"**/locales/**/*.json",
"**/translations/**/*.json",
"**/lang/**/*.json",
"**/i18n/**/*.json",
"**/messages/*.json",
"**/*.po", # gettext
]
files = []
for pattern in patterns:
files.extend(project_path.glob(pattern))
return [f for f in files if 'node_modules' not in str(f)]
def check_locale_completeness(locale_files: list) -> dict:
"""Check if all locales have the same keys."""
issues = []
passed = []
if not locale_files:
return {'passed': [], 'issues': ["[!] No locale files found"]}
# Group by parent folder (language)
locales = {}
for f in locale_files:
if f.suffix == '.json':
try:
lang = f.parent.name
content = json.loads(f.read_text(encoding='utf-8'))
if lang not in locales:
locales[lang] = {}
locales[lang][f.stem] = set(flatten_keys(content))
except:
continue
if len(locales) < 2:
passed.append(f"[OK] Found {len(locale_files)} locale file(s)")
return {'passed': passed, 'issues': issues}
passed.append(f"[OK] Found {len(locales)} language(s): {', '.join(locales.keys())}")
# Compare keys across locales
all_langs = list(locales.keys())
base_lang = all_langs[0]
for namespace in locales.get(base_lang, {}):
base_keys = locales[base_lang].get(namespace, set())
for lang in all_langs[1:]:
other_keys = locales.get(lang, {}).get(namespace, set())
missing = base_keys - other_keys
if missing:
issues.append(f"[X] {lang}/{namespace}: Missing {len(missing)} keys")
extra = other_keys - base_keys
if extra:
issues.append(f"[!] {lang}/{namespace}: {len(extra)} extra keys")
if not issues:
passed.append("[OK] All locales have matching keys")
return {'passed': passed, 'issues': issues}
def flatten_keys(d, prefix=''):
"""Flatten nested dict keys."""
keys = set()
for k, v in d.items():
new_key = f"{prefix}.{k}" if prefix else k
if isinstance(v, dict):
keys.update(flatten_keys(v, new_key))
else:
keys.add(new_key)
return keys
def check_hardcoded_strings(project_path: Path) -> dict:
"""Check for hardcoded strings in code files."""
issues = []
passed = []
# Find code files
extensions = {
'.tsx': 'jsx', '.jsx': 'jsx', '.ts': 'jsx', '.js': 'jsx',
'.vue': 'vue',
'.py': 'python'
}
code_files = []
for ext in extensions:
code_files.extend(project_path.rglob(f"*{ext}"))
code_files = [f for f in code_files if not any(x in str(f) for x in
['node_modules', '.git', 'dist', 'build', '__pycache__', 'venv', 'test', 'spec'])]
if not code_files:
return {'passed': ["[!] No code files found"], 'issues': []}
files_with_i18n = 0
files_with_hardcoded = 0
hardcoded_examples = []
for file_path in code_files[:50]: # Limit
try:
content = file_path.read_text(encoding='utf-8', errors='ignore')
ext = file_path.suffix
file_type = extensions.get(ext, 'jsx')
# Check for i18n usage
has_i18n = any(re.search(p, content) for p in I18N_PATTERNS)
if has_i18n:
files_with_i18n += 1
# Check for hardcoded strings
patterns = HARDCODED_PATTERNS.get(file_type, [])
hardcoded_found = False
for pattern in patterns:
matches = re.findall(pattern, content)
if matches and not has_i18n:
hardcoded_found = True
if len(hardcoded_examples) < 5:
hardcoded_examples.append(f"{file_path.name}: {str(matches[0])[:40]}...")
if hardcoded_found:
files_with_hardcoded += 1
except:
continue
passed.append(f"[OK] Analyzed {len(code_files)} code files")
if files_with_i18n > 0:
passed.append(f"[OK] {files_with_i18n} files use i18n")
if files_with_hardcoded > 0:
issues.append(f"[X] {files_with_hardcoded} files may have hardcoded strings")
for ex in hardcoded_examples:
issues.append(f"{ex}")
else:
passed.append("[OK] No obvious hardcoded strings detected")
return {'passed': passed, 'issues': issues}
def main():
target = sys.argv[1] if len(sys.argv) > 1 else "."
project_path = Path(target)
print("\n" + "=" * 60)
print(" i18n CHECKER - Internationalization Audit")
print("=" * 60 + "\n")
# Check locale files
locale_files = find_locale_files(project_path)
locale_result = check_locale_completeness(locale_files)
# Check hardcoded strings
code_result = check_hardcoded_strings(project_path)
# Print results
print("[LOCALE FILES]")
print("-" * 40)
for item in locale_result['passed']:
print(f" {item}")
for item in locale_result['issues']:
print(f" {item}")
print("\n[CODE ANALYSIS]")
print("-" * 40)
for item in code_result['passed']:
print(f" {item}")
for item in code_result['issues']:
print(f" {item}")
# Summary
critical_issues = sum(1 for i in locale_result['issues'] + code_result['issues'] if i.startswith("[X]"))
print("\n" + "=" * 60)
if critical_issues == 0:
print("[OK] i18n CHECK: PASSED")
sys.exit(0)
else:
print(f"[X] i18n CHECK: {critical_issues} issues found")
sys.exit(1)
if __name__ == "__main__":
main()

View File

@@ -1,6 +1,9 @@
---
name: IDOR Vulnerability Testing
description: This skill should be used when the user asks to "test for insecure direct object references," "find IDOR vulnerabilities," "exploit broken access control," "enumerate user IDs or object references," or "bypass authorization to access other users' data." It provides comprehensive guidance for detecting, exploiting, and remediating IDOR vulnerabilities in web applications.
metadata:
author: zebbern
version: "1.1"
---
# IDOR Vulnerability Testing

View File

@@ -0,0 +1,45 @@
---
name: lint-and-validate
description: Automatic quality control, linting, and static analysis procedures. Use after every code modification to ensure syntax correctness and project standards. Triggers onKeywords: lint, format, check, validate, types, static analysis.
allowed-tools: Read, Glob, Grep, Bash
---
# Lint and Validate Skill
> **MANDATORY:** Run appropriate validation tools after EVERY code change. Do not finish a task until the code is error-free.
### Procedures by Ecosystem
#### Node.js / TypeScript
1. **Lint/Fix:** `npm run lint` or `npx eslint "path" --fix`
2. **Types:** `npx tsc --noEmit`
3. **Security:** `npm audit --audit-level=high`
#### Python
1. **Linter (Ruff):** `ruff check "path" --fix` (Fast & Modern)
2. **Security (Bandit):** `bandit -r "path" -ll`
3. **Types (MyPy):** `mypy "path"`
## The Quality Loop
1. **Write/Edit Code**
2. **Run Audit:** `npm run lint && npx tsc --noEmit`
3. **Analyze Report:** Check the "FINAL AUDIT REPORT" section.
4. **Fix & Repeat:** Submitting code with "FINAL AUDIT" failures is NOT allowed.
## Error Handling
- If `lint` fails: Fix the style or syntax issues immediately.
- If `tsc` fails: Correct type mismatches before proceeding.
- If no tool is configured: Check the project root for `.eslintrc`, `tsconfig.json`, `pyproject.toml` and suggest creating one.
---
**Strict Rule:** No code should be committed or reported as "done" without passing these checks.
---
## Scripts
| Script | Purpose | Command |
|--------|---------|---------|
| `scripts/lint_runner.py` | Unified lint check | `python scripts/lint_runner.py <project_path>` |
| `scripts/type_coverage.py` | Type coverage analysis | `python scripts/type_coverage.py <project_path>` |

View File

@@ -0,0 +1,172 @@
#!/usr/bin/env python3
"""
Lint Runner - Unified linting and type checking
Runs appropriate linters based on project type.
Usage:
python lint_runner.py <project_path>
Supports:
- Node.js: npm run lint, npx tsc --noEmit
- Python: ruff check, mypy
"""
import subprocess
import sys
import json
from pathlib import Path
from datetime import datetime
# Fix Windows console encoding
try:
sys.stdout.reconfigure(encoding='utf-8', errors='replace')
except:
pass
def detect_project_type(project_path: Path) -> dict:
"""Detect project type and available linters."""
result = {
"type": "unknown",
"linters": []
}
# Node.js project
package_json = project_path / "package.json"
if package_json.exists():
result["type"] = "node"
try:
pkg = json.loads(package_json.read_text(encoding='utf-8'))
scripts = pkg.get("scripts", {})
deps = {**pkg.get("dependencies", {}), **pkg.get("devDependencies", {})}
# Check for lint script
if "lint" in scripts:
result["linters"].append({"name": "npm lint", "cmd": ["npm", "run", "lint"]})
elif "eslint" in deps:
result["linters"].append({"name": "eslint", "cmd": ["npx", "eslint", "."]})
# Check for TypeScript
if "typescript" in deps or (project_path / "tsconfig.json").exists():
result["linters"].append({"name": "tsc", "cmd": ["npx", "tsc", "--noEmit"]})
except:
pass
# Python project
if (project_path / "pyproject.toml").exists() or (project_path / "requirements.txt").exists():
result["type"] = "python"
# Check for ruff
result["linters"].append({"name": "ruff", "cmd": ["ruff", "check", "."]})
# Check for mypy
if (project_path / "mypy.ini").exists() or (project_path / "pyproject.toml").exists():
result["linters"].append({"name": "mypy", "cmd": ["mypy", "."]})
return result
def run_linter(linter: dict, cwd: Path) -> dict:
"""Run a single linter and return results."""
result = {
"name": linter["name"],
"passed": False,
"output": "",
"error": ""
}
try:
proc = subprocess.run(
linter["cmd"],
cwd=str(cwd),
capture_output=True,
text=True,
encoding='utf-8',
errors='replace',
timeout=120
)
result["output"] = proc.stdout[:2000] if proc.stdout else ""
result["error"] = proc.stderr[:500] if proc.stderr else ""
result["passed"] = proc.returncode == 0
except FileNotFoundError:
result["error"] = f"Command not found: {linter['cmd'][0]}"
except subprocess.TimeoutExpired:
result["error"] = "Timeout after 120s"
except Exception as e:
result["error"] = str(e)
return result
def main():
project_path = Path(sys.argv[1] if len(sys.argv) > 1 else ".").resolve()
print(f"\n{'='*60}")
print(f"[LINT RUNNER] Unified Linting")
print(f"{'='*60}")
print(f"Project: {project_path}")
print(f"Time: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
# Detect project type
project_info = detect_project_type(project_path)
print(f"Type: {project_info['type']}")
print(f"Linters: {len(project_info['linters'])}")
print("-"*60)
if not project_info["linters"]:
print("No linters found for this project type.")
output = {
"script": "lint_runner",
"project": str(project_path),
"type": project_info["type"],
"checks": [],
"passed": True,
"message": "No linters configured"
}
print(json.dumps(output, indent=2))
sys.exit(0)
# Run each linter
results = []
all_passed = True
for linter in project_info["linters"]:
print(f"\nRunning: {linter['name']}...")
result = run_linter(linter, project_path)
results.append(result)
if result["passed"]:
print(f" [PASS] {linter['name']}")
else:
print(f" [FAIL] {linter['name']}")
if result["error"]:
print(f" Error: {result['error'][:200]}")
all_passed = False
# Summary
print("\n" + "="*60)
print("SUMMARY")
print("="*60)
for r in results:
icon = "[PASS]" if r["passed"] else "[FAIL]"
print(f"{icon} {r['name']}")
output = {
"script": "lint_runner",
"project": str(project_path),
"type": project_info["type"],
"checks": results,
"passed": all_passed
}
print("\n" + json.dumps(output, indent=2))
sys.exit(0 if all_passed else 1)
if __name__ == "__main__":
main()

View File

@@ -0,0 +1,173 @@
#!/usr/bin/env python3
"""
Type Coverage Checker - Measures TypeScript/Python type coverage.
Identifies untyped functions, any usage, and type safety issues.
"""
import sys
import re
import subprocess
from pathlib import Path
# Fix Windows console encoding for Unicode output
try:
sys.stdout.reconfigure(encoding='utf-8', errors='replace')
sys.stderr.reconfigure(encoding='utf-8', errors='replace')
except AttributeError:
pass # Python < 3.7
def check_typescript_coverage(project_path: Path) -> dict:
"""Check TypeScript type coverage."""
issues = []
passed = []
stats = {'any_count': 0, 'untyped_functions': 0, 'total_functions': 0}
ts_files = list(project_path.rglob("*.ts")) + list(project_path.rglob("*.tsx"))
ts_files = [f for f in ts_files if 'node_modules' not in str(f) and '.d.ts' not in str(f)]
if not ts_files:
return {'type': 'typescript', 'files': 0, 'passed': [], 'issues': ["[!] No TypeScript files found"], 'stats': stats}
for file_path in ts_files[:30]: # Limit
try:
content = file_path.read_text(encoding='utf-8', errors='ignore')
# Count 'any' usage
any_matches = re.findall(r':\s*any\b', content)
stats['any_count'] += len(any_matches)
# Find functions without return types
# function name(params) { - no return type
untyped = re.findall(r'function\s+\w+\s*\([^)]*\)\s*{', content)
# Arrow functions without types: const fn = (x) => or (x) =>
untyped += re.findall(r'=\s*\([^:)]*\)\s*=>', content)
stats['untyped_functions'] += len(untyped)
# Count typed functions
typed = re.findall(r'function\s+\w+\s*\([^)]*\)\s*:\s*\w+', content)
typed += re.findall(r':\s*\([^)]*\)\s*=>\s*\w+', content)
stats['total_functions'] += len(typed) + len(untyped)
except Exception:
continue
# Analyze results
if stats['any_count'] == 0:
passed.append("[OK] No 'any' types found")
elif stats['any_count'] <= 5:
issues.append(f"[!] {stats['any_count']} 'any' types found (acceptable)")
else:
issues.append(f"[X] {stats['any_count']} 'any' types found (too many)")
if stats['total_functions'] > 0:
typed_ratio = (stats['total_functions'] - stats['untyped_functions']) / stats['total_functions'] * 100
if typed_ratio >= 80:
passed.append(f"[OK] Type coverage: {typed_ratio:.0f}%")
elif typed_ratio >= 50:
issues.append(f"[!] Type coverage: {typed_ratio:.0f}% (improve)")
else:
issues.append(f"[X] Type coverage: {typed_ratio:.0f}% (too low)")
passed.append(f"[OK] Analyzed {len(ts_files)} TypeScript files")
return {'type': 'typescript', 'files': len(ts_files), 'passed': passed, 'issues': issues, 'stats': stats}
def check_python_coverage(project_path: Path) -> dict:
"""Check Python type hints coverage."""
issues = []
passed = []
stats = {'untyped_functions': 0, 'typed_functions': 0, 'any_count': 0}
py_files = list(project_path.rglob("*.py"))
py_files = [f for f in py_files if not any(x in str(f) for x in ['venv', '__pycache__', '.git', 'node_modules'])]
if not py_files:
return {'type': 'python', 'files': 0, 'passed': [], 'issues': ["[!] No Python files found"], 'stats': stats}
for file_path in py_files[:30]: # Limit
try:
content = file_path.read_text(encoding='utf-8', errors='ignore')
# Count Any usage
any_matches = re.findall(r':\s*Any\b', content)
stats['any_count'] += len(any_matches)
# Find functions with type hints
typed_funcs = re.findall(r'def\s+\w+\s*\([^)]*:[^)]+\)', content)
typed_funcs += re.findall(r'def\s+\w+\s*\([^)]*\)\s*->', content)
stats['typed_functions'] += len(typed_funcs)
# Find functions without type hints
all_funcs = re.findall(r'def\s+\w+\s*\(', content)
stats['untyped_functions'] += len(all_funcs) - len(typed_funcs)
except Exception:
continue
total = stats['typed_functions'] + stats['untyped_functions']
if total > 0:
typed_ratio = stats['typed_functions'] / total * 100
if typed_ratio >= 70:
passed.append(f"[OK] Type hints coverage: {typed_ratio:.0f}%")
elif typed_ratio >= 40:
issues.append(f"[!] Type hints coverage: {typed_ratio:.0f}%")
else:
issues.append(f"[X] Type hints coverage: {typed_ratio:.0f}% (add type hints)")
if stats['any_count'] == 0:
passed.append("[OK] No 'Any' types found")
elif stats['any_count'] <= 3:
issues.append(f"[!] {stats['any_count']} 'Any' types found")
else:
issues.append(f"[X] {stats['any_count']} 'Any' types found")
passed.append(f"[OK] Analyzed {len(py_files)} Python files")
return {'type': 'python', 'files': len(py_files), 'passed': passed, 'issues': issues, 'stats': stats}
def main():
target = sys.argv[1] if len(sys.argv) > 1 else "."
project_path = Path(target)
print("\n" + "=" * 60)
print(" TYPE COVERAGE CHECKER")
print("=" * 60 + "\n")
results = []
# Check TypeScript
ts_result = check_typescript_coverage(project_path)
if ts_result['files'] > 0:
results.append(ts_result)
# Check Python
py_result = check_python_coverage(project_path)
if py_result['files'] > 0:
results.append(py_result)
if not results:
print("[!] No TypeScript or Python files found.")
sys.exit(0)
# Print results
critical_issues = 0
for result in results:
print(f"\n[{result['type'].upper()}]")
print("-" * 40)
for item in result['passed']:
print(f" {item}")
for item in result['issues']:
print(f" {item}")
if item.startswith("[X]"):
critical_issues += 1
print("\n" + "=" * 60)
if critical_issues == 0:
print("[OK] TYPE COVERAGE: ACCEPTABLE")
sys.exit(0)
else:
print(f"[X] TYPE COVERAGE: {critical_issues} critical issues")
sys.exit(1)
if __name__ == "__main__":
main()

View File

@@ -1,6 +1,9 @@
---
name: Linux Privilege Escalation
description: This skill should be used when the user asks to "escalate privileges on Linux", "find privesc vectors on Linux systems", "exploit sudo misconfigurations", "abuse SUID binaries", "exploit cron jobs for root access", "enumerate Linux systems for privilege escalation", or "gain root access from low-privilege shell". It provides comprehensive techniques for identifying and exploiting privilege escalation paths on Linux systems.
metadata:
author: zebbern
version: "1.1"
---
# Linux Privilege Escalation

View File

@@ -1,6 +1,9 @@
---
name: Linux Production Shell Scripts
description: This skill should be used when the user asks to "create bash scripts", "automate Linux tasks", "monitor system resources", "backup files", "manage users", or "write production shell scripts". It provides ready-to-use shell script templates for system administration.
metadata:
author: zebbern
version: "1.1"
---
# Linux Production Shell Scripts

View File

@@ -1,6 +1,9 @@
---
name: Metasploit Framework
description: This skill should be used when the user asks to "use Metasploit for penetration testing", "exploit vulnerabilities with msfconsole", "create payloads with msfvenom", "perform post-exploitation", "use auxiliary modules for scanning", or "develop custom exploits". It provides comprehensive guidance for leveraging the Metasploit Framework in security assessments.
metadata:
author: zebbern
version: "1.1"
---
# Metasploit Framework

View File

@@ -0,0 +1,394 @@
---
name: mobile-design
description: Mobile-first design thinking and decision-making for iOS and Android apps. Touch interaction, performance patterns, platform conventions. Teaches principles, not fixed values. Use when building React Native, Flutter, or native mobile apps.
allowed-tools: Read, Glob, Grep, Bash
---
# Mobile Design System
> **Philosophy:** Touch-first. Battery-conscious. Platform-respectful. Offline-capable.
> **Core Principle:** Mobile is NOT a small desktop. THINK mobile constraints, ASK platform choice.
---
## 🔧 Runtime Scripts
**Execute these for validation (don't read, just run):**
| Script | Purpose | Usage |
|--------|---------|-------|
| `scripts/mobile_audit.py` | Mobile UX & Touch Audit | `python scripts/mobile_audit.py <project_path>` |
---
## 🔴 MANDATORY: Read Reference Files Before Working!
**⛔ DO NOT start development until you read the relevant files:**
### Universal (Always Read)
| File | Content | Status |
|------|---------|--------|
| **[mobile-design-thinking.md](mobile-design-thinking.md)** | **⚠️ ANTI-MEMORIZATION: Forces thinking, prevents AI defaults** | **⬜ CRITICAL FIRST** |
| **[touch-psychology.md](touch-psychology.md)** | **Fitts' Law, gestures, haptics, thumb zone** | **⬜ CRITICAL** |
| **[mobile-performance.md](mobile-performance.md)** | **RN/Flutter performance, 60fps, memory** | **⬜ CRITICAL** |
| **[mobile-backend.md](mobile-backend.md)** | **Push notifications, offline sync, mobile API** | **⬜ CRITICAL** |
| **[mobile-testing.md](mobile-testing.md)** | **Testing pyramid, E2E, platform-specific** | **⬜ CRITICAL** |
| **[mobile-debugging.md](mobile-debugging.md)** | **Native vs JS debugging, Flipper, Logcat** | **⬜ CRITICAL** |
| [mobile-navigation.md](mobile-navigation.md) | Tab/Stack/Drawer, deep linking | ⬜ Read |
| [mobile-typography.md](mobile-typography.md) | System fonts, Dynamic Type, a11y | ⬜ Read |
| [mobile-color-system.md](mobile-color-system.md) | OLED, dark mode, battery-aware | ⬜ Read |
| [decision-trees.md](decision-trees.md) | Framework/state/storage selection | ⬜ Read |
> 🧠 **mobile-design-thinking.md is PRIORITY!** This file ensures AI thinks instead of using memorized patterns.
### Platform-Specific (Read Based on Target)
| Platform | File | Content | When to Read |
|----------|------|---------|--------------|
| **iOS** | [platform-ios.md](platform-ios.md) | Human Interface Guidelines, SF Pro, SwiftUI patterns | Building for iPhone/iPad |
| **Android** | [platform-android.md](platform-android.md) | Material Design 3, Roboto, Compose patterns | Building for Android |
| **Cross-Platform** | Both above | Platform divergence points | React Native / Flutter |
> 🔴 **If building for iOS → Read platform-ios.md FIRST!**
> 🔴 **If building for Android → Read platform-android.md FIRST!**
> 🔴 **If cross-platform → Read BOTH and apply conditional platform logic!**
---
## ⚠️ CRITICAL: ASK BEFORE ASSUMING (MANDATORY)
> **STOP! If the user's request is open-ended, DO NOT default to your favorites.**
### You MUST Ask If Not Specified:
| Aspect | Ask | Why |
|--------|-----|-----|
| **Platform** | "iOS, Android, or both?" | Affects EVERY design decision |
| **Framework** | "React Native, Flutter, or native?" | Determines patterns and tools |
| **Navigation** | "Tab bar, drawer, or stack-based?" | Core UX decision |
| **State** | "What state management? (Zustand/Redux/Riverpod/BLoC?)" | Architecture foundation |
| **Offline** | "Does this need to work offline?" | Affects data strategy |
| **Target devices** | "Phone only, or tablet support?" | Layout complexity |
### ⛔ AI MOBILE ANTI-PATTERNS (YASAK LİSTESİ)
> 🚫 **These are AI default tendencies that MUST be avoided!**
#### Performance Sins
| ❌ NEVER DO | Why It's Wrong | ✅ ALWAYS DO |
|-------------|----------------|--------------|
| **ScrollView for long lists** | Renders ALL items, memory explodes | Use `FlatList` / `FlashList` / `ListView.builder` |
| **Inline renderItem function** | New function every render, all items re-render | `useCallback` + `React.memo` |
| **Missing keyExtractor** | Index-based keys cause bugs on reorder | Unique, stable ID from data |
| **Skip getItemLayout** | Async layout = janky scroll | Provide when items have fixed height |
| **setState() everywhere** | Unnecessary widget rebuilds | Targeted state, `const` constructors |
| **Native driver: false** | Animations blocked by JS thread | `useNativeDriver: true` always |
| **console.log in production** | Blocks JS thread severely | Remove before release build |
| **Skip React.memo/const** | Every item re-renders on any change | Memoize list items ALWAYS |
#### Touch/UX Sins
| ❌ NEVER DO | Why It's Wrong | ✅ ALWAYS DO |
|-------------|----------------|--------------|
| **Touch target < 44px** | Impossible to tap accurately, frustrating | Minimum 44pt (iOS) / 48dp (Android) |
| **Spacing < 8px between targets** | Accidental taps on neighbors | Minimum 8-12px gap |
| **Gesture-only interactions** | Motor impaired users excluded | Always provide button alternative |
| **No loading state** | User thinks app crashed | ALWAYS show loading feedback |
| **No error state** | User stuck, no recovery path | Show error with retry option |
| **No offline handling** | Crash/block when network lost | Graceful degradation, cached data |
| **Ignore platform conventions** | Users confused, muscle memory broken | iOS feels iOS, Android feels Android |
#### Security Sins
| ❌ NEVER DO | Why It's Wrong | ✅ ALWAYS DO |
|-------------|----------------|--------------|
| **Token in AsyncStorage** | Easily accessible, stolen on rooted device | `SecureStore` / `Keychain` / `EncryptedSharedPreferences` |
| **Hardcode API keys** | Reverse engineered from APK/IPA | Environment variables, secure storage |
| **Skip SSL pinning** | MITM attacks possible | Pin certificates in production |
| **Log sensitive data** | Logs can be extracted | Never log tokens, passwords, PII |
#### Architecture Sins
| ❌ NEVER DO | Why It's Wrong | ✅ ALWAYS DO |
|-------------|----------------|--------------|
| **Business logic in UI** | Untestable, unmaintainable | Service layer separation |
| **Global state for everything** | Unnecessary re-renders, complexity | Local state default, lift when needed |
| **Deep linking as afterthought** | Notifications, shares broken | Plan deep links from day one |
| **Skip dispose/cleanup** | Memory leaks, zombie listeners | Clean up subscriptions, timers |
---
## 📱 Platform Decision Matrix
### When to Unify vs Diverge
```
UNIFY (same on both) DIVERGE (platform-specific)
─────────────────── ──────────────────────────
Business Logic ✅ Always -
Data Layer ✅ Always -
Core Features ✅ Always -
Navigation - ✅ iOS: edge swipe, Android: back button
Gestures - ✅ Platform-native feel
Icons - ✅ SF Symbols vs Material Icons
Date Pickers - ✅ Native pickers feel right
Modals/Sheets - ✅ iOS: bottom sheet vs Android: dialog
Typography - ✅ SF Pro vs Roboto (or custom)
Error Dialogs - ✅ Platform conventions for alerts
```
### Quick Reference: Platform Defaults
| Element | iOS | Android |
|---------|-----|---------|
| **Primary Font** | SF Pro / SF Compact | Roboto |
| **Min Touch Target** | 44pt × 44pt | 48dp × 48dp |
| **Back Navigation** | Edge swipe left | System back button/gesture |
| **Bottom Tab Icons** | SF Symbols | Material Symbols |
| **Action Sheet** | UIActionSheet from bottom | Bottom Sheet / Dialog |
| **Progress** | Spinner | Linear progress (Material) |
| **Pull to Refresh** | Native UIRefreshControl | SwipeRefreshLayout |
---
## 🧠 Mobile UX Psychology (Quick Reference)
### Fitts' Law for Touch
```
Desktop: Cursor is precise (1px)
Mobile: Finger is imprecise (~7mm contact area)
→ Touch targets MUST be 44-48px minimum
→ Important actions in THUMB ZONE (bottom of screen)
→ Destructive actions AWAY from easy reach
```
### Thumb Zone (One-Handed Usage)
```
┌─────────────────────────────┐
│ HARD TO REACH │ ← Navigation, menu, back
│ (stretch) │
├─────────────────────────────┤
│ OK TO REACH │ ← Secondary actions
│ (natural) │
├─────────────────────────────┤
│ EASY TO REACH │ ← PRIMARY CTAs, tab bar
│ (thumb's natural arc) │ ← Main content interaction
└─────────────────────────────┘
[ HOME ]
```
### Mobile-Specific Cognitive Load
| Desktop | Mobile Difference |
|---------|-------------------|
| Multiple windows | ONE task at a time |
| Keyboard shortcuts | Touch gestures |
| Hover states | NO hover (tap or nothing) |
| Large viewport | Limited space, scroll vertical |
| Stable attention | Interrupted constantly |
For deep dive: [touch-psychology.md](touch-psychology.md)
---
## ⚡ Performance Principles (Quick Reference)
### React Native Critical Rules
```typescript
// ✅ CORRECT: Memoized renderItem + React.memo wrapper
const ListItem = React.memo(({ item }: { item: Item }) => (
<View style={styles.item}>
<Text>{item.title}</Text>
</View>
));
const renderItem = useCallback(
({ item }: { item: Item }) => <ListItem item={item} />,
[]
);
// ✅ CORRECT: FlatList with all optimizations
<FlatList
data={items}
renderItem={renderItem}
keyExtractor={(item) => item.id} // Stable ID, NOT index
getItemLayout={(data, index) => ({
length: ITEM_HEIGHT,
offset: ITEM_HEIGHT * index,
index,
})}
removeClippedSubviews={true}
maxToRenderPerBatch={10}
windowSize={5}
/>
```
### Flutter Critical Rules
```dart
// ✅ CORRECT: const constructors prevent rebuilds
class MyWidget extends StatelessWidget {
const MyWidget({super.key}); // CONST!
@override
Widget build(BuildContext context) {
return const Column( // CONST!
children: [
Text('Static content'),
MyConstantWidget(),
],
);
}
}
// ✅ CORRECT: Targeted state with ValueListenableBuilder
ValueListenableBuilder<int>(
valueListenable: counter,
builder: (context, value, child) => Text('$value'),
child: const ExpensiveWidget(), // Won't rebuild!
)
```
### Animation Performance
```
GPU-accelerated (FAST): CPU-bound (SLOW):
├── transform ├── width, height
├── opacity ├── top, left, right, bottom
└── (use these ONLY) ├── margin, padding
└── (AVOID animating these)
```
For complete guide: [mobile-performance.md](mobile-performance.md)
---
## 📝 CHECKPOINT (MANDATORY Before Any Mobile Work)
> **Before writing ANY mobile code, you MUST complete this checkpoint:**
```
🧠 CHECKPOINT:
Platform: [ iOS / Android / Both ]
Framework: [ React Native / Flutter / SwiftUI / Kotlin ]
Files Read: [ List the skill files you've read ]
3 Principles I Will Apply:
1. _______________
2. _______________
3. _______________
Anti-Patterns I Will Avoid:
1. _______________
2. _______________
```
**Example:**
```
🧠 CHECKPOINT:
Platform: iOS + Android (Cross-platform)
Framework: React Native + Expo
Files Read: touch-psychology.md, mobile-performance.md, platform-ios.md, platform-android.md
3 Principles I Will Apply:
1. FlatList with React.memo + useCallback for all lists
2. 48px touch targets, thumb zone for primary CTAs
3. Platform-specific navigation (edge swipe iOS, back button Android)
Anti-Patterns I Will Avoid:
1. ScrollView for lists → FlatList
2. Inline renderItem → Memoized
3. AsyncStorage for tokens → SecureStore
```
> 🔴 **Can't fill the checkpoint? → GO BACK AND READ THE SKILL FILES.**
---
## 🔧 Framework Decision Tree
```
WHAT ARE YOU BUILDING?
├── Need OTA updates + rapid iteration + web team
│ └── ✅ React Native + Expo
├── Need pixel-perfect custom UI + performance critical
│ └── ✅ Flutter
├── Deep native features + single platform focus
│ ├── iOS only → SwiftUI
│ └── Android only → Kotlin + Jetpack Compose
├── Existing RN codebase + new features
│ └── ✅ React Native (bare workflow)
└── Enterprise + existing Flutter codebase
└── ✅ Flutter
```
For complete decision trees: [decision-trees.md](decision-trees.md)
---
## 📋 Pre-Development Checklist
### Before Starting ANY Mobile Project
- [ ] **Platform confirmed?** (iOS / Android / Both)
- [ ] **Framework chosen?** (RN / Flutter / Native)
- [ ] **Navigation pattern decided?** (Tabs / Stack / Drawer)
- [ ] **State management selected?** (Zustand / Redux / Riverpod / BLoC)
- [ ] **Offline requirements known?**
- [ ] **Deep linking planned from day one?**
- [ ] **Target devices defined?** (Phone / Tablet / Both)
### Before Every Screen
- [ ] **Touch targets ≥ 44-48px?**
- [ ] **Primary CTA in thumb zone?**
- [ ] **Loading state exists?**
- [ ] **Error state with retry exists?**
- [ ] **Offline handling considered?**
- [ ] **Platform conventions followed?**
### Before Release
- [ ] **console.log removed?**
- [ ] **SecureStore for sensitive data?**
- [ ] **SSL pinning enabled?**
- [ ] **Lists optimized (memo, keyExtractor)?**
- [ ] **Memory cleanup on unmount?**
- [ ] **Tested on low-end devices?**
- [ ] **Accessibility labels on all interactive elements?**
---
## 📚 Reference Files
For deeper guidance on specific areas:
| File | When to Use |
|------|-------------|
| [mobile-design-thinking.md](mobile-design-thinking.md) | **FIRST! Anti-memorization, forces context-based thinking** |
| [touch-psychology.md](touch-psychology.md) | Understanding touch interaction, Fitts' Law, gesture design |
| [mobile-performance.md](mobile-performance.md) | Optimizing RN/Flutter, 60fps, memory/battery |
| [platform-ios.md](platform-ios.md) | iOS-specific design, HIG compliance |
| [platform-android.md](platform-android.md) | Android-specific design, Material Design 3 |
| [mobile-navigation.md](mobile-navigation.md) | Navigation patterns, deep linking |
| [mobile-typography.md](mobile-typography.md) | Type scale, system fonts, accessibility |
| [mobile-color-system.md](mobile-color-system.md) | OLED optimization, dark mode, battery |
| [decision-trees.md](decision-trees.md) | Framework, state, storage decisions |
---
> **Remember:** Mobile users are impatient, interrupted, and using imprecise fingers on small screens. Design for the WORST conditions: bad network, one hand, bright sun, low battery. If it works there, it works everywhere.

View File

@@ -0,0 +1,516 @@
# Mobile Decision Trees
> Framework selection, state management, storage strategy, and context-based decisions.
> **These are THINKING guides, not copy-paste answers.**
---
## 1. Framework Selection
### Master Decision Tree
```
WHAT ARE YOU BUILDING?
├── Need OTA updates without app store review?
│ │
│ ├── Yes → React Native + Expo
│ │ ├── Expo Go for development
│ │ ├── EAS Update for production OTA
│ │ └── Best for: rapid iteration, web teams
│ │
│ └── No → Continue ▼
├── Need pixel-perfect custom UI across platforms?
│ │
│ ├── Yes → Flutter
│ │ ├── Custom rendering engine
│ │ ├── Single UI for iOS + Android
│ │ └── Best for: branded, visual apps
│ │
│ └── No → Continue ▼
├── Heavy native features (ARKit, HealthKit, specific sensors)?
│ │
│ ├── iOS only → SwiftUI / UIKit
│ │ └── Maximum native capability
│ │
│ ├── Android only → Kotlin + Jetpack Compose
│ │ └── Maximum native capability
│ │
│ └── Both → Consider native with shared logic
│ └── Kotlin Multiplatform for shared
├── Existing web team + TypeScript codebase?
│ │
│ └── Yes → React Native
│ ├── Familiar paradigm for React devs
│ ├── Share code with web (limited)
│ └── Large ecosystem
└── Enterprise with existing Flutter team?
└── Yes → Flutter
└── Leverage existing expertise
```
### Framework Comparison
| Factor | React Native | Flutter | Native (Swift/Kotlin) |
|--------|-------------|---------|----------------------|
| **OTA Updates** | ✅ Expo | ❌ No | ❌ No |
| **Learning Curve** | Low (React devs) | Medium | Higher |
| **Performance** | Good | Excellent | Best |
| **UI Consistency** | Platform-native | Identical | Platform-native |
| **Bundle Size** | Medium | Larger | Smallest |
| **Native Access** | Via bridges | Via channels | Direct |
| **Hot Reload** | ✅ | ✅ | ✅ (Xcode 15+) |
### When to Choose Native
```
CHOOSE NATIVE WHEN:
├── Maximum performance required (games, 3D)
├── Deep OS integration needed
├── Platform-specific features are core
├── Team has native expertise
├── App store presence is primary
└── Long-term maintenance priority
AVOID NATIVE WHEN:
├── Limited budget/time
├── Need rapid iteration
├── Identical UI on both platforms
├── Team is web-focused
└── Cross-platform is priority
```
---
## 2. State Management Selection
### React Native State Decision
```
WHAT'S YOUR STATE COMPLEXITY?
├── Simple app, few screens, minimal shared state
│ │
│ └── Zustand (or just useState/Context)
│ ├── Minimal boilerplate
│ ├── Easy to understand
│ └── Scales OK to medium
├── Primarily server data (API-driven)
│ │
│ └── TanStack Query (React Query) + Zustand
│ ├── Query for server state
│ ├── Zustand for UI state
│ └── Excellent caching, refetching
├── Complex app with many features
│ │
│ └── Redux Toolkit + RTK Query
│ ├── Predicable, debuggable
│ ├── RTK Query for API
│ └── Good for large teams
└── Atomic, granular state needs
└── Jotai
├── Atom-based (like Recoil)
├── Minimizes re-renders
└── Good for derived state
```
### Flutter State Decision
```
WHAT'S YOUR STATE COMPLEXITY?
├── Simple app, learning Flutter
│ │
│ └── Provider (or setState)
│ ├── Official, simple
│ ├── Built into Flutter
│ └── Good for small apps
├── Modern, type-safe, testable
│ │
│ └── Riverpod 2.0
│ ├── Compile-time safety
│ ├── Code generation
│ ├── Excellent for medium-large apps
│ └── Recommended for new projects
├── Enterprise, strict patterns needed
│ │
│ └── BLoC
│ ├── Event → State pattern
│ ├── Very testable
│ ├── More boilerplate
│ └── Good for large teams
└── Quick prototyping
└── GetX (with caution)
├── Fast to implement
├── Less strict patterns
└── Can become messy at scale
```
### State Management Anti-Patterns
```
❌ DON'T:
├── Use global state for everything
├── Mix state management approaches
├── Store server state in local state
├── Skip state normalization
├── Overuse Context (re-render heavy)
└── Put navigation state in app state
✅ DO:
├── Server state → Query library
├── UI state → Minimal, local first
├── Lift state only when needed
├── Choose ONE approach per project
└── Keep state close to where it's used
```
---
## 3. Navigation Pattern Selection
```
HOW MANY TOP-LEVEL DESTINATIONS?
├── 2 destinations
│ └── Consider: Top tabs or simple stack
├── 3-5 destinations (equal importance)
│ └── ✅ Tab Bar / Bottom Navigation
│ ├── Most common pattern
│ └── Easy discovery
├── 5+ destinations
│ │
│ ├── All important → Drawer Navigation
│ │ └── Hidden but many options
│ │
│ └── Some less important → Tab bar + drawer hybrid
└── Single linear flow?
└── Stack Navigation only
└── Onboarding, checkout, etc.
```
### Navigation by App Type
| App Type | Pattern | Reason |
|----------|---------|--------|
| Social (Instagram) | Tab bar | Frequent switching |
| E-commerce | Tab bar + stack | Categories as tabs |
| Email (Gmail) | Drawer + list-detail | Many folders |
| Settings | Stack only | Deep drill-down |
| Onboarding | Stack wizard | Linear flow |
| Messaging | Tab (chats) + stack | Threads |
---
## 4. Storage Strategy Selection
```
WHAT TYPE OF DATA?
├── Sensitive (tokens, passwords, keys)
│ │
│ └── ✅ Secure Storage
│ ├── iOS: Keychain
│ ├── Android: EncryptedSharedPreferences
│ └── RN: expo-secure-store / react-native-keychain
├── User preferences (settings, theme)
│ │
│ └── ✅ Key-Value Storage
│ ├── iOS: UserDefaults
│ ├── Android: SharedPreferences
│ └── RN: AsyncStorage / MMKV
├── Structured data (entities, relationships)
│ │
│ └── ✅ Database
│ ├── SQLite (expo-sqlite, sqflite)
│ ├── Realm (NoSQL, reactive)
│ └── WatermelonDB (large datasets)
├── Large files (images, documents)
│ │
│ └── ✅ File System
│ ├── iOS: Documents / Caches directory
│ ├── Android: Internal/External storage
│ └── RN: react-native-fs / expo-file-system
└── Cached API data
└── ✅ Query Library Cache
├── TanStack Query (RN)
├── Riverpod async (Flutter)
└── Automatic invalidation
```
### Storage Comparison
| Storage | Speed | Security | Capacity | Use Case |
|---------|-------|----------|----------|----------|
| Secure Storage | Medium | 🔒 High | Small | Tokens, secrets |
| Key-Value | Fast | Low | Medium | Settings |
| SQLite | Fast | Low | Large | Structured data |
| File System | Medium | Low | Very Large | Media, documents |
| Query Cache | Fast | Low | Medium | API responses |
---
## 5. Offline Strategy Selection
```
HOW CRITICAL IS OFFLINE?
├── Nice to have (works when possible)
│ │
│ └── Cache last data + show stale
│ ├── Simple implementation
│ ├── TanStack Query with staleTime
│ └── Show "last updated" timestamp
├── Essential (core functionality offline)
│ │
│ └── Offline-first architecture
│ ├── Local database as source of truth
│ ├── Sync to server when online
│ ├── Conflict resolution strategy
│ └── Queue actions for later sync
└── Real-time critical (collaboration, chat)
└── WebSocket + local queue
├── Optimistic updates
├── Eventual consistency
└── Complex conflict handling
```
### Offline Implementation Patterns
```
1. CACHE-FIRST (Simple)
Request → Check cache → If stale, fetch → Update cache
2. STALE-WHILE-REVALIDATE
Request → Return cached → Fetch update → Update UI
3. OFFLINE-FIRST (Complex)
Action → Write to local DB → Queue sync → Sync when online
4. SYNC ENGINE
Use: Firebase, Realm Sync, Supabase realtime
Handles conflict resolution automatically
```
---
## 6. Authentication Pattern Selection
```
WHAT AUTH TYPE NEEDED?
├── Simple email/password
│ │
│ └── Token-based (JWT)
│ ├── Store refresh token securely
│ ├── Access token in memory
│ └── Silent refresh flow
├── Social login (Google, Apple, etc.)
│ │
│ └── OAuth 2.0 + PKCE
│ ├── Use platform SDKs
│ ├── Deep link callback
│ └── Apple Sign-In required for iOS
├── Enterprise/SSO
│ │
│ └── OIDC / SAML
│ ├── Web view or system browser
│ └── Handle redirect properly
└── Biometric (FaceID, fingerprint)
└── Local auth + secure token
├── Biometrics unlock stored token
├── Not a replacement for server auth
└── Fallback to PIN/password
```
### Auth Token Storage
```
❌ NEVER store tokens in:
├── AsyncStorage (plain text)
├── Redux/state (not persisted correctly)
├── Local storage equivalent
└── Logs or debug output
✅ ALWAYS store tokens in:
├── iOS: Keychain
├── Android: EncryptedSharedPreferences
├── Expo: SecureStore
├── Biometric-protected if available
```
---
## 7. Project Type Templates
### E-Commerce App
```
RECOMMENDED STACK:
├── Framework: React Native + Expo (OTA for pricing)
├── Navigation: Tab bar (Home, Search, Cart, Account)
├── State: TanStack Query (products) + Zustand (cart)
├── Storage: SecureStore (auth) + SQLite (cart cache)
├── Offline: Cache products, queue cart actions
└── Auth: Email/password + Social + Apple Pay
KEY DECISIONS:
├── Product images: Lazy load, cache aggressively
├── Cart: Sync across devices via API
├── Checkout: Secure, minimal steps
└── Deep links: Product shares, marketing
```
### Social/Content App
```
RECOMMENDED STACK:
├── Framework: React Native or Flutter
├── Navigation: Tab bar (Feed, Search, Create, Notifications, Profile)
├── State: TanStack Query (feed) + Zustand (UI)
├── Storage: SQLite (feed cache, drafts)
├── Offline: Cache feed, queue posts
└── Auth: Social login primary, Apple required
KEY DECISIONS:
├── Feed: Infinite scroll, memoized items
├── Media: Upload queuing, background upload
├── Push: Deep link to content
└── Real-time: WebSocket for notifications
```
### Productivity/SaaS App
```
RECOMMENDED STACK:
├── Framework: Flutter (consistent UI) or RN
├── Navigation: Drawer or Tab bar
├── State: Riverpod/BLoC or Redux Toolkit
├── Storage: SQLite (offline), SecureStore (auth)
├── Offline: Full offline editing, sync
└── Auth: SSO/OIDC for enterprise
KEY DECISIONS:
├── Data sync: Conflict resolution strategy
├── Collaborative: Real-time or eventual?
├── Files: Large file handling
└── Enterprise: MDM, compliance
```
---
## 8. Decision Checklist
### Before Starting ANY Project
- [ ] Target platforms defined (iOS/Android/both)?
- [ ] Framework selected based on criteria?
- [ ] State management approach chosen?
- [ ] Navigation pattern selected?
- [ ] Storage strategy for each data type?
- [ ] Offline requirements defined?
- [ ] Auth flow designed?
- [ ] Deep linking planned from start?
### Questions to Ask User
```
If project details are vague, ASK:
1. "Will this need OTA updates without app store review?"
→ Affects framework choice (Expo = yes)
2. "Do iOS and Android need identical UI?"
→ Affects framework (Flutter = identical)
3. "What's the offline requirement?"
→ Affects architecture complexity
4. "Is there an existing backend/auth system?"
→ Affects auth and API approach
5. "What devices? Phone only, or tablet?"
→ Affects navigation and layout
6. "Enterprise or consumer?"
→ Affects auth (SSO), security, compliance
```
---
## 9. Anti-Pattern Decisions
### ❌ Decision Anti-Patterns
| Anti-Pattern | Why It's Bad | Better Approach |
|--------------|--------------|-----------------|
| **Redux for simple app** | Massive overkill | Zustand or context |
| **Native for MVP** | Slow development | Cross-platform MVP |
| **Drawer for 3 sections** | Hidden navigation | Tab bar |
| **AsyncStorage for tokens** | Insecure | SecureStore |
| **No offline consideration** | Broken on subway | Plan from start |
| **Same stack for all projects** | Doesn't fit context | Evaluate per project |
---
## 10. Quick Reference
### Framework Quick Pick
```
OTA needed? → React Native + Expo
Identical UI? → Flutter
Maximum performance? → Native
Web team? → React Native
Quick prototype? → Expo
```
### State Quick Pick
```
Simple app? → Zustand / Provider
Server-heavy? → TanStack Query / Riverpod
Enterprise? → Redux / BLoC
Atomic state? → Jotai
```
### Storage Quick Pick
```
Secrets? → SecureStore / Keychain
Settings? → AsyncStorage / UserDefaults
Structured data? → SQLite
API cache? → Query library
```
---
> **Remember:** These trees are guides for THINKING, not rules to follow blindly. Every project has unique constraints. ASK clarifying questions when requirements are vague, and choose based on actual needs, not defaults.

View File

@@ -0,0 +1,491 @@
# Mobile Backend Patterns
> **This file covers backend/API patterns SPECIFIC to mobile clients.**
> Generic backend patterns are in `nodejs-best-practices` and `api-patterns`.
> **Mobile backend is NOT the same as web backend. Different constraints, different patterns.**
---
## 🧠 MOBILE BACKEND MINDSET
```
Mobile clients are DIFFERENT from web clients:
├── Unreliable network (2G, subway, elevator)
├── Battery constraints (minimize wake-ups)
├── Limited storage (can't cache everything)
├── Interrupted sessions (calls, notifications)
├── Diverse devices (old phones to flagships)
└── Binary updates are slow (App Store review)
```
**Your backend must compensate for ALL of these.**
---
## 🚫 AI MOBILE BACKEND ANTI-PATTERNS
### These are common AI mistakes when building mobile backends:
| ❌ AI Default | Why It's Wrong | ✅ Mobile-Correct |
|---------------|----------------|-------------------|
| Same API for web and mobile | Mobile needs compact responses | Separate mobile endpoints OR field selection |
| Full object responses | Wastes bandwidth, battery | Partial responses, pagination |
| No offline consideration | App crashes without network | Offline-first design, sync queues |
| WebSocket for everything | Battery drain | Push notifications + polling fallback |
| No app versioning | Can't force updates, breaking changes | Version headers, minimum version check |
| Generic error messages | Users can't fix issues | Mobile-specific error codes + recovery actions |
| Session-based auth | Mobile apps restart | Token-based with refresh |
| Ignore device info | Can't debug issues | Device ID, app version in headers |
---
## 1. Push Notifications
### Platform Architecture
```
┌─────────────────────────────────────────────────────────────────┐
│ YOUR BACKEND │
├─────────────────────────────────────────────────────────────────┤
│ │ │
│ ┌──────────┴──────────┐ │
│ ▼ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ FCM (Google) │ │ APNs (Apple) │ │
│ │ Firebase │ │ Direct or FCM │ │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Android Device │ │ iOS Device │ │
│ └─────────────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
```
### Push Types
| Type | Use Case | User Sees |
|------|----------|-----------|
| **Display** | New message, order update | Notification banner |
| **Silent** | Background sync, content update | Nothing (background) |
| **Data** | Custom handling by app | Depends on app logic |
### Anti-Patterns
| ❌ NEVER | ✅ ALWAYS |
|----------|----------|
| Send sensitive data in push | Push says "New message", app fetches content |
| Overload with pushes | Batch, dedupe, respect quiet hours |
| Same message to all | Segment by user preference, timezone |
| Ignore failed tokens | Clean up invalid tokens regularly |
| Skip APNs for iOS | FCM alone doesn't guarantee iOS delivery |
### Token Management
```
TOKEN LIFECYCLE:
├── App registers → Get token → Send to backend
├── Token can change → App must re-register on start
├── Token expires → Clean from database
├── User uninstalls → Token becomes invalid (detect via error)
└── Multiple devices → Store multiple tokens per user
```
---
## 2. Offline Sync & Conflict Resolution
### Sync Strategy Selection
```
WHAT TYPE OF DATA?
├── Read-only (news, catalog)
│ └── Simple cache + TTL
│ └── ETag/Last-Modified for invalidation
├── User-owned (notes, todos)
│ └── Last-write-wins (simple)
│ └── Or timestamp-based merge
├── Collaborative (shared docs)
│ └── CRDT or OT required
│ └── Consider Firebase/Supabase
└── Critical (payments, inventory)
└── Server is source of truth
└── Optimistic UI + server confirmation
```
### Conflict Resolution Strategies
| Strategy | How It Works | Best For |
|----------|--------------|----------|
| **Last-write-wins** | Latest timestamp overwrites | Simple data, single user |
| **Server-wins** | Server always authoritative | Critical transactions |
| **Client-wins** | Offline changes prioritized | Offline-heavy apps |
| **Merge** | Combine changes field-by-field | Documents, rich content |
| **CRDT** | Mathematically conflict-free | Real-time collaboration |
### Sync Queue Pattern
```
CLIENT SIDE:
├── User makes change → Write to local DB
├── Add to sync queue → { action, data, timestamp, retries }
├── Network available → Process queue FIFO
├── Success → Remove from queue
├── Failure → Retry with backoff (max 5 retries)
└── Conflict → Apply resolution strategy
SERVER SIDE:
├── Accept change with client timestamp
├── Compare with server version
├── Apply conflict resolution
├── Return merged state
└── Client updates local with server response
```
---
## 3. Mobile API Optimization
### Response Size Reduction
| Technique | Savings | Implementation |
|-----------|---------|----------------|
| **Field selection** | 30-70% | `?fields=id,name,thumbnail` |
| **Compression** | 60-80% | gzip/brotli (automatic) |
| **Pagination** | Varies | Cursor-based for mobile |
| **Image variants** | 50-90% | `/image?w=200&q=80` |
| **Delta sync** | 80-95% | Only changed records since timestamp |
### Pagination: Cursor vs Offset
```
OFFSET (Bad for mobile):
├── Page 1: OFFSET 0 LIMIT 20
├── Page 2: OFFSET 20 LIMIT 20
├── Problem: New item added → duplicates!
└── Problem: Large offset = slow query
CURSOR (Good for mobile):
├── First: ?limit=20
├── Next: ?limit=20&after=cursor_abc123
├── Cursor = encoded (id + sort values)
├── No duplicates on data changes
└── Consistent performance
```
### Batch Requests
```
Instead of:
GET /users/1
GET /users/2
GET /users/3
(3 round trips, 3x latency)
Use:
POST /batch
{ requests: [
{ method: "GET", path: "/users/1" },
{ method: "GET", path: "/users/2" },
{ method: "GET", path: "/users/3" }
]}
(1 round trip)
```
---
## 4. App Versioning
### Version Check Endpoint
```
GET /api/app-config
Headers:
X-App-Version: 2.1.0
X-Platform: ios
X-Device-ID: abc123
Response:
{
"minimum_version": "2.0.0",
"latest_version": "2.3.0",
"force_update": false,
"update_url": "https://apps.apple.com/...",
"feature_flags": {
"new_player": true,
"dark_mode": true
},
"maintenance": false,
"maintenance_message": null
}
```
### Version Comparison Logic
```
CLIENT VERSION vs MINIMUM VERSION:
├── client >= minimum → Continue normally
├── client < minimum → Show force update screen
│ └── Block app usage until updated
└── client < latest → Show optional update prompt
FEATURE FLAGS:
├── Enable/disable features without app update
├── A/B testing by version/device
└── Gradual rollout (10% → 50% → 100%)
```
---
## 5. Authentication for Mobile
### Token Strategy
```
ACCESS TOKEN:
├── Short-lived (15 min - 1 hour)
├── Stored in memory (not persistent)
├── Used for API requests
└── Refresh when expired
REFRESH TOKEN:
├── Long-lived (30-90 days)
├── Stored in SecureStore/Keychain
├── Used only to get new access token
└── Rotate on each use (security)
DEVICE TOKEN:
├── Identifies this device
├── Allows "log out all devices"
├── Stored alongside refresh token
└── Server tracks active devices
```
### Silent Re-authentication
```
REQUEST FLOW:
├── Make request with access token
├── 401 Unauthorized?
│ ├── Have refresh token?
│ │ ├── Yes → Call /auth/refresh
│ │ │ ├── Success → Retry original request
│ │ │ └── Failure → Force logout
│ │ └── No → Force logout
│ └── Token just expired (not invalid)
│ └── Auto-refresh, user doesn't notice
└── Success → Continue
```
---
## 6. Error Handling for Mobile
### Mobile-Specific Error Format
```json
{
"error": {
"code": "PAYMENT_DECLINED",
"message": "Your payment was declined",
"user_message": "Please check your card details or try another payment method",
"action": {
"type": "navigate",
"destination": "payment_methods"
},
"retry": {
"allowed": true,
"after_seconds": 5
}
}
}
```
### Error Categories
| Code Range | Category | Mobile Handling |
|------------|----------|-----------------|
| 400-499 | Client error | Show message, user action needed |
| 401 | Auth expired | Silent refresh or re-login |
| 403 | Forbidden | Show upgrade/permission screen |
| 404 | Not found | Remove from local cache |
| 409 | Conflict | Show sync conflict UI |
| 429 | Rate limit | Retry after header, backoff |
| 500-599 | Server error | Retry with backoff, show "try later" |
| Network | No connection | Use cached data, queue for sync |
---
## 7. Media & Binary Handling
### Image Optimization
```
CLIENT REQUEST:
GET /images/{id}?w=400&h=300&q=80&format=webp
SERVER RESPONSE:
├── Resize on-the-fly OR use CDN
├── WebP for Android (smaller)
├── HEIC for iOS 14+ (if supported)
├── JPEG fallback
└── Cache-Control: max-age=31536000
```
### Chunked Upload (Large Files)
```
UPLOAD FLOW:
1. POST /uploads/init
{ filename, size, mime_type }
→ { upload_id, chunk_size }
2. PUT /uploads/{upload_id}/chunks/{n}
→ Upload each chunk (1-5 MB)
→ Can resume if interrupted
3. POST /uploads/{upload_id}/complete
→ Server assembles chunks
→ Return final file URL
```
### Streaming Audio/Video
```
REQUIREMENTS:
├── HLS (HTTP Live Streaming) for iOS
├── DASH or HLS for Android
├── Multiple quality levels (adaptive bitrate)
├── Range request support (seeking)
└── Offline download chunks
ENDPOINTS:
GET /media/{id}/manifest.m3u8 → HLS manifest
GET /media/{id}/segment_{n}.ts → Video segment
GET /media/{id}/download → Full file for offline
```
---
## 8. Security for Mobile
### Device Attestation
```
VERIFY REAL DEVICE (not emulator/bot):
├── iOS: DeviceCheck API
│ └── Server verifies with Apple
├── Android: Play Integrity API (replaces SafetyNet)
│ └── Server verifies with Google
└── Fail closed: Reject if attestation fails
```
### Request Signing
```
CLIENT:
├── Create signature = HMAC(timestamp + path + body, secret)
├── Send: X-Signature: {signature}
├── Send: X-Timestamp: {timestamp}
└── Send: X-Device-ID: {device_id}
SERVER:
├── Validate timestamp (within 5 minutes)
├── Recreate signature with same inputs
├── Compare signatures
└── Reject if mismatch (tampering detected)
```
### Rate Limiting
```
MOBILE-SPECIFIC LIMITS:
├── Per device (X-Device-ID)
├── Per user (after auth)
├── Per endpoint (stricter for sensitive)
└── Sliding window preferred
HEADERS:
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1609459200
Retry-After: 60 (when 429)
```
---
## 9. Monitoring & Analytics
### Required Headers from Mobile
```
Every mobile request should include:
├── X-App-Version: 2.1.0
├── X-Platform: ios | android
├── X-OS-Version: 17.0
├── X-Device-Model: iPhone15,2
├── X-Device-ID: uuid (persistent)
├── X-Request-ID: uuid (per request, for tracing)
├── Accept-Language: tr-TR
└── X-Timezone: Europe/Istanbul
```
### What to Log
```
FOR EACH REQUEST:
├── All headers above
├── Endpoint, method, status
├── Response time
├── Error details (if any)
└── User ID (if authenticated)
ALERTS:
├── Error rate > 5% per version
├── P95 latency > 2 seconds
├── Specific version crash spike
├── Auth failure spike (attack?)
└── Push delivery failure spike
```
---
## 📝 MOBILE BACKEND CHECKLIST
### Before API Design
- [ ] Identified mobile-specific requirements?
- [ ] Planned offline behavior?
- [ ] Designed sync strategy?
- [ ] Considered bandwidth constraints?
### For Every Endpoint
- [ ] Response as small as possible?
- [ ] Pagination cursor-based?
- [ ] Proper caching headers?
- [ ] Mobile error format with actions?
### Authentication
- [ ] Token refresh implemented?
- [ ] Silent re-auth flow?
- [ ] Multi-device logout?
- [ ] Secure token storage guidance?
### Push Notifications
- [ ] FCM + APNs configured?
- [ ] Token lifecycle managed?
- [ ] Silent vs display push defined?
- [ ] Sensitive data NOT in push payload?
### Release
- [ ] Version check endpoint ready?
- [ ] Feature flags configured?
- [ ] Force update mechanism?
- [ ] Monitoring headers required?
---
> **Remember:** Mobile backend must be resilient to bad networks, respect battery life, and handle interrupted sessions gracefully. The client cannot be trusted, but it also cannot be hung up—provide offline capabilities and clear error recovery paths.

View File

@@ -0,0 +1,420 @@
# Mobile Color System Reference
> OLED optimization, dark mode, battery-aware colors, and outdoor visibility.
> **Color on mobile isn't just aesthetics—it's battery life and usability.**
---
## 1. Mobile Color Fundamentals
### Why Mobile Color is Different
```
DESKTOP: MOBILE:
├── LCD screens (backlit) ├── OLED common (self-emissive)
├── Controlled lighting ├── Outdoor, bright sun
├── Stable power ├── Battery matters
├── Personal preference ├── System-wide dark mode
└── Static viewing └── Variable angles, motion
```
### Mobile Color Priorities
| Priority | Why |
|----------|-----|
| **1. Readability** | Outdoor, variable lighting |
| **2. Battery efficiency** | OLED = dark mode saves power |
| **3. System integration** | Dark/light mode support |
| **4. Semantics** | Error, success, warning colors |
| **5. Brand** | After functional requirements |
---
## 2. OLED Considerations
### How OLED Differs
```
LCD (Liquid Crystal Display):
├── Backlight always on
├── Black = backlight through dark filter
├── Energy use = constant
└── Dark mode = no battery savings
OLED (Organic LED):
├── Each pixel emits own light
├── Black = pixel OFF (zero power)
├── Energy use = brighter pixels use more
└── Dark mode = significant battery savings
```
### Battery Savings with OLED
```
Color energy consumption (relative):
#000000 (True Black) ████░░░░░░ 0%
#1A1A1A (Near Black) █████░░░░░ ~15%
#333333 (Dark Gray) ██████░░░░ ~30%
#666666 (Medium Gray) ███████░░░ ~50%
#FFFFFF (White) ██████████ 100%
Saturated colors also use significant power:
├── Blue pixels: Most efficient
├── Green pixels: Medium
├── Red pixels: Least efficient
└── Desaturated colors save more
```
### True Black vs Near Black
```
#000000 (True Black):
├── Maximum battery savings
├── Can cause "black smear" on scroll
├── Sharp contrast (may be harsh)
└── Used by Apple in pure dark mode
#121212 or #1A1A1A (Near Black):
├── Still good battery savings
├── Smoother scrolling (no smear)
├── Slightly softer on eyes
└── Material Design recommendation
RECOMMENDATION: #000000 for backgrounds, #0D0D0D-#1A1A1A for surfaces
```
---
## 3. Dark Mode Design
### Dark Mode Benefits
```
Users enable dark mode for:
├── Battery savings (OLED)
├── Reduced eye strain (low light)
├── Personal preference
├── AMOLED aesthetic
└── Accessibility (light sensitivity)
```
### Dark Mode Color Strategy
```
LIGHT MODE DARK MODE
────────── ─────────
Background: #FFFFFF → #000000 or #121212
Surface: #F5F5F5 → #1E1E1E
Surface 2: #EEEEEE → #2C2C2C
Primary: #1976D2 → #90CAF9 (lighter)
Text: #212121 → #E0E0E0 (not pure white)
Secondary: #757575 → #9E9E9E
Elevation in dark mode:
├── Higher = slightly lighter surface
├── 0dp → 0% overlay
├── 4dp → 9% overlay
├── 8dp → 12% overlay
└── Creates depth without shadows
```
### Text Colors in Dark Mode
| Role | Light Mode | Dark Mode |
|------|------------|-----------|
| Primary | #000000 (Black) | #E8E8E8 (Not pure white) |
| Secondary | #666666 | #B0B0B0 |
| Disabled | #9E9E9E | #6E6E6E |
| Links | #1976D2 | #8AB4F8 |
### Color Inversion Rules
```
DON'T just invert colors:
├── Saturated colors become eye-burning
├── Semantic colors lose meaning
├── Brand colors may break
└── Contrast ratios change unpredictably
DO create intentional dark palette:
├── Desaturate primary colors
├── Use lighter tints for emphasis
├── Maintain semantic color meanings
├── Check contrast ratios independently
```
---
## 4. Outdoor Visibility
### The Sunlight Problem
```
Screen visibility outdoors:
├── Bright sun washes out low contrast
├── Glare reduces readability
├── Polarized sunglasses affect
└── Users shield screen with hand
Affected elements:
├── Light gray text on white
├── Subtle color differences
├── Low opacity overlays
└── Pastel colors
```
### High Contrast Strategies
```
For outdoor visibility:
MINIMUM CONTRAST RATIOS:
├── Normal text: 4.5:1 (WCAG AA)
├── Large text: 3:1 (WCAG AA)
├── Recommended: 7:1+ (AAA)
AVOID:
├── #999 on #FFF (fails AA)
├── #BBB on #FFF (fails)
├── Pale colors on light backgrounds
└── Subtle gradients for critical info
DO:
├── Use system semantic colors
├── Test in bright environment
├── Provide high contrast mode
└── Use solid colors for critical UI
```
---
## 5. Semantic Colors
### Consistent Meaning
| Semantic | Meaning | iOS Default | Android Default |
|----------|---------|-------------|-----------------|
| Error | Problems, destruction | #FF3B30 | #B3261E |
| Success | Completion, positive | #34C759 | #4CAF50 |
| Warning | Attention, caution | #FF9500 | #FFC107 |
| Info | Information | #007AFF | #2196F3 |
### Semantic Color Rules
```
NEVER use semantic colors for:
├── Branding (confuses meaning)
├── Decoration (reduces impact)
├── Arbitrary styling
└── Status indicators (use icons too)
ALWAYS:
├── Pair with icons (colorblind users)
├── Maintain across light/dark modes
├── Keep consistent throughout app
└── Follow platform conventions
```
### Error State Colors
```
Error states need:
├── Red-ish color (semantic)
├── High contrast against background
├── Icon reinforcement
├── Clear text explanation
iOS:
├── Light: #FF3B30
├── Dark: #FF453A
Android:
├── Light: #B3261E
├── Dark: #F2B8B5 (on error container)
```
---
## 6. Dynamic Color (Android)
### Material You
```
Android 12+ Dynamic Color:
User's wallpaper → Color extraction → App theme
Your app automatically gets:
├── Primary (from wallpaper dominant)
├── Secondary (complementary)
├── Tertiary (accent)
├── Surface colors (neutral, derived)
├── On-colors (text on each)
```
### Supporting Dynamic Color
```kotlin
// Jetpack Compose
MaterialTheme(
colorScheme = dynamicColorScheme()
?: staticColorScheme() // Fallback for older Android
)
// React Native
// Limited support - consider react-native-material-you
```
### Fallback Colors
```
When dynamic color unavailable:
├── Android < 12
├── User disabled
├── Non-supporting launchers
Provide static color scheme:
├── Define your brand colors
├── Test in both modes
├── Match dynamic color roles
└── Support light + dark
```
---
## 7. Color Accessibility
### Colorblind Considerations
```
~8% of men, ~0.5% of women are colorblind
Types:
├── Protanopia (red weakness)
├── Deuteranopia (green weakness)
├── Tritanopia (blue weakness)
├── Monochromacy (rare, no color)
Design rules:
├── Never rely on color alone
├── Use patterns, icons, text
├── Test with simulation tools
├── Avoid red/green distinctions only
```
### Contrast Testing Tools
```
Use these to verify:
├── Built-in accessibility inspector (Xcode)
├── Accessibility Scanner (Android)
├── Contrast ratio calculators
├── Colorblind simulation
└── Test on actual devices in sunlight
```
### Sufficient Contrast
```
WCAG Guidelines:
AA (Minimum)
├── Normal text: 4.5:1
├── Large text (18pt+): 3:1
├── UI components: 3:1
AAA (Enhanced)
├── Normal text: 7:1
├── Large text: 4.5:1
Mobile recommendation: Meet AA, aim for AAA
```
---
## 8. Color Anti-Patterns
### ❌ Common Mistakes
| Mistake | Problem | Fix |
|---------|---------|-----|
| **Light gray on white** | Invisible outdoors | Min 4.5:1 contrast |
| **Pure white in dark mode** | Eye strain | Use #E0E0E0-#F0F0F0 |
| **Same saturation dark mode** | Garish, glowing | Desaturate colors |
| **Red/green only indicator** | Colorblind users can't see | Add icons |
| **Semantic colors for brand** | Confusing meaning | Use neutral for brand |
| **Ignoring system dark mode** | Jarring experience | Support both modes |
### ❌ AI Color Mistakes
```
AI tends to:
├── Use same colors for light/dark
├── Ignore OLED battery implications
├── Skip contrast calculations
├── Default to purple/violet (BANNED)
├── Use low contrast "aesthetic" grays
├── Not test in outdoor conditions
└── Forget colorblind users
RULE: Design for the worst case.
Test in bright sunlight, with colorblindness simulation.
```
---
## 9. Color System Checklist
### Before Choosing Colors
- [ ] Light and dark mode variants defined?
- [ ] Contrast ratios checked (4.5:1+)?
- [ ] OLED battery considered (dark mode)?
- [ ] Semantic colors follow conventions?
- [ ] Colorblind-safe (not color-only indicators)?
### Before Release
- [ ] Tested in bright sunlight?
- [ ] Tested dark mode on OLED device?
- [ ] System dark mode respected?
- [ ] Dynamic color supported (Android)?
- [ ] Error/success/warning consistent?
- [ ] All text meets contrast requirements?
---
## 10. Quick Reference
### Dark Mode Backgrounds
```
True black (OLED max savings): #000000
Near black (Material): #121212
Surface 1: #1E1E1E
Surface 2: #2C2C2C
Surface 3: #3C3C3C
```
### Text on Dark
```
Primary: #E0E0E0 to #ECECEC
Secondary: #A0A0A0 to #B0B0B0
Disabled: #606060 to #707070
```
### Contrast Ratios
```
Small text: 4.5:1 (minimum)
Large text: 3:1 (minimum)
UI elements: 3:1 (minimum)
Ideal: 7:1 (AAA)
```
---
> **Remember:** Color on mobile must work in the worst conditions—bright sun, tired eyes, colorblindness, low battery. Pretty colors that fail these tests are useless colors.

View File

@@ -0,0 +1,122 @@
# Mobile Debugging Guide
> **Stop console.log() debugging!**
> Mobile apps have complex native layers. Text logs are not enough.
> **This file teaches effective mobile debugging strategies.**
---
## 🧠 MOBILE DEBUGGING MINDSET
```
Web Debugging: Mobile Debugging:
┌──────────────┐ ┌──────────────┐
│ Browser │ │ JS Bridge │
│ DevTools │ │ Native UI │
│ Network Tab │ │ GPU/Memory │
└──────────────┘ │ Threads │
└──────────────┘
```
**Key Differences:**
1. **Native Layer:** JS code works, but app crashes? It's likely native (Java/Obj-C).
2. **Deployment:** You can't just "refresh". State gets lost or stuck.
3. **Network:** SSL Pinning, proxy settings are harder.
4. **Device Logs:** `adb logcat` and `Console.app` are your truth.
---
## 🚫 AI DEBUGGING ANTI-PATTERNS
| ❌ Default | ✅ Mobile-Correct |
|------------|-------------------|
| "Add console.logs" | Use Flipper / Reactotron |
| "Check network tab" | Use Charles Proxy / Proxyman |
| "It works on simulator" | **Test on Real Device** (HW specific bugs) |
| "Reinstall node_modules" | **Clean Native Build** (Gradle/Pod cache) |
| Ignored native logs | Read `logcat` / Xcode logs |
---
## 1. The Toolset
### ⚡ React Native & Expo
| Tool | Purpose | Best For |
|------|---------|----------|
| **Reactotron** | State/API/Redux | JS side debugging |
| **Flipper** | Layout/Network/db | Native + JS bridge |
| **Expo Tools** | Element inspector | Quick UI checks |
### 🛠️ Native Layer (The Deep Dive)
| Tool | Platform | Command | Why Use? |
|------|----------|---------|----------|
| **Logcat** | Android | `adb logcat` | Native crashes, ANRs |
| **Console** | iOS | via Xcode | Native exceptions, memory |
| **Layout Insp.** | Android | Android Studio | UI hierarchy bugs |
| **View Insp.** | iOS | Xcode | UI hierarchy bugs |
---
## 2. Common Debugging Workflows
### 🕵️ "The App Just Crashed" (Red Screen vs Crash to Home)
**Scenario A: Red Screen (JS Error)**
- **Cause:** Undefined is not an object, import error.
- **Fix:** Read the stack trace on screen. It's usually clear.
**Scenario B: Crash to Home Screen (Native Crash)**
- **Cause:** Native module failure, memory OOM, permission usage without declaration.
- **Tools:**
- **Android:** `adb logcat *:E` (Filter for Errors)
- **iOS:** Open Xcode → Window → Devices → View Device Logs
> **💡 Pro Tip:** If app crashes immediately on launch, it's almost 100% a native configuration issue (Info.plist, AndroidManifest.xml).
### 🌐 "API Request Failed" (Network)
**Web:** Open Chrome DevTools → Network.
**Mobile:** *You usually can't see this easily.*
**Solution 1: Reactotron/Flipper**
- View network requests in the monitoring app.
**Solution 2: Proxy (Charles/Proxyman)**
- **Hard but powerful.** See ALL traffic even from native SDKs.
- Requires installing SSL cert on device.
### 🐢 "The UI is Laggy" (Performance)
**Don't guess.** measure.
- **React Native:** Performance Monitor (Shake menu).
- **Android:** "Profile GPU Rendering" in Developer Options.
- **Issues:**
- **JS FPS drop:** Heavy calculation in JS thread.
- **UI FPS drop:** Too many views, intricate hierarchy, heavy images.
---
## 3. Platform-Specific Nightmares
### Android
- **Gradle Sync Fail:** Usually Java version mismatch or duplicate classes.
- **Emulator Network:** Emulator `localhost` is `10.0.2.2`, NOT `127.0.0.1`.
- **Cached Builds:** `./gradlew clean` is your best friend.
### iOS
- **Pod Issues:** `pod deintegrate && pod install`.
- **Signing Errors:** Check Team ID and Bundle Identifier.
- **Cache:** Xcode → Product → Clean Build Folder.
---
## 📝 DEBUGGING CHECKLIST
- [ ] **Is it a JS or Native crash?** (Red screen or home screen?)
- [ ] **Did you clean build?** (Native caches are aggressive)
- [ ] **Are you on a real device?** (Simulators hide concurrency bugs)
- [ ] **Did you check the native logs?** (Not just terminal output)
> **Remember:** If JavaScript looks perfect but the app fails, look closer at the Native side.

View File

@@ -0,0 +1,357 @@
# Mobile Design Thinking
> **This file prevents AI from using memorized patterns and forces genuine thinking.**
> Mechanisms to prevent standard AI training defaults in mobile development.
> **The mobile equivalent of frontend's layout decomposition approach.**
---
## 🧠 DEEP MOBILE THINKING PROTOCOL
### This Process is Mandatory Before Every Mobile Project
```
┌─────────────────────────────────────────────────────────────────┐
│ DEEP MOBILE THINKING │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1⃣ CONTEXT SCAN │
│ └── What are my assumptions for this project? │
│ └── QUESTION these assumptions │
│ │
│ 2⃣ ANTI-DEFAULT ANALYSIS │
│ └── Am I applying a memorized pattern? │
│ └── Is this pattern REALLY the best for THIS project? │
│ │
│ 3⃣ PLATFORM DECOMPOSITION │
│ └── Did I think about iOS and Android separately? │
│ └── What are the platform-specific patterns? │
│ │
│ 4⃣ TOUCH INTERACTION BREAKDOWN │
│ └── Did I analyze each interaction individually? │
│ └── Did I apply Fitts' Law, Thumb Zone? │
│ │
│ 5⃣ PERFORMANCE IMPACT ANALYSIS │
│ └── Did I consider performance impact of each component? │
│ └── Is the default solution performant? │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## 🚫 AI MOBILE DEFAULTS (FORBIDDEN LIST)
### Using These Patterns Automatically is FORBIDDEN!
The following patterns are "defaults" that AIs learned from training data.
Before using any of these, **QUESTION them and CONSIDER ALTERNATIVES!**
```
┌─────────────────────────────────────────────────────────────────┐
│ 🚫 AI MOBILE SAFE HARBOR │
│ (Default Patterns - Never Use Without Questioning) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ NAVIGATION DEFAULTS: │
│ ├── Tab bar for every project (Would drawer be better?) │
│ ├── Fixed 5 tabs (Are 3 enough? For 6+, drawer?) │
│ ├── "Home" tab on left (What does user behavior say?) │
│ └── Hamburger menu (Is it outdated now?) │
│ │
│ STATE MANAGEMENT DEFAULTS: │
│ ├── Redux everywhere (Is Zustand/Jotai sufficient?) │
│ ├── Global state for everything (Isn't local state enough?) │
│ ├── Context Provider hell (Is atom-based better?) │
│ └── BLoC for every Flutter project (Is Riverpod more modern?) │
│ │
│ LIST IMPLEMENTATION DEFAULTS: │
│ ├── FlatList as default (Is FlashList more performant?) │
│ ├── windowSize=21 (Is it really needed?) │
│ ├── removeClippedSubviews (Always?) │
│ └── ListView.builder (Is ListView.separated better?) │
│ │
│ UI PATTERN DEFAULTS: │
│ ├── FAB bottom-right (Is bottom-left more accessible?) │
│ ├── Pull-to-refresh on every list (Is it needed everywhere?) │
│ ├── Swipe-to-delete from left (Is right better?) │
│ └── Bottom sheet for every modal (Is full screen better?) │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## 🔍 COMPONENT DECOMPOSITION (MANDATORY)
### Decomposition Analysis for Every Screen
Before designing any screen, perform this analysis:
```
SCREEN: [Screen Name]
├── PRIMARY ACTION: [What is the main action?]
│ └── Is it in thumb zone? [Yes/No → Why?]
├── TOUCH TARGETS: [All tappable elements]
│ ├── [Element 1]: [Size]pt → Sufficient?
│ ├── [Element 2]: [Size]pt → Sufficient?
│ └── Spacing: [Gap]pt → Accidental tap risk?
├── SCROLLABLE CONTENT:
│ ├── Is it a list? → FlatList/FlashList [Why this choice?]
│ ├── Item count: ~[N] → Performance consideration?
│ └── Fixed height? → Is getItemLayout needed?
├── STATE REQUIREMENTS:
│ ├── Is local state sufficient?
│ ├── Do I need to lift state?
│ └── Is global required? [Why?]
├── PLATFORM DIFFERENCES:
│ ├── iOS: [Anything different needed?]
│ └── Android: [Anything different needed?]
├── OFFLINE CONSIDERATION:
│ ├── Should this screen work offline?
│ └── Cache strategy: [Yes/No/Which one?]
└── PERFORMANCE IMPACT:
├── Any heavy components?
├── Is memoization needed?
└── Animation performance?
```
---
## 🎯 PATTERN QUESTIONING MATRIX
Ask these questions for every default pattern:
### Navigation Pattern Questioning
| Assumption | Question | Alternative |
|------------|----------|-------------|
| "I'll use tab bar" | How many destinations? | 3 → minimal tabs, 6+ → drawer |
| "5 tabs" | Are all equally important? | "More" tab? Drawer hybrid? |
| "Bottom nav" | iPad/tablet support? | Navigation rail alternative |
| "Stack navigation" | Did I consider deep links? | URL structure = navigation structure |
### State Pattern Questioning
| Assumption | Question | Alternative |
|------------|----------|-------------|
| "I'll use Redux" | How complex is the app? | Simple: Zustand, Server: TanStack |
| "Global state" | Is this state really global? | Local lift, Context selector |
| "Context Provider" | Will re-render be an issue? | Zustand, Jotai (atom-based) |
| "BLoC pattern" | Is the boilerplate worth it? | Riverpod (less code) |
### List Pattern Questioning
| Assumption | Question | Alternative |
|------------|----------|-------------|
| "FlatList" | Is performance critical? | FlashList (faster) |
| "Standard renderItem" | Is it memoized? | useCallback + React.memo |
| "Index key" | Does data order change? | Use item.id |
| "ListView" | Are there separators? | ListView.separated |
### UI Pattern Questioning
| Assumption | Question | Alternative |
|------------|----------|-------------|
| "FAB bottom-right" | User handedness? | Accessibility settings |
| "Pull-to-refresh" | Does this list need refresh? | Only when necessary |
| "Modal bottom sheet" | How much content? | Full screen modal might be better |
| "Swipe actions" | Discoverability? | Visible button alternative |
---
## 🧪 ANTI-MEMORIZATION TEST
### Ask Yourself Before Every Solution
```
┌─────────────────────────────────────────────────────────────────┐
│ ANTI-MEMORIZATION CHECKLIST │
├─────────────────────────────────────────────────────────────────┤
│ │
│ □ Did I pick this solution "because I always do it this way"? │
│ → If YES: STOP. Consider alternatives. │
│ │
│ □ Is this a pattern I've seen frequently in training data? │
│ → If YES: Is it REALLY suitable for THIS project? │
│ │
│ □ Did I write this solution automatically without thinking? │
│ → If YES: Step back, do decomposition. │
│ │
│ □ Did I consider an alternative approach? │
│ → If NO: Think of at least 2 alternatives, then decide. │
│ │
│ □ Did I think platform-specifically? │
│ → If NO: Analyze iOS and Android separately. │
│ │
│ □ Did I consider performance impact of this solution? │
│ → If NO: What is the memory, CPU, battery impact? │
│ │
│ □ Is this solution suitable for THIS project's CONTEXT? │
│ → If NO: Customize based on context. │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## 📊 CONTEXT-BASED DECISION PROTOCOL
### Think Differently Based on Project Type
```
DETERMINE PROJECT TYPE:
├── E-Commerce App
│ ├── Navigation: Tab (Home, Search, Cart, Account)
│ ├── Lists: Product grids (memoized, image optimized)
│ ├── Performance: Image caching CRITICAL
│ ├── Offline: Cart persistence, product cache
│ └── Special: Checkout flow, payment security
├── Social/Content App
│ ├── Navigation: Tab (Feed, Search, Create, Notify, Profile)
│ ├── Lists: Infinite scroll, complex items
│ ├── Performance: Feed rendering CRITICAL
│ ├── Offline: Feed cache, draft posts
│ └── Special: Real-time updates, media handling
├── Productivity/SaaS App
│ ├── Navigation: Drawer or adaptive (mobile tab, tablet rail)
│ ├── Lists: Data tables, forms
│ ├── Performance: Data sync
│ ├── Offline: Full offline editing
│ └── Special: Conflict resolution, background sync
├── Utility App
│ ├── Navigation: Minimal (stack-only possible)
│ ├── Lists: Probably minimal
│ ├── Performance: Fast startup
│ ├── Offline: Core feature offline
│ └── Special: Widget, shortcuts
└── Media/Streaming App
├── Navigation: Tab (Home, Search, Library, Profile)
├── Lists: Horizontal carousels, vertical feeds
├── Performance: Preloading, buffering
├── Offline: Download management
└── Special: Background playback, casting
```
---
## 🔄 INTERACTION BREAKDOWN
### Analysis for Every Gesture
Before adding any gesture:
```
GESTURE: [Gesture Type]
├── DISCOVERABILITY:
│ └── How will users discover this gesture?
│ ├── Is there a visual hint?
│ ├── Will it be shown in onboarding?
│ └── Is there a button alternative? (MANDATORY)
├── PLATFORM CONVENTION:
│ ├── What does this gesture mean on iOS?
│ ├── What does this gesture mean on Android?
│ └── Am I deviating from platform convention?
├── ACCESSIBILITY:
│ ├── Can motor-impaired users perform this gesture?
│ ├── Is there a VoiceOver/TalkBack alternative?
│ └── Does it work with switch control?
├── CONFLICT CHECK:
│ ├── Does it conflict with system gestures?
│ │ ├── iOS: Edge swipe back
│ │ ├── Android: Back gesture
│ │ └── Home indicator swipe
│ └── Is it consistent with other app gestures?
└── FEEDBACK:
├── Is haptic feedback defined?
├── Is visual feedback sufficient?
└── Is audio feedback needed?
```
---
## 🎭 SPIRIT OVER CHECKLIST (Mobile Edition)
### Passing the Checklist is Not Enough!
| ❌ Self-Deception | ✅ Honest Assessment |
|-------------------|----------------------|
| "Touch target is 44px" (but on edge, unreachable) | "Can user reach it one-handed?" |
| "I used FlatList" (but didn't memoize) | "Is scroll smooth?" |
| "Platform-specific nav" (but only icons differ) | "Does iOS feel like iOS, Android like Android?" |
| "Offline support exists" (but error message is generic) | "What can user actually do offline?" |
| "Loading state exists" (but just a spinner) | "Does user know how long to wait?" |
> 🔴 **Passing the checklist is NOT the goal. Creating great mobile UX IS the goal.**
---
## 📝 MOBILE DESIGN COMMITMENT
### Fill This at the Start of Every Mobile Project
```
📱 MOBILE DESIGN COMMITMENT
Project: _______________
Platform: iOS / Android / Both
1. Default pattern I will NOT use in this project:
└── _______________
2. Context-specific focus for this project:
└── _______________
3. Platform-specific differences I will implement:
└── iOS: _______________
└── Android: _______________
4. Area I will specifically optimize for performance:
└── _______________
5. Unique challenge of this project:
└── _______________
🧠 If I can't fill this commitment → I don't understand the project well enough.
→ Go back, understand context better, ask the user.
```
---
## 🚨 MANDATORY: Before Every Mobile Work
```
┌─────────────────────────────────────────────────────────────────┐
│ PRE-WORK VALIDATION │
├─────────────────────────────────────────────────────────────────┤
│ │
│ □ Did I complete Component Decomposition? │
│ □ Did I fill the Pattern Questioning Matrix? │
│ □ Did I pass the Anti-Memorization Test? │
│ □ Did I make context-based decisions? │
│ □ Did I analyze Interaction Breakdown? │
│ □ Did I fill the Mobile Design Commitment? │
│ │
│ ⚠️ Do not write code without completing these! │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
> **Remember:** If you chose a solution "because that's how it's always done," you chose WITHOUT THINKING. Every project is unique. Every context is different. Every user behavior is specific. **THINK, then code.**

View File

@@ -0,0 +1,458 @@
# Mobile Navigation Reference
> Navigation patterns, deep linking, back handling, and tab/stack/drawer decisions.
> **Navigation is the skeleton of your app—get it wrong and everything feels broken.**
---
## 1. Navigation Selection Decision Tree
```
WHAT TYPE OF APP?
├── 3-5 top-level sections (equal importance)
│ └── ✅ Tab Bar / Bottom Navigation
│ Examples: Social, E-commerce, Utility
├── Deep hierarchical content (drill down)
│ └── ✅ Stack Navigation
│ Examples: Settings, Email folders
├── Many destinations (>5 top-level)
│ └── ✅ Drawer Navigation
│ Examples: Gmail, complex enterprise
├── Single linear flow
│ └── ✅ Stack only (wizard/onboarding)
│ Examples: Checkout, Setup flow
└── Tablet/Foldable
└── ✅ Navigation Rail + List-Detail
Examples: Mail, Notes on iPad
```
---
## 2. Tab Bar Navigation
### When to Use
```
✅ USE Tab Bar when:
├── 3-5 top-level destinations
├── Destinations are of equal importance
├── User frequently switches between them
├── Each tab has independent navigation stack
└── App is used in short sessions
❌ AVOID Tab Bar when:
├── More than 5 destinations
├── Destinations have clear hierarchy
├── Tabs would be used very unequally
└── Content flows in a sequence
```
### Tab Bar Best Practices
```
iOS Tab Bar:
├── Height: 49pt (83pt with home indicator)
├── Max items: 5
├── Icons: SF Symbols, 25×25pt
├── Labels: Always show (accessibility)
├── Active indicator: Tint color
Android Bottom Navigation:
├── Height: 80dp
├── Max items: 5 (3-5 ideal)
├── Icons: Material Symbols, 24dp
├── Labels: Always show
├── Active indicator: Pill shape + filled icon
```
### Tab State Preservation
```
RULE: Each tab maintains its own navigation stack.
User journey:
1. Home tab → Drill into item → Add to cart
2. Switch to Profile tab
3. Switch back to Home tab
→ Should return to "Add to cart" screen, NOT home root
Implementation:
├── React Navigation: Each tab has own navigator
├── Flutter: IndexedStack for state preservation
└── Never reset tab stack on switch
```
---
## 3. Stack Navigation
### Core Concepts
```
Stack metaphor: Cards stacked on top of each other
Push: Add screen on top
Pop: Remove top screen (back)
Replace: Swap current screen
Reset: Clear stack, set new root
Visual: New screen slides in from right (LTR)
Back: Screen slides out to right
```
### Stack Navigation Patterns
| Pattern | Use Case | Implementation |
|---------|----------|----------------|
| **Simple Stack** | Linear flow | Push each step |
| **Nested Stack** | Sections with sub-navigation | Stack inside tab |
| **Modal Stack** | Focused tasks | Present modally |
| **Auth Stack** | Login vs Main | Conditional root |
### Back Button Handling
```
iOS:
├── Edge swipe from left (system)
├── Back button in nav bar (optional)
├── Interactive pop gesture
└── Never override swipe back without good reason
Android:
├── System back button/gesture
├── Up button in toolbar (optional, for drill-down)
├── Predictive back animation (Android 14+)
└── Must handle back correctly (Activity/Fragment)
Cross-Platform Rule:
├── Back ALWAYS navigates up the stack
├── Never hijack back for other purposes
├── Confirm before discarding unsaved data
└── Deep links should allow full back traversal
```
---
## 4. Drawer Navigation
### When to Use
```
✅ USE Drawer when:
├── More than 5 top-level destinations
├── Less frequently accessed destinations
├── Complex app with many features
├── Need for branding/user info in nav
└── Tablet/large screen with persistent drawer
❌ AVOID Drawer when:
├── 5 or fewer destinations (use tabs)
├── All destinations equally important
├── Mobile-first simple app
└── Discoverability is critical (drawer is hidden)
```
### Drawer Patterns
```
Modal Drawer:
├── Opens over content (scrim behind)
├── Swipe to open from edge
├── Hamburger icon ( ☰ ) triggers
└── Most common on mobile
Permanent Drawer:
├── Always visible (large screens)
├── Content shifts over
├── Good for productivity apps
└── Tablets, desktops
Navigation Rail (Android):
├── Narrow vertical strip
├── Icons + optional labels
├── For tablets in portrait
└── 80dp width
```
---
## 5. Modal Navigation
### Modal vs Push
```
PUSH (Stack): MODAL:
├── Horizontal slide ├── Vertical slide up (sheet)
├── Part of hierarchy ├── Separate task
├── Back returns ├── Dismiss (X) returns
├── Same navigation context ├── Own navigation context
└── "Drill in" └── "Focus on task"
USE MODAL for:
├── Creating new content
├── Settings/preferences
├── Completing a transaction
├── Self-contained workflows
├── Quick actions
```
### Modal Types
| Type | iOS | Android | Use Case |
|------|-----|---------|----------|
| **Sheet** | `.sheet` | Bottom Sheet | Quick tasks |
| **Full Screen** | `.fullScreenCover` | Full Activity | Complex forms |
| **Alert** | Alert | Dialog | Confirmations |
| **Action Sheet** | Action Sheet | Menu/Bottom Sheet | Choose from options |
### Modal Dismissal
```
Users expect to dismiss modals by:
├── Tapping X / Close button
├── Swiping down (sheet)
├── Tapping scrim (non-critical)
├── System back (Android)
├── Hardware back (old Android)
RULE: Only block dismissal for unsaved data.
```
---
## 6. Deep Linking
### Why Deep Links from Day One
```
Deep links enable:
├── Push notification navigation
├── Sharing content
├── Marketing campaigns
├── Spotlight/Search integration
├── Widget navigation
├── External app integration
Building later is HARD:
├── Requires navigation refactor
├── Screen dependencies unclear
├── Parameter passing complex
└── Always plan deep links at start
```
### URL Structure
```
Scheme://host/path?params
Examples:
├── myapp://product/123
├── https://myapp.com/product/123 (Universal/App Link)
├── myapp://checkout?promo=SAVE20
├── myapp://tab/profile/settings
Hierarchy should match navigation:
├── myapp://home
├── myapp://home/product/123
├── myapp://home/product/123/reviews
└── URL path = navigation path
```
### Deep Link Navigation Rules
```
1. FULL STACK CONSTRUCTION
Deep link to myapp://product/123 should:
├── Put Home at root of stack
├── Push Product screen on top
└── Back button returns to Home
2. AUTHENTICATION AWARENESS
If deep link requires auth:
├── Save intended destination
├── Redirect to login
├── After login, navigate to destination
3. INVALID LINKS
If deep link target doesn't exist:
├── Navigate to fallback (home)
├── Show error message
└── Never crash or blank screen
4. STATEFUL NAVIGATION
Deep link during active session:
├── Don't blow away current stack
├── Push on top OR
├── Ask user if should navigate away
```
---
## 7. Navigation State Persistence
### What to Persist
```
SHOULD persist:
├── Current tab selection
├── Scroll position in lists
├── Form draft data
├── Recent navigation stack
└── User preferences
SHOULD NOT persist:
├── Modal states (dialogs)
├── Temporary UI states
├── Stale data (refresh on return)
├── Authentication state (use secure storage)
```
### Implementation
```javascript
// React Navigation - State Persistence
const [isReady, setIsReady] = useState(false);
const [initialState, setInitialState] = useState();
useEffect(() => {
const loadState = async () => {
const savedState = await AsyncStorage.getItem('NAV_STATE');
if (savedState) setInitialState(JSON.parse(savedState));
setIsReady(true);
};
loadState();
}, []);
const handleStateChange = (state) => {
AsyncStorage.setItem('NAV_STATE', JSON.stringify(state));
};
<NavigationContainer
initialState={initialState}
onStateChange={handleStateChange}
>
```
---
## 8. Transition Animations
### Platform Defaults
```
iOS Transitions:
├── Push: Slide from right
├── Modal: Slide from bottom (sheet) or fade
├── Tab switch: Cross-fade
├── Interactive: Swipe to go back
Android Transitions:
├── Push: Fade + slide from right
├── Modal: Slide from bottom
├── Tab switch: Cross-fade or none
├── Shared element: Hero animations
```
### Custom Transitions
```
When to custom:
├── Brand identity requires it
├── Shared element connections
├── Special reveal effects
└── Keep it subtle, <300ms
When to use default:
├── Most of the time
├── Standard drill-down
├── Platform consistency
└── Performance critical paths
```
### Shared Element Transitions
```
Connect elements between screens:
Screen A: Product card with image
↓ (tap)
Screen B: Product detail with same image (expanded)
Image animates from card position to detail position.
Implementation:
├── React Navigation: shared element library
├── Flutter: Hero widget
├── SwiftUI: matchedGeometryEffect
└── Compose: Shared element transitions
```
---
## 9. Navigation Anti-Patterns
### ❌ Navigation Sins
| Anti-Pattern | Problem | Solution |
|--------------|---------|----------|
| **Inconsistent back** | User confused, can't predict | Always pop stack |
| **Hidden navigation** | Features undiscoverable | Visible tabs/drawer trigger |
| **Deep nesting** | User gets lost | Max 3-4 levels, breadcrumbs |
| **Breaking swipe back** | iOS users frustrated | Never override gesture |
| **No deep links** | Can't share, bad notifications | Plan from start |
| **Tab stack reset** | Work lost on switch | Preserve tab states |
| **Modal for primary flow** | Can't back track | Use stack navigation |
### ❌ AI Navigation Mistakes
```
AI tends to:
├── Use modals for everything (wrong)
├── Forget tab state preservation (wrong)
├── Skip deep linking (wrong)
├── Override platform back behavior (wrong)
├── Reset stack on tab switch (wrong)
└── Ignore predictive back (Android 14+)
RULE: Use platform navigation patterns.
Don't reinvent navigation.
```
---
## 10. Navigation Checklist
### Before Navigation Architecture
- [ ] App type determined (tabs/drawer/stack)
- [ ] Number of top-level destinations counted
- [ ] Deep link URL scheme planned
- [ ] Auth flow integrated with navigation
- [ ] Tablet/large screen considered
### Before Every Screen
- [ ] Can user navigate back? (not dead end)
- [ ] Deep link to this screen planned
- [ ] State preserved on navigate away/back
- [ ] Transition appropriate for relationship
- [ ] Auth required? Handled?
### Before Release
- [ ] All deep links tested
- [ ] Back button works everywhere
- [ ] Tab states preserved correctly
- [ ] Edge swipe back works (iOS)
- [ ] Predictive back works (Android 14+)
- [ ] Universal/App links configured
- [ ] Push notification deep links work
---
> **Remember:** Navigation is invisible when done right. Users shouldn't think about HOW to get somewhere—they just get there. If they notice navigation, something is wrong.

View File

@@ -0,0 +1,767 @@
# Mobile Performance Reference
> Deep dive into React Native and Flutter performance optimization, 60fps animations, memory management, and battery considerations.
> **This file covers the #1 area where AI-generated code FAILS.**
---
## 1. The Mobile Performance Mindset
### Why Mobile Performance is Different
```
DESKTOP: MOBILE:
├── Unlimited power ├── Battery matters
├── Abundant RAM ├── RAM is shared, limited
├── Stable network ├── Network is unreliable
├── CPU always available ├── CPU throttles when hot
└── User expects fast anyway └── User expects INSTANT
```
### Performance Budget Concept
```
Every frame must complete in:
├── 60fps → 16.67ms per frame
├── 120fps (ProMotion) → 8.33ms per frame
If your code takes longer:
├── Frame drops → Janky scroll/animation
├── User perceives as "slow" or "broken"
└── They WILL uninstall your app
```
---
## 2. React Native Performance
### 🚫 The #1 AI Mistake: ScrollView for Lists
```javascript
// ❌ NEVER DO THIS - AI's favorite mistake
<ScrollView>
{items.map(item => (
<ItemComponent key={item.id} item={item} />
))}
</ScrollView>
// Why it's catastrophic:
// ├── Renders ALL items immediately (1000 items = 1000 renders)
// ├── Memory explodes
// ├── Initial render takes seconds
// └── Scroll becomes janky
// ✅ ALWAYS USE FlatList
<FlatList
data={items}
renderItem={renderItem}
keyExtractor={item => item.id}
/>
```
### FlatList Optimization Checklist
```javascript
// ✅ CORRECT: All optimizations applied
// 1. Memoize the item component
const ListItem = React.memo(({ item }: { item: Item }) => {
return (
<Pressable style={styles.item}>
<Text>{item.title}</Text>
</Pressable>
);
});
// 2. Memoize renderItem with useCallback
const renderItem = useCallback(
({ item }: { item: Item }) => <ListItem item={item} />,
[] // Empty deps = never recreated
);
// 3. Stable keyExtractor (NEVER use index!)
const keyExtractor = useCallback((item: Item) => item.id, []);
// 4. Provide getItemLayout for fixed-height items
const getItemLayout = useCallback(
(data: Item[] | null, index: number) => ({
length: ITEM_HEIGHT, // Fixed height
offset: ITEM_HEIGHT * index,
index,
}),
[]
);
// 5. Apply to FlatList
<FlatList
data={items}
renderItem={renderItem}
keyExtractor={keyExtractor}
getItemLayout={getItemLayout}
// Performance props
removeClippedSubviews={true} // Android: detach off-screen
maxToRenderPerBatch={10} // Items per batch
windowSize={5} // Render window (5 = 2 screens each side)
initialNumToRender={10} // Initial items
updateCellsBatchingPeriod={50} // Batching delay
/>
```
### Why Each Optimization Matters
| Optimization | What It Prevents | Impact |
|--------------|------------------|--------|
| `React.memo` | Re-render on parent change | 🔴 Critical |
| `useCallback renderItem` | New function every render | 🔴 Critical |
| Stable `keyExtractor` | Wrong item recycling | 🔴 Critical |
| `getItemLayout` | Async layout calculation | 🟡 High |
| `removeClippedSubviews` | Memory from off-screen | 🟡 High |
| `maxToRenderPerBatch` | Blocking main thread | 🟢 Medium |
| `windowSize` | Memory usage | 🟢 Medium |
### FlashList: The Better Option
```javascript
// Consider FlashList for better performance
import { FlashList } from "@shopify/flash-list";
<FlashList
data={items}
renderItem={renderItem}
estimatedItemSize={ITEM_HEIGHT}
keyExtractor={keyExtractor}
/>
// Benefits over FlatList:
// ├── Faster recycling
// ├── Better memory management
// ├── Simpler API
// └── Fewer optimization props needed
```
### Animation Performance
```javascript
// ❌ JS-driven animation (blocks JS thread)
Animated.timing(value, {
toValue: 1,
duration: 300,
useNativeDriver: false, // BAD!
}).start();
// ✅ Native-driver animation (runs on UI thread)
Animated.timing(value, {
toValue: 1,
duration: 300,
useNativeDriver: true, // GOOD!
}).start();
// Native driver supports ONLY:
// ├── transform (translate, scale, rotate)
// └── opacity
//
// Does NOT support:
// ├── width, height
// ├── backgroundColor
// ├── borderRadius changes
// └── margin, padding
```
### Reanimated for Complex Animations
```javascript
// For animations native driver can't handle, use Reanimated 3
import Animated, {
useSharedValue,
useAnimatedStyle,
withSpring,
} from 'react-native-reanimated';
const Component = () => {
const offset = useSharedValue(0);
const animatedStyles = useAnimatedStyle(() => ({
transform: [{ translateX: withSpring(offset.value) }],
}));
return <Animated.View style={animatedStyles} />;
};
// Benefits:
// ├── Runs on UI thread (60fps guaranteed)
// ├── Can animate any property
// ├── Gesture-driven animations
// └── Worklets for complex logic
```
### Memory Leak Prevention
```javascript
// ❌ Memory leak: uncleared interval
useEffect(() => {
const interval = setInterval(() => {
fetchData();
}, 5000);
// Missing cleanup!
}, []);
// ✅ Proper cleanup
useEffect(() => {
const interval = setInterval(() => {
fetchData();
}, 5000);
return () => clearInterval(interval); // CLEANUP!
}, []);
// Common memory leak sources:
// ├── Timers (setInterval, setTimeout)
// ├── Event listeners
// ├── Subscriptions (WebSocket, PubSub)
// ├── Async operations that update state after unmount
// └── Image caching without limits
```
### React Native Performance Checklist
```markdown
## Before Every List
- [ ] Using FlatList or FlashList (NOT ScrollView)
- [ ] renderItem is useCallback memoized
- [ ] List items are React.memo wrapped
- [ ] keyExtractor uses stable ID (NOT index)
- [ ] getItemLayout provided (if fixed height)
## Before Every Animation
- [ ] useNativeDriver: true (if possible)
- [ ] Using Reanimated for complex animations
- [ ] Only animating transform/opacity
- [ ] Tested on low-end Android device
## Before Any Release
- [ ] console.log statements removed
- [ ] Cleanup functions in all useEffects
- [ ] No memory leaks (test with profiler)
- [ ] Tested in release build (not dev)
```
---
## 3. Flutter Performance
### 🚫 The #1 AI Mistake: setState Overuse
```dart
// ❌ WRONG: setState rebuilds ENTIRE widget tree
class BadCounter extends StatefulWidget {
@override
State<BadCounter> createState() => _BadCounterState();
}
class _BadCounterState extends State<BadCounter> {
int _counter = 0;
void _increment() {
setState(() {
_counter++; // This rebuilds EVERYTHING below!
});
}
@override
Widget build(BuildContext context) {
return Column(
children: [
Text('Counter: $_counter'),
ExpensiveWidget(), // Rebuilds unnecessarily!
AnotherExpensiveWidget(), // Rebuilds unnecessarily!
],
);
}
}
```
### The `const` Constructor Revolution
```dart
// ✅ CORRECT: const prevents rebuilds
class GoodCounter extends StatefulWidget {
const GoodCounter({super.key}); // CONST constructor!
@override
State<GoodCounter> createState() => _GoodCounterState();
}
class _GoodCounterState extends State<GoodCounter> {
int _counter = 0;
@override
Widget build(BuildContext context) {
return Column(
children: [
Text('Counter: $_counter'),
const ExpensiveWidget(), // Won't rebuild!
const AnotherExpensiveWidget(), // Won't rebuild!
],
);
}
}
// RULE: Add `const` to EVERY widget that doesn't depend on state
```
### Targeted State Management
```dart
// ❌ setState rebuilds whole tree
setState(() => _value = newValue);
// ✅ ValueListenableBuilder: surgical rebuilds
class TargetedState extends StatelessWidget {
final ValueNotifier<int> counter = ValueNotifier(0);
@override
Widget build(BuildContext context) {
return Column(
children: [
// Only this rebuilds when counter changes
ValueListenableBuilder<int>(
valueListenable: counter,
builder: (context, value, child) => Text('$value'),
child: const Icon(Icons.star), // Won't rebuild!
),
const ExpensiveWidget(), // Never rebuilds
],
);
}
}
```
### Riverpod/Provider Best Practices
```dart
// ❌ WRONG: Reading entire provider in build
Widget build(BuildContext context) {
final state = ref.watch(myProvider); // Rebuilds on ANY change
return Text(state.name);
}
// ✅ CORRECT: Select only what you need
Widget build(BuildContext context) {
final name = ref.watch(myProvider.select((s) => s.name));
return Text(name); // Only rebuilds when name changes
}
```
### ListView Optimization
```dart
// ❌ WRONG: ListView without builder (renders all)
ListView(
children: items.map((item) => ItemWidget(item)).toList(),
)
// ✅ CORRECT: ListView.builder (lazy rendering)
ListView.builder(
itemCount: items.length,
itemBuilder: (context, index) => ItemWidget(items[index]),
// Additional optimizations:
itemExtent: 56, // Fixed height = faster layout
cacheExtent: 100, // Pre-render distance
)
// ✅ EVEN BETTER: ListView.separated for dividers
ListView.separated(
itemCount: items.length,
itemBuilder: (context, index) => ItemWidget(items[index]),
separatorBuilder: (context, index) => const Divider(),
)
```
### Image Optimization
```dart
// ❌ WRONG: No caching, full resolution
Image.network(url)
// ✅ CORRECT: Cached with proper sizing
CachedNetworkImage(
imageUrl: url,
width: 100,
height: 100,
fit: BoxFit.cover,
memCacheWidth: 200, // Cache at 2x for retina
memCacheHeight: 200,
placeholder: (context, url) => const Skeleton(),
errorWidget: (context, url, error) => const Icon(Icons.error),
)
```
### Dispose Pattern
```dart
class MyWidget extends StatefulWidget {
@override
State<MyWidget> createState() => _MyWidgetState();
}
class _MyWidgetState extends State<MyWidget> {
late final StreamSubscription _subscription;
late final AnimationController _controller;
late final TextEditingController _textController;
@override
void initState() {
super.initState();
_subscription = stream.listen((_) {});
_controller = AnimationController(vsync: this);
_textController = TextEditingController();
}
@override
void dispose() {
// ALWAYS dispose in reverse order of creation
_textController.dispose();
_controller.dispose();
_subscription.cancel();
super.dispose();
}
@override
Widget build(BuildContext context) => Container();
}
```
### Flutter Performance Checklist
```markdown
## Before Every Widget
- [ ] const constructor added (if no runtime args)
- [ ] const keywords on static children
- [ ] Minimal setState scope
- [ ] Using selectors for provider watches
## Before Every List
- [ ] Using ListView.builder (NOT ListView with children)
- [ ] itemExtent provided (if fixed height)
- [ ] Image caching with size limits
## Before Any Animation
- [ ] Using Impeller (Flutter 3.16+)
- [ ] Avoiding Opacity widget (use FadeTransition)
- [ ] TickerProviderStateMixin for AnimationController
## Before Any Release
- [ ] All dispose() methods implemented
- [ ] No print() in production
- [ ] Tested in profile/release mode
- [ ] DevTools performance overlay checked
```
---
## 4. Animation Performance (Both Platforms)
### The 60fps Imperative
```
Human eye detects:
├── < 24 fps → "Slideshow" (broken)
├── 24-30 fps → "Choppy" (uncomfortable)
├── 30-45 fps → "Noticeably not smooth"
├── 45-60 fps → "Smooth" (acceptable)
├── 60 fps → "Buttery" (target)
└── 120 fps → "Premium" (ProMotion devices)
NEVER ship < 60fps animations.
```
### GPU vs CPU Animation
```
GPU-ACCELERATED (FAST): CPU-BOUND (SLOW):
├── transform: translate ├── width, height
├── transform: scale ├── top, left, right, bottom
├── transform: rotate ├── margin, padding
├── opacity ├── border-radius (animated)
└── (Composited, off main) └── box-shadow (animated)
RULE: Only animate transform and opacity.
Everything else causes layout recalculation.
```
### Animation Timing Guide
| Animation Type | Duration | Easing |
|----------------|----------|--------|
| Micro-interaction | 100-200ms | ease-out |
| Standard transition | 200-300ms | ease-out |
| Page transition | 300-400ms | ease-in-out |
| Complex/dramatic | 400-600ms | ease-in-out |
| Loading skeletons | 1000-1500ms | linear (loop) |
### Spring Physics
```javascript
// React Native Reanimated
withSpring(targetValue, {
damping: 15, // How quickly it settles (higher = faster stop)
stiffness: 150, // How "tight" the spring (higher = faster)
mass: 1, // Weight of the object
})
// Flutter
SpringSimulation(
SpringDescription(
mass: 1,
stiffness: 150,
damping: 15,
),
start,
end,
velocity,
)
// Natural feel ranges:
// Damping: 10-20 (bouncy to settled)
// Stiffness: 100-200 (loose to tight)
// Mass: 0.5-2 (light to heavy)
```
---
## 5. Memory Management
### Common Memory Leaks
| Source | Platform | Solution |
|--------|----------|----------|
| Timers | Both | Clear in cleanup/dispose |
| Event listeners | Both | Remove in cleanup/dispose |
| Subscriptions | Both | Cancel in cleanup/dispose |
| Large images | Both | Limit cache, resize |
| Async after unmount | RN | isMounted check or AbortController |
| Animation controllers | Flutter | Dispose controllers |
### Image Memory
```
Image memory = width × height × 4 bytes (RGBA)
1080p image = 1920 × 1080 × 4 = 8.3 MB
4K image = 3840 × 2160 × 4 = 33.2 MB
10 4K images = 332 MB → App crash!
RULE: Always resize images to display size (or 2-3x for retina).
```
### Memory Profiling
```
React Native:
├── Flipper → Memory tab
├── Xcode Instruments (iOS)
└── Android Studio Profiler
Flutter:
├── DevTools → Memory tab
├── Observatory
└── flutter run --profile
```
---
## 6. Battery Optimization
### Battery Drain Sources
| Source | Impact | Mitigation |
|--------|--------|------------|
| **Screen on** | 🔴 Highest | Dark mode on OLED |
| **GPS continuous** | 🔴 Very high | Use significant change |
| **Network requests** | 🟡 High | Batch, cache aggressively |
| **Animations** | 🟡 Medium | Reduce when low battery |
| **Background work** | 🟡 Medium | Defer non-critical |
| **CPU computation** | 🟢 Lower | Offload to backend |
### OLED Battery Saving
```
OLED screens: Black pixels = OFF = 0 power
Dark mode savings:
├── True black (#000000) → Maximum savings
├── Dark gray (#1a1a1a) → Slight savings
├── Any color → Some power
└── White (#FFFFFF) → Maximum power
RULE: On dark mode, use true black for backgrounds.
```
### Background Task Guidelines
```
iOS:
├── Background refresh: Limited, system-scheduled
├── Push notifications: Use for important updates
├── Background modes: Location, audio, VoIP only
└── Background tasks: Max ~30 seconds
Android:
├── WorkManager: System-scheduled, battery-aware
├── Foreground service: Visible to user, continuous
├── JobScheduler: Batch network operations
└── Doze mode: Respect it, batch operations
```
---
## 7. Network Performance
### Offline-First Architecture
```
┌──────────────┐
│ UI │
└──────┬───────┘
┌──────▼───────┐
│ Cache │ ← Read from cache FIRST
└──────┬───────┘
┌──────▼───────┐
│ Network │ ← Update cache from network
└──────────────┘
Benefits:
├── Instant UI (no loading spinner for cached data)
├── Works offline
├── Reduces data usage
└── Better UX on slow networks
```
### Request Optimization
```
BATCH: Combine multiple requests into one
├── 10 small requests → 1 batch request
├── Reduces connection overhead
└── Better for battery (radio on once)
CACHE: Don't re-fetch unchanged data
├── ETag/If-None-Match headers
├── Cache-Control headers
└── Stale-while-revalidate pattern
COMPRESS: Reduce payload size
├── gzip/brotli compression
├── Request only needed fields (GraphQL)
└── Paginate large lists
```
---
## 8. Performance Testing
### What to Test
| Metric | Target | Tool |
|--------|--------|------|
| **Frame rate** | ≥ 60fps | Performance overlay |
| **Memory** | Stable, no growth | Profiler |
| **Cold start** | < 2s | Manual timing |
| **TTI (Time to Interactive)** | < 3s | Lighthouse |
| **List scroll** | No jank | Manual feel |
| **Animation smoothness** | No drops | Performance monitor |
### Test on Real Devices
```
⚠️ NEVER trust only:
├── Simulator/emulator (faster than real)
├── Dev mode (slower than release)
├── High-end devices only
✅ ALWAYS test on:
├── Low-end Android (< $200 phone)
├── Older iOS device (iPhone 8 or SE)
├── Release/profile build
└── With real data (not 10 items)
```
### Performance Monitoring Checklist
```markdown
## During Development
- [ ] Performance overlay enabled
- [ ] Watching for dropped frames
- [ ] Memory usage stable
- [ ] No console warnings about performance
## Before Release
- [ ] Tested on low-end device
- [ ] Profiled memory over extended use
- [ ] Cold start time measured
- [ ] List scroll tested with 1000+ items
- [ ] Animations tested at 60fps
- [ ] Network tested on slow 3G
```
---
## 9. Quick Reference Card
### React Native Essentials
```javascript
// List: Always use
<FlatList
data={data}
renderItem={useCallback(({item}) => <MemoItem item={item} />, [])}
keyExtractor={useCallback(item => item.id, [])}
getItemLayout={useCallback((_, i) => ({length: H, offset: H*i, index: i}), [])}
/>
// Animation: Always native
useNativeDriver: true
// Cleanup: Always present
useEffect(() => {
return () => cleanup();
}, []);
```
### Flutter Essentials
```dart
// Widgets: Always const
const MyWidget()
// Lists: Always builder
ListView.builder(itemBuilder: ...)
// State: Always targeted
ValueListenableBuilder() or ref.watch(provider.select(...))
// Dispose: Always cleanup
@override
void dispose() {
controller.dispose();
super.dispose();
}
```
### Animation Targets
```
Transform/Opacity only ← What to animate
16.67ms per frame ← Time budget
60fps minimum ← Target
Low-end Android ← Test device
```
---
> **Remember:** Performance is not optimization—it's baseline quality. A slow app is a broken app. Test on the worst device your users have, not the best device you have.

View File

@@ -0,0 +1,356 @@
# Mobile Testing Patterns
> **Mobile testing is NOT web testing. Different constraints, different strategies.**
> This file teaches WHEN to use each testing approach and WHY.
> **Code examples are minimal - focus on decision-making.**
---
## 🧠 MOBILE TESTING MINDSET
```
Mobile testing differs from web:
├── Real devices matter (emulators hide bugs)
├── Platform differences (iOS vs Android behavior)
├── Network conditions vary wildly
├── Battery/performance under test
├── App lifecycle (background, killed, restored)
├── Permissions and system dialogs
└── Touch interactions vs clicks
```
---
## 🚫 AI MOBILE TESTING ANTI-PATTERNS
| ❌ AI Default | Why It's Wrong | ✅ Mobile-Correct |
|---------------|----------------|-------------------|
| Jest-only testing | Misses native layer | Jest + E2E on device |
| Enzyme patterns | Deprecated, web-focused | React Native Testing Library |
| Browser-based E2E (Cypress) | Can't test native features | Detox / Maestro |
| Mock everything | Misses integration bugs | Real device testing |
| Ignore platform tests | iOS/Android differ | Platform-specific cases |
| Skip performance tests | Mobile perf is critical | Profile on low-end device |
| Test only happy path | Mobile has more edge cases | Offline, permissions, interrupts |
| 100% unit test coverage | False security | Pyramid balance |
| Copy web testing patterns | Different environment | Mobile-specific tools |
---
## 1. Testing Tool Selection
### Decision Tree
```
WHAT ARE YOU TESTING?
├── Pure functions, utilities, helpers
│ └── Jest (unit tests)
│ └── No special mobile setup needed
├── Individual components (isolated)
│ ├── React Native → React Native Testing Library
│ └── Flutter → flutter_test (widget tests)
├── Components with hooks, context, navigation
│ ├── React Native → RNTL + mocked providers
│ └── Flutter → integration_test package
├── Full user flows (login, checkout, etc.)
│ ├── Detox (React Native, fast, reliable)
│ ├── Maestro (Cross-platform, YAML-based)
│ └── Appium (Legacy, slow, last resort)
└── Performance, memory, battery
├── Flashlight (RN performance)
├── Flutter DevTools
└── Real device profiling (Xcode/Android Studio)
```
### Tool Comparison
| Tool | Platform | Speed | Reliability | Use When |
|------|----------|-------|-------------|----------|
| **Jest** | RN | ⚡⚡⚡ | ⚡⚡⚡ | Unit tests, logic |
| **RNTL** | RN | ⚡⚡⚡ | ⚡⚡ | Component tests |
| **flutter_test** | Flutter | ⚡⚡⚡ | ⚡⚡⚡ | Widget tests |
| **Detox** | RN | ⚡⚡ | ⚡⚡⚡ | E2E, critical flows |
| **Maestro** | Both | ⚡⚡ | ⚡⚡ | E2E, cross-platform |
| **Appium** | Both | ⚡ | ⚡ | Legacy, last resort |
---
## 2. Testing Pyramid for Mobile
```
┌───────────────┐
│ E2E Tests │ 10%
│ (Real device) │ Slow, expensive, essential
├───────────────┤
│ Integration │ 20%
│ Tests │ Component + context
├───────────────┤
│ Component │ 30%
│ Tests │ Isolated UI
├───────────────┤
│ Unit Tests │ 40%
│ (Jest) │ Pure logic
└───────────────┘
```
### Why This Distribution?
| Level | Why This % |
|-------|------------|
| **E2E 10%** | Slow, flaky, but catches integration bugs |
| **Integration 20%** | Tests real user flows without full app |
| **Component 30%** | Fast feedback on UI changes |
| **Unit 40%** | Fastest, most stable, logic coverage |
> 🔴 **If you have 90% unit tests and 0% E2E, you're testing the wrong things.**
---
## 3. What to Test at Each Level
### Unit Tests (Jest)
```
✅ TEST:
├── Utility functions (formatDate, calculatePrice)
├── State reducers (Redux, Zustand stores)
├── API response transformers
├── Validation logic
└── Business rules
❌ DON'T TEST:
├── Component rendering (use component tests)
├── Navigation (use integration tests)
├── Native modules (mock them)
└── Third-party libraries
```
### Component Tests (RNTL / flutter_test)
```
✅ TEST:
├── Component renders correctly
├── User interactions (tap, type, swipe)
├── Loading/error/empty states
├── Accessibility labels exist
└── Props change behavior
❌ DON'T TEST:
├── Internal implementation details
├── Snapshot everything (only key components)
├── Styling specifics (brittle)
└── Third-party component internals
```
### Integration Tests
```
✅ TEST:
├── Form submission flows
├── Navigation between screens
├── State persistence across screens
├── API integration (with mocked server)
└── Context/provider interactions
❌ DON'T TEST:
├── Every possible path (use unit tests)
├── Third-party services (mock them)
└── Backend logic (backend tests)
```
### E2E Tests
```
✅ TEST:
├── Critical user journeys (login, purchase, signup)
├── Offline → online transitions
├── Deep link handling
├── Push notification navigation
├── Permission flows
└── Payment flows
❌ DON'T TEST:
├── Every edge case (too slow)
├── Visual regression (use snapshot tests)
├── Non-critical features
└── Backend-only logic
```
---
## 4. Platform-Specific Testing
### What Differs Between iOS and Android?
| Area | iOS Behavior | Android Behavior | Test Both? |
|------|--------------|------------------|------------|
| **Back navigation** | Edge swipe | System back button | ✅ YES |
| **Permissions** | Ask once, settings | Ask each time, rationale | ✅ YES |
| **Keyboard** | Different appearance | Different behavior | ✅ YES |
| **Date picker** | Wheel/modal | Material dialog | ⚠️ If custom UI |
| **Push format** | APNs payload | FCM payload | ✅ YES |
| **Deep links** | Universal Links | App Links | ✅ YES |
| **Gestures** | Some unique | Material gestures | ⚠️ If custom |
### Platform Testing Strategy
```
FOR EACH PLATFORM:
├── Run unit tests (same on both)
├── Run component tests (same on both)
├── Run E2E on REAL DEVICE
│ ├── iOS: iPhone (not just simulator)
│ └── Android: Mid-range device (not flagship)
└── Test platform-specific features separately
```
---
## 5. Offline & Network Testing
### Offline Scenarios to Test
| Scenario | What to Verify |
|----------|----------------|
| Start app offline | Shows cached data or offline message |
| Go offline mid-action | Action queued, not lost |
| Come back online | Queue synced, no duplicates |
| Slow network (2G) | Loading states, timeouts work |
| Flaky network | Retry logic, error recovery |
### How to Test Network Conditions
```
APPROACH:
├── Unit tests: Mock NetInfo, test logic
├── Integration: Mock API responses, test UI
├── E2E (Detox): Use device.setURLBlacklist()
├── E2E (Maestro): Use network conditions
└── Manual: Use Charles Proxy / Network Link Conditioner
```
---
## 6. Performance Testing
### What to Measure
| Metric | Target | How to Measure |
|--------|--------|----------------|
| **App startup** | < 2 seconds | Profiler, Flashlight |
| **Screen transition** | < 300ms | React DevTools |
| **List scroll** | 60 FPS | Profiler, feel |
| **Memory** | Stable, no leaks | Instruments / Android Profiler |
| **Bundle size** | Minimize | Metro bundler analysis |
### When to Performance Test
```
PERFORMANCE TEST:
├── Before release (required)
├── After adding heavy features
├── After upgrading dependencies
├── When users report slowness
└── On CI (optional, automated benchmarks)
WHERE TO TEST:
├── Real device (REQUIRED)
├── Low-end device (Galaxy A series, old iPhone)
├── NOT on emulator (lies about performance)
└── With production-like data (not 3 items)
```
---
## 7. Accessibility Testing
### What to Verify
| Element | Check |
|---------|-------|
| Interactive elements | Have accessibilityLabel |
| Images | Have alt text or decorative flag |
| Forms | Labels linked to inputs |
| Buttons | Role = button |
| Touch targets | ≥ 44x44 (iOS) / 48x48 (Android) |
| Color contrast | WCAG AA minimum |
### How to Test
```
AUTOMATED:
├── React Native: jest-axe
├── Flutter: Accessibility checker in tests
└── Lint rules for missing labels
MANUAL:
├── Enable VoiceOver (iOS) / TalkBack (Android)
├── Navigate entire app with screen reader
├── Test with increased text size
└── Test with reduced motion
```
---
## 8. CI/CD Integration
### What to Run Where
| Stage | Tests | Devices |
|-------|-------|---------|
| **PR** | Unit + Component | None (fast) |
| **Merge to main** | + Integration | Simulator/Emulator |
| **Pre-release** | + E2E | Real devices (farm) |
| **Nightly** | Full suite | Device farm |
### Device Farm Options
| Service | Pros | Cons |
|---------|------|------|
| **Firebase Test Lab** | Free tier, Google devices | Android focus |
| **AWS Device Farm** | Wide selection | Expensive |
| **BrowserStack** | Good UX | Expensive |
| **Local devices** | Free, reliable | Limited variety |
---
## 📝 MOBILE TESTING CHECKLIST
### Before PR
- [ ] Unit tests for new logic
- [ ] Component tests for new UI
- [ ] No console.logs in tests
- [ ] Tests pass on CI
### Before Release
- [ ] E2E on real iOS device
- [ ] E2E on real Android device
- [ ] Tested on low-end device
- [ ] Offline scenarios verified
- [ ] Performance acceptable
- [ ] Accessibility verified
### What to Skip (Consciously)
- [ ] 100% coverage (aim for meaningful coverage)
- [ ] Every visual permutation (use snapshots sparingly)
- [ ] Third-party library internals
- [ ] Backend logic (separate tests)
---
## 🎯 Testing Questions to Ask
Before writing tests, answer:
1. **What could break?** → Test that
2. **What's critical for users?** → E2E test that
3. **What's complex logic?** → Unit test that
4. **What's platform-specific?** → Test on both platforms
5. **What happens offline?** → Test that scenario
> **Remember:** Good mobile testing is about testing the RIGHT things, not EVERYTHING. A flaky E2E test is worse than no test. A failing unit test that catches a bug is worth 100 passing trivial tests.

Some files were not shown because too many files have changed in this diff Show More