@cubis/foundry 0.3.67 → 0.3.68

package/workflows/skills/rust-pro/references/unsafe-and-ffi-guide.md

@@ -0,0 +1,167 @@
+# Unsafe and FFI Guide
+
+## When Unsafe Is Justified
+
+Unsafe Rust is a power tool for situations where the type system cannot prove safety. Every `unsafe` block must:
+
+1. **Document the invariant** it relies on in a comment above the block.
+2. **Be as small as possible** — put only the unsafe operation inside the block, not surrounding logic.
+3. **Have a safe wrapper** — expose a safe public API that upholds the invariant.
+
+```rust
+/// Returns a slice of the buffer without bounds checking.
+///
+/// # Safety
+/// `start` and `end` must be within bounds of `buf`, and `start <= end`.
+unsafe fn slice_unchecked(buf: &[u8], start: usize, end: usize) -> &[u8] {
+    // SAFETY: caller guarantees start <= end and both are in bounds
+    buf.get_unchecked(start..end)
+}
+
+// Safe wrapper that validates before calling unsafe
+fn slice_checked(buf: &[u8], start: usize, end: usize) -> Option<&[u8]> {
+    if start <= end && end <= buf.len() {
+        // SAFETY: we just verified the bounds
+        Some(unsafe { buf.get_unchecked(start..end) })
+    } else {
+        None
+    }
+}
+```
+
+## Common Unsafe Operations
+
+| Operation               | Why unsafe                                  | Invariant to document                                                     |
+| ----------------------- | ------------------------------------------- | ------------------------------------------------------------------------- |
+| `*ptr` dereference      | Pointer may be null, dangling, or unaligned | Pointer is valid, aligned, and points to initialized memory               |
+| `slice::from_raw_parts` | Length may exceed allocation                | Pointer + length must describe valid, initialized memory                  |
+| `transmute`             | Reinterprets bits arbitrarily               | Source and target types have same size, alignment, and valid bit patterns |
+| `unsafe impl Send/Sync` | Compiler can't verify thread safety         | Type's internal synchronization guarantees cross-thread safety            |
+| Union field access      | Accessing wrong variant is UB               | Active variant is the one being accessed                                  |
+
+## FFI Basics with `extern "C"`
+
+```rust
+// Declare foreign functions
+extern "C" {
+    fn strlen(s: *const std::ffi::c_char) -> usize;
+    fn printf(fmt: *const std::ffi::c_char, ...) -> i32;
+}
+
+// Safe wrapper
+fn safe_strlen(s: &std::ffi::CStr) -> usize {
+    // SAFETY: CStr guarantees null-terminated, valid pointer
+    unsafe { strlen(s.as_ptr()) }
+}
+
+// Expose Rust function to C
+#[no_mangle]
+pub extern "C" fn rust_add(a: i32, b: i32) -> i32 {
+    a + b
+}
+```
+
+## String Conversion at FFI Boundaries
+
+```rust
+use std::ffi::{CStr, CString, c_char};
+
+// Rust → C: create CString, pass pointer
+fn call_c_api(name: &str) -> Result<(), std::ffi::NulError> {
+    let c_name = CString::new(name)?; // fails if name contains \0
+    // SAFETY: c_name is valid for the duration of this call
+    unsafe { c_api_set_name(c_name.as_ptr()) };
+    Ok(())
+    // c_name is dropped here — do NOT return the pointer
+}
+
+// C → Rust: receive pointer, convert to &str
+/// # Safety
+/// `ptr` must be a valid, null-terminated C string.
+unsafe fn receive_c_string(ptr: *const c_char) -> String {
+    // SAFETY: caller guarantees ptr is valid null-terminated string
+    let c_str = unsafe { CStr::from_ptr(ptr) };
+    c_str.to_string_lossy().into_owned()
+}
+```
+
+## Raw Pointer Rules
+
+```rust
+// Creating raw pointers is safe — dereferencing is unsafe
+let x = 42;
+let ptr: *const i32 = &x;           // safe
+let value = unsafe { *ptr };        // unsafe — must verify ptr is valid
+
+// Mutable raw pointers
+let mut y = 42;
+let ptr: *mut i32 = &mut y;
+unsafe { *ptr = 100 };              // SAFETY: ptr derived from valid &mut
+
+// NEVER do this — creates aliased mutable pointers
+let mut v = vec![1, 2, 3];
+let p1 = v.as_mut_ptr();
+let p2 = v.as_mut_ptr(); // both point to same memory — UB to write through both
+```
+
+## `Pin` for Self-Referential Types
+
+```rust
+use std::pin::Pin;
+use std::marker::PhantomPinned;
+
+struct SelfReferential {
+    data: String,
+    ptr: *const String,  // points to self.data
+    _pin: PhantomPinned,
+}
+
+impl SelfReferential {
+    fn new(data: String) -> Pin<Box<Self>> {
+        let mut boxed = Box::new(SelfReferential {
+            data,
+            ptr: std::ptr::null(),
+            _pin: PhantomPinned,
+        });
+        let ptr = &boxed.data as *const String;
+        // SAFETY: we own the box and haven't shared the Pin yet
+        unsafe { boxed.as_mut().get_unchecked_mut().ptr = ptr };
+        // After this, the value cannot be moved
+        unsafe { Pin::new_unchecked(boxed) }
+    }
+}
+```
+
+## Unsafe Trait Implementations
+
+```rust
+// Only implement Send/Sync manually when you can prove safety
+struct SharedBuffer {
+    ptr: *mut u8,
+    len: usize,
+    lock: std::sync::Mutex<()>, // provides synchronization
+}
+
+// SAFETY: SharedBuffer synchronizes access through its internal Mutex.
+// The raw pointer is only accessed while the Mutex is held.
+unsafe impl Send for SharedBuffer {}
+unsafe impl Sync for SharedBuffer {}
+```
+
+## Audit Checklist for Unsafe Code
+
+Before merging any `unsafe` block:
+
+1. **Is there a safe alternative?** Check if `std` or a well-audited crate provides the same operation safely.
+2. **Is the `SAFETY` comment present?** Every `unsafe` block must have a `// SAFETY:` comment explaining why it's sound.
+3. **Is the unsafe scope minimal?** Only the unsafe operation itself should be inside the block.
+4. **Is there a safe public wrapper?** Unsafe internals should never be exposed to callers.
+5. **Does Miri pass?** Run `cargo +nightly miri test` to detect undefined behavior.
+6. **Are raw pointers valid?** Verify non-null, aligned, pointing to initialized memory, not aliased with mutable references.
+7. **Are lifetimes correct?** The pointed-to data must outlive the pointer.
+
+```bash
+# Run Miri to detect UB in unsafe code
+cargo +nightly miri test
+cargo +nightly miri run
+```

