devstack 0.1.0

package/vendor/skills/skills/game-changing-features/SKILL.md

@@ -0,0 +1,287 @@
+---
+name: game-changing-features
+description: Find 10x product opportunities and high-leverage improvements. Use when user wants strategic product thinking, mentions '10x', wants to find high-impact features, or says 'what would make this 10x better', 'product strategy', or 'what should we build next'.
+---
+
+# 10x Mode
+
+You are a product strategist with founder mentality. We're not here to add features—we're here to find the moves that 10x the product's value. Think like you own this. What would make users unable to live without it?
+
+> **No Chat Output**: ALL responses go to `.claude/docs/ai/<product-or-area>/10x/session-N.md`
+> **No Code**: This is pure strategy. Implementation comes later.
+
+---
+
+## The Point
+
+Most product work is incremental: fix bugs, add requested features, polish edges. That's necessary but not sufficient.
+
+This mode forces a different question: **What would make this 10x more valuable?**
+
+Not 10% better. Not "nice to have." Game-changing. The kind of thing that makes users say "how did I live without this?"
+
+---
+
+## Session Setup
+
+User provides:
+
+- **Product/Area**: What we're thinking about
+- **Current state** (optional): Brief description of what exists
+- **Constraints** (optional): Technical limits, timeline, team size
+
+---
+
+## Workflow
+
+### Step 1: Understand Current Value
+
+Before proposing additions, understand what value exists:
+
+1. **What problem does this solve today?**
+2. **Who uses it and why?**
+3. **What's the core action users take?**
+4. **Where do users spend most time?**
+5. **What do users complain about / request most?**
+
+Research the codebase, look at existing features, understand the shape of the product.
+
+### Step 2: Find the 10x Opportunities
+
+Think across three scales:
+
+#### Massive (High effort, transformative)
+
+Features that fundamentally expand what the product can do. New markets, new use cases, new capabilities that weren't possible before.
+
+Ask:
+
+- What adjacent problem could we solve that would make this indispensable?
+- What would make this a platform instead of a tool?
+- What would make users bring their team/friends/family?
+- What's the feature that would make competitors nervous?
+
+#### Medium (Moderate effort, high leverage)
+
+Features that significantly enhance the core experience. Force multipliers on what already works.
+
+Ask:
+
+- What would make the core action 10x faster/easier?
+- What data do we have that we're not using?
+- What workflow is painful that we could automate?
+- What would turn casual users into power users?
+
+#### Small (Low effort, disproportionate value)
+
+Tiny changes that punch way above their weight. Often overlooked because they seem "too simple."
+
+Ask:
+
+- What single button/shortcut would save users minutes daily?
+- What information is users hunting for that we could surface?
+- What anxiety do users have that we could eliminate with one indicator?
+- What's the thing users do manually that we could remember/automate?
+
+### Step 3: Evaluate Ruthlessly
+
+For each idea, assess:
+
+| Criteria            | Question                                            |
+| ------------------- | --------------------------------------------------- |
+| **Impact**          | How much more valuable does this make the product?  |
+| **Reach**           | What % of users would this affect?                  |
+| **Frequency**       | How often would users encounter this value?         |
+| **Differentiation** | Does this set us apart or just match competitors?   |
+| **Defensibility**   | Is this easy to copy or does it compound over time? |
+| **Feasibility**     | Can we actually build this?                         |
+
+Use a simple scoring:
+
+- 🔥 **Must do** — High impact, clearly worth it
+- 👍 **Strong** — Good impact, should prioritize
+- 🤔 **Maybe** — Interesting but needs more thought
+- ❌ **Pass** — Not worth it right now
+
+### Step 4: Identify the Highest-Leverage Moves
+
+Look for:
+
+**Quick wins with outsized impact**
+
+- Small effort, big value
+- Often overlooked because they're "obvious"
+- Can ship fast, validate fast
+
+**Strategic bets**
+
+- Larger effort, potentially transformative
+- Opens new possibilities
+- Worth the investment if it works
+
+**Compounding features**
+
+- Get more valuable over time
+- Network effects, data effects, habit formation
+- Build moats
+
+### Step 5: Prioritize
+
+Don't just list ideas—stack rank them:
+
+```
+## Recommended Priority
+
+### Do Now (Quick wins)
+1. [Feature] — Why: [reason], Impact: [what changes]
+
+### Do Next (High leverage)
+1. [Feature] — Why: [reason], Unlocks: [what becomes possible]
+
+### Explore (Strategic bets)
+1. [Feature] — Why: [reason], Risk: [what could go wrong], Upside: [what we gain]
+
+### Backlog (Good but not now)
+1. [Feature] — Why later: [reason]
+```
+
+---
+
+## Idea Categories to Explore
+
+Force yourself through each category:
+
+| Category            | Question                         | Example                            |
+| ------------------- | -------------------------------- | ---------------------------------- |
+| **Speed**           | What takes too long?             | Instant search, predictive loading |
+| **Automation**      | What's repetitive?               | Auto-scheduling, smart defaults    |
+| **Intelligence**    | What could be smarter?           | Recommendations, anomaly detection |
+| **Integration**     | What else do users use?          | Calendar sync, export options      |
+| **Collaboration**   | How do users work together?      | Sharing, comments, real-time       |
+| **Personalization** | How is everyone different?       | Custom views, preferences          |
+| **Visibility**      | What's hidden that shouldn't be? | Dashboards, progress tracking      |
+| **Confidence**      | What creates anxiety?            | Confirmations, undo, previews      |
+| **Delight**         | What could spark joy?            | Animations, celebrations, polish   |
+| **Access**          | Who can't use this yet?          | Mobile, offline, accessibility     |
+
+---
+
+## Output Format
+
+```markdown
+# 10x Analysis: <Product/Area>
+
+Session N | Date: YYYY-MM-DD
+
+## Current Value
+
+What the product does today and for whom.
+
+## The Question
+
+What would make this 10x more valuable?
+
+---
+
+## Massive Opportunities
+
+### 1. [Feature Name]
+
+**What**: Description
+**Why 10x**: Why this is transformative
+**Unlocks**: What becomes possible
+**Effort**: High/Very High
+**Risk**: What could go wrong
+**Score**: 🔥/👍/🤔/❌
+
+### 2. ...
+
+---
+
+## Medium Opportunities
+
+### 1. [Feature Name]
+
+**What**: Description
+**Why 10x**: Why this matters more than it seems
+**Impact**: What changes for users
+**Effort**: Medium
+**Score**: 🔥/👍/🤔/❌
+
+### 2. ...
+
+---
+
+## Small Gems
+
+### 1. [Feature Name]
+
+**What**: Description (one line)
+**Why powerful**: Why this punches above its weight
+**Effort**: Low
+**Score**: 🔥/👍/🤔/❌
+
+### 2. ...
+
+---
+
+## Recommended Priority
+
+### Do Now
+
+1. ...
+
+### Do Next
+
+1. ...
+
+### Explore
+
+1. ...
+
+---
+
+## Questions
+
+### Answered
+
+- **Q**: ... **A**: ...
+
+### Blockers
+
+- **Q**: ... (need user input)
+
+## Next Steps
+
+- [ ] Validate assumption: ...
+- [ ] Research: ...
+- [ ] Decide: ...
+```
+
+---
+
+## Rules
+
+- **THINK BIG FIRST**—don't self-censor with "that's too hard." Capture the idea, evaluate later.
+- **SMALL CAN BE HUGE**—don't dismiss simple ideas. Sometimes one button changes everything.
+- **USER VALUE, NOT FEATURE COUNT**—10 features that add 1% each ≠ 1 feature that adds 10x.
+- **BE SPECIFIC**—"better UX" is not an idea. "One-click rescheduling from notification" is.
+- **QUESTION ASSUMPTIONS**—"users want X" may be wrong. What do they actually need?
+- **COMPOUND THINKING**—prefer features that get better over time.
+- **NO SAFE IDEAS**—if every idea is "obviously good," you're not thinking hard enough.
+- **CITE EVIDENCE**—if you saw something in the codebase or research, reference it.
+
+---
+
+## Prompts to Unstick Thinking
+
+If stuck, ask yourself:
+
+- "What would make a user tell their friend about this?"
+- "What's the thing users do every day that's slightly annoying?"
+- "What would we build if we had 10x the engineering team? 1/10th?"
+- "What would a competitor need to build to beat us?"
+- "What do power users do manually that we could make native?"
+- "What's the insight we have from data that users don't see?"
+- "What would make this addictive (in a good way)?"
+- "What's the feature that sounds crazy but might work?"

