# Professional Development Superskill

> Comprehensive superskill consolidating 41 professional development skills across planning, testing, debugging, code review, git workflow, writing, architecture, meta-skills, thinking frameworks, and communication. Use when you need a complete reference for software development best practices, workflows, and methodologies.

- Skill: `majiayu000/professional-development-superskill` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/professional-development-superskill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/professional-development-superskill/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/professional-development-superskill

---


# Professional Development Superskill

A comprehensive reference consolidating 41 professional skills into one complete guide.

## 📚 Table of Contents

### I. Development Process
1. [Brainstorming](#1-brainstorming) - Ideas → Designs
2. [Writing Plans](#2-writing-plans) - Implementation planning
3. [Executing Plans](#3-executing-plans) - Systematic execution
4. [Verification Before Completion](#4-verification-before-completion) - Quality gates

### II. Testing
5. [Test-Driven Development](#5-test-driven-development) - Tests first
6. [Testing with Subagents](#6-testing-with-subagents) - Multi-agent testing
7. [Testing Anti-Patterns](#7-testing-anti-patterns) - Mistakes to avoid
8. [Condition-Based Waiting](#8-condition-based-waiting) - Replace timeouts
9. [Test Under Pressure](#9-test-under-pressure) - Time-constrained testing

### III. Debugging
10. [Systematic Debugging](#10-systematic-debugging) - Four-phase framework
11. [Root Cause Tracing](#11-root-cause-tracing) - Find origins
12. [When Stuck](#12-when-stuck) - Get unstuck

### IV. Code Review
13. [Code Reviewer](#13-code-reviewer) - Reviewing effectively
14. [Requesting Reviews](#14-requesting-reviews) - Get good reviews
15. [Receiving Reviews](#15-receiving-reviews) - Handle feedback

### V. Git & Workflow
16. [Using Git Worktrees](#16-using-git-worktrees) - Multiple branches
17. [Finishing Branches](#17-finishing-branches) - Complete work

### VI. Writing & Documentation
18. [Writing Skills](#18-writing-skills) - Technical writing
19. [Writing Clearly and Concisely](#19-writing-clearly-and-concisely) - Clear prose
20. [Elements of Style](#20-elements-of-style) - Timeless principles

### VII. Architecture & Design
21. [Defense in Depth](#21-defense-in-depth) - Layered validation
22. [Subagent-Driven Development](#22-subagent-driven-development) - Autonomous agents
23. [Dispatching Parallel Agents](#23-dispatching-parallel-agents) - Coordination
24. [Collision Zone Thinking](#24-collision-zone-thinking) - Identify conflicts
25. [Preserving Productive Tensions](#25-preserving-productive-tensions) - Balance forces
26. [Simplification Cascades](#26-simplification-cascades) - Progressive simplification

### VIII. Meta-Skills
27. [Using Skills](#27-using-skills) - Apply skills effectively
28. [Using Superpowers](#28-using-superpowers) - Advanced techniques
29. [Sharing Skills](#29-sharing-skills) - Distribute knowledge
30. [Gardening Skills Wiki](#30-gardening-skills-wiki) - Maintain library
31. [Pulling Updates](#31-pulling-updates) - Sync repositories

### IX. Thinking & Analysis
32. [Meta-Pattern Recognition](#32-meta-pattern-recognition) - Cross-domain patterns
33. [Inversion Exercise](#33-inversion-exercise) - Think backwards
34. [Tracing Knowledge Lineages](#34-tracing-knowledge-lineages) - Knowledge evolution
35. [Search Agent](#35-search-agent) - Effective searching
36. [Remembering Conversations](#36-remembering-conversations) - Context retention

### X. Communication
37. [Persuasion Principles](#37-persuasion-principles) - Influence effectively
38. [Scale Game](#38-scale-game) - Communication at scale

---

# I. Development Process

## 1. Brainstorming

**Purpose:** Transform rough ideas into fully-formed designs through structured questioning.

**Core Principle:** Ask questions to understand, explore alternatives, present design incrementally for validation.

### The 6-Phase Process

1. **Understanding** - Ask ONE question at a time, gather purpose/constraints/criteria
2. **Exploration** - Propose 2-3 approaches with trade-offs
3. **Design Presentation** - Present in 200-300 word sections, validate each
4. **Design Documentation** - Write to `docs/plans/YYYY-MM-DD-<topic>-design.md`
5. **Worktree Setup** - Set up isolated workspace (if implementing)
6. **Planning Handoff** - Create implementation plan

### Key Principles
- **One question at a time** - Never overwhelm with multiple questions
- **YAGNI ruthlessly** - Remove unnecessary features
- **Explore alternatives** - Always propose 2-3 approaches
- **Incremental validation** - Validate each section
- **Flexible progression** - Go backward when needed

### When to Use
- Before writing code
- Before creating implementation plans
- When refining rough ideas into designs

---

## 2. Writing Plans

**Purpose:** Create detailed implementation plans from validated designs.

**Core Principle:** Break work into concrete, verifiable tasks with clear dependencies.

### Plan Structure

```markdown
# Implementation Plan: [Feature Name]

## Overview
- Goal: What we're building
- Context: Why we're building it
- Success criteria: How we know it's done

## Tasks

### Phase 1: Foundation
- [ ] Task 1 (Est: 2h)
  - Why: Reason for task
  - Acceptance: How to verify
  - Dependencies: What must be done first

### Phase 2: Core Features
...

## Risks & Mitigation
- Risk 1: Description → Mitigation strategy

## Testing Strategy
How will we verify this works?
```

### Key Elements
- **Task hierarchy** - Organize by phases
- **Clear acceptance criteria** - Know when done
- **Dependencies explicit** - What blocks what
- **Time estimates** - Rough sizing
- **Risk identification** - Surface problems early

---

## 3. Executing Plans

**Purpose:** Systematically execute implementation plans while adapting to discoveries.

**Core Principle:** Follow the plan, but adapt when reality differs from expectations.

### Execution Process

1. **Start with current task** - Follow plan order
2. **Document deviations** - Note when plan differs from reality
3. **Update as you go** - Keep plan synchronized
4. **Verify completion** - Check acceptance criteria
5. **Mark complete** - Update task status

### When to Deviate
- Discovery makes approach obsolete
- Dependency breaks assumption
- Better approach becomes clear
- **Document WHY you deviated**

### Tracking Progress
```markdown
## Progress Log
- [x] Task 1 - Completed 2h (estimated 2h)
- [x] Task 2 - Completed 3h (estimated 2h) - Reason for variance
- [ ] Task 3 - In progress
```

---

## 4. Verification Before Completion

**Purpose:** Comprehensive verification before marking work complete.

**Core Principle:** Never mark done until ALL criteria met.

### Verification Checklist

**Functionality**
- [ ] All requirements implemented
- [ ] All acceptance criteria met
- [ ] Edge cases handled
- [ ] Error cases handled

**Testing**
- [ ] Unit tests written and passing
- [ ] Integration tests passing
- [ ] Manual testing completed
- [ ] No test regressions

**Code Quality**
- [ ] Code reviewed (or self-reviewed)
- [ ] No obvious bugs
- [ ] Follows project conventions
- [ ] Appropriate comments

**Documentation**
- [ ] README updated if needed
- [ ] API docs updated
- [ ] Comments explain "why" not "what"

**Integration**
- [ ] Merges cleanly with main
- [ ] No conflicts
- [ ] CI/CD passing
- [ ] Deployable

---

# II. Testing

## 5. Test-Driven Development

**Purpose:** Write tests before implementation to drive design and ensure correctness.

**Core Principle:** Red → Green → Refactor

### The TDD Cycle

1. **RED** - Write a failing test
   - Test describes desired behavior
   - Should fail for right reason
   - Minimal test to start

2. **GREEN** - Make it pass
   - Simplest code that works
   - Don't worry about perfect yet
   - Just make test pass

3. **REFACTOR** - Improve the code
   - Now make it clean
   - Tests stay green
   - Improve design

4. **REPEAT** - Next test

### TDD Principles

- **Test first, always** - No production code without failing test
- **Minimal implementation** - Just enough to pass
- **Continuous refactoring** - Keep code clean
- **Tests as specification** - Tests document behavior
- **Fast feedback** - Tests run in seconds

### When NOT to TDD
- Exploratory spike (time-boxed)
- Throwaway prototype
- UI layout tweaking
- **But** - Even these benefit from tests eventually

---

## 6. Testing with Subagents

**Purpose:** Test complex multi-agent or skill-based systems.

**Core Principle:** Isolate agents, mock dependencies, verify integration.

### Testing Strategies

**Unit Test Individual Agents**
- Test agent logic in isolation
- Mock external dependencies
- Verify single responsibility

**Integration Test Agent Coordination**
- Test agents working together
- Use test doubles for external systems
- Verify communication protocols

**End-to-End Test Full System**
- All agents, real dependencies
- Test critical user journeys
- Keep these minimal (slow, brittle)

### Agent Testing Patterns

**Mock Subagent Responses**
```python
def test_coordinator_handles_agent_failure():
    mock_agent = Mock(return_value=Error("Agent failed"))
    coordinator = Coordinator(agent=mock_agent)
    result = coordinator.execute_task()
    assert result.handled_gracefully
```

**Test Agent State Management**
- Verify state transitions
- Test concurrent access
- Validate state persistence

---

## 7. Testing Anti-Patterns

**Purpose:** Recognize and avoid common testing mistakes.

**Core Principle:** Tests should be fast, isolated, reliable, and maintainable.

### Common Anti-Patterns

**1. Fragile Tests**
- **Problem:** Tests break on irrelevant changes
- **Solution:** Test behavior, not implementation

**2. Test Interdependence**
- **Problem:** Tests must run in specific order
- **Solution:** Each test completely isolated

**3. Over-Mocking**
- **Problem:** Mocking everything, testing nothing real
- **Solution:** Mock external dependencies only

**4. Poor Assertions**
- **Problem:** `assert result != null`
- **Solution:** `assert result.value == expected_value`

**5. Slow Test Suites**
- **Problem:** Tests take minutes to run
- **Solution:** Fast unit tests, minimal integration tests

**6. Testing Private Methods**
- **Problem:** Coupled to implementation
- **Solution:** Test public interface only

**7. Not Testing Edge Cases**
- **Problem:** Only happy path tested
- **Solution:** Test error cases, boundaries, edge cases

---

## 8. Condition-Based Waiting

**Purpose:** Replace arbitrary timeouts with actual condition checks.

**Core Principle:** Wait for the condition, not arbitrary time.

### The Problem with Sleep

```python
# BAD - Arbitrary timeout
click_button()
time.sleep(5)  # Hope it's loaded
assert element_visible()
```

### Solution: Wait for Condition

```python
# GOOD - Wait for actual condition
click_button()
wait_until(lambda: element_visible(), timeout=10, interval=0.1)
assert element_visible()
```

### Implementation Pattern

```python
def wait_until(condition, timeout=10, interval=0.1):
    start = time.time()
    while time.time() - start < timeout:
        if condition():
            return True
        time.sleep(interval)
    raise TimeoutError(f"Condition not met after {timeout}s")
```

### Benefits
- **Deterministic** - Tests don't randomly fail
- **Faster** - Don't wait longer than needed
- **Clear failure messages** - Know what condition failed

---

## 9. Test Under Pressure

**Purpose:** Testing strategies when time is limited.

**Core Principle:** Risk-based testing - test the most important things first.

### Pressure Testing Strategy

**Phase 1: Critical Path (Must Have)**
- Core functionality
- Happy path for main features
- Data integrity
- Security basics

**Phase 2: Important Features (Should Have)**
- Secondary features
- Common error cases
- Integration points

**Phase 3: Nice to Have (Could Have)**
- Edge cases
- Performance testing
- Comprehensive error handling

### Time-Saving Techniques

**Smoke Tests** - Quick "does it work at all?" tests
**Parallel Testing** - Run tests concurrently
**Test Prioritization** - Most critical first
**Manual Verification** - For UI when time-pressed
**Defer Comprehensive** - Note what's untested

### When to Stop
- Critical path covered
- No known blocking bugs
- Risks documented
- Plan for post-release testing

---

# III. Debugging

## 10. Systematic Debugging

**Purpose:** Four-phase framework ensuring root cause investigation before fixes.

**Core Principle:** NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

### The Iron Law

```
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
```

If you haven't completed Phase 1, you cannot propose fixes.

### The Four Phases

**Phase 1: Root Cause Investigation**

1. Read error messages carefully - completely
2. Reproduce consistently - exact steps
3. Check recent changes - what changed?
4. Gather evidence in multi-component systems:
   - Log data entering/exiting each component
   - Verify config propagation
   - Check state at each layer
5. Trace data flow - where does bad value originate?

**Phase 2: Pattern Analysis**

1. Find working examples - what works that's similar?
2. Compare against references - read completely
3. Identify differences - list every difference
4. Understand dependencies - what does this need?

**Phase 3: Hypothesis and Testing**

1. Form single hypothesis - "I think X because Y"
2. Test minimally - smallest possible change
3. Verify before continuing - did it work?
4. When you don't know - say so, ask for help

**Phase 4: Implementation**

1. Create failing test case - simplest reproduction
2. Implement single fix - address root cause
3. Verify fix - test passes, no regressions
4. If fix doesn't work - Return to Phase 1
5. **If 3+ fixes failed** - Question the architecture

### Red Flags - STOP

- "Quick fix for now, investigate later"
- "Just try changing X and see"
- "Add multiple changes, run tests"
- "Skip the test, I'll manually verify"
- "I don't fully understand but this might work"
- "One more fix attempt" (after 2+ failures)

### After 3 Failed Fixes

**STOP and question fundamentals:**
- Is this pattern fundamentally sound?
- Should we refactor architecture vs. continue fixing symptoms?
- Discuss with team before attempting more fixes

---

## 11. Root Cause Tracing

**Purpose:** Trace issues backward through call stack to find their origin.

**Core Principle:** Fix at source, not at symptom.

### Backward Tracing Technique

1. **Start at error location** - Where does it fail?
2. **Trace back one step** - What called this with bad value?
3. **Continue upward** - Keep tracing to source
4. **Find the origin** - Where did bad value start?
5. **Fix at source** - Not at symptom location

### Example Trace

```
Error: Invalid user ID "-1"
  ↑ renderUserProfile(userId=-1)
  ↑ getUserProfile(userId=-1)
  ↑ processRequest(params={userId: "-1"})
  ↑ parseQueryString("?userId=-1")  ← SOURCE OF PROBLEM
  
Fix: Add validation in parseQueryString, not in renderUserProfile
```

### Tracing Patterns

**Bad Value Propagation**
- Value starts bad → Fix at origin
- Value becomes bad → Fix at transformation

**Missing Validation**
- Data crosses trust boundary → Add validation there
- Internal function assumes valid → Validate at entry

**State Corruption**
- Who last modified state?
- What sequence led to corruption?
- Fix the sequence, not the symptom

---

## 12. When Stuck

**Purpose:** Strategies to identify why you're stuck and get unstuck.

**Core Principle:** Recognize the pattern of being stuck, then change approach.

### Signs You're Stuck

- Trying same thing repeatedly
- Making no progress for >30 minutes
- Feeling frustrated or confused
- Not sure what to try next
- Each attempt reveals new problem

### Unsticking Strategies

**1. Take a Break**
- Step away for 5-10 minutes
- Fresh perspective often helps
- Don't force it

**2. Explain the Problem**
- Rubber duck debugging
- Write it down
- Tell someone else
- Often solution appears while explaining

**3. Question Assumptions**
- What am I assuming is true?
- Is that assumption correct?
- What if the opposite were true?

**4. Simplify**
- Remove complexity
- Test smallest possible case
- Build up from working baseline

**5. Change Approach**
- Try different angle
- Different tool
- Different strategy

**6. Ask for Help**
- Don't suffer alone
- Someone else's perspective helps
- Describe what you've tried

### When to Ask for Help

- After 3 failed attempts
- When fundamentally confused
- When time-critical
- **Earlier is better than later**

---

# IV. Code Review

## 13. Code Reviewer

**Purpose:** Provide valuable, constructive code reviews.

**Core Principle:** Review for correctness first, then everything else.

### Review Priority Order

1. **Correctness** - Does it work?
2. **Security** - Any vulnerabilities?
3. **Performance** - Any obvious issues?
4. **Maintainability** - Can others understand/modify?
5. **Style** - Follows conventions?

### Review Checklist

**Functionality**
- Does code do what PR says?
- Are edge cases handled?
- Are error cases handled?

**Security**
- Input validation?
- SQL injection risks?
- XSS vulnerabilities?
- Authentication/authorization?

**Testing**
- Are there tests?
- Do tests cover important cases?
- Are tests clear and maintainable?

**Design**
- Is design appropriate?
- Too complex or too simple?
- Fits with existing architecture?

**Readability**
- Can you understand it?
- Are names clear?
- Is flow logical?

### Giving Feedback

**Be Constructive**
- Explain WHY something is a problem
- Suggest alternatives
- Balance critique with praise

**Be Specific**
```
# Bad
"This is confusing"

# Good  
"The variable name 'x' doesn't indicate what it represents. Consider 'userId' instead."
```

**Distinguish Blocking vs. Non-Blocking**
- **Blocking:** Must fix (bugs, security)
- **Non-blocking:** Suggestions (style, optimization)

---

## 14. Requesting Reviews

**Purpose:** Prepare code reviews that reviewers can act on quickly.

**Core Principle:** Make reviewer's job easy.

### Before Requesting Review

**Self-Review First**
- Read your own code
- Check for obvious issues
- Run tests locally
- Review the diff

**Make it Reviewable**
- Small, focused changes
- One logical change per PR
- Clear title and description

### PR Description Template

```markdown
## What
Brief description of change

## Why
Why is this change needed?

## How
How does it work?

## Testing
- [ ] Unit tests added/updated
- [ ] Manual testing completed
- [ ] No regressions

## Screenshots
(if UI change)

## Notes for Reviewer
Anything tricky or unusual?
```

### Size Guidelines

- **Small:** < 200 lines - Easy to review
- **Medium:** 200-500 lines - Takes focus
- **Large:** 500+ lines - Consider breaking up

---

## 15. Receiving Reviews

**Purpose:** Respond to code review feedback constructively.

**Core Principle:** Assume good intent, learn from feedback.

### Responding to Feedback

**1. Assume Good Intent**
- Reviewer wants to help
- Not personal attack
- Opportunity to learn

**2. Ask Clarifying Questions**
```
"Could you elaborate on why this is a concern?"
"What alternative approach would you suggest?"
```

**3. Defend When Needed**
- Explain reasoning objectively
- Provide context reviewer might lack
- Be open to being wrong

**4. Thank Reviewers**
- Appreciate their time
- Acknowledge good catches
- Build positive relationship

### Handling Different Feedback Types

**Bugs Found**
- "Good catch! I'll fix that."
- Fix and re-request review

**Design Disagreements**
- Discuss trade-offs objectively
- May need to escalate if can't agree
- Document decision

**Style Nitpicks**
- If convention exists: follow it
- If no convention: discuss with team
- Don't fight over preferences

---

# V. Git & Workflow

## 16. Using Git Worktrees

**Purpose:** Work on multiple branches simultaneously without switching.

**Core Principle:** Separate working directories per branch, no switching overhead.

### What Are Worktrees?

Git worktrees let you check out multiple branches into different directories simultaneously.

```
project/
├── main/           (main branch)
├── feature-a/      (feature-a branch)
└── feature-b/      (feature-b branch)
```

### Creating a Worktree

```bash
# From main repo
git worktree add ../project-feature-a feature-a

# Creates new directory with feature-a branch checked out
cd ../project-feature-a
# Work on feature-a without affecting main
```

### Benefits

- **No branch switching** - Open multiple in IDE
- **Parallel testing** - Test different branches simultaneously
- **Comparison** - Easy to compare branches
- **No stashing** - Work-in-progress stays in place

### Worktree Workflow

```bash
# List worktrees
git worktree list

# Create new worktree
git worktree add path/to/dir branch-name

# Remove worktree (after done)
git worktree remove path/to/dir

# Or just delete directory and prune
rm -rf path/to/dir
git worktree prune
```

### Safety Checks

**Before creating worktree:**
- [ ] Main branch is clean
- [ ] Target directory doesn't exist
- [ ] Branch name is clear

---

## 17. Finishing Branches

**Purpose:** Properly complete and merge development branches.

**Core Principle:** Clean history, verified work, proper cleanup.

### Branch Completion Checklist

**Before Merging**
- [ ] All tests passing
- [ ] Code reviewed and approved
- [ ] Conflicts resolved
- [ ] Commit history clean
- [ ] Branch up-to-date with main

**Merge Strategy**

**Option 1: Merge Commit**
```bash
git checkout main
git merge --no-ff feature-branch
```
- Preserves branch history
- Clear feature boundary
- Good for feature branches

**Option 2: Rebase**
```bash
git checkout feature-branch
git rebase main
git checkout main
git merge --ff-only feature-branch
```
- Linear history
- Cleaner log
- Good for small changes

**Option 3: Squash**
```bash
git checkout main
git merge --squash feature-branch
git commit -m "Feature: description"
```
- Single commit
- Clean history
- Good for many small commits

**After Merging**
- [ ] Delete feature branch locally
- [ ] Delete feature branch remotely
- [ ] Tag if releasing
- [ ] Update documentation

---

# VI. Writing & Documentation

## 18. Writing Skills

**Purpose:** Comprehensive guide to technical and documentation writing.

**Core Principle:** Write for your audience with clarity and precision.

### Know Your Audience

**Technical Level**
- Expert: Use jargon, skip basics
- Intermediate: Explain concepts, provide context
- Beginner: Define terms, provide examples

**Purpose**
- Learning: Step-by-step, examples
- Reference: Quick lookup, comprehensive
- Troubleshooting: Problem-focused, solutions

### Document Structure

**Every Document Needs:**
1. **Title** - What is this?
2. **Overview** - What will I learn?
3. **Prerequisites** - What do I need to know?
4. **Content** - The actual information
5. **Examples** - Show, don't just tell
6. **Summary** - What did I learn?

### Writing Guidelines

**Be Clear**
- Short sentences
- Active voice
- Specific words
- One idea per paragraph

**Be Precise**
- Exact terms
- No ambiguity
- Define acronyms
- Consistent terminology

**Be Concise**
- Remove unnecessary words
- Get to the point
- Don't repeat
- Value reader's time

### Code Examples

```markdown
# Good example
## Installing the Package

Install using pip:
```bash
pip install package-name
```

Verify installation:
```bash
python -c "import package; print(package.__version__)"
```
```

---

## 19. Writing Clearly and Concisely

**Purpose:** Apply timeless rules for clear, strong, professional writing.

**Core Principle:** Omit needless words, use active voice, be specific.

### Strunk's Key Rules

**1. Use Active Voice**
```
# Passive
The bug was fixed by the developer.

# Active
The developer fixed the bug.
```

**2. Omit Needless Words**
```
# Wordy
Due to the fact that the system was experiencing issues...

# Concise
Because the system had issues...
```

**3. Use Specific, Concrete Language**
```
# Vague
The system is slow.

# Specific
The API responds in 5 seconds (target: <1 second).
```

**4. Avoid Qualifiers**
```
# Weak
The code is somewhat complex.

# Strong
The code is complex.
```

**5. Parallel Construction**
```
# Inconsistent
The function should validate input, processing the data, and return results.

# Parallel
The function should validate input, process data, and return results.
```

### Quick Improvement Checklist

- [ ] Remove "very", "really", "quite"
- [ ] Change passive to active voice
- [ ] Replace "there is/are" constructions
- [ ] Make subjects and verbs close together
- [ ] Use specific nouns, strong verbs

---

## 20. Elements of Style

**Purpose:** Classical writing principles from Strunk & White.

**Core Principle:** Elementary rules create clear, vigorous prose.

### Elementary Rules of Usage

1. **Form possessive singular** - Add 's (Charles's)
2. **In a series, use comma** - red, white, and blue
3. **Enclose parenthetic expressions** - Use commas
4. **Place a comma before** - conjunction in compound sentence
5. **Do not join independent clauses** - Use semicolon

### Elementary Principles of Composition

1. **Choose a suitable design** - Plan before writing
2. **Make the paragraph the unit** - One topic per paragraph
3. **Use active voice** - Subject acts
4. **Put statements in positive form** - Say what is, not isn't
5. **Use definite, specific, concrete language** - Precision
6. **Omit needless words** - Brevity
7. **Avoid succession of loose sentences** - Vary structure
8. **Express coordinate ideas in similar form** - Parallel
9. **Keep related words together** - Proximity
10. **In summaries, same tense** - Consistency
11. **Place emphatic words at the end** - Power position

### Words Often Misused

- **affect/effect** - Affect = verb, Effect = noun
- **comprise/compose** - Whole comprises parts
- **different from/than** - Different from (not than)
- **less/fewer** - Less (mass), Fewer (count)
- **which/that** - That (restrictive), Which (non-restrictive)

---

# VII. Architecture & Design

## 21. Defense in Depth

**Purpose:** Implement multiple layers of validation and protection.

**Core Principle:** Never rely on a single layer of defense.

### Layered Validation

**Layer 1: Input Validation**
```python
def process_user_input(data):
    # First line of defense
    if not isinstance(data, dict):
        raise ValueError("Invalid input type")
    if "id" not in data:
        raise ValueError("Missing required field: id")
```

**Layer 2: Business Logic Validation**
```python
def update_user(user_id, changes):
    # Second line of defense
    user = get_user(user_id)
    if not user:
        raise NotFound("User not found")
    if not has_permission(current_user, user):
        raise Forbidden("No permission to update")
```

**Layer 3: Database Constraints**
```sql
CREATE TABLE users (
    id INT PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);
```

### Defense Layers

1. **Client-side** - UX, not security
2. **API Gateway** - Rate limiting, authentication
3. **Application** - Business logic validation
4. **Database** - Constraints, transactions
5. **Infrastructure** - Firewalls, network isolation

### Principles

- **Fail securely** - Default to deny
- **Validate explicitly** - Never assume
- **Principle of least privilege** - Minimum necessary access
- **Defense in depth** - Multiple layers

---

## 22. Subagent-Driven Development

**Purpose:** Coordinate development using autonomous sub-agents.

**Core Principle:** Independent agents with clear interfaces and responsibilities.

### Agent Decomposition

**Identify Agents**
- Each handles one responsibility
- Clear input/output contract
- Can operate independently
- Minimal shared state

**Example Decomposition**
```
Project: E-commerce System

Agents:
- ProductCatalogAgent - Manages products
- OrderProcessingAgent - Handles orders
- PaymentAgent - Processes payments
- NotificationAgent - Sends notifications
```

### Agent Coordination Patterns

**1. Message Passing**
```python
class OrderAgent:
    async def process_order(self, order):
        # Process order
        await self.send_message(
            PaymentAgent,
            "process_payment",
            payment_info
        )
```

**2. Event Broadcasting**
```python
class OrderAgent:
    async def complete_order(self, order):
        # Complete order
        await self.emit_event("order_completed", order_id)
        # Multiple agents can listen
```

**3. Shared Queue**
```python
# Agents pull tasks from shared queue
task_queue = Queue()
agents = [Agent() for _ in range(5)]
for agent in agents:
    agent.start_processing(task_queue)
```

### Agent Testing

- Test each agent in isolation
- Mock inter-agent communication
- Test coordination separately
- Integration test critical paths

---

## 23. Dispatching Parallel Agents

**Purpose:** Launch and manage parallel agents effectively.

**Core Principle:** Coordinate work distribution, track progress, handle failures.

### Parallel Dispatch Pattern

```python
async def dispatch_parallel_agents(tasks):
    results = []
    
    # Create agents
    agents = [Agent(task) for task in tasks]
    
    # Launch all
    futures = [agent.execute() for agent in agents]
    
    # Wait for completion
    results = await asyncio.gather(*futures, return_exceptions=True)
    
    # Handle results
    for task, result in zip(tasks, results):
        if isinstance(result, Exception):
            handle_failure(task, result)
        else:
            handle_success(task, result)
    
    return results
```

### Work Distribution Strategies

**Round Robin**
- Even distribution
- Simple
- No load balancing

**Load-Based**
- Assign to least-loaded agent
- Better utilization
- Requires monitoring

**Task-Based**
- Agents specialized for task type
- Efficient
- More complex

### Progress Tracking

```python
class ProgressTracker:
    def __init__(self, total_tasks):
        self.total = total_tasks
        self.completed = 0
        self.failed = 0
    
    def task_completed(self):
        self.completed += 1
        print(f"Progress: {self.completed}/{self.total}")
    
    def task_failed(self, error):
        self.failed += 1
        log_error(error)
```

---

## 24. Collision Zone Thinking

**Purpose:** Identify where different parts of system might conflict.

**Core Principle:** Find shared resources and concurrent access points.

### Finding Collision Zones

**Shared State**
```python
# COLLISION ZONE
class Counter:
    count = 0  # Shared between threads
    
    def increment(self):
        # Race condition!
        self.count += 1
```

**Concurrent Database Access**
```sql
-- COLLISION ZONE
-- Two users updating same row simultaneously
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
```

**File System**
```python
# COLLISION ZONE
# Multiple processes writing same file
with open("shared.txt", "w") as f:
    f.write("data")
```

### Collision Analysis Framework

1. **Identify shared resources**
   - Memory
   - Files
   - Database records
   - Network connections

2. **Map access patterns**
   - Who accesses what?
   - When do they access it?
   - Read or write?

3. **Find overlaps**
   - Simultaneous writes = collision
   - Write during read = collision
   - Simultaneous reads = OK (usually)

4. **Design resolution**
   - Locking
   - Queuing
   - Partitioning
   - Eventual consistency

### Collision Resolution Strategies

**Pessimistic Locking**
```python
with lock:
    # Exclusive access
    value = shared_resource.read()
    shared_resource.write(value + 1)
```

**Optimistic Locking**
```python
while True:
    version = shared_resource.version
    value = shared_resource.read()
    if shared_resource.write_if_version(value + 1, version):
        break  # Success
    # Retry if version changed
```

---

## 25. Preserving Productive Tensions

**Purpose:** Maintain healthy tension between competing design concerns.

**Core Principle:** Don't resolve tensions, balance them.

### Productive Tensions

**Speed vs. Quality**
- Speed pushes for shipping
- Quality pushes for perfection
- **Balance:** Ship quality that's good enough

**Flexibility vs. Simplicity**
- Flexibility enables future changes
- Simplicity makes current work easier
- **Balance:** Flexible where needed, simple elsewhere

**Abstraction vs. Concreteness**
- Abstraction enables reuse
- Concreteness is clear
- **Balance:** Abstract common patterns, concrete specifics

**Perfect vs. Good Enough**
- Perfect takes forever
- Good enough ships
- **Balance:** Perfect critical paths, good enough elsewhere

### Balancing Tensions

**Don't Pick Sides**
- Both perspectives have value
- Tension is productive
- Resolution kills creativity

**Make Trade-offs Explicit**
```markdown
## Decision: How abstract should this API be?

Flexibility Argument:
- Future use cases unknown
- Extensibility valuable

Simplicity Argument:
- Current use case is clear
- Complexity has cost

Decision: Abstract the data model, concrete the operations.
Rationale: Data changes more than operations.
```

**Revisit Periodically**
- Tensions shift over time
- Rebalance as context changes

---

## 26. Simplification Cascades

**Purpose:** Progressively simplify systems through cascading improvements.

**Core Principle:** Simplifying one layer enables simplification of dependent layers.

### The Cascade Effect

```
Complex database schema
    ↓ Simplify schema
Simpler queries
    ↓ Simpler queries enable
Simpler business logic
    ↓ Simpler logic enables
Simpler API
    ↓ Simpler API enables
Simpler client code
```

### Simplification Process

**1. Identify Complexity Source**
- Where does complexity originate?
- What drives the complexity?
- Can we address the source?

**2. Simplify One Layer**
- Start at source of complexity
- Make ONE simplification
- Don't try to fix everything

**3. Observe Cascade**
- What else becomes simpler?
- What constraints are relaxed?
- What opportunities appear?

**4. Simplify Next Layer**
- Use relaxed constraints
- Simplify dependent layer
- Repeat

**5. Stop When Stable**
- No more obvious simplifications
- System feels "right"
- Further simplification adds complexity

### Example Cascade

**Before:**
```python
# Complex state machine with 47 states
class OrderProcessor:
    states = [PENDING, VALIDATING, VALIDATED, CHECKING_INVENTORY, ...]
```

**Simplification 1:** Reduce states
```python
# 5 states
class OrderProcessor:
    states = [PENDING, PROCESSING, COMPLETED, FAILED, CANCELLED]
```

**Cascade Effect:** State machine simpler → transitions simpler → testing simpler → monitoring simpler

---

# VIII. Meta-Skills

## 27. Using Skills

**Purpose:** Apply skills effectively in your workflow.

**Core Principle:** Skills are tools - know when and how to use them.

### When to Invoke Skills

**Explicit Triggers**
- Problem matches skill description
- Task requires skill's workflow
- User explicitly references skill

**Implicit Triggers**
- Patterns indicate skill would help
- Quality would improve with skill
- Efficiency would increase with skill

### Announcing Skill Usage

```markdown
I'm using the [skill-name] skill to [accomplish goal].
```

**Why announce?**
- Transparency
- Educational
- Sets expectations
- Enables feedback

### Combining Skills

**Sequential:**
```
1. brainstorming → design
2. writing-plans → implementation plan
3. test-driven-development → implementation
4. code-reviewer → quality check
```

**Parallel:**
```
- systematic-debugging (find bug)
- root-cause-tracing (trace origin)
- Used together for thorough debugging
```

### Skill Selection

**Ask:**
- What problem am I solving?
- Which skills address this problem?
- Which is most appropriate?
- Do I need multiple skills?

---

## 28. Using Superpowers

**Purpose:** Advanced techniques for skill composition and mastery.

**Core Principle:** Skills compose, adapt, and extend.

### Skill Chaining

```
Input → Skill A → Intermediate → Skill B → Output
```

**Example:**
```
Rough idea → brainstorming → Design
Design → writing-plans → Implementation Plan
Plan → executing-plans → Working Code
```

### Skill Adaptation

**Adapt skills to context:**
- Adjust level of detail
- Modify process steps
- Combine with domain knowledge

**Example:**
```
test-driven-development (standard)
+ mobile app context
= TDD with platform-specific considerations
```

### Context Switching

**Between skills:**
- Clearly mark transitions
- State current skill
- Explain why switching

**Example:**
```
[Using brainstorming skill]
... design work ...

[Switching to systematic-debugging skill]
Found an issue, debugging systematically...
```

### Performance Optimization

**Use skills efficiently:**
- Don't over-apply
- Skip irrelevant sections
- Adapt depth to needs
- Balance thoroughness with speed

---

## 29. Sharing Skills

**Purpose:** Package and share skills with your team or community.

**Core Principle:** Well-documented skills multiply their value.

### Packaging Skills

**Skill Structure:**
```
skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter
│   └── Markdown content
├── scripts/ (optional)
├── references/ (optional)
└── assets/ (optional)
```

**YAML Frontmatter:**
```yaml
---
name: skill-name
description: What it does and when to use it
---
```

### Distribution Methods

**1. Direct Sharing**
- Zip the skill directory
- Share .skill file
- Include in email/Slack

**2. Repository**
- Git repository
- Version control
- Collaborative improvement

**3. Package Manager**
- Published package
- Easy installation
- Dependency management

### Documentation Requirements

**Every skill needs:**
- Clear name
- Description with trigger conditions
- Usage instructions
- Examples
- When to use / when not to use

---

## 30. Gardening Skills Wiki

**Purpose:** Maintain and grow the skill library.

**Core Principle:** Living documentation requires active cultivation.

### Maintenance Activities

**Regular Review (Monthly)**
- Are skills still accurate?
- Are examples current?
- Are there new patterns to capture?

**Deprecation**
- Mark outdated skills
- Provide migration path
- Eventually remove

**Consolidation**
- Similar skills? Merge them
- Overlapping? Clarify boundaries
- Conflicting? Resolve or explain

**Quality Standards**
- Clear descriptions
- Working examples
- Proper formatting
- No broken references

### Growing the Library

**Capture New Patterns**
- New technique learned?
- Solved hard problem?
- Found better approach?
→ Create a skill

**Improve Existing**
- Better explanation?
- More examples?
- Clearer structure?
→ Update the skill

**Community Input**
- Collect feedback
- Track usage
- Identify gaps

---

## 31. Pulling Updates

**Purpose:** Keep local skills synchronized with central repository.

**Core Principle:** Regular updates prevent drift and capture improvements.

### Update Workflow

**1. Check for Updates**
```bash
git fetch origin
git log HEAD..origin/main --oneline
```

**2. Review Changes**
```bash
git diff HEAD..origin/main -- skills/
```

**3. Selective Update**
```bash
# Update specific skill
git checkout origin/main -- skills/specific-skill/

# Update all skills
git merge origin/main
```

**4. Resolve Conflicts**
- If local changes conflict
- Review both versions
- Merge manually
- Commit resolution

**5. Verify**
- Check skills still work
- Test any changed workflows
- Update local documentation

### Version Management

**Track versions:**
```yaml
---
name: skill-name
version: 2.1.0
last_updated: 2025-10-24
---
```

**Semantic versioning:**
- Major: Breaking changes
- Minor: New features
- Patch: Bug fixes

---

# IX. Thinking & Analysis

## 32. Meta-Pattern Recognition

**Purpose:** Recognize and apply patterns that transcend specific contexts.

**Core Principle:** Patterns repeat across domains - learn to see them.

### Cross-Domain Pattern Mapping

**Pattern:** Caching
- **Computers:** Store computed results
- **Business:** Inventory management
- **Biology:** Memory formation
- **Architecture:** Prefabrication

**Pattern:** Queue
- **Computers:** Message queue
- **Business:** Customer service line
- **Traffic:** Road congestion
- **Manufacturing:** Work-in-progress

### Finding Meta-Patterns

**1. Abstract the Structure**
- Remove domain-specific details
- What's the core pattern?
- What are the key relationships?

**2. Map to Other Domains**
- Whe

…(truncated)