freddie 0.0.41

package/skills/creative/concept-diagrams/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: concept-diagrams
+description: Generate concept maps, mind maps, and ER diagrams from free-form descriptions
+category: creative
+---
+
+# Concept Diagrams
+
+Extract structure from free-form descriptions and render as concept maps, mind maps, or entity-relationship diagrams.
+
+## Diagram types
+
+### Mind map (Mermaid mindmap)
+Hierarchical, radiating from a central concept. Use when exploring a topic.
+
+```mermaid
+mindmap
+  root((Cloud Native))
+    Containers
+      Docker
+      Podman
+    Orchestration
+      Kubernetes
+      Nomad
+    Observability
+      Metrics
+      Logs
+      Traces
+```
+
+### Concept map (Mermaid graph)
+Nodes connected by labelled relationships.
+
+```mermaid
+graph LR
+    Domain -->|contains| BoundedContext
+    BoundedContext -->|has| AggregateRoot
+    AggregateRoot -->|emits| DomainEvent
+    DomainEvent -->|handled by| EventHandler
+```
+
+### ER diagram (Mermaid erDiagram)
+
+```mermaid
+erDiagram
+    USER ||--o{ ORDER : places
+    ORDER ||--|{ LINE_ITEM : contains
+    PRODUCT ||--o{ LINE_ITEM : appears-in
+```
+
+## Process
+
+1. Identify **nouns** (entities/concepts) and **verbs** (relationships/actions).
+2. Choose diagram type: hierarchy → mindmap, relationships → concept map, data model → ER.
+3. Assign cardinalities for ER, labels for concept maps, levels for mind maps.
+4. Produce the diagram with a brief explanation of key relationships.
+
+## Rules
+
+- Every edge must have a label.
+- Keep node names ≤3 words; longer names in `""`.
+- Do not add nodes not mentioned unless structurally necessary.
+- For ER: include primary keys when schema details are provided.
+
+Produce the diagram immediately from the user's description.

package/skills/data/README.md

@@ -0,0 +1,3 @@
+# data skills
+
+Built-in skills in this category. Drop additional SKILL.md files in subdirectories.

package/skills/data/etl-pipelines/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: etl-pipelines
+description: Design, implement, and debug ETL/ELT pipelines — batch or streaming, any source/sink
+category: data
+---
+
+# ETL Pipelines
+
+You are a data engineering expert. Design and implement reliable, observable, re-runnable ETL/ELT pipelines.
+
+## Pipeline anatomy
+
+```
+[Extract] → [Validate] → [Transform] → [Load] → [Reconcile]
+```
+
+- **Extract**: idempotent reads with watermark/cursor (last_updated_at, offset)
+- **Validate**: schema, null, range checks — fail fast before writing
+- **Transform**: pure functions, no side effects
+- **Load**: upsert over truncate+insert; use staging tables for bulk
+- **Reconcile**: row count + checksum comparison between source and sink
+
+## Patterns
+
+### Incremental load
+```python
+last_run = get_watermark('orders')
+rows = db.query("SELECT * FROM orders WHERE updated_at > %s", last_run)
+load_to_warehouse(rows)
+set_watermark('orders', datetime.utcnow())
+```
+
+### Idempotent upsert (Postgres)
+```sql
+INSERT INTO orders_dw SELECT * FROM orders_staging
+ON CONFLICT (order_id) DO UPDATE SET
+  status = EXCLUDED.status,
+  updated_at = EXCLUDED.updated_at;
+```
+
+### Streaming (Kafka → sink)
+```js
+consumer.on('message', async (msg) => {
+    const row = JSON.parse(msg.value)
+    await validate(row)
+    await sink.upsert(transform(row))
+    await consumer.commitOffset(msg)
+})
+```
+
+## Rules
+
+- Never truncate+insert a production table without a staging safety net.
+- Always log: rows extracted, rows loaded, rows rejected, duration.
+- Make every pipeline re-runnable: same input → same output, no duplicates.
+- Store watermarks in a durable location (DB table, not in-memory).
+- Chunk large loads to ≤50k rows per transaction.
+
+Produce: pipeline code, schema validation block, reconciliation query, and monitoring note.
+Ask the user for source, sink, and transformation rules before generating code.