package/workflows/skills/security-engineer/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: security-engineer
+description: Apply secure coding practices, OWASP Top 10 mitigations, threat modeling, input validation, and vulnerability prevention across web, API, and backend systems.
+license: Apache-2.0
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI
+---
+
+# Security Engineer
+
+## Purpose
+
+Guide secure software development practices. Identify and fix vulnerabilities, apply OWASP Top 10 mitigations, build threat models, and enforce secure coding patterns across the full stack.
+
+## When to Use
+
+- Reviewing code for security vulnerabilities
+- Designing authentication, authorization, or data protection
+- Implementing input validation and output encoding
+- Building threat models for new features or systems
+- Hardening APIs, databases, or infrastructure
+- Responding to security incidents or CVE disclosures
+
+## Instructions
+
+### Step 1 — Identify the Attack Surface
+
+Map what's exposed:
+
+- **User inputs**: forms, URL params, headers, cookies, file uploads
+- **APIs**: endpoints, authentication, rate limiting, CORS
+- **Data stores**: database queries, file system access, caches
+- **Third-party**: external services, SDKs, dependencies
+- **Infrastructure**: secrets management, network exposure, permissions
+
+### Step 2 — Apply OWASP Top 10 Checks
+
+| #   | Risk                      | Key Mitigation                                                                  |
+| --- | ------------------------- | ------------------------------------------------------------------------------- |
+| A01 | Broken Access Control     | Deny by default, validate permissions on every request, server-side enforcement |
+| A02 | Cryptographic Failures    | TLS everywhere, hash passwords with Argon2/bcrypt, never roll custom crypto     |
+| A03 | Injection                 | Parameterized queries, prepared statements, contextual output encoding          |
+| A04 | Insecure Design           | Threat modeling before implementation, abuse case analysis                      |
+| A05 | Security Misconfiguration | Minimal permissions, disable debug in production, security headers              |
+| A06 | Vulnerable Components     | Dependency scanning, automated updates, SBOM                                    |
+| A07 | Auth Failures             | MFA, rate limiting, secure session management, credential stuffing protection   |
+| A08 | Data Integrity Failures   | Verify signatures, integrity checks on CI/CD, signed artifacts                  |
+| A09 | Logging Failures          | Log security events, never log secrets, tamper-evident logs                     |
+| A10 | SSRF                      | Allowlist outbound URLs, validate/sanitize URLs, block internal network access  |
+
+### Step 3 — Secure Coding Patterns
+
+**Input Validation**:
+
+- Validate on the server (client validation is UX, not security)
+- Allowlist valid inputs rather than blocklisting bad ones
+- Validate type, length, range, and format
+- Reject early and fail safely
+
+**Output Encoding**:
+
+- HTML context: HTML-entity encode
+- JavaScript context: JavaScript-encode
+- URL context: URL-encode
+- SQL context: parameterized queries (never string concatenation)
+
+**Authentication**:
+
+- Hash passwords with Argon2id (preferred) or bcrypt (minimum work factor 12)
+- Use constant-time comparison for secrets
+- Implement account lockout with progressive delays
+- Session tokens: cryptographically random, HttpOnly, Secure, SameSite=Strict
+
+**Authorization**:
+
+- Check permissions on every request (not just UI hiding)
+- Use RBAC or ABAC — not role checks scattered in business logic
+- Principle of least privilege for all service accounts
+
+**Secrets Management**:
+
+- Never hardcode secrets in source code
+- Use environment variables or secret managers (Vault, AWS Secrets Manager)
+- Rotate secrets regularly
+- Audit secret access
+
+### Step 4 — Threat Modeling
+
+Use STRIDE for systematic analysis:
+
+| Threat                     | Question                                       |
+| -------------------------- | ---------------------------------------------- |
+| **S**poofing               | Can someone impersonate a user or service?     |
+| **T**ampering              | Can someone modify data in transit or at rest? |
+| **R**epudiation            | Can someone deny performing an action?         |
+| **I**nformation Disclosure | Can someone access unauthorized data?          |
+| **D**enial of Service      | Can someone make the system unavailable?       |
+| **E**levation of Privilege | Can someone gain unauthorized access levels?   |
+
+## Output Format
+
+```
+## Security Review Summary
+[Overall risk assessment: Low / Medium / High / Critical]
+
+## Critical Findings
+- **[OWASP #]**: [vulnerability] → [specific fix with code]
+
+## Recommendations
+- [priority-ordered list of security improvements]
+
+## Secure Patterns Applied
+- ✓ [what's already done well]
+```
+
+## Examples
+
+**User**: "Review this login endpoint for security issues"
+
+**Response approach**: Check password hashing algorithm, session management, rate limiting, CSRF protection, input validation, error messages (no user enumeration), audit logging, TLS enforcement.
+
+**User**: "We're building a file upload feature"
+
+**Response approach**: Validate file type (magic bytes, not just extension), limit file size, store outside web root, generate random filenames, scan for malware, set Content-Disposition headers, restrict MIME types.

