@cubis/foundry 0.3.71 → 0.3.72

package/workflows/powers/sre-engineer/SKILL.md

@@ -1,87 +1,146 @@
 ---
 name: sre-engineer
-description: Use when defining SLIs/SLOs, managing error budgets, or building reliable systems at scale. Invoke for incident management, chaos engineering, toil reduction, capacity planning.
-license: MIT
+description: Apply site reliability engineering practices including SLOs, error budgets, capacity planning, chaos engineering, and incident management for production systems.
+license: Apache-2.0
 metadata:
-  author: https://github.com/Jeffallan
-  version: "1.0.0"
-  domain: devops
-  triggers: SRE, site reliability, SLO, SLI, error budget, incident management, chaos engineering, toil reduction, on-call, MTTR
-  role: specialist
-  scope: implementation
-  output-format: code
-  related-skills: devops-engineer, cloud-architect, kubernetes-specialist
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI
 ---
 
 # SRE Engineer
 
-Senior Site Reliability Engineer with expertise in building highly reliable, scalable systems through SLI/SLO management, error budgets, capacity planning, and automation.
+## Purpose
 
-## Role Definition
+Apply Site Reliability Engineering practices to build and maintain reliable production systems. Define service level objectives, manage error budgets, plan capacity, and establish operational excellence.
 
-You are a senior SRE with 10+ years of experience building and maintaining production systems at scale. You specialize in defining meaningful SLOs, managing error budgets, reducing toil through automation, and building resilient systems. Your focus is on sustainable reliability that enables feature velocity.
+## When to Use
 
-## When to Use This Skill
+- Defining SLOs, SLIs, and SLAs for a new or existing service
+- Managing error budgets and reliability trade-offs
+- Capacity planning and scaling decisions
+- Designing for graceful degradation and resilience
+- Conducting chaos engineering experiments
+- Building on-call procedures and runbooks
+- Postmortem analysis and reliability improvements
 
-- Defining SLIs/SLOs and error budgets
-- Implementing reliability monitoring and alerting
-- Reducing operational toil through automation
-- Designing chaos engineering experiments
-- Managing incidents and postmortems
-- Building capacity planning models
-- Establishing on-call practices
+## Instructions
 
-## Core Workflow
+### Step 1 — Define Service Level Indicators (SLIs)
 
-1. **Assess reliability** - Review architecture, SLOs, incidents, toil levels
-2. **Define SLOs** - Identify meaningful SLIs and set appropriate targets
-3. **Implement monitoring** - Build golden signal dashboards and alerting
-4. **Automate toil** - Identify repetitive tasks and build automation
-5. **Test resilience** - Design and execute chaos experiments
+SLIs are the metrics that matter to users:
 
-## Reference Guide
+| SLI Category | Measures                        | Example                                  |
+| ------------ | ------------------------------- | ---------------------------------------- |
+| Availability | System is accepting requests    | Successful requests / total requests     |
+| Latency      | Response time for good requests | p99 < 300ms                              |
+| Throughput   | System handles expected load    | Requests/sec at peak without degradation |
+| Correctness  | Responses are accurate          | Successful data validations / total      |
+| Freshness    | Data is up to date              | Time since last successful sync < 1 min  |
 
-Load detailed guidance based on context:
+**Choose 3–5 SLIs per service** — too many dilutes focus.
 
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| SLO/SLI | `references/slo-sli-management.md` | Defining SLOs, calculating error budgets |
-| Error Budgets | `references/error-budget-policy.md` | Managing budgets, burn rates, policies |
-| Monitoring | `references/monitoring-alerting.md` | Golden signals, alert design, dashboards |
-| Automation | `references/automation-toil.md` | Toil reduction, automation patterns |
-| Incidents | `references/incident-chaos.md` | Incident response, chaos engineering |
+### Step 2 — Set Service Level Objectives (SLOs)
 
-## Constraints
+SLOs are targets for SLIs:
 
-### MUST DO
-- Define quantitative SLOs (e.g., 99.9% availability)
-- Calculate error budgets from SLO targets
-- Monitor golden signals (latency, traffic, errors, saturation)
-- Write blameless postmortems for all incidents
-- Measure toil and track reduction progress
-- Automate repetitive operational tasks
-- Test failure scenarios with chaos engineering
-- Balance reliability with feature velocity
+```
+Availability SLO: 99.9% of requests succeed (43.8 min downtime/month)
+Latency SLO: 99% of requests complete in < 200ms
+```
 
