Initial commit

skills/common-patterns/bd-commands.md

@@ -0,0 +1,141 @@
+# bd Command Reference
+
+Common bd commands used across multiple skills. Reference this instead of duplicating.
+
+## Reading Issues
+
+```bash
+# Show single issue with full design
+bd show bd-3
+
+# List all open issues
+bd list --status open
+
+# List closed issues
+bd list --status closed
+
+# Show dependency tree for an epic
+bd dep tree bd-1
+
+# Find tasks ready to work on (no blocking dependencies)
+bd ready
+
+# List tasks in a specific epic
+bd list --parent bd-1
+```
+
+## Creating Issues
+
+```bash
+# Create epic
+bd create "Epic: Feature Name" \
+  --type epic \
+  --priority [0-4] \
+  --design "## Goal
+[Epic description]
+
+## Success Criteria
+- [ ] All phases complete
+..."
+
+# Create feature/phase
+bd create "Phase 1: Phase Name" \
+  --type feature \
+  --priority [0-4] \
+  --design "[Phase design]"
+
+# Create task
+bd create "Task Name" \
+  --type task \
+  --priority [0-4] \
+  --design "[Task design]"
+```
+
+## Updating Issues
+
+```bash
+# Update issue design (detailed description)
+bd update bd-3 --design "$(cat <<'EOF'
+[Complete updated design]
+EOF
+)"
+```
+
+**IMPORTANT**: Use `--design` for the full detailed description, NOT `--description` (which is title only).
+
+## Managing Status
+
+```bash
+# Start working on task
+bd update bd-3 --status in_progress
+
+# Complete task
+bd close bd-3
+
+# Reopen task
+bd update bd-3 --status open
+```
+
+**Common Mistakes:**
+```bash
+# ❌ WRONG - bd status shows database overview, doesn't change status
+bd status bd-3 --status in_progress
+
+# ✅ CORRECT - use bd update to change status
+bd update bd-3 --status in_progress
+
+# ❌ WRONG - using hyphens in status values
+bd update bd-3 --status in-progress
+
+# ✅ CORRECT - use underscores in status values
+bd update bd-3 --status in_progress
+
+# ❌ WRONG - 'done' is not a valid status
+bd update bd-3 --status done
+
+# ✅ CORRECT - use bd close to complete
+bd close bd-3
+```
+
+**Valid status values:** `open`, `in_progress`, `blocked`, `closed`
+
+## Managing Dependencies
+
+```bash
+# Add blocking dependency (LATER depends on EARLIER)
+# Syntax: bd dep add <dependent> <dependency>
+bd dep add bd-3 bd-2  # bd-3 depends on bd-2 (do bd-2 first)
+
+# Add parent-child relationship
+# Syntax: bd dep add <child> <parent> --type parent-child
+bd dep add bd-3 bd-1 --type parent-child  # bd-3 is child of bd-1
+
+# View dependency tree
+bd dep tree bd-1
+```
+
+## Commit Message Format
+
+Reference bd task IDs in commits (use hyperpowers:test-runner agent):
+
+```bash
+# Use test-runner agent to avoid pre-commit hook pollution
+Dispatch hyperpowers:test-runner agent: "Run: git add <files> && git commit -m 'feat(bd-3): implement feature
+
+Implements step 1 of bd-3: Task Name
+'"
+```
+
+## Common Queries
+
+```bash
+# Check if all tasks in epic are closed
+bd list --status open --parent bd-1
+# Output: [empty] = all closed
+
+# See what's blocking current work
+bd ready  # Shows only unblocked tasks
+
+# Find all in-progress work
+bd list --status in_progress
+```

skills/common-patterns/common-anti-patterns.md