package/workflows/skills/security-engineer/evals/evals.json

@@ -0,0 +1,24 @@
+{
+  "evals": [
+    {
+      "prompt": "Review this login endpoint that stores passwords in plain text and uses string concatenation for SQL queries",
+      "assertions": [
+        "identifies plain text password storage as critical vulnerability",
+        "recommends Argon2id or bcrypt for password hashing",
+        "identifies SQL injection vulnerability from string concatenation",
+        "recommends parameterized queries or prepared statements",
+        "references OWASP Top 10 categories (A02, A03)"
+      ]
+    },
+    {
+      "prompt": "Build a threat model for a new file upload feature",
+      "assertions": [
+        "uses STRIDE or similar systematic framework",
+        "identifies file type validation (magic bytes, not just extension)",
+        "addresses storage location (outside web root)",
+        "considers malware scanning",
+        "addresses file size limits and DoS prevention"
+      ]
+    }
+  ]
+}

package/workflows/skills/seo-fundamentals/SKILL.md

@@ -1,129 +1,86 @@
 ---
 name: seo-fundamentals
-description: SEO fundamentals, E-E-A-T, Core Web Vitals, and Google algorithm principles.
-allowed-tools: Read, Glob, Grep
+description: "Use when implementing technical SEO, content optimization, schema markup, or Core Web Vitals improvements for search engine visibility."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # SEO Fundamentals
 
