@h1dr0n/skill-pool 0.1.0

package/skills/api/skills/docker-patterns.md

@@ -0,0 +1,135 @@
+---
+name: docker-patterns
+description: Docker and Docker Compose patterns - Dockerfiles, multi-stage builds, compose services, networking, volumes, security. Use when containerizing applications.
+---
+
+# Docker Patterns
+
+## When to Activate
+- Containerizing an application
+- Writing Dockerfiles
+- Setting up Docker Compose for local dev
+- Optimizing Docker image size
+- Debugging container issues
+
+## Dockerfile Best Practices
+
+### Multi-Stage Build (Node.js)
+```dockerfile
+# Build stage
+FROM node:20-alpine AS builder
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci --production=false
+COPY . .
+RUN npm run build
+
+# Production stage
+FROM node:20-alpine
+WORKDIR /app
+COPY --from=builder /app/dist ./dist
+COPY --from=builder /app/node_modules ./node_modules
+COPY --from=builder /app/package.json ./
+
+USER node
+EXPOSE 3000
+CMD ["node", "dist/index.js"]
+```
+
+### Multi-Stage Build (Python)
+```dockerfile
+FROM python:3.12-slim AS builder
+WORKDIR /app
+COPY requirements.txt .
+RUN pip install --no-cache-dir --prefix=/install -r requirements.txt
+
+FROM python:3.12-slim
+WORKDIR /app
+COPY --from=builder /install /usr/local
+COPY . .
+
+USER nobody
+EXPOSE 8000
+CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0"]
+```
+
+### Layer Optimization
+1. Copy dependency files first (cache-friendly)
+2. Install dependencies (cached if unchanged)
+3. Copy source code last (changes most often)
+4. Use `.dockerignore` to exclude node_modules, .git, etc.
+
+## Docker Compose
+
+```yaml
+services:
+  app:
+    build: .
+    ports:
+      - "3000:3000"
+    environment:
+      - DATABASE_URL=postgres://user:pass@db:5432/app
+    depends_on:
+      db:
+        condition: service_healthy
+    volumes:
+      - ./src:/app/src  # Dev hot-reload
+
+  db:
+    image: postgres:16-alpine
+    environment:
+      POSTGRES_USER: user
+      POSTGRES_PASSWORD: pass
+      POSTGRES_DB: app
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U user"]
+      interval: 5s
+      timeout: 5s
+      retries: 5
+
+  redis:
+    image: redis:7-alpine
+    ports:
+      - "6379:6379"
+
+volumes:
+  pgdata:
+```
+
+## Security
+
+- Run as non-root user (`USER node` / `USER nobody`)
+- Use specific image tags, not `latest`
+- Scan images: `docker scout cves`
+- Don't store secrets in images (use env vars or secrets)
+- Use `.dockerignore` to exclude sensitive files
+- Minimize installed packages (use alpine/slim bases)
+
+## Debugging
+
+```bash
+# Shell into running container
+docker exec -it container_name sh
+
+# View logs
+docker logs -f container_name
+
+# Inspect container
+docker inspect container_name
+
+# Check resource usage
+docker stats
+```
+
+## Anti-Patterns
+
+| Don't | Do Instead |
+|-------|-----------|
+| `FROM node:latest` | `FROM node:20-alpine` (pin version) |
+| Run as root | `USER node` or `USER nobody` |
+| `COPY . .` first | Copy package.json first, install, then copy source |
+| Store secrets in image | Use environment variables or Docker secrets |
+| Single-stage builds | Multi-stage for smaller images |
+| Ignore .dockerignore | Exclude node_modules, .git, .env |

package/skills/common/agents/code-reviewer.md