@@ -0,0 +1,123 @@
+# Common Anti-Patterns
+
+Anti-patterns that apply across multiple skills. Reference this to avoid duplication.
+
+## Language-Specific Anti-Patterns
+
+### Rust
+
+```
+❌ No unwrap() or expect() in production code
+   Use proper error handling with Result/Option
+
+❌ No todo!(), unimplemented!(), or panic!() in production
+   Implement all code paths properly
+
+❌ No #[ignore] on tests without bd issue number
+   Fix or track broken tests
+
+❌ No unsafe blocks without documentation
+   Document safety invariants
+
+❌ Use proper array bounds checking
+   Prefer .get() over direct indexing in production
+```
+
+### Swift
+
+```
+❌ No force unwrap (!) in production code
+   Use optional chaining or guard/if let
+
+❌ No fatalError() in production code
+   Handle errors gracefully
+
+❌ No disabled tests without bd issue number
+   Fix or track broken tests
+
+❌ Use proper array bounds checking
+   Check indices before accessing
+
+❌ Handle all enum cases
+   No default: fatalError() shortcuts
+```
+
+### TypeScript
+
+```
+❌ No @ts-ignore or @ts-expect-error without bd issue number
+   Fix type issues properly
+
+❌ No any types without justification
+   Use proper typing
+
+❌ No .skip() on tests without bd issue number
+   Fix or track broken tests
+
+❌ No throw in async code without proper handling
+   Use try/catch or Promise.catch()
+```
+
+## General Anti-Patterns
+
+### Code Quality
+
+```
+❌ No TODOs or FIXMEs without bd issue numbers
+   Track work in bd, not in code comments
+
+❌ No stub implementations
+   Empty functions, placeholder returns forbidden
+
+❌ No commented-out code
+   Delete it - version control remembers
+
+❌ No debug print statements in commits
+   Remove console.log, println!, print() before committing
+
+❌ No "we'll do this later"
+   Either do it now or create bd issue and reference it
+```
+
+### Testing
+
+```
+❌ Don't test mock behavior
+   Test real behavior or unmock it
+
+❌ Don't add test-only methods to production code
+   Put in test utilities instead
+
+❌ Don't mock without understanding dependencies
+   Understand what you're testing first
+
+❌ Don't skip verifications
+   Run the test, see the output, then claim it passes
+```
+
+### Process
+
+```
+❌ Don't commit without running tests
+   Verify tests pass before committing
+
+❌ Don't create PR without running full test suite
+   All tests must pass before PR creation
+
+❌ Don't skip pre-commit hooks
+   Never use --no-verify
+
+❌ Don't force push without explicit request
+   Respect shared branch history
+
+❌ Don't assume backwards compatibility is desired
+   Ask if breaking changes are acceptable
+```
+
+## Project-Specific Additions
+
+Each project may have additional anti-patterns. Check CLAUDE.md for:
+- Project-specific code patterns to avoid
+- Custom linting rules
+- Framework-specific anti-patterns
+- Team conventions

skills/common-patterns/common-rationalizations.md