-> Principles for search engine visibility.
+## Purpose
 
----
-
-## 1. E-E-A-T Framework
-
-| Principle | Signals |
-|-----------|---------|
-| **Experience** | First-hand knowledge, real examples |
-| **Expertise** | Credentials, depth of knowledge |
-| **Authoritativeness** | Backlinks, mentions, industry recognition |
-| **Trustworthiness** | HTTPS, transparency, accurate info |
+Use when implementing technical SEO, content optimization, schema markup, or Core Web Vitals improvements for search engine visibility.
 
----
+## When to Use
 
-## 2. Core Web Vitals
+- Implementing technical SEO (sitemaps, robots.txt, canonical tags, HTTPS, meta tags).
+- Optimizing Core Web Vitals (LCP, INP, CLS) for search ranking.
+- Adding structured data and schema markup (Article, FAQPage, Product, Organization).
+- Improving content quality using E-E-A-T framework.
+- Auditing a site for SEO issues and prioritizing fixes.
 
-| Metric | Target | Measures |
-|--------|--------|----------|
-| **LCP** | < 2.5s | Loading performance |
-| **INP** | < 200ms | Interactivity |
-| **CLS** | < 0.1 | Visual stability |
+## Instructions
 
----
+1. Audit technical SEO fundamentals — sitemaps, robots.txt, canonical tags, HTTPS, meta tags.
+2. Measure Core Web Vitals — LCP < 2.5s, INP < 200ms, CLS < 0.1.
+3. Implement structured data with appropriate schema types.
+4. Evaluate content quality against E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness).
+5. Prioritize fixes by impact: content quality > backlinks > page experience > technical SEO.
 
-## 3. Technical SEO Principles
+### Baseline standards
 
-### Site Structure
+- Core Web Vitals targets: LCP < 2.5s, INP < 200ms, CLS < 0.1.
+- Every page must have unique title + meta description.
+- XML sitemap must be current and submitted.
+- Canonical tags must prevent duplicate content issues.
+- Schema markup must validate against Google's structured data testing tool.
 
-| Element | Purpose |
-|---------|---------|
-| XML sitemap | Help crawling |
-| robots.txt | Control access |
-| Canonical tags | Prevent duplicates |
-| HTTPS | Security signal |
+### Ranking factors priority
 
-### Performance
+| Priority | Factor                                     |
+| -------- | ------------------------------------------ |
+| 1        | Content quality and relevance              |
+| 2        | Backlink profile                           |
+| 3        | Page experience (Core Web Vitals)          |
+| 4        | Technical SEO (crawlability, indexability) |
+| 5        | Content freshness                          |
 
-| Factor | Impact |
-|--------|--------|
-| Page speed | Core Web Vital |
-| Mobile-friendly | Ranking factor |
-| Clean URLs | Crawlability |
+### Schema types reference
 
----
+| Type           | Use For                   |
+| -------------- | ------------------------- |
+| Article        | Blog posts, news articles |
+| Organization   | Company info, contact     |
+| FAQPage        | FAQ sections              |
+| Product        | E-commerce product pages  |
+| Review         | User reviews, ratings     |
+| BreadcrumbList | Navigation breadcrumbs    |
+| HowTo          | Step-by-step guides       |
 
-## 4. Content SEO Principles
+### Constraints
 
-### Page Elements
+- Never use hidden text, keyword stuffing, or cloaking.
+- Never create doorway pages or thin content for ranking.
+- Always follow Google's webmaster guidelines.
+- Always validate schema markup before deploying.
 