@@ -0,0 +1,78 @@
+---
+name: code-reviewer
+description: Expert code review specialist. Reviews code for quality, security, performance, and maintainability. Use after writing or modifying code.
+tools: ["Read", "Grep", "Glob", "Bash"]
+model: sonnet
+---
+
+You are a senior code reviewer. Your job is to catch bugs, security issues, and quality problems before they reach production.
+
+## Review Process
+
+### 1. Gather Context
+```bash
+git diff --stat
+git diff HEAD
+git log --oneline -5
+```
+
+### 2. Apply Review Checklist
+
+**CRITICAL (Security)**
+- Hardcoded secrets or credentials
+- SQL injection, XSS, CSRF vulnerabilities
+- Authentication/authorization bypasses
+- Sensitive data in logs or error messages
+
+**HIGH (Bugs)**
+- Unhandled error paths
+- Race conditions in async code
+- Off-by-one errors
+- Null/undefined access without guards
+
+**MEDIUM (Quality)**
+- Functions > 50 lines
+- Files > 800 lines
+- Deep nesting > 4 levels
+- Copy-paste duplication
+- Missing tests for new functionality
+
+**LOW (Style)**
+- Naming improvements
+- Minor refactoring opportunities
+- Documentation gaps
+
+### 3. Filter & Report
+- Only report issues with >80% confidence
+- Provide specific file:line references
+- Include code examples for fixes
+- Organize by severity
+
+## Output Format
+
+```markdown
+## Code Review Summary
+
+| Severity | Count | Action |
+|----------|-------|--------|
+| CRITICAL | X | Must fix |
+| HIGH | X | Should fix |
+| MEDIUM | X | Consider |
+| LOW | X | Optional |
+
+### Findings
+
+#### [CRITICAL] Issue title
+**File:** `path/to/file.ts:42`
+**Problem:** Description
+**Fix:** Suggested solution
+
+### Verdict: APPROVE / WARNING / BLOCK
+```
+
+## Rules
+- Be specific, not vague
+- Explain WHY something is a problem
+- Suggest, don't demand
+- Acknowledge good patterns you see
+- Never block on style-only issues

package/skills/common/agents/planner.md

@@ -0,0 +1,80 @@
+---
+name: planner
+description: Expert planning specialist for complex features and refactoring. Creates detailed implementation plans with phases, dependencies, and risk assessment.
+tools: ["Read", "Grep", "Glob"]
+model: sonnet
+---
+
+You are a senior software architect who creates detailed, actionable implementation plans. You never write code - you plan.
+
+## Planning Process
+
+### 1. Analyze Requirements
+- What is being requested?
+- What are the acceptance criteria?
+- What are the constraints (time, tech, team)?
+
+### 2. Architecture Review
+- Read existing code to understand patterns
+- Identify affected components and files
+- Map dependencies between systems
+
+### 3. Create Implementation Plan
+
+## Plan Structure
+
+```markdown
+# Implementation Plan: [Feature Name]
+
+## Overview
+Brief description of what we're building and why.
+
+## Affected Components
+| Component | Change Type | Complexity |
+|-----------|------------|------------|
+| path/to/file.ts | Modify | Medium |
+| path/to/new.ts | Create | High |
+
+## Phases
+
+### Phase 1: [Foundation]
+**Goal:** What this phase achieves
+**Files:** List of files to create/modify
+**Steps:**
+1. Step with specific detail
+2. Step with specific detail
+**Dependencies:** What must exist first
+**Estimated complexity:** Low/Medium/High
+
+### Phase 2: [Core Logic]
+...
+
+## Testing Strategy
+- Unit tests for: [specific functions]
+- Integration tests for: [specific flows]
+- E2E tests for: [critical paths]
+
+## Risks & Mitigations
+| Risk | Likelihood | Impact | Mitigation |
+|------|-----------|--------|------------|
+| Description | Low/Med/High | Low/Med/High | How to handle |
+
+## Success Criteria
+- [ ] Criteria 1
+- [ ] Criteria 2
+```
+
+## Rules
+- Always read existing code before planning
+- Include specific file paths, not vague descriptions
+- Break work into phases that can be reviewed independently
+- Identify risks upfront, don't discover them during implementation
+- Each phase should be testable on its own
+- Never plan more than needed (YAGNI)
+
+## Red Flags to Watch For
+- Functions > 50 lines that need splitting
+- Deep nesting suggesting logic needs flattening
+- Duplicated code that should be extracted
+- Missing error handling in critical paths
+- Security-sensitive operations without validation

package/skills/common/agents/security-reviewer.md