package/skills/data/sql-explainer/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: sql-explainer
+description: "Explain SQL queries, execution plans, and performance issues in plain English with rewrites"
+category: data
+---
+
+# SQL Explainer
+
+Explain SQL queries, analyse execution plans, identify performance bottlenecks, and suggest rewrites.
+
+## Explanation format
+
+For any query:
+
+```
+WHAT IT DOES (one sentence)
+
+STEP BY STEP:
+1. FROM / JOIN — which tables, join type and implications
+2. WHERE — filters, sargability (can indexes be used?)
+3. GROUP BY / HAVING — aggregation logic
+4. SELECT — columns, computed expressions
+5. ORDER BY / LIMIT — sort and pagination
+
+EDGE CASES:
+- NULLs: which columns and how they affect results
+- Empty sets: what happens if a subquery returns no rows
+- Duplicates: expected or a bug?
+
+PERFORMANCE NOTES:
+- Estimated scan type
+- Columns that should have indexes
+- Estimated row count at each stage
+```
+
+## EXPLAIN ANALYZE reading
+
+- Highest **actual time** node = bottleneck.
+- **rows estimated vs actual** divergence → stale statistics (`ANALYZE` needed).
+- **Seq Scan on large table with filter** → missing index.
+- **Hash Join with large hash** → may spill to disk; check `work_mem`.
+- **Nested Loop on large outer, inner Seq Scan** → N+1; index the join key.
+
+## Common rewrites
+
+| Anti-pattern | Fix |
+|---|---|
+| `SELECT *` in subquery | Select only the join key |
+| `NOT IN (subquery with NULLs)` | Use `NOT EXISTS` |
+| Correlated subquery in SELECT | LEFT JOIN + COALESCE |
+| `DISTINCT` hiding a bad join | Fix the join |
+| `ORDER BY` on un-indexed column with small LIMIT | Index the sort column |
+
+## Rules
+
+- Always state the SQL dialect assumed (PostgreSQL, MySQL, SQLite, BigQuery, etc.).
+- Never change query semantics in a rewrite without flagging the difference.
+- If slow but correct, suggest `EXPLAIN ANALYZE` output before guessing at indexes.
+
+Paste the query (and optionally DDL + EXPLAIN output) and I will explain immediately.

package/skills/ops/README.md

@@ -0,0 +1,3 @@
+# ops skills
+
+Built-in skills in this category. Drop additional SKILL.md files in subdirectories.

package/skills/ops/incident-response/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: incident-response
+description: "Guide incident response: triage, diagnosis, mitigation, communication, and post-mortem"
+category: ops
+---
+
+# Incident Response
+
+You are a senior SRE leading incident response. Keep a clear head, drive toward mitigation, document everything.
+
+## Severity levels
+
+| Sev | Definition | Response |
+|---|---|---|
+| P0 | Complete outage, data loss, security breach | <5 min |
+| P1 | Major feature down, >20% users affected | <15 min |
+| P2 | Degraded, workaround exists | <1 hour |
+| P3 | Minor, no user impact | Next business day |
+
+## Response phases
+
+### 1. TRIAGE (first 5 min)
+- Confirm the incident is real (not a false positive).
+- Assign an Incident Commander (IC). Open a war room.
+- Post first status update. Identify blast radius.
+
+### 2. DIAGNOSIS
+1. What changed recently? (deploy, config, traffic spike)
+2. Which component is the source? (check error rates by service)
+3. What does the error look like? (logs, stack traces, status codes)
+4. Getting better, worse, or stable?
+
+```bash
+kubectl top pods -A | sort -k3 -rn | head -20
+kubectl rollout history deployment/<name>
+kubectl logs -f deployment/<name> --tail=100
+psql -c "SELECT count(*), state FROM pg_stat_activity GROUP BY state;"
+```
+
+### 3. MITIGATION (reduce blast radius first)
+
+1. **Rollback**: `kubectl rollout undo deployment/<name>`
+2. **Feature flag**: disable without a deploy
+3. **Scale up**: `kubectl scale deployment/<name> --replicas=N`
+4. **Circuit break**: route traffic away from unhealthy instance
+5. **Failover**: promote replica to primary
+
+### 4. COMMUNICATION
+
+Post updates every 15 minutes:
+```
+[P1 UPDATE — 14:35 UTC]
+Status: Investigating
+Impact: ~15% of users seeing 502 errors on checkout
+Root cause: Under investigation
+Next update: 14:50 UTC
+IC: @name
+```
+
+### 5. POST-MORTEM (within 48 hours)
+
+- Timeline (UTC), Root cause (specific), Contributing factors
+- Impact (users, duration, data loss), What went well
+- Action items (owner + due date)
+
+## Rules
+
+- Mitigation before root cause — stop the bleeding first.
+- One IC owns the call. Others execute, do not freelance.
+- Never restart without capturing logs first.
+- Every action logged with a timestamp.
+- Blameless post-mortems only.
+
+Describe the current incident and I will guide you through triage.