-### MUST NOT DO
-- Set SLOs without user impact justification
-- Alert on symptoms without actionable runbooks
-- Tolerate >50% toil without automation plan
-- Skip postmortems or assign blame
-- Implement manual processes for recurring tasks
-- Deploy without capacity planning
-- Ignore error budget exhaustion
-- Build systems that can't degrade gracefully
+**SLO calibration**:
+| Target | Monthly Downtime | Error Budget |
+|--------|-----------------|--------------|
+| 99.0% | 7.3 hours | 1% of requests can fail |
+| 99.9% | 43.8 minutes | 0.1% of requests can fail |
+| 99.95% | 21.9 minutes | 0.05% of requests can fail |
+| 99.99% | 4.3 minutes | 0.01% of requests can fail |
 
-## Output Templates
+**Rules**:
 
-When implementing SRE practices, provide:
-1. SLO definitions with SLI measurements and targets
-2. Monitoring/alerting configuration (Prometheus, etc.)
-3. Automation scripts (Python, Go, Terraform)
-4. Runbooks with clear remediation steps
-5. Brief explanation of reliability impact
+- SLO must be achievable with current architecture
+- SLO must be measurable with existing instrumentation
+- SLO should be tighter than the SLA (contract with users)
+- Start conservative, tighten as reliability improves
 
-## Knowledge Reference
+### Step 3 — Manage Error Budgets
 
-SLO/SLI design, error budgets, golden signals (latency/traffic/errors/saturation), Prometheus/Grafana, chaos engineering (Chaos Monkey, Gremlin), toil reduction, incident management, blameless postmortems, capacity planning, on-call best practices
+Error budget = 100% − SLO target
+
+**When budget is healthy** (> 50% remaining):
+
+- Ship features aggressively
+- Run chaos experiments
+- Take on technical debt reduction
+
+**When budget is burning** (< 25% remaining):
+
+- Slow down feature releases
+- Prioritize reliability work
+- Increase review rigor
+
+**When budget is exhausted** (0%):
+
+- Freeze non-critical changes
+- All engineering effort on reliability
+- Root cause analysis on budget-burning incidents
+
+### Step 4 — Design for Resilience
+
+**Failure modes and mitigations**:
+
+| Failure               | Mitigation                                              |
+| --------------------- | ------------------------------------------------------- |
+| Single instance crash | Multiple replicas, health checks, auto-restart          |
+| Dependency timeout    | Circuit breakers, timeouts, fallback responses          |
+| Traffic spike         | Auto-scaling, rate limiting, load shedding              |
+| Data center outage    | Multi-region deployment, DNS failover                   |
+| Data corruption       | Immutable audit logs, point-in-time recovery, checksums |
+| Cascading failure     | Bulkheads, retry budgets, backpressure                  |
+
+**Graceful degradation**:
+
+- Serve cached/stale data when the database is slow
+- Disable non-critical features under load
+- Return partial results instead of failing completely
+- Queue work for later processing when at capacity
+
+### Step 5 — Operational Readiness
+
+**Production readiness checklist**:
+
+- [ ] SLOs defined and dashboarded
+- [ ] Alerting on SLO burn rate (not just raw metrics)
+- [ ] Runbooks for every alert
+- [ ] On-call rotation established
+- [ ] Rollback procedure documented and tested
+- [ ] Disaster recovery plan tested within last quarter
+- [ ] Dependency failures handled (circuit breakers, timeouts)
+- [ ] Load testing performed at 2x expected peak
+
+## Output Format
+
+```
+## Reliability Assessment
+[current state and risk level]
+
+## SLO Definitions
+[SLI → SLO mappings with error budgets]
+
+## Recommendations
+[priority-ordered reliability improvements]
+
+## Operational Procedures
+[runbooks, on-call procedures, escalation paths]
+```
+
+## Examples
+
+**User**: "Define SLOs for our payment processing API"
+
+**Response approach**: High-reliability target (99.99% availability for financial operations). SLIs: availability, latency (p99 < 500ms), correctness (transaction accuracy). Error budget: 4.3 min/month. Alerting on 1-hour burn rate. Circuit breaker on downstream payment provider.
+
+**User**: "Our service keeps going down during traffic spikes"
+
+**Response approach**: Analyze the failure mode (OOM? connection pool exhaustion? cold starts?). Recommend auto-scaling with pre-warming, rate limiting per client, load shedding for non-critical endpoints. Define SLO for acceptable degradation under load.

package/workflows/powers/static-analysis/POWER.md

@@ -2,115 +2,159 @@
 ---
 inclusion: manual
 name: static-analysis
-description: Runs CodeQL-based static security analysis (database build, query pack selection, and SARIF results) for vulnerability discovery and audits. Not for custom QL authoring or CI/CD setup.
-allowed-tools:
-  - Bash
-  - Read
-  - Write
-  - Glob
-  - Grep
-  - AskUserQuestion
-  - Task
-  - TaskCreate
-  - TaskList
-  - TaskUpdate
+description: Configure and use static analysis tools including linters, formatters, type checkers, and custom rules to enforce code quality and consistency.
+license: Apache-2.0
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI
 ---
 