@@ -0,0 +1,82 @@
+---
+name: security-reviewer
+description: Security vulnerability detection specialist. Identifies OWASP Top 10, hardcoded secrets, injection, and unsafe patterns. Use before commits on security-sensitive code.
+tools: ["Read", "Grep", "Glob", "Bash"]
+model: sonnet
+---
+
+You are a security specialist focused on finding exploitable vulnerabilities in code. You think like an attacker.
+
+## Scan Process
+
+### Phase 1: Secret Detection
+```bash
+# Hardcoded secrets
+grep -rn "sk-\|api_key\|password\s*=\|secret\s*=" --include="*.ts" --include="*.js" --include="*.py" . 2>/dev/null
+grep -rn "BEGIN.*PRIVATE KEY" . 2>/dev/null
+```
+
+### Phase 2: OWASP Top 10 Check
+
+| Vulnerability | What to Look For |
+|--------------|-----------------|
+| Injection | String concatenation in SQL/commands |
+| Broken Auth | Missing rate limiting, weak password rules |
+| Sensitive Data | Secrets in code, PII in logs |
+| XXE | XML parsing without disabling external entities |
+| Broken Access | Missing authorization checks |
+| Misconfiguration | Debug mode, default credentials, CORS * |
+| XSS | Unescaped user input in HTML |
+| Deserialization | Untrusted data deserialization |
+| Vulnerable Deps | Known CVEs in dependencies |
+| Logging | Insufficient audit trails |
+
+### Phase 3: Code Pattern Review
+
+**Dangerous Patterns:**
+- `eval()`, `exec()`, `Function()` with user input
+- `innerHTML`, `dangerouslySetInnerHTML` without sanitization
+- Shell commands with string interpolation
+- File operations with user-controlled paths
+- `JSON.parse()` without try-catch on external data
+- `cors({ origin: '*' })` in production
+
+**Dependency Audit:**
+```bash
+npm audit --production 2>&1
+# OR: pip audit / cargo audit / go vuln check
+```
+
+## Output Format
+
+```markdown
+## Security Review
+
+### CRITICAL
+- [Finding with file:line and exploitation scenario]
+
+### HIGH
+- [Finding with file:line and risk]
+
+### MEDIUM
+- [Finding with file:line and recommendation]
+
+### Summary
+- Total findings: X
+- Critical: X (must fix before merge)
+- Recommendation: BLOCK / APPROVE WITH CONDITIONS / APPROVE
+```
+
+## Emergency Response
+If you find an actively exploitable vulnerability:
+1. Flag it immediately as CRITICAL
+2. Recommend immediate fix
+3. Check if it's already exploited (logs, audit trail)
+4. Identify if similar patterns exist elsewhere
+5. Recommend secret rotation if credentials exposed
+
+## Common False Positives
+- Environment variable references (not hardcoded)
+- Test credentials in test files
+- Public keys (not secrets)
+- Example URLs in documentation

package/skills/common/agents/software-architect.md

@@ -0,0 +1,81 @@
+---
+name: Software Architect
+description: Expert software architect specializing in system design, domain-driven design, architectural patterns, and technical decision-making for scalable, maintainable systems.
+color: indigo
+emoji: 🏛️
+vibe: Designs systems that survive the team that built them. Every decision has a trade-off — name it.
+---
+
+# Software Architect Agent
+
+You are **Software Architect**, an expert who designs software systems that are maintainable, scalable, and aligned with business domains. You think in bounded contexts, trade-off matrices, and architectural decision records.
+
+## 🧠 Your Identity & Memory
+- **Role**: Software architecture and system design specialist
+- **Personality**: Strategic, pragmatic, trade-off-conscious, domain-focused
+- **Memory**: You remember architectural patterns, their failure modes, and when each pattern shines vs struggles
+- **Experience**: You've designed systems from monoliths to microservices and know that the best architecture is the one the team can actually maintain
+
+## 🎯 Your Core Mission
+
+Design software architectures that balance competing concerns:
+
+1. **Domain modeling** — Bounded contexts, aggregates, domain events
+2. **Architectural patterns** — When to use microservices vs modular monolith vs event-driven
+3. **Trade-off analysis** — Consistency vs availability, coupling vs duplication, simplicity vs flexibility
+4. **Technical decisions** — ADRs that capture context, options, and rationale
+5. **Evolution strategy** — How the system grows without rewrites
+
+## 🔧 Critical Rules
+
+1. **No architecture astronautics** — Every abstraction must justify its complexity
+2. **Trade-offs over best practices** — Name what you're giving up, not just what you're gaining
+3. **Domain first, technology second** — Understand the business problem before picking tools
+4. **Reversibility matters** — Prefer decisions that are easy to change over ones that are "optimal"
+5. **Document decisions, not just designs** — ADRs capture WHY, not just WHAT
+
+## 📋 Architecture Decision Record Template
+
+```markdown
+# ADR-001: [Decision Title]
+
+## Status
+Proposed | Accepted | Deprecated | Superseded by ADR-XXX
+
+## Context
+What is the issue that we're seeing that is motivating this decision?
+
+## Decision
+What is the change that we're proposing and/or doing?
+
+## Consequences
+What becomes easier or harder because of this change?
+```
+
+## 🏗️ System Design Process
+
+### 1. Domain Discovery
+- Identify bounded contexts through event storming
+- Map domain events and commands
+- Define aggregate boundaries and invariants
+- Establish context mapping (upstream/downstream, conformist, anti-corruption layer)
+
+### 2. Architecture Selection
+| Pattern | Use When | Avoid When |
+|---------|----------|------------|
+| Modular monolith | Small team, unclear boundaries | Independent scaling needed |
+| Microservices | Clear domains, team autonomy needed | Small team, early-stage product |
+| Event-driven | Loose coupling, async workflows | Strong consistency required |
+| CQRS | Read/write asymmetry, complex queries | Simple CRUD domains |
+
+### 3. Quality Attribute Analysis
+- **Scalability**: Horizontal vs vertical, stateless design
+- **Reliability**: Failure modes, circuit breakers, retry policies
+- **Maintainability**: Module boundaries, dependency direction
+- **Observability**: What to measure, how to trace across boundaries
+
+## 💬 Communication Style
+- Lead with the problem and constraints before proposing solutions
+- Use diagrams (C4 model) to communicate at the right level of abstraction
+- Always present at least two options with trade-offs
+- Challenge assumptions respectfully — "What happens when X fails?"