package/skills/ops/log-triage/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: log-triage
+description: Triage application and system logs to find root causes, anomalies, and error patterns
+category: ops
+---
+
+# Log Triage
+
+Given logs, structured JSONL, or excerpts — identify errors, anomalies, and root causes quickly.
+
+## What you do
+
+1. **Parse** — identify format (plain text, JSON, syslog, nginx, k8s).
+2. **Classify** — group by level (ERROR/WARN/INFO) and origin (service, host, pod).
+3. **Correlate** — link errors by request ID, trace ID, or timestamp.
+4. **Identify root cause** — find the first error in the causal chain.
+5. **Summarise** — triage report with counts, timeline, top errors.
+
+## Triage process
+
+### Step 1 — Extract errors
+```bash
+# JSON logs
+jq 'select(.level == "error" or .level == "fatal")' app.log | jq -c '{ts, msg, service, err}'
+# Plain text
+grep -E 'ERROR|FATAL|panic|exception' app.log | sort | uniq -c | sort -rn | head -20
+```
+
+### Step 2 — Find the first error (usually root cause)
+```bash
+grep -m1 -E 'ERROR|FATAL' app.log
+```
+
+### Step 3 — Correlate by request/trace ID
+```bash
+grep '"trace_id":"abc123"' *.log | sort -k1
+```
+
+### Step 4 — Count error frequency
+```bash
+jq -r 'select(.level=="error") | .msg' app.log | sort | uniq -c | sort -rn
+```
+
+## Common patterns
+
+| Error pattern | Likely cause |
+|---|---|
+| `connection refused` on DB port | DB down or pool exhausted |
+| `timeout` on upstream | Upstream slow or dead; check circuit breaker |
+| `OOM killed` in k8s | Memory limit too low or memory leak |
+| `too many open files` | File descriptor limit; check `ulimit -n` |
+| `certificate has expired` | TLS cert needs renewal |
+| `ECONNRESET` in Node.js | Client disconnected; benign unless spike |
+| `deadlock detected` in Postgres | Competing transactions; check slow query log |
+
+## Triage report format
+
+```
+LOG TRIAGE REPORT — <date>
+Source: <file or service>
+Time range: <start> → <end>
+
+SUMMARY
+  Total lines: N | ERROR: N | WARN: N | INFO: N
+
+TOP ERRORS
+  1. [N×] "message" — first seen <ts>
+  2. [N×] "message" — first seen <ts>
+
+ROOT CAUSE HYPOTHESIS
+  First error at <ts>: "<message>"
+  Caused by: <analysis>
+  Likely trigger: <deploy/traffic/dependency>
+
+RECOMMENDED ACTIONS
+  1. ...
+```
+
+Paste the logs (or describe the file) and I will triage immediately.

package/skills/planning/README.md

@@ -0,0 +1,3 @@
+# planning skills
+
+Built-in skills in this category. Drop additional SKILL.md files in subdirectories.

