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.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
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.
Professional Development Superskill
A comprehensive reference consolidating 41 professional skills into one complete guide.
Purpose: Create detailed implementation plans from validated designs.
Core Principle: Break work into concrete, verifiable tasks with clear dependencies.
Plan Structure
# 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
Start with current task - Follow plan order
Document deviations - Note when plan differs from reality
# GOOD - Wait for actual condition
click_button()
wait_until(lambda: element_visible(), timeout=10, interval=0.1)
assert element_visible()
Implementation Pattern
defwait_until(condition, timeout=10, interval=0.1):
start = time.time()
while time.time() - start < timeout:
if condition():
returnTrue
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
Read error messages carefully - completely
Reproduce consistently - exact steps
Check recent changes - what changed?
Gather evidence in multi-component systems:
Log data entering/exiting each component
Verify config propagation
Check state at each layer
Trace data flow - where does bad value originate?
Phase 2: Pattern Analysis
Find working examples - what works that's similar?
Compare against references - read completely
Identify differences - list every difference
Understand dependencies - what does this need?
Phase 3: Hypothesis and Testing
Form single hypothesis - "I think X because Y"
Test minimally - smallest possible change
Verify before continuing - did it work?
When you don't know - say so, ask for help
Phase 4: Implementation
Create failing test case - simplest reproduction
Implement single fix - address root cause
Verify fix - test passes, no regressions
If fix doesn't work - Return to Phase 1
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
Start at error location - Where does it fail?
Trace back one step - What called this with bad value?
Continue upward - Keep tracing to source
Find the origin - Where did bad value start?
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
Correctness - Does it work?
Security - Any vulnerabilities?
Performance - Any obvious issues?
Maintainability - Can others understand/modify?
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
## 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.
# From main repo
git worktree add ../project-feature-a feature-a
# Creates new directory with feature-a branch checked outcd ../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
# 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 prunerm -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.
---
## 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
defupdate_user(user_id, changes):
# Second line of defense
user = get_user(user_id)
ifnot user:
raise NotFound("User not found")
ifnot has_permission(current_user, user):
raise Forbidden("No permission to update")
Layer 3: Database Constraints
CREATE TABLE users (
id INTPRIMARY KEY,
email VARCHAR(255) NOT NULLUNIQUE,
created_at TIMESTAMPNOT NULLDEFAULTCURRENT_TIMESTAMP
);
Defense Layers
Client-side - UX, not security
API Gateway - Rate limiting, authentication
Application - Business logic validation
Database - Constraints, transactions
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.
-- COLLISION ZONE-- Two users updating same row simultaneouslyUPDATE accounts SET balance = balance -100WHERE id =1;
File System
# COLLISION ZONE# Multiple processes writing same filewithopen("shared.txt", "w") as f:
f.write("data")
Collision Analysis Framework
Identify shared resources
Memory
Files
Database records
Network connections
Map access patterns
Who accesses what?
When do they access it?
Read or write?
Find overlaps
Simultaneous writes = collision
Write during read = collision
Simultaneous reads = OK (usually)
Design resolution
Locking
Queuing
Partitioning
Eventual consistency
Collision Resolution Strategies
Pessimistic Locking
with lock:
# Exclusive access
value = shared_resource.read()
shared_resource.write(value + 1)
Optimistic Locking
whileTrue:
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.
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
## 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:
# Complex state machine with 47 statesclassOrderProcessor:
states = [PENDING, VALIDATING, VALIDATED, CHECKING_INVENTORY, ...]
Simplification 1: Reduce states
# 5 statesclassOrderProcessor:
states = [PENDING, PROCESSING, COMPLETED, FAILED, CANCELLED]
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
Where else does this structure appear?
Different context, same pattern?
What's similar, what's different?
3. Transfer Insights
Solution from one domain → another
Avoid reinventing the wheel
Adapt, don't copy blindly
Pattern Catalog
Common Meta-Patterns:
Layering - Abstraction levels
Pipeline - Sequential transformation
Feedback loops - Output → Input
Caching - Store for reuse
Partitioning - Divide and conquer
Replication - Redundancy for reliability
33. Inversion Exercise
Purpose: Think backwards from desired outcome to find solution path.
Core Principle: Start with the end, work backwards to the beginning.
The Inversion Process
1. Define End State
What does success look like?
Be specific and concrete
Measurable if possible
2. Work Backwards
What must be true immediately before?
And before that?
Continue until reaching current state
3. Identify Prerequisites
What must exist at each step?
What must be true?
What must be done?
4. Remove Obstacles
What blocks each step?
How to remove blockers?
What dependencies?
5. Reverse for Forward Plan
Now you have the path
Execute in reverse order
Each step enables next
Example Inversion
Goal: Ship product feature
Backwards:
Feature in production
← Must pass deployment
← Must pass QA
← Must be code complete
← Must have passing tests
← Must have design
← Must have requirements
This superskill consolidates 41 professional skills across 10 categories. Use it as a comprehensive reference for software development best practices, workflows, and methodologies.