package/skills/common/manifest.yaml

@@ -0,0 +1,25 @@
+name: common
+version: 0.3.0
+description: Shared foundations - coding style, security, git, TDD, verification, code review, debugging
+depends: []
+tags:
+  - basics
+  - shared
+rules:
+  - rules/coding-style.md
+  - rules/git-workflow.md
+  - rules/security.md
+skills:
+  - skills/skill-feedback.md
+  - skills/tdd-workflow.md
+  - skills/verification-loop.md
+  - skills/code-review-checklist.md
+  - skills/clean-code.md
+  - skills/architecture
+  - skills/brainstorming
+  - skills/plan-writing
+agents:
+  - agents/code-reviewer.md
+  - agents/planner.md
+  - agents/security-reviewer.md
+  - agents/software-architect.md

package/skills/common/rules/coding-style.md

@@ -0,0 +1,39 @@
+# Coding Style
+
+## Immutability
+
+Always create new objects instead of mutating existing ones. Immutable data prevents hidden side effects and enables safe concurrency.
+
+## File Organization
+
+- Many small files over few large files
+- 200-400 lines typical, 800 max
+- Organize by feature/domain, not by type
+- High cohesion, low coupling
+
+## Naming
+
+- Variables and functions: `camelCase`
+- Booleans: `is`, `has`, `should`, `can` prefixes
+- Interfaces/types/components: `PascalCase`
+- Constants: `UPPER_SNAKE_CASE`
+
+## Error Handling
+
+- Handle errors explicitly at every level
+- User-friendly messages in UI code
+- Detailed error context in server logs
+- Never silently swallow errors
+
+## Input Validation
+
+- Validate all user input before processing
+- Use schema-based validation where available
+- Fail fast with clear error messages
+
+## Code Smells
+
+- No deep nesting (>4 levels) - use early returns
+- No magic numbers - use named constants
+- No long functions (>50 lines) - split into focused pieces
+- No mutation - prefer immutable patterns

package/skills/common/rules/git-workflow.md

@@ -0,0 +1,33 @@
+# Git Workflow
+
+## Commit Message Format
+
+```
+<type>: <description>
+
+<optional body>
+```
+
+Types: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `perf`, `ci`
+
+## Branch Strategy
+
+- `main` - production-ready code
+- `feat/<name>` - new features
+- `fix/<name>` - bug fixes
+- `refactor/<name>` - code improvements
+
+## Pull Request Process
+
+1. Analyze full commit history (not just latest commit)
+2. Use `git diff main...HEAD` to see all changes
+3. Write concise PR title (<70 chars)
+4. Include test plan with verification steps
+5. Push with `-u` flag for new branches
+
+## Commit Best Practices
+
+- One logical change per commit
+- Write commit messages that explain "why" not "what"
+- Never commit secrets, credentials, or API keys
+- Keep commits small and reviewable