package/skills/planning/okr-drafter/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: okr-drafter
+description: Draft Objectives and Key Results from goals, strategy docs, or free-form priorities
+category: planning
+---
+
+# OKR Drafter
+
+Draft ambitious, measurable Objectives and Key Results aligned with strategy and trackable weekly.
+
+## OKR fundamentals
+
+- **Objective**: qualitative, inspiring, time-bound (one quarter). *What do we want to achieve?*
+- **Key Result**: quantitative, binary-completable, max 3-5 per objective. *How do we know we achieved it?*
+- **Initiative**: the work that drives KRs (not part of the OKR).
+
+### Good vs bad KRs
+
+| Bad (output) | Good (outcome) |
+|---|---|
+| Launch feature X | Feature X used by ≥30% of active users |
+| Fix bugs | P1 bug resolution time <4 hours |
+| Improve performance | p95 API latency <200ms for checkout |
+| Write documentation | Docs CSAT score ≥4.2/5 |
+
+## Process
+
+1. Read the team's **mission** and **top 3 priorities for the quarter**.
+2. Identify 2-4 **themes** from those priorities.
+3. Draft one **Objective** per theme — active verbs, no jargon.
+4. Draft 3-5 **Key Results** per Objective — each needs baseline, target, and unit.
+5. Sanity-check: measurable today? Baseline known? Target ambitious but ≥70% confident?
+
+## Output format
+
+```
+QUARTER: Q2 2026
+TEAM: <team>
+
+O1: Make our checkout experience the fastest in the industry
+  KR1.1  p95 checkout latency: 800ms → 200ms
+  KR1.2  Cart abandonment rate: 34% → 22%
+  KR1.3  Lighthouse performance score for /checkout ≥ 90
+
+O2: Build the foundation for self-serve onboarding
+  KR2.1  Time-to-first-value: 3 days → 4 hours
+  KR2.2  Support tickets from onboarding: 120/wk → 30/wk
+  KR2.3  ≥80% of new accounts complete setup without human help
+```
+
+## Rules
+
+- Objectives use active verbs: "Become", "Establish", "Deliver", "Eliminate".
+- KRs are **outcomes**, never tasks or outputs.
+- Every KR has a **from → to** metric or a binary milestone.
+- Max 4 Objectives per team per quarter.
+- No "increase engagement" without numbers.
+- Flag any KR without a known baseline — it cannot be tracked.
+
+Tell me the team name, quarter, and top priorities and I will draft OKRs immediately.

package/skills/planning/weekly-review/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: weekly-review
+description: Facilitate a structured weekly review covering what shipped, blockers, decisions, and next week's priorities
+category: planning
+---
+
+# Weekly Review
+
+Facilitate a structured weekly review. Surface what matters, clear blockers, align on priorities.
+
+## Review structure (45 minutes)
+
+### 1. SHIPPED THIS WEEK (10 min)
+Format: `[scope] description — impact`
+Example: `[checkout] Reduced p95 latency 800ms → 210ms — unblocks Q2 KR1.1`
+
+### 2. IN PROGRESS (5 min)
+State + estimated completion date. Flag anything >50% over estimate.
+
+### 3. BLOCKERS (10 min)
+For each: what is blocked, who can unblock it, ETA.
+Escalate anything blocked >2 days without a clear owner.
+
+### 4. DECISIONS NEEDED (10 min)
+Format: `[decision] options + recommendation + owner + deadline`
+
+### 5. NEXT WEEK PRIORITIES (10 min)
+Top 3-5 items, ranked by impact, with an owner.
+
+## Output format
+
+```
+WEEKLY REVIEW — Week of 2026-04-28
+
+SHIPPED
+✓ [auth] Migrated session storage to Redis — reduces DB load 40%
+✓ [infra] Upgraded k8s cluster to 1.29 — zero downtime
+
+IN PROGRESS
+→ [checkout] Payment provider migration — 60% done, ETA 2026-05-05
+→ [data] ETL pipeline — blocked (see blockers)
+
+BLOCKERS
+⚠ ETL pipeline needs Snowflake credentials — owner: @alice, ETA: 2026-05-02
+⚠ Design review for onboarding — waiting on design since 2026-04-25
+
+DECISIONS NEEDED
+? Monorepo vs multi-repo for mobile — recommend monorepo — owner: @bob — deadline: 2026-05-03
+
+NEXT WEEK
+1. Finish payment provider migration — @carol
+2. Unblock ETL pipeline — @dave
+3. Ship onboarding v2 to 10% of new signups — @eve
+```
+
+## Rules
+
+- Shipped items: completed/shipped/merged only — no "worked on X".
+- Blockers must have an owner and deadline, or they are risks not blockers.
+- Decisions without a deadline are discussions not decisions.
+- Next week: ≤5 priorities. Help rank and drop if the team lists more.
+- Carry unresolved blockers from last week to the top of this week's list.
+
+Paste last week's notes, Jira/Linear export, or describe what happened and I will produce the review.

package/skills/software-development/README.md

@@ -0,0 +1,3 @@
+# software-development skills
+
+Built-in skills in this category. Drop additional SKILL.md files in subdirectories.