-# CodeQL Analysis
+# Static Analysis
 
-Supported languages: Python, JavaScript/TypeScript, Go, Java/Kotlin, C/C++, C#, Ruby, Swift.
+## Purpose
 
-**Skill resources:** Reference files and templates are located at `{baseDir}/references/` and `{baseDir}/workflows/`. Use `{baseDir}` to resolve paths to these files at runtime.
+Guide the setup and use of static analysis tools — linters, formatters, type checkers, and custom rules — to catch bugs early, enforce conventions, and maintain code quality automatically.
 
-## Quick Start
+## When to Use
 
-For the common case ("scan this codebase for vulnerabilities"):
+- Setting up linting and formatting for a new project
+- Configuring ESLint, Prettier, Biome, or equivalent tools
+- Writing custom lint rules for team conventions
+- Fixing lint errors or understanding why a rule exists
+- Integrating static analysis into CI/CD
+- Choosing between competing tools
 
-```bash
-# 1. Verify CodeQL is installed
-command -v codeql >/dev/null 2>&1 && codeql --version || echo "NOT INSTALLED"
+## Instructions
 
-# 2. Check for existing database
-ls -dt codeql_*.db 2>/dev/null | head -1
-```
+### Step 1 — Choose the Right Tools
 
-Then execute the full pipeline: **build database → create data extensions → run analysis** using the workflows below.
+| Language      | Linter        | Formatter       | Type Checker       |
+| ------------- | ------------- | --------------- | ------------------ |
+| TypeScript/JS | ESLint, Biome | Prettier, Biome | TypeScript (`tsc`) |
+| Python        | Ruff, Flake8  | Black, Ruff     | mypy, pyright      |
+| Go            | golangci-lint | gofmt           | Go compiler        |
+| Rust          | Clippy        | rustfmt         | Rust compiler      |
 
-## When to Use
+**Recommended approach**:
 
-- Scanning a codebase for security vulnerabilities with deep data flow analysis
-- Building a CodeQL database from source code (with build capability for compiled languages)
-- Finding complex vulnerabilities that require interprocedural taint tracking or AST/CFG analysis
-- Performing comprehensive security audits with multiple query packs
+- Biome for TypeScript/JS projects (replaces ESLint + Prettier, faster)
+- Ruff for Python (replaces Flake8 + Black + isort, faster)
+- Use the language's official formatter when available
 
-## When NOT to Use
+### Step 2 — Configure Incrementally
 
-- **Writing custom queries** - Use a dedicated query development skill
-- **CI/CD integration** - Use GitHub Actions documentation directly
-- **Quick pattern searches** - Use Semgrep or grep for speed
-- **No build capability** for compiled languages - Consider Semgrep instead
-- **Single-file or lightweight analysis** - Semgrep is faster for simple pattern matching
+**Start strict, relax as needed**:
 
-## Rationalizations to Reject
+1. Start with recommended preset (`"extends": ["recommended"]`)
+2. Enable formatting rules (consistent style, no debates)
+3. Enable correctness rules (actual bugs: unused vars, unreachable code)
+4. Enable performance rules (avoidable perf issues)
+5. Add custom rules specific to your team after the baseline is stable
 
-These shortcuts lead to missed findings. Do not accept them:
+**Don't**:
 
-- **"security-extended is enough"** - It is the baseline. Always check if Trail of Bits packs and Community Packs are available for the language. They catch categories `security-extended` misses entirely.
-- **"The database built, so it's good"** - A database that builds does not mean it extracted well. Always run Step 4 (quality assessment) and check file counts against expected source files. A cached build produces zero useful extraction.
-- **"Data extensions aren't needed for standard frameworks"** - Even Django/Spring apps have custom wrappers around ORM calls, request parsing, or shell execution that CodeQL does not model. Skipping the extensions workflow means missing vulnerabilities in project-specific code.
-- **"build-mode=none is fine for compiled languages"** - It produces severely incomplete analysis. No interprocedural data flow through compiled code is traced. Only use as an absolute last resort and clearly flag the limitation.
-- **"No findings means the code is secure"** - Zero findings can indicate poor database quality, missing models, or wrong query packs. Investigate before reporting clean results.
-- **"I'll just run the default suite"** - The default suite varies by how CodeQL is invoked. Always explicitly specify the suite (e.g., `security-extended`) so results are reproducible.
+- Enable everything at once on an existing codebase
+- Disable rules because they're "annoying" without understanding them
+- Use `// eslint-disable` without a comment explaining why
 
----
+### Step 3 — Key Rules by Category
 
-## Workflow Selection
+**Correctness** (catch bugs):
 