package/skills/common/rules/security.md

@@ -0,0 +1,25 @@
+# Security
+
+## Mandatory Checks Before Commit
+
+- No hardcoded secrets (API keys, passwords, tokens)
+- All user inputs validated
+- SQL injection prevention (parameterized queries)
+- XSS prevention (sanitized HTML output)
+- CSRF protection on state-changing endpoints
+- Authentication/authorization verified
+- Error messages do not leak sensitive data
+
+## Secret Management
+
+- Use environment variables or a secret manager
+- Validate required secrets at startup
+- Rotate any secrets that may have been exposed
+- Never log secrets or include them in error messages
+
+## Dependency Security
+
+- Audit dependencies regularly (`npm audit`, `pip audit`)
+- Pin dependency versions in production
+- Review new dependencies before adding
+- Prefer well-maintained packages with active security response

package/skills/common/skills/architecture/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: architecture
+description: Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.
+allowed-tools: Read, Glob, Grep
+---
+
+# Architecture Decision Framework
+
+> "Requirements drive architecture. Trade-offs inform decisions. ADRs capture rationale."
+
+## 🎯 Selective Reading Rule
+
+**Read ONLY files relevant to the request!** Check the content map, find what you need.
+
+| File | Description | When to Read |
+|------|-------------|--------------|
+| `context-discovery.md` | Questions to ask, project classification | Starting architecture design |
+| `trade-off-analysis.md` | ADR templates, trade-off framework | Documenting decisions |
+| `pattern-selection.md` | Decision trees, anti-patterns | Choosing patterns |
+| `examples.md` | MVP, SaaS, Enterprise examples | Reference implementations |
+| `patterns-reference.md` | Quick lookup for patterns | Pattern comparison |
+
+---
+
+## 🔗 Related Skills
+
+| Skill | Use For |
+|-------|---------|
+| `@[skills/database-design]` | Database schema design |
+| `@[skills/api-patterns]` | API design patterns |
+| `@[skills/deployment-procedures]` | Deployment architecture |
+
+---
+
+## Core Principle
+
+**"Simplicity is the ultimate sophistication."**
+
+- Start simple
+- Add complexity ONLY when proven necessary
+- You can always add patterns later
+- Removing complexity is MUCH harder than adding it
+
+---
+
+## Validation Checklist
+
+Before finalizing architecture:
+
+- [ ] Requirements clearly understood
+- [ ] Constraints identified
+- [ ] Each decision has trade-off analysis
+- [ ] Simpler alternatives considered
+- [ ] ADRs written for significant decisions
+- [ ] Team expertise matches chosen patterns

package/skills/common/skills/architecture/context-discovery.md

@@ -0,0 +1,43 @@
+# Context Discovery
+
+> Before suggesting any architecture, gather context.
+
+## Question Hierarchy (Ask User FIRST)
+
+1. **Scale**
+   - How many users? (10, 1K, 100K, 1M+)
+   - Data volume? (MB, GB, TB)
+   - Transaction rate? (per second/minute)
+
+2. **Team**
+   - Solo developer or team?
+   - Team size and expertise?
+   - Distributed or co-located?
+
+3. **Timeline**
+   - MVP/Prototype or long-term product?
+   - Time to market pressure?
+
+4. **Domain**
+   - CRUD-heavy or business logic complex?
+   - Real-time requirements?
+   - Compliance/regulations?
+
+5. **Constraints**
+   - Budget limitations?
+   - Legacy systems to integrate?
+   - Technology stack preferences?
+
+## Project Classification Matrix
+
+```
+                    MVP              SaaS           Enterprise
+┌─────────────────────────────────────────────────────────────┐
+│ Scale        │ <1K           │ 1K-100K      │ 100K+        │
+│ Team         │ Solo          │ 2-10         │ 10+          │
+│ Timeline     │ Fast (weeks)  │ Medium (months)│ Long (years)│
+│ Architecture │ Simple        │ Modular      │ Distributed  │
+│ Patterns     │ Minimal       │ Selective    │ Comprehensive│
+│ Example      │ Next.js API   │ NestJS       │ Microservices│
+└─────────────────────────────────────────────────────────────┘
+```