-| Element | Best Practice |
-|---------|---------------|
-| Title tag | 50-60 chars, keyword front |
-| Meta description | 150-160 chars, compelling |
-| H1 | One per page, main keyword |
-| H2-H6 | Logical hierarchy |
-| Alt text | Descriptive, not stuffed |
+## Output Format
 
-### Content Quality
+Provide SEO audit findings, implementation guidance, schema markup code, and Core Web Vitals optimization recommendations.
 
-| Factor | Importance |
-|--------|------------|
-| Depth | Comprehensive coverage |
-| Freshness | Regular updates |
-| Uniqueness | Original value |
-| Readability | Clear writing |
+## References
 
----
-
-## 5. Schema Markup Types
-
-| Type | Use |
-|------|-----|
-| Article | Blog posts, news |
-| Organization | Company info |
-| Person | Author profiles |
-| FAQPage | Q&A content |
-| Product | E-commerce |
-| Review | Ratings |
-| BreadcrumbList | Navigation |
-
----
+No reference files for this skill right now.
 
-## 6. AI Content Guidelines
+## Scripts
 
-### What Google Looks For
+No helper scripts are required for this skill right now.
 
-| ✅ Do | ❌ Don't |
-|-------|----------|
-| AI draft + human edit | Publish raw AI content |
-| Add original insights | Copy without value |
-| Expert review | Skip fact-checking |
-| Follow E-E-A-T | Keyword stuffing |
-
----
-
-## 7. Ranking Factors (Prioritized)
-
-| Priority | Factor |
-|----------|--------|
-| 1 | Quality, relevant content |
-| 2 | Backlinks from authority sites |
-| 3 | Page experience (Core Web Vitals) |
-| 4 | Mobile optimization |
-| 5 | Technical SEO fundamentals |
-
----
-
-## 8. Measurement
-
-| Metric | Tool |
-|--------|------|
-| Rankings | Search Console, Ahrefs |
-| Traffic | Analytics |
-| Core Web Vitals | PageSpeed Insights |
-| Indexing | Search Console |
-| Backlinks | Ahrefs, Semrush |
-
----
+## Examples
 
-> **Remember:** SEO is a long-term game. Quality content + technical excellence + patience = results.
+- "Audit this Next.js site for SEO issues and prioritize fixes"
+- "Add structured data markup for our product pages"
+- "Improve Core Web Vitals scores on our landing pages"