-This skill has three workflows:
+- No unused variables/imports
+- No unreachable code
+- No implicit type coercion in comparisons
+- No floating promises (unhandled async)
+- No shadowed variables in nested scopes
 
-| Workflow | Purpose |
-|----------|---------|
-| [build-database](workflows/build-database.md) | Create CodeQL database using 3 build methods in sequence |
-| [create-data-extensions](workflows/create-data-extensions.md) | Detect or generate data extension models for project APIs |
-| [run-analysis](workflows/run-analysis.md) | Select rulesets, execute queries, process results |
+**Consistency** (enforce style):
 
+- Consistent naming conventions (camelCase, PascalCase, SCREAMING_SNAKE)
+- Consistent import ordering
+- Consistent quote style and semicolons
+- Consistent use of `const` vs `let`
 
-### Auto-Detection Logic
+**Security** (prevent vulnerabilities):
 
-**If user explicitly specifies** what to do (e.g., "build a database", "run analysis"), execute that workflow.
+- No `eval()` or `Function()` constructor
+- No `innerHTML` assignments (XSS risk)
+- No hardcoded secrets or credentials
+- No `any` type in TypeScript (use `unknown` for unknown types)
 
-**Default pipeline for "test", "scan", "analyze", or similar:** Execute all three workflows sequentially: build → extensions → analysis. The create-data-extensions step is critical for finding vulnerabilities in projects with custom frameworks or annotations that CodeQL doesn't model by default.
+**Performance** (avoid waste):
 
-```bash
-# Check if database exists
-DB=$(ls -dt codeql_*.db 2>/dev/null | head -1)
-if [ -n "$DB" ] && codeql resolve database -- "$DB" >/dev/null 2>&1; then
-  echo "DATABASE EXISTS ($DB) - can run analysis"
-else
-  echo "NO DATABASE - need to build first"
-fi
-```
+- No unnecessary re-renders (React-specific)
+- No synchronous file operations in async contexts
+- No `console.log` in production code
+
+### Step 4 — Integrate into Workflow
+
+**Local development**:
+
+- Editor integration (real-time feedback as you type)
+- Format on save
+- Pre-commit hook (lint-staged + husky or lefthook)
+
+**CI/CD**:
+
+- Run lint check on every PR
+- Fail the build on lint errors (not warnings — fix or disable)
+- Cache lint results between runs
 
-| Condition | Action |
-|-----------|--------|
-| No database exists | Execute build → extensions → analysis (full pipeline) |
-| Database exists, no extensions | Execute extensions → analysis |
-| Database exists, extensions exist | Ask user: run analysis on existing DB, or rebuild? |
-| User says "just run analysis" or "skip extensions" | Run analysis only |
+**Migration strategy** (existing codebase):
 
+- Fix auto-fixable issues in one PR (formatting, import order)
+- Enable new rules as warnings first, then promote to errors
+- Fix rules incrementally by directory, not all at once
 
-### Decision Prompt
+### Step 5 — Write Custom Rules
 
-If unclear, ask user:
+When team conventions aren't covered by existing rules:
 
+**ESLint custom rule example** (no importing from internal paths):
+
+```javascript
+module.exports = {
+  meta: {
+    type: "problem",
+    messages: { noInternal: "Do not import from internal modules" },
+  },
+  create(context) {
+    return {
+      ImportDeclaration(node) {
+        if (node.source.value.includes("/internal/")) {
+          context.report({ node, messageId: "noInternal" });
+        }
+      },
+    };
+  },
+};
 ```
-I can help with CodeQL analysis. What would you like to do?
 
-1. **Full scan (Recommended)** - Build database, create extensions, then run analysis
-2. **Build database** - Create a new CodeQL database from this codebase
-3. **Create data extensions** - Generate custom source/sink models for project APIs
-4. **Run analysis** - Run security queries on existing database
+## Output Format
+
+```
+## Tool Configuration
+[config files and settings]
+
+## Rules Enabled
+[categorized list of rules with rationale]
+
+## CI Integration
+[pipeline step definition]
 
-[If database exists: "I found an existing database at <DB_NAME>"]
+## Migration Plan
+[how to adopt incrementally on existing code]
 ```
+
+## Examples
+
+**User**: "Set up ESLint and Prettier for our TypeScript React project"
+
+**Response approach**: Recommend Biome as modern alternative. If staying with ESLint: configure with typescript-eslint, eslint-plugin-react, prettier integration. Show config file, ignore patterns, and pre-commit hook setup.
+
+**User**: "We have 5000 lint errors — how do we fix this?"
+
+**Response approach**: Auto-fix formatting issues first (one big PR). Establish baseline with current errors suppressed. Enable rules as warnings. Fix incrementally by directory. Add CI check that blocks new violations.
 ````