package/vendor/skills/skills/git-rebase/SKILL.md

@@ -0,0 +1,422 @@
+---
+name: git-rebase
+description: Intelligently handle git rebase operations and resolve merge conflicts while preserving features and maintaining code quality. Use when rebasing feature branches, resolving conflicts across commits, and ensuring clean linear history without losing changes.
+---
+
+# Git Rebase with Intelligent Conflict Resolution
+
+## Quick Start
+
+For most rebases with multiple commits, use the squash-first strategy to resolve conflicts only once:
+
+```bash
+# Step 1: Backup current state
+bash scripts/pre-rebase-backup.sh
+
+# Step 2: Squash commits (interactive rebase on current branch)
+git rebase -i $(git merge-base HEAD origin/main)
+
+# Step 3: Rebase onto target
+git rebase origin/main
+
+# Step 4: If conflicts, resolve them once (see workflow below)
+# Then continue: git rebase --continue
+
+# Step 5: Force push safely
+git push origin $(git rev-parse --abbrev-ref HEAD) --force-with-lease
+```
+
+This approach resolves conflicts once instead of per-commit, saving time and mental overhead.
+
+## Core Workflow: Conflict Analysis & Resolution
+
+Copy this checklist and mark progress:
+
+```
+Rebase Workflow:
+- [ ] Step 1: Create safety backup
+- [ ] Step 2: Fetch latest from target branch
+- [ ] Step 3: Analyze conflict scope
+- [ ] Step 4: Choose resolution strategy
+- [ ] Step 5: Apply conflict resolutions
+- [ ] Step 6: Validate merged code
+- [ ] Step 7: Run tests
+- [ ] Step 8: Force push safely
+```
+
+### Step 1: Create Safety Backup
+
+ALWAYS do this first. If rebase goes wrong, you can recover:
+
+```bash
+# Use the bundled script
+bash scripts/pre-rebase-backup.sh
+
+# Or manually create timestamped backup branch
+TIMESTAMP=$(date +%Y%m%d_%H%M%S)
+git branch backup-rebase-$TIMESTAMP
+
+# Alternative: Create temporary ref to your current commit
+git reflog  # Note your current HEAD SHA for manual recovery
+```
+
+This costs nothing and saves hours of work if something goes wrong.
+
+### Step 2: Fetch Latest Changes
+
+Ensure you have the most recent remote state:
+
+```bash
+# Fetch without modifying local branches
+git fetch origin
+
+# View the divergence
+git log --oneline origin/main..HEAD  # Your commits
+git log --oneline HEAD..origin/main  # New commits on main
+```
+
+Understand how many commits you're rebasing and how much main has changed.
+
+### Step 3: Analyze Conflict Scope
+
+Before starting the rebase, predict conflicts:
+
+```bash
+# See which files you changed
+git diff --name-only origin/main...HEAD
+
+# See which files main changed
+git diff --name-only origin/main HEAD
+
+# Likely conflict areas: files changed in both
+```
+
+**Key insight**: If you changed `auth.ts` and so did main, you WILL get conflicts in `auth.ts`.
+
+Anticipating conflicts helps you understand how to resolve them.
+
+### Step 4: Choose Resolution Strategy
+
+**For detailed strategy comparison and decision matrix**, see [references/strategies.md](references/strategies.md).
+
+#### Strategy A: Squash First (Recommended for 3+ commits)
+
+**When to use**: Multiple feature commits with many conflicts expected
+
+**Why**: Reduces conflicts to one resolution phase instead of per-commit
+
+```bash
+# Interactive rebase on current branch first
+git rebase -i $(git merge-base HEAD origin/main)
+
+# In editor, change all "pick" to "squash" (or 's') except first commit
+# Save and exit - commits are squashed into one
+# Edit commit message to describe the entire feature
+
+# Now rebase the squashed commit
+git rebase origin/main
+
+# Resolve conflicts once, then git rebase --continue
+```
+
+**Tradeoffs**: Lose individual commit history, but simpler conflict resolution
+
+#### Strategy B: Interactive Rebase with Conflict Awareness
+
+**When to use**: 1-2 commits, clean history, or complex per-commit logic
+
+```bash
+git rebase -i origin/main
+
+# In editor, you can:
+# - Reorder commits to isolate conflict-prone ones
+# - Drop commits that are already in main (git detects this)
+# - Combine related commits before rebasing
+
+# Save and exit - rebase proceeds, stopping at conflicts
+```
+
+**Tradeoffs**: More control, but more conflict-resolution iterations
+
+#### Strategy C: Simple Linear Rebase (Fastest, Auto-Resolution)
+
+**When to use**: Simple cases, no critical decisions, or in automated pipelines
+
+```bash
+# Rebase all commits at once
+git rebase origin/main
+
+# If no conflicts, done
+# If conflicts, you resolve each one
+```
+
+**Warning**: Not recommended for complex scenarios. Use Strategies A or B instead.
+
+### Step 5: Apply Conflict Resolutions
+
+When `git rebase` pauses with conflicts, use the analysis script:
+
+```bash
+# Analyze conflicts
+bash scripts/analyze-conflicts.sh
+
+# See which files conflict
+git status
+
+# For each conflicted file:
+# - RECOMMENDED: Use merge tool for visual clarity
+git mergetool --no-prompt
+
+# - ALTERNATIVE: Manual edit in your editor
+# Search for conflict markers: <<<<<<, ======, >>>>>>
+```
+
+#### Conflict Marker Anatomy
+
+```javascript
+<<<<<<< HEAD
+// Your current feature code
+function authenticate(token) {
+  validateToken(token);
+  return true;
+}
+=======
+// Main branch code (incoming)
+function authenticate(token) {
+  if (!token) throw new Error("No token");
+  validateToken(token);
+  setSession(token);
+  return true;
+}
+>>>>>>> origin/main
+```
+
+**Decision framework** (before deleting markers):
+
+1. **Can you keep both?** YES → Merge them intelligently
+
+   ```javascript
+   function authenticate(token) {
+     if (!token) throw new Error("No token"); // Keep main's validation
+     validateToken(token);
+     setSession(token); // Keep main's session setup
+     return true; // Keep feature's return
+   }
+   ```
+
+2. **Conflicting logic?** Understand WHY they differ, then decide
+   - Did main add critical security checks? → Keep main's version
+   - Did your feature add essential functionality? → Keep feature's version
+   - Are they trying to do different things? → Combine intentionally
+
+3. **Lost features?** NEVER let a feature silently disappear
+   - If you added authentication logic, ensure it's in final version
+   - If main improved database access, ensure that's preserved
+
+**For detailed resolution patterns**, see [references/resolution-patterns.md](references/resolution-patterns.md).
+
+#### Key Resolution Principles
+
+**✅ DO**:
+
+- Keep both versions' important functionality when possible
+- Use the merge tool for visual representation
+- Add comments explaining merged conflicts: `// Merged from both versions: main's validation + feature's session setup`
+- Test each file after resolution
+
+**❌ DON'T**:
+
+- Mindlessly pick one version without understanding both
+- Delete conflict markers without understanding the conflict
+- Keep duplicate code - merge intelligently
+- Skip testing before continuing
+
+### Step 6: Validate Merged Code
+
+After resolving conflicts, validate the merged code:
+
+```bash
+# Use the validation script
+bash scripts/validate-merge.sh
+
+# Manual checks:
+# 1. Check syntax
+npm run lint  # or eslint, pylint, etc.
+
+# 2. Check types (if TypeScript)
+npm run type-check  # or tsc --noEmit
+
+# 3. Spot-check key files
+git diff HEAD origin/main -- <conflicted-file>
+
+# If validation fails:
+# 1. Fix the issue in the file
+# 2. git add <file>
+# 3. git rebase --continue
+```
+
+**Important**: Validation catches mistakes BEFORE you commit them.
+
+### Step 7: Run Tests
+
+This is your safety net:
+
+```bash
+# Run full test suite
+npm test
+
+# Or specific tests for changed areas
+npm test -- --testPathPattern=auth  # If auth.ts was changed
+
+# If tests fail:
+# 1. Understand what broke
+# 2. Fix in the files
+# 3. git add <files>
+# 4. git rebase --continue
+```
+
+**Rule**: Never force-push code that fails tests.
+
+### Step 8: Force Push Safely
+
+Use `--force-with-lease` instead of `--force`. It protects against accidentally overwriting others' work:
+
+```bash
+# SAFE: Protects others' commits
+git push origin $(git rev-parse --abbrev-ref HEAD) --force-with-lease
+
+# UNSAFE: Can overwrite others' work
+git push origin your-branch -f  # Don't do this
+
+# If force-with-lease fails:
+# Someone else pushed to your branch
+# Coordinate with them before forcing
+```
+
+## Common Scenarios & Strategies
+
+### Scenario 1: Many Small Conflicts Across 5+ Commits
+
+**Use**: Squash-first strategy
+
+```bash
+git rebase -i $(git merge-base HEAD origin/main)
+# Mark all but first commit as 's' (squash)
+# Save - commits squash into one
+
+git rebase origin/main
+# Resolve conflicts once
+git rebase --continue
+
+# Only one conflict-resolution phase!
+```
+
+**Why**: Each commit might have conflicts. Squashing before rebasing means one pass.
+
+### Scenario 2: One Specific Commit Has Conflicts
+
+**Use**: Target that commit with interactive rebase
+
+```bash
+git rebase -i origin/main
+
+# In editor, move the problematic commit to the end
+# Save - rebase proceeds, stopping at that commit
+
+# When it stops, you know exactly which commit conflicts
+git status  # See what changed in this commit
+
+# Resolve, then continue
+git rebase --continue
+```
+
+**Why**: Isolating the commit helps you understand what it's trying to do.
+
+### Scenario 3: Conflicts Keep Repeating (Same File, Different Commits)
+
+**Use**: Git rerere (reuse recorded resolution)
+
+```bash
+# Enable rerere globally (one-time setup)
+git config --global rerere.enabled true
+
+# Now when you hit the same conflict in a second commit,
+# Git automatically applies the first commit's resolution
+
+git rebase origin/main
+
+# Git remembers your first conflict resolution
+# and replays it automatically for similar conflicts
+```
+
+**Why**: When rebasing and hitting the same file repeatedly, rerere saves manual work.
+
+### Scenario 4: Rebase Conflicts Are Too Complex
+
+**Emergency escape plan**:
+
+```bash
+# Abort the rebase - return to original state
+git rebase --abort
+
+# Fall back to merge (safer for complex scenarios)
+git merge origin/main
+
+# Or try a different approach:
+# - Squash your entire feature branch first
+# - Cherry-pick main's critical changes selectively
+```
+
+**Important**: It's okay to abort and rethink. Better than a broken rebase.
+
+## Bundled Scripts
+
+This skill includes helper scripts in `scripts/`:
+
+- **`pre-rebase-backup.sh`**: Creates a safety backup before rebasing
+- **`analyze-conflicts.sh`**: Analyzes current conflicts and provides detailed information
+- **`validate-merge.sh`**: Validates that merge/rebase is clean and ready for testing
+
+Run scripts with `bash scripts/<script-name>.sh`.
+
+## Reference Files
+
+For detailed information on specific topics:
+
+- **Strategies**: [references/strategies.md](references/strategies.md) - Complete strategy comparison and decision matrix
+- **Resolution Patterns**: [references/resolution-patterns.md](references/resolution-patterns.md) - Common conflict resolution patterns and heuristics
+- **Troubleshooting**: [references/troubleshooting.md](references/troubleshooting.md) - Solutions to common rebase problems
+- **Automation**: [references/automation.md](references/automation.md) - Automated conflict resolution for CI/CD
+- **Scripts & Tools**: [references/scripts-tools.md](references/scripts-tools.md) - Additional git commands and tool usage
+
+## Checklist: Before You Commit to Rebasing
+
+- [ ] Understand why you're rebasing (cleaner history, syncing with main, etc.)
+- [ ] Backup your current branch: `bash scripts/pre-rebase-backup.sh`
+- [ ] Run tests on current branch - they should pass
+- [ ] Fetch latest: `git fetch origin`
+- [ ] Understand what you'll be rebasing (5 commits? 50?)
+- [ ] Understand main's recent changes (1 commit? Major refactor?)
+- [ ] Choose your strategy (see [references/strategies.md](references/strategies.md))
+- [ ] Have your merge tool ready (if using GUI)
+- [ ] Block 30 mins - don't rush conflict resolution
+- [ ] Have tests ready to run after rebase
+
+## When NOT to Rebase
+
+- Shared branches (use merge instead: `git merge origin/main`)
+- Critical production code without comprehensive tests
+- When multiple people are pushing to the same branch
+- If you don't understand the conflicts you're seeing
+
+**Default to merge if uncertain.** Merge is safer for collaborative work.
+
+**Use rebase when**: Solo feature branch, clean history matters, no shared dependencies.
+
+## Summary: The Rebase Philosophy
+
+Rebasing is a tool for creating clean, linear commit history. **Used well**, it makes debugging and code review easier. **Used poorly**, it loses work.
+
+**The key principle**: Understand every conflict before resolving it. Don't automate away the thinking.
+
+With this Skill, you can rebase with confidence, understanding each decision and protecting your code throughout the process.