package/workflows/skills/serverless-patterns/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: serverless-patterns
+description: Design serverless architectures with Lambda, Edge Functions, event-driven patterns, cold start optimization, and cost management strategies.
+license: Apache-2.0
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI
+---
+
+# Serverless Patterns
+
+## Purpose
+
+Guide serverless architecture design and implementation. Covers function design, event-driven patterns, cold start optimization, edge computing, cost management, and common pitfalls.
+
+## When to Use
+
+- Designing serverless applications (Lambda, Cloud Functions, Edge Functions)
+- Choosing between serverless and traditional server architectures
+- Optimizing cold starts and execution time
+- Implementing event-driven workflows (queues, streams, triggers)
+- Managing costs and avoiding serverless anti-patterns
+- Building API backends with serverless functions
+
+## Instructions
+
+### Step 1 — Choose the Right Compute Model
+
+| Model                                            | Best For                                | Latency                | Cost Model                |
+| ------------------------------------------------ | --------------------------------------- | ---------------------- | ------------------------- |
+| AWS Lambda / Cloud Functions                     | Event-driven, variable load             | Cold start: 100ms-2s   | Per-invocation + duration |
+| Edge Functions (Cloudflare Workers, Vercel Edge) | Low latency, geographically distributed | < 50ms (no cold start) | Per-request               |
+| Long-running containers (ECS, Cloud Run)         | Steady load, WebSockets, > 15 min tasks | No cold start          | Per-second                |
+
+**Serverless fits when**:
+
+- Traffic is bursty or unpredictable
+- Functions complete in < 30 seconds
+- Stateless request/response pattern
+- Event-driven processing (queue consumers, webhooks)
+
+**Serverless doesn't fit when**:
+
+- Persistent connections (WebSockets, long polling)
+- Heavy computation (> 15 min)
+- Steady high-throughput workloads (always-on is cheaper)
+- Complex local state management
+
+### Step 2 — Design Functions
+
+**Single-responsibility**: one function per operation
+
+```
+api/
+├── users/
+│   ├── create.ts      (POST /users)
+│   ├── get.ts         (GET /users/:id)
+│   └── list.ts        (GET /users)
+├── orders/
+│   ├── create.ts      (POST /orders)
+│   └── process.ts     (SQS consumer)
+└── shared/
+    ├── db.ts           (connection pooling)
+    └── auth.ts         (token validation)
+```
+
+**Rules**:
+
+- Keep functions small (< 200 lines)
+- Initialize expensive resources outside the handler (connection pools, SDK clients)
+- Handle one event type per function
+- Return early for validation failures
+
+### Step 3 — Optimize Cold Starts
+
+**Cold start happens when**:
+
+- First invocation after deployment
+- Scaling up to handle more concurrent requests
+- Function hasn't been invoked for ~15 minutes
+
+**Optimization strategies**:
+| Strategy | Impact |
+|----------|--------|
+| Smaller bundle size | Fewer bytes to load = faster start |
+| Fewer dependencies | Less initialization code |
+| Lazy-load non-critical modules | Only import what the handler needs |
+| Provisioned concurrency | Pre-warm instances (costs more) |
+| Edge functions | No cold start (Cloudflare Workers) |
+| Choose lighter runtimes | Node.js > Python > Java for cold start |
+
+**Connection pooling**:
+
+```typescript
+// Initialize OUTSIDE the handler (reused across invocations)
+const pool = new Pool({ connectionString: process.env.DATABASE_URL, max: 1 });
+
+export async function handler(event) {
+  const client = await pool.connect();
+  try {
+    // use client
+  } finally {
+    client.release(); // return to pool, don't close
+  }
+}
+```
+
+### Step 4 — Event-Driven Patterns
+
+| Pattern              | Use Case                               | Services                           |
+| -------------------- | -------------------------------------- | ---------------------------------- |
+| Queue consumer       | Decoupled async processing             | SQS, Cloud Tasks                   |
+| Fan-out              | Parallel processing of events          | SNS + Lambda, EventBridge          |
+| Saga / Step Function | Multi-step workflows with compensation | Step Functions, Temporal           |
+| CRON                 | Scheduled tasks                        | EventBridge rules, Cloud Scheduler |
+| Stream processing    | Real-time event processing             | Kinesis, Kafka                     |
+| Webhook receiver     | Third-party event handling             | API Gateway + Lambda               |
+
+**Error handling in async functions**:
+
+- Use dead-letter queues (DLQ) for failed messages
+- Implement idempotency (same message processed twice = same result)
+- Retry with exponential backoff
+- Alert on DLQ depth
+
+### Step 5 — Manage Costs
+
+**Cost drivers**:
+
+- Number of invocations
+- Execution duration × memory allocated
+- Data transfer (egress)
+- Provisioned concurrency (if used)
+
+**Optimization**:
+
+- Right-size memory (sometimes more memory = faster = cheaper)
+- Minimize execution time (return early, batch operations)
+- Use reserved concurrency to cap costs
+- Compress responses to reduce data transfer
+- Monitor with cost allocation tags
+
+## Output Format
+
+```
+## Architecture
+[serverless design with function layout and event flows]
+
+## Implementation
+[function code with cold start optimization]
+
+## Infrastructure
+[IaC for deployment (CDK, Terraform, serverless.yml)]
+
+## Cost Estimate
+[projected costs based on expected traffic]
+```
+
+## Examples
+
+**User**: "Build a serverless API for our mobile app"
+
+**Response approach**: API Gateway + Lambda per endpoint. JWT auth at the gateway. DynamoDB or RDS Proxy for data. Optimize cold starts with minimal dependencies. Show CDK or Serverless Framework config.
+
+**User**: "Our Lambda functions have 3-second cold starts"
+
+**Response approach**: Audit bundle size and dependencies. Lazy-load non-critical modules. Move initialization outside handler. Consider provisioned concurrency for latency-sensitive functions. Evaluate edge functions for the hottest paths.