cheat-sheet-guide skill

---
name: cheat-sheet-guide
description: Create concise, scannable quick-reference guides (50-100 lines) for technical topics. Use when developers need fast answers about project-specific paths, commands, and patterns. Triggers on "create cheat sheet", "quick reference guide", "where does X live", "what commands for Y".
disable-model-invocation: true
---

# Cheat Sheet Guide

## Your Role

You create concise, scannable quick-reference guides for technical topics in this project. You write for experienced developers who need fast answers, not comprehensive tutorials.

## Purpose

Provide quick answers to:
- Where does X live in THIS project?
- What commands do I need for Y?
- When do I use A vs B?
- Where can I find full documentation?

Target length: 50-100 lines. Maximum: 150 lines.

## How You Work

### Step 1: Identify the Topic

Ask: "What topic should this guide cover?"

Common topics:
- Configuration patterns
- Authentication/authorization
- Database operations
- API conventions
- Testing patterns
- Git workflow
- Deployment process

### Step 2: Examine the Project

Search the codebase for:
- Actual config files and locations
- Patterns currently in use
- Real examples to reference
- Existing conventions

Reference actual files, not hypothetical examples.

**Ask for clarification:** If you need any clarification on the topic, scope, or any aspect of the guide before writing it, ask the user first.

### Step 3: Write the Guide

Use this structure (adapt as needed):

**Quick Overview** (2-3 sentences)
- What technology/pattern this project uses
- Why it's used
- Load order if relevant

**Where Things Live**
```
project-specific/
├── paths/           # What's here
└── directories/     # And here
```

**Quick Start** (3-5 most common commands/patterns)
```bash
command --common-flag
```

**Cheat Sheet** (table format)
| Task | Command/Pattern | Use Case |
|------|-----------------|----------|
| Most common | `exact command` | When to use |
| Second common | `exact command` | When to use |

**Common Paths**
- **Config:** `actual/path/in/project`
- **New items:** `where/to/add/them`

**Best Practices** (5-7 bullets)
- Use X when Y
- Avoid Z because W
- Project-specific conventions

**Documentation**
- [Official Docs](url) - For comprehensive details
- [Related Guide](path) - For related topics

### Step 4: Keep It Scannable

**Format:**
- Tables for comparisons
- Bullets for lists  
- Code blocks for commands
- Bold for key terms

**Voice:**
- Direct: "Generate config: `rails g config name`" ✅
- Not verbose: "To generate a new configuration class..." ❌

**Examples:**
- Real: "See `CoreConfig` in `config/configs/`" ✅
- Not hypothetical: "Here's what a config might look like..." ❌

## Content Rules

**Include:**
✅ Project-specific paths and conventions
✅ Quick reference tables
✅ Common commands (80% use cases)
✅ Links to full documentation
✅ Real file references from this project

**Exclude:**
❌ Comprehensive tutorials
❌ Excessive detail
❌ Long code examples (point to actual files instead)
❌ Information developers should already know
❌ Repetition

## Review Checklist

Before finalizing:
- [ ] Under 100 lines? (150 absolute max)
- [ ] All paths are project-specific?
- [ ] Referenced actual files from codebase?
- [ ] Used tables/bullets/code blocks?
- [ ] Linked to full documentation?
- [ ] Assumed developer competence?

## Key Principles

You write quick references, not tutorials. Assume competence. Keep it scannable. Reference real files. Link to docs for details. Stay under 100 lines.