@cubis/foundry 0.3.71 → 0.3.72

package/workflows/powers/spec-miner/SKILL.md

@@ -1,82 +1,74 @@
 ---
 name: spec-miner
-description: Use when understanding legacy or undocumented systems, creating documentation for existing code, or extracting specifications from implementations. Invoke for legacy analysis, code archaeology, undocumented features.
+description: "Use when reverse-engineering legacy or undocumented systems into structured specifications with code-grounded evidence and EARS-format requirements."
 license: MIT
-allowed-tools: Read, Grep, Glob, Bash
 metadata:
-  author: https://github.com/Jeffallan
-  version: "1.0.0"
-  domain: workflow
-  triggers: reverse engineer, legacy code, code analysis, undocumented, understand codebase, existing system
-  role: specialist
-  scope: review
-  output-format: document
-  related-skills: feature-forge, fullstack-guardian, architecture-designer
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # Spec Miner
 
-Reverse-engineering specialist who extracts specifications from existing codebases.
+## Purpose
 
-## Role Definition
+Use when reverse-engineering legacy or undocumented systems into structured specifications with code-grounded evidence and EARS-format requirements.
 
-You are a senior software archaeologist with 10+ years of experience. You operate with two perspectives: **Arch Hat** for system architecture and data flows, and **QA Hat** for observable behaviors and edge cases.
+## When to Use
 
-## When to Use This Skill
+- Understanding legacy or undocumented systems by extracting behavior from code.
+- Creating documentation for existing codebases that lack specifications.
+- Onboarding onto unfamiliar projects by mapping structure, data flows, and business logic.
+- Planning enhancements or migrations that require understanding current behavior first.
+- Extracting implicit requirements from implementations for formal specification.
 
-- Understanding legacy or undocumented systems
-- Creating documentation for existing code
-- Onboarding to a new codebase
-- Planning enhancements to existing features
-- Extracting requirements from implementation
+## Instructions
 
-## Core Workflow
+1. Scope the analysis — identify target modules, boundaries, and what the spec should cover.
+2. Explore structure — map directory layout, entry points, and dependency graph using file discovery.
+3. Trace data flows — follow request paths, state transformations, and external integrations.
+4. Extract behaviors — document observed requirements in EARS format (Ubiquitous, Event-Driven, State-Driven, Conditional, Optional).
+5. Flag uncertainties — mark areas where behavior is ambiguous or requires human clarification.
+6. Produce specification — structured document with technology stack, architecture, modules, requirements, acceptance criteria, and open questions.
 
-1. **Scope** - Identify analysis boundaries (full system or specific feature)
-2. **Explore** - Map structure using Glob, Grep, Read tools
-3. **Trace** - Follow data flows and request paths
-4. **Document** - Write observed requirements in EARS format
-5. **Flag** - Mark areas needing clarification
+### Baseline standards
 
-## Reference Guide
+- Ground every finding in code evidence with file paths and line references.
+- Distinguish facts (observed in code) from inferences (reasonable assumptions).
+- Operate with dual mindset: Architecture Hat (structure, data flows) and QA Hat (behaviors, edge cases).
+- Document security, authentication, and error handling patterns explicitly.
+- Include external integrations, configuration, and environment dependencies.
 
-Load detailed guidance based on context:
+### Constraints
 
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| Analysis Process | `references/analysis-process.md` | Starting exploration, Glob/Grep patterns |
-| EARS Format | `references/ears-format.md` | Writing observed requirements |
-| Specification Template | `references/specification-template.md` | Creating final specification document |
-| Analysis Checklist | `references/analysis-checklist.md` | Ensuring thorough analysis |
+- Never assume behavior without code evidence.
+- Never skip security or error handling paths during analysis.
+- Never generate a specification without thorough codebase exploration.
+- Always include code locations for every documented behavior.
+- Always mark uncertainties and questions separately from confirmed findings.
 
-## Constraints
+## Output Format
 
-### MUST DO
-- Ground all observations in actual code evidence
-- Use Read, Grep, Glob extensively to explore
-- Distinguish between observed facts and inferences
-- Document uncertainties in dedicated section
-- Include code locations for each observation
+Save as `specs/{project_name}_reverse_spec.md`:
 
-### MUST NOT DO
-- Make assumptions without code evidence
-- Skip security pattern analysis
-- Ignore error handling patterns
-- Generate spec without thorough exploration
+1. Technology stack and architecture overview
+2. Module and directory structure
+3. Observed requirements in EARS format
+4. Non-functional observations (performance, security, scalability)
+5. Inferred acceptance criteria
+6. Uncertainties and questions
+7. Recommendations for improvement
 
-## Output Templates
+## References
 
-Save specification as: `specs/{project_name}_reverse_spec.md`
+No additional reference files.
 
-Include:
-1. Technology stack and architecture
-2. Module/directory structure
-3. Observed requirements (EARS format)
-4. Non-functional observations
-5. Inferred acceptance criteria
-6. Uncertainties and questions
-7. Recommendations
+## Scripts
+
+No helper scripts are required for this skill right now.
 
-## Knowledge Reference
+## Examples
 
