k8s-debug
Launch ephemeral debug container in running pod for interactive debugging. Use when you need to debug a pod without restarting it.
What this skill does
# Debug Kubernetes Container
Launch an ephemeral debug container attached to a running pod for interactive debugging.
## When to Use
- Pod is failing but you need to inspect it live
- Need debugging tools (curl, netstat, tcpdump) not available in production container
- Want to debug without modifying production container image
- Investigating network, process, or filesystem issues in running pod
## Pre-flight Checks
### Authentication and Context
```bash
# Check kubectl context
kubectl config current-context || {
echo "No kubectl context. Run: kubectl config use-context <context>"
exit 1
}
# Show current context
echo "K8s Context: $(kubectl config current-context)"
```
## Workflow
### 1. Launch Debug Container
**Basic debug container**:
```bash
# Attach ephemeral debug container to running pod
kubectl debug -it <pod-name> \
--image=nicolaka/netshoot \
--namespace=<namespace>
```
**With specific container target** (for multi-container pods):
```bash
# Target specific container in pod
kubectl debug -it <pod-name> \
--image=nicolaka/netshoot \
--target=<container-name> \
--namespace=<namespace>
```
**With custom image**:
```bash
# Use custom debug image
kubectl debug -it <pod-name> \
--image=ubuntu:latest \
--namespace=<namespace>
```
### 2. Common Debug Commands Inside Container
Once inside the debug container, use these commands:
**Network debugging**:
```bash
# Test HTTP endpoints
curl http://localhost:8080/health
curl -v http://database-service:5432
# Check listening ports
netstat -tulpn
# Capture network traffic
tcpdump -i any port 8080
# DNS resolution
nslookup database-service
dig +short database-service.default.svc.cluster.local
```
**Process inspection**:
```bash
# List processes
ps aux
# Monitor processes
top
# Check process details
ps aux | grep api-gateway
```
**File system inspection**:
```bash
# Check application directory
ls -la /app
# View config files
cat /app/config.yaml
# Check environment variables
env | grep API
# Check mounted volumes
df -h
mount | grep /app
```
**Container metadata**:
```bash
# Check container env
printenv
# View pod labels (if tools available)
cat /etc/podinfo/labels
```
### 3. Document and Exit
After debugging:
1. Document findings in investigation notes or Linear ticket
2. Exit debug container: `exit` or Ctrl+D
3. Debug container is automatically removed
## Recommended Debug Images
**nicolaka/netshoot** (Recommended for network debugging):
- Includes: curl, dig, netstat, tcpdump, wget, nc, nslookup
- Best for: Network connectivity, DNS, HTTP debugging
- Size: ~300MB
**busybox**:
- Includes: Basic Unix utilities
- Best for: Minimal debugging, file system inspection
- Size: ~5MB
**ubuntu:latest**:
- Includes: Full package manager (apt)
- Best for: Installing custom tools on-the-fly
- Size: ~70MB
**alpine:latest**:
- Includes: Package manager (apk)
- Best for: Lightweight debugging with custom tools
- Size: ~7MB
## Tips
- Use `--target` when debugging multi-container pods
- Debug containers share process namespace with target container
- Debug containers have access to target container's filesystem
- Use `--copy-to=<new-pod-name>` to create a copy of the pod for debugging
- Debug containers are ephemeral and removed on exit
- Check pod status before debugging: `kubectl get pod <pod-name> -n <namespace>`
## Limitations
- Requires Kubernetes 1.18+ (ephemeral containers feature)
- Some clusters may have PodSecurityPolicy restricting debug containers
- Shared PID namespace may not be available in all environments
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.