@@ -0,0 +1,99 @@
+# Common Rationalizations - STOP
+
+These rationalizations appear across multiple contexts. When you catch yourself thinking any of these, STOP - you're about to violate a skill.
+
+## Process Shortcuts
+
+| Excuse | Reality |
+|--------|---------|
+| "This is simple, can skip the process" | Simple tasks done wrong become complex problems. |
+| "Just this once" | No exceptions. Process exists because exceptions fail. |
+| "I'm confident this will work" | Confidence ≠ evidence. Run the verification. |
+| "I'm tired" | Exhaustion ≠ excuse for shortcuts. |
+| "No time for proper approach" | Shortcuts cost more time in rework. |
+| "Partner won't notice" | They will. Trust is earned through consistency. |
+| "Different words so rule doesn't apply" | Spirit over letter. Intent matters. |
+
+## Verification Shortcuts
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification command. |
+| "Looks correct" | Run it and see the output. |
+| "Tests probably pass" | Probably ≠ verified. Run them. |
+| "Linter passed, must be fine" | Linter ≠ compiler ≠ tests. Run everything. |
+| "Partial check is enough" | Partial proves nothing about the whole. |
+| "Agent said success" | Agents lie/hallucinate. Verify independently. |
+
+## Documentation Shortcuts
+
+| Excuse | Reality |
+|--------|---------|
+| "File probably exists" | Use tools to verify. Don't assume. |
+| "Design mentioned it, must be there" | Codebase changes. Verify current state. |
+| "I can verify quickly myself" | Use investigator agents. Prevents hallucination. |
+| "User can figure it out during execution" | Your job is exact instructions. No ambiguity. |
+
+## Planning Shortcuts
+
+| Excuse | Reality |
+|--------|---------|
+| "Can skip exploring alternatives" | Comparison reveals issues. Always propose 2-3. |
+| "Partner knows what they want" | Questions reveal hidden constraints. Always ask. |
+| "Whole design at once for efficiency" | Incremental validation catches problems early. |
+| "Checklist is just suggestion" | Create TodoWrite todos. Track properly. |
+| "Subtask can reference parent for details" | NO. Subtasks must be complete. NO placeholders, NO "see parent". |
+| "I'll use placeholder and fill in later" | NO. Write actual content NOW. No meta-references like "[detailed above]". |
+| "Design field is too long, use placeholder" | Length doesn't matter. Write full content. Placeholder defeats the purpose. |
+| "Should I continue to the next task?" | YES. You have a TodoWrite plan. Execute it. Don't interrupt your own workflow. |
+| "Let me ask user's preference for remaining tasks" | NO. The user gave you the work. Do it. Only ask at natural completion points. |
+| "Should I stop here or keep going?" | Your TodoWrite list tells you. If tasks remain, continue. |
+
+## Execution Shortcuts
+
+| Excuse | Reality |
+|--------|---------|
+| "Task is tracked in TodoWrite, don't need step tracking" | Tasks have 4-8 implementation steps. Without substep tracking, steps 4-8 get skipped. |
+| "Made progress on the task, can move on" | Progress ≠ complete. All substeps must finish. 2/6 steps = 33%, not done. |
+| "Other tasks are waiting, should continue" | Current task incomplete = blocked. Finish all substeps first. |
+| "Can finish remaining steps later" | Later never comes. Complete all substeps now before closing task. |
+
+## Quality Shortcuts
+
+| Excuse | Reality |
+|--------|---------|
+| "Small gaps don't matter" | Spec is contract. All criteria must be met. |
+| "Will fix in next PR" | This PR should complete this work. Fix now. |
+| "Partner will review anyway" | You review first. Don't delegate your quality check. |
+| "Good enough for now" | "Now" becomes "forever". Do it right. |
+
+## TDD Shortcuts
+
+| Excuse | Reality |
+|--------|---------|
+| "Test is obvious, can skip RED phase" | If you don't watch it fail, you don't know it works. |
+| "Will adapt this code while writing test" | Delete it. Start fresh from the test. |
+| "Can keep it as reference" | No. Delete means delete. |
+| "Test is simple, don't need to run it" | Simple tests fail for subtle reasons. Run it. |
+
+## Research Shortcuts
+
+| Excuse | Reality |
+|--------|---------|
+| "I can research quickly myself" | Use agents. You'll hallucinate or waste context. |
+| "Agent didn't find it first try, must not exist" | Be persistent. Refine query and try again. |
+| "I know this codebase" | You don't know current state. Always verify. |
+| "Obvious solution, skip research" | Codebase may have established pattern. Check first. |
+
+**All of these mean: STOP. Follow the requirements exactly.**
+
+## Why This Matters
+
+Rationalizations are how good processes fail:
+1. Developer thinks "just this once"
+2. Shortcut causes subtle bug
+3. Bug found in production/PR
+4. More time spent fixing than process would have cost
+5. Trust damaged
+
+**No shortcuts. Follow the process. Every time.**