-Code archaeology, static analysis, design patterns, architectural patterns, EARS syntax, API documentation inference
+- "Reverse-engineer the authentication flow in this legacy codebase"
+- "Create a specification document for this undocumented API service"
+- "Map the data flows and business logic in this module for onboarding"

package/workflows/powers/sqlite/POWER.md

@@ -0,0 +1,67 @@
+````markdown
+---
+inclusion: manual
+name: sqlite
+description: "Use when the task is specifically SQLite or libSQL/Turso-style SQLite: local-first schema design, WAL/concurrency tradeoffs, embedded deployments, and lightweight migration strategy."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# SQLite
+
+## Purpose
+
+Use when the task is specifically SQLite or libSQL/Turso-style SQLite: local-first schema design, WAL/concurrency tradeoffs, embedded deployments, and lightweight migration strategy.
+
+## When to Use
+
+- The engine is SQLite, libSQL, Turso, or another SQLite-derived deployment.
+- The task depends on embedded/local-first behavior, WAL mode, file-level concurrency, or sync constraints.
+- You need SQLite-aware schema, migration, or indexing guidance.
+
+## Instructions
+
+1. Confirm whether the workload is embedded, mobile, edge, or remotely replicated SQLite.
+2. Model data and indexes around the read paths while keeping writes and locking behavior visible.
+3. Decide WAL, foreign key, sync, and migration posture explicitly.
+4. Validate whether single-writer and file-level concurrency constraints remain acceptable.
+5. Report operational caveats such as replication, backup, and schema rollout behavior.
+
+### Baseline standards
+
+- Prefer simple relational design and predictable transactions.
+- Keep migrations small and reversible.
+- Treat write concurrency and sync semantics as product constraints, not implementation details.
+- Use SQLite because the workload fits it, not because setup is easy.
+
+### Constraints
+
+- Avoid assuming server-database scaling behavior.
+- Avoid ignoring WAL, checkpointing, or file-lock realities.
+- Avoid large migration steps with no rollback or recovery plan.
+- Avoid using SQLite past the point where product constraints clearly demand a different engine.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+Load on demand. Do not preload all reference files.
+
+| File | Load when |
+| --- | --- |
+| `references/sqlite-checklist.md` | You need a deeper SQLite playbook for WAL, concurrency, local-first deployment, sync constraints, and lightweight migration posture. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with sqlite best practices in this project"
+- "Review my sqlite implementation for issues"
+````

package/workflows/powers/sqlite/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: sqlite
+description: "Use when the task is specifically SQLite or libSQL/Turso-style SQLite: local-first schema design, WAL/concurrency tradeoffs, embedded deployments, and lightweight migration strategy."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# SQLite
+
+## Purpose
+
+Use when the task is specifically SQLite or libSQL/Turso-style SQLite: local-first schema design, WAL/concurrency tradeoffs, embedded deployments, and lightweight migration strategy.
+
+## When to Use
+
+- The engine is SQLite, libSQL, Turso, or another SQLite-derived deployment.
+- The task depends on embedded/local-first behavior, WAL mode, file-level concurrency, or sync constraints.
+- You need SQLite-aware schema, migration, or indexing guidance.
+
+## Instructions
+
+1. Confirm whether the workload is embedded, mobile, edge, or remotely replicated SQLite.
+2. Model data and indexes around the read paths while keeping writes and locking behavior visible.
+3. Decide WAL, foreign key, sync, and migration posture explicitly.
+4. Validate whether single-writer and file-level concurrency constraints remain acceptable.
+5. Report operational caveats such as replication, backup, and schema rollout behavior.
+
+### Baseline standards
+
+- Prefer simple relational design and predictable transactions.
+- Keep migrations small and reversible.
+- Treat write concurrency and sync semantics as product constraints, not implementation details.
+- Use SQLite because the workload fits it, not because setup is easy.
+
+### Constraints
+
+- Avoid assuming server-database scaling behavior.
+- Avoid ignoring WAL, checkpointing, or file-lock realities.
+- Avoid large migration steps with no rollback or recovery plan.
+- Avoid using SQLite past the point where product constraints clearly demand a different engine.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+Load on demand. Do not preload all reference files.
+
+| File | Load when |
+| --- | --- |
+| `references/sqlite-checklist.md` | You need a deeper SQLite playbook for WAL, concurrency, local-first deployment, sync constraints, and lightweight migration posture. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with sqlite best practices in this project"
+- "Review my sqlite implementation for issues"

package/workflows/powers/sqlite/references/sqlite-checklist.md

@@ -0,0 +1,19 @@
+# SQLite Checklist
+
+Load this when SQLite or libSQL-specific behavior matters.
+
+## Workload fit
+
+- Confirm the workload fits embedded or local-first constraints.
+- Keep single-writer and file-level concurrency visible.
+
+## Operational choices
+
+- Decide WAL posture explicitly.
+- Check checkpoint, backup, and sync behavior when the product depends on them.
+- Keep migrations small and recovery-friendly.
+
+## Design
+
+- Model around actual read paths.
+- Do not assume server-database scaling or operational patterns.

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

@@ -2,89 +2,148 @@
 ---
 inclusion: manual
 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.
 ````