package/skills/software-development/code-review/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: code-review
+description: Perform thorough code reviews covering correctness, security, performance, readability, and test coverage
+category: software-development
+---
+
+# Code Review
+
+Perform rigorous, constructive code reviews. Flag real issues, suggest concrete fixes, acknowledge what is done well.
+
+## Review dimensions (in order of severity)
+
+### 1. CORRECTNESS
+- Does the code do what the PR description claims?
+- Off-by-one errors, wrong comparisons, wrong variable names?
+- Async/await patterns correct? Error propagation complete?
+- Null/undefined/empty cases handled?
+
+### 2. SECURITY
+- Injection: SQL, shell, HTML, path traversal
+- Hardcoded secrets or tokens in logs
+- Protected routes actually protected?
+- User input validated at boundaries?
+- New deps pinned? Known CVEs?
+
+### 3. PERFORMANCE
+- N+1 queries (loop that calls DB/API per iteration)
+- Missing indexes for new query patterns
+- Blocking calls in async context
+- Large allocations in hot paths
+
+### 4. READABILITY
+- Names accurate and unambiguous?
+- Functions ≤20 lines?
+- Magic numbers replaced with named constants?
+- Error handling consistent with codebase?
+
+### 5. TESTS
+- New behaviour covered?
+- Tests assert outcomes, not implementation details?
+- Error paths tested, not just happy path?
+- Tests deterministic (no flaky sleeps, no ordering dependence)?
+
+## Comment format
+
+```
+[BLOCKER] src/auth.js:42 — SQL built by string concatenation. Use: db.query('SELECT * FROM users WHERE id = $1', [id])
+
+[SUGGESTION] src/api.js:88 — Loop calls getUserById() N times. Fetch all with WHERE id = ANY($1) and build a Map.
+
+[NITPICK] src/util.js:15 — Variable name `d` is ambiguous. Use `date` or `deadline`.
+
+[PRAISE] src/cache.js — Cache invalidation logic is clean; TTL=0 and concurrent write edge cases handled correctly.
+```
+
+Severity:
+- **BLOCKER** — must fix before merge (bug, security, data loss)
+- **SUGGESTION** — should fix, significant improvement
+- **NITPICK** — optional, style/clarity
+- **PRAISE** — acknowledge explicitly
+
+## Rules
+
+- File:line reference on every comment.
+- Every BLOCKER includes a concrete fix.
+- Do not nitpick formatting if there is a linter — reference the linter rule.
+- Do not comment on code outside the diff unless the diff depends on it.
+- End with: APPROVE / REQUEST CHANGES / NEEDS DISCUSSION.
+
+Paste the diff or describe the PR and I will review it.

package/skills/software-development/rfc-writer/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: rfc-writer
+description: Write technical RFCs and design documents from a problem statement or rough notes
+category: software-development
+---
+
+# RFC Writer
+
+Write clear, well-structured technical RFCs that drive decisions, not just describe ideas.
+
+## RFC structure
+
+```markdown
+# RFC-NNN: <Title>
+
+**Status**: Draft | In Review | Accepted | Rejected | Superseded by RFC-NNN
+**Author(s)**: <names>
+**Date**: YYYY-MM-DD
+**Decision deadline**: YYYY-MM-DD
+
+## Summary
+One paragraph. What are we proposing, and why does it matter?
+
+## Problem statement
+Current situation, pain caused, data (error rates, latency, support tickets, developer hours).
+
+## Goals
+Specific, measurable outcomes this RFC achieves.
+
+## Non-goals
+Explicitly out of scope.
+
+## Proposed solution
+Architecture diagram (Mermaid preferred), key data structures, API contracts,
+migration path, rollout plan (feature flags, gradual rollout, kill switch).
+
+## Alternatives considered
+For each: what it is, why rejected (specific reasons — not just "too complex").
+
+## Impact assessment
+| Dimension | Assessment |
+|---|---|
+| Performance | adds 2ms p99 latency |
+| Security | no new attack surface |
+| Reliability | one new external dependency |
+| Cost | +$200/mo Snowflake compute |
+
+## Open questions
+Numbered list. Each has an owner and resolution deadline.
+
+## Implementation plan
+- [ ] Phase 1: ... (owner, ETA)
+- [ ] Phase 2: ... (owner, ETA)
+
+## References
+Related RFCs, ADRs, tickets, papers, external docs.
+```
+
+## Rules
+
+- Problem statement before solution. Never lead with "we want to build X".
+- Every alternative must explain specifically why it was rejected.
+- Open questions must have owners. Ownerless questions are abandoned questions.
+- Summary readable by someone unfamiliar with the domain.
+- Total RFC under 2000 words. Appendices OK for data.
+- If the decision deadline is missing, add one.
+
+Describe the problem and rough solution and I will draft the RFC immediately.