@cubis/foundry 0.3.70 → 0.3.72

package/workflows/powers/behavioral-modes/SKILL.md

@@ -7,6 +7,7 @@ allowed-tools: Read, Glob, Grep
 # Behavioral Modes - Adaptive AI Operating Modes
 
 ## Purpose
+
 This skill defines distinct behavioral modes that optimize AI performance for specific tasks. Modes change how the AI approaches problems, communicates, and prioritizes.
 
 ---
@@ -18,6 +19,7 @@ This skill defines distinct behavioral modes that optimize AI performance for sp
 **When to use:** Early project planning, feature ideation, architecture decisions
 
 **Behavior:**
+
 - Ask clarifying questions before assumptions
 - Offer multiple alternatives (at least 3)
 - Think divergently - explore unconventional solutions
@@ -25,6 +27,7 @@ This skill defines distinct behavioral modes that optimize AI performance for sp
 - Use visual diagrams (mermaid) to explain concepts
 
 **Output style:**
+
 ```
 "Let's explore this together. Here are some approaches:
 
@@ -46,6 +49,7 @@ What resonates with you? Or should we explore a different direction?"
 **When to use:** Writing code, building features, executing plans
 
 **Behavior:**
+
 - **CRITICAL: Use `clean-code` skill standards** - concise, direct, no verbose explanations
 - Fast execution - minimize questions
 - Use established patterns and best practices
@@ -57,6 +61,7 @@ What resonates with you? Or should we explore a different direction?"
 - **NO RUSHING** - Quality > Speed. Read ALL references before coding.
 
 **Output style:**
+
 ```
 [Code block]
 
@@ -64,6 +69,7 @@ What resonates with you? Or should we explore a different direction?"
 ```
 
 **NOT:**
+
 ```
 "Building [feature]...
 
@@ -83,6 +89,7 @@ Run `npm run dev` to test."
 **When to use:** Fixing bugs, troubleshooting errors, investigating issues
 
 **Behavior:**
+
 - Ask for error messages and reproduction steps
 - Think systematically - check logs, trace data flow
 - Form hypothesis → test → verify
@@ -90,6 +97,7 @@ Run `npm run dev` to test."
 - Prevent future occurrences
 
 **Output style:**
+
 ```
 "Investigating...
 
@@ -106,6 +114,7 @@ Run `npm run dev` to test."
 **When to use:** Code review, architecture review, security audit
 
 **Behavior:**
+
 - Be thorough but constructive
 - Categorize by severity (Critical/High/Medium/Low)
 - Explain the "why" behind suggestions
@@ -113,6 +122,7 @@ Run `npm run dev` to test."
 - Acknowledge what's done well
 
 **Output style:**
+
 ```
 ## Code Review: [file/feature]
 
@@ -133,6 +143,7 @@ Run `npm run dev` to test."
 **When to use:** Explaining concepts, documentation, onboarding
 
 **Behavior:**
+
 - Explain from fundamentals
 - Use analogies and examples
 - Progress from simple to complex
@@ -140,6 +151,7 @@ Run `npm run dev` to test."
 - Check understanding
 
 **Output style:**
+
 ```
 ## Understanding [Concept]
 
@@ -163,6 +175,7 @@ Run `npm run dev` to test."
 **When to use:** Production deployment, final polish, release preparation
 
 **Behavior:**
+
 - Focus on stability over features
 - Check for missing error handling
 - Verify environment configs
@@ -170,6 +183,7 @@ Run `npm run dev` to test."
 - Create deployment checklist
 
 **Output style:**
+
 ```
 ## Pre-Ship Checklist
 
@@ -195,35 +209,111 @@ Run `npm run dev` to test."
 
 The AI should automatically detect the appropriate mode based on:
 
-| Trigger | Mode |
-|---------|------|
-| "what if", "ideas", "options" | BRAINSTORM |
-| "build", "create", "add" | IMPLEMENT |
-| "not working", "error", "bug" | DEBUG |
-| "review", "check", "audit" | REVIEW |
-| "explain", "how does", "learn" | TEACH |
-| "deploy", "release", "production" | SHIP |
+| Trigger                                        | Mode                |
+| ---------------------------------------------- | ------------------- |
+| "what if", "ideas", "options"                  | BRAINSTORM          |
+| "build", "create", "add"                       | IMPLEMENT           |
+| "not working", "error", "bug"                  | DEBUG               |
+| "review", "check", "audit"                     | REVIEW              |
+| "explain", "how does", "learn"                 | TEACH               |
+| "deploy", "release", "production"              | SHIP                |
+| "iterate", "refine quality", "not good enough" | EVALUATOR-OPTIMIZER |
+
+---
+
+## Workflow Patterns
+
+Three patterns govern how modes combine across multiple agents or steps. Use the simplest pattern that solves the problem — add complexity only when it measurably improves results.
+
+### 1. Sequential (default)
+
+Use when tasks have dependencies — each step needs the previous step's output.
+
+```
+[BRAINSTORM] → [IMPLEMENT] → [REVIEW] → [SHIP]
+```
+
+Best for: multi-stage features, draft-review-polish cycles, data pipelines.
+
+### 2. Parallel
+
+Use when tasks are independent and doing them one at a time is too slow.
+
+```
+[security REVIEW + performance REVIEW + quality REVIEW] → synthesize
+```
+
+Best for: code review across multiple dimensions, parallel analysis. Requires a clear aggregation strategy before starting.
+
+### 3. Evaluator-Optimizer (new)
+
+Use when first-draft quality consistently falls short and quality is measurable.
+
+```
+[IMPLEMENT] → [REVIEW with criteria] → pass? → done
+                      ↓ fail
+               feedback → [IMPLEMENT again]
+```
+
+**When to use:**
+
+- Technical docs, customer communications, SQL queries against specific standards
+- Any output where the gap between first attempt and required quality is significant
+- When you have clear, checkable criteria (not just "make it better")
+
+**When NOT to use:**
+
+- First-attempt quality is already acceptable
+- Criteria are too subjective for consistent AI evaluation
+- Real-time use cases needing immediate responses
+- Deterministic validators exist (linters, schema validators) — use those instead
+
+**Implementation:**
+
+```
+## Generator
+Task: [what to create]
+Constraints: [specific, measurable requirements — these become eval criteria]
+
+## Evaluator
+Criteria:
+1. [Criterion A] — Pass/Fail + specific failure note
+2. [Criterion B] — Pass/Fail + specific failure note
+
+Output JSON: { "pass": bool, "failures": ["..."], "revision_note": "..." }
+
+Max iterations: 3  ← always set a ceiling
+Stop when: all criteria pass OR max iterations reached
+```
 
 ---
 
-## Multi-Agent Collaboration Patterns (2025)
+## Multi-Agent Collaboration Patterns
 
 Modern architectures optimized for agent-to-agent collaboration:
 
 ### 1. 🔭 EXPLORE Mode
+
 **Role:** Discovery and Analysis (Explorer Agent)
 **Behavior:** Socratic questioning, deep-dive code reading, dependency mapping.
 **Output:** `discovery-report.json`, architectural visualization.
 
 ### 2. 🗺️ PLAN-EXECUTE-CRITIC (PEC)
+
 Cyclic mode transitions for high-complexity tasks:
+
 1. **Planner:** Decomposes the task into atomic steps (`task.md`).
 2. **Executor:** Performs the actual coding (`IMPLEMENT`).
 3. **Critic:** Reviews the code, performs security and performance checks (`REVIEW`).
 
 ### 3. 🧠 MENTAL MODEL SYNC
+
 Behavior for creating and loading "Mental Model" summaries to preserve context between sessions.
 
+### 4. 🔄 EVALUATOR-OPTIMIZER
+
+Paired agents in an iterative quality loop: Generator produces, Evaluator scores against criteria, Generator refines. Set max iteration ceiling before starting.
+
 ---
 
 ## Combining Modes
@@ -239,4 +329,5 @@ Users can explicitly request a mode:
 /implement the user profile page
 /debug why login fails
 /review this pull request
+/iterate [target quality bar]    ← triggers evaluator-optimizer
 ```

package/workflows/powers/c-pro/POWER.md

@@ -0,0 +1,105 @@
+````markdown
+---
+inclusion: manual
+name: c-pro
+description: "Use for modern C23-era systems and embedded engineering with memory safety discipline, build reproducibility, and low-level debugging awareness."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "2.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# C Pro
+
+## Purpose
+
+Use for modern C23-era systems and embedded engineering with memory safety discipline, build reproducibility, and low-level debugging awareness.
+
+## When to Use
+
+- Writing or refactoring C systems, embedded, or low-level runtime code.
+- Tightening memory ownership, ABI boundaries, and build hygiene.
+- Debugging undefined behavior, portability, or toolchain-sensitive code.
+
+## Instructions
+
+1. Confirm platform, compiler, and ABI constraints before writing code.
+2. Make ownership, lifetime, and error handling explicit at every interface.
+3. Prefer simple control flow over macro-heavy indirection.
+4. Validate assumptions with warnings, sanitizers, or focused repros.
+5. Keep portability and deterministic builds in view throughout the change.
+
+### Baseline standards
+
+- Compile with `-Wall -Wextra -Werror` (or equivalent) in CI. Treat warnings as defects.
+- Enable sanitizers (`-fsanitize=address,undefined`) in debug and test builds.
+- Use `static` for file-scoped functions and variables. Minimize public symbols.
+- Declare `const` by default. Mutable state must be justified.
+- Keep headers self-contained: every `.h` must compile on its own.
+- Prefer fixed-width integers (`uint32_t`, `int64_t`) over bare `int` for data structures and protocols.
+
+### Memory safety discipline
+
+- Every allocation must have a single, clear owner and a documented free path.
+- Prefer stack allocation and arena allocators over scattered `malloc`/`free`.
+- Initialize all variables at declaration. Never rely on implicit zero-initialization.
+- Bounds-check array and buffer access at trust boundaries (user input, file I/O, network).
+- Use `memset`/`memcpy` with explicit size — never assume buffer sizes from context.
+- After `free`, set pointer to `NULL` to catch use-after-free during debugging.
+
+### Build reproducibility
+
+- Pin compiler version and flags in the build system. Builds must produce identical output across machines.
+- Prefer CMake, Meson, or a Makefile with explicit dependency tracking over ad-hoc scripts.
+- Declare all external dependencies with exact versions. Avoid system-installed headers for portable projects.
+- Run CI on at least two compilers (GCC + Clang) and two platforms where applicable.
+- Enable Link-Time Optimization (LTO) for release builds but verify correctness with sanitizers first.
+
+### Debugging and diagnostics
+
+- Compile debug builds with `-g -O0` for accurate stack traces and variable inspection.
+- Use AddressSanitizer for memory errors, UndefinedBehaviorSanitizer for UB, and ThreadSanitizer for data races.
+- Add `assert()` for invariants that must never be violated — strip in release builds.
+- Prefer structured error codes with context over errno alone. Return error structs from functions that can fail.
+- When debugging crashes: reproduce with sanitizers first, then gdb/lldb with watchpoints.
+
+### Performance
+
+- Profile with `perf`, `Instruments`, or `gprof` before micro-optimizing. Measure, don't guess.
+- Prefer cache-friendly data layouts (arrays of structs vs. structs of arrays depending on access pattern).
+- Minimize heap allocations in hot paths. Pre-allocate where the upper bound is known.
+- Avoid premature inline — let the compiler decide, then verify with benchmarks.
+
+### Constraints
+
+- Avoid `void*` casts without size tracking — type-unsafe and bug-prone.
+- Avoid variable-length arrays (VLAs) in production code — stack overflow risk.
+- Avoid macro-heavy logic that hides control flow (`goto` cleanup patterns are acceptable when simple).
+- Avoid ignoring compiler warnings — every warning is a potential bug.
+- Avoid global mutable state without synchronization.
+- Avoid relying on implementation-defined or undefined behavior for correctness.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                              | Load when                                                                                                      |
+| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
+| `references/memory-safety-and-build-checklist.md` | Memory ownership patterns, sanitizer configuration, build system hygiene, or ABI boundary review is needed.    |
+| `references/common-ub-and-portability.md`         | Undefined behavior patterns, implementation-defined traps, or cross-platform portability decisions are needed. |
+| `references/build-systems-and-toolchains.md`      | CMake/Meson setup, cross-compilation, CI matrix configuration, or toolchain pinning is needed.                 |
+| `references/posix-and-platform-apis.md`           | POSIX system calls, file I/O, signal handling, or platform abstraction layer design is needed.                 |
+| `references/debugging-with-sanitizers.md`         | AddressSanitizer, UBSan, ThreadSanitizer configuration, or crash diagnosis workflow is needed.                 |
+
+## 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 c pro best practices in this project"
+- "Review my c pro implementation for issues"
+````

package/workflows/powers/c-pro/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: c-pro
+description: "Use for modern C23-era systems and embedded engineering with memory safety discipline, build reproducibility, and low-level debugging awareness."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "2.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# C Pro
+
+## Purpose
+
+Use for modern C23-era systems and embedded engineering with memory safety discipline, build reproducibility, and low-level debugging awareness.
+
+## When to Use
+
+- Writing or refactoring C systems, embedded, or low-level runtime code.
+- Tightening memory ownership, ABI boundaries, and build hygiene.
+- Debugging undefined behavior, portability, or toolchain-sensitive code.
+
+## Instructions
+
+1. Confirm platform, compiler, and ABI constraints before writing code.
+2. Make ownership, lifetime, and error handling explicit at every interface.
+3. Prefer simple control flow over macro-heavy indirection.
+4. Validate assumptions with warnings, sanitizers, or focused repros.
+5. Keep portability and deterministic builds in view throughout the change.
+
+### Baseline standards
+
+- Compile with `-Wall -Wextra -Werror` (or equivalent) in CI. Treat warnings as defects.
+- Enable sanitizers (`-fsanitize=address,undefined`) in debug and test builds.
+- Use `static` for file-scoped functions and variables. Minimize public symbols.
+- Declare `const` by default. Mutable state must be justified.
+- Keep headers self-contained: every `.h` must compile on its own.
+- Prefer fixed-width integers (`uint32_t`, `int64_t`) over bare `int` for data structures and protocols.
+
+### Memory safety discipline
+
+- Every allocation must have a single, clear owner and a documented free path.
+- Prefer stack allocation and arena allocators over scattered `malloc`/`free`.
+- Initialize all variables at declaration. Never rely on implicit zero-initialization.
+- Bounds-check array and buffer access at trust boundaries (user input, file I/O, network).
+- Use `memset`/`memcpy` with explicit size — never assume buffer sizes from context.
+- After `free`, set pointer to `NULL` to catch use-after-free during debugging.
+
+### Build reproducibility
+
+- Pin compiler version and flags in the build system. Builds must produce identical output across machines.
+- Prefer CMake, Meson, or a Makefile with explicit dependency tracking over ad-hoc scripts.
+- Declare all external dependencies with exact versions. Avoid system-installed headers for portable projects.
+- Run CI on at least two compilers (GCC + Clang) and two platforms where applicable.
+- Enable Link-Time Optimization (LTO) for release builds but verify correctness with sanitizers first.
+
+### Debugging and diagnostics
+
+- Compile debug builds with `-g -O0` for accurate stack traces and variable inspection.
+- Use AddressSanitizer for memory errors, UndefinedBehaviorSanitizer for UB, and ThreadSanitizer for data races.
+- Add `assert()` for invariants that must never be violated — strip in release builds.
+- Prefer structured error codes with context over errno alone. Return error structs from functions that can fail.
+- When debugging crashes: reproduce with sanitizers first, then gdb/lldb with watchpoints.
+
+### Performance
+
+- Profile with `perf`, `Instruments`, or `gprof` before micro-optimizing. Measure, don't guess.
+- Prefer cache-friendly data layouts (arrays of structs vs. structs of arrays depending on access pattern).
+- Minimize heap allocations in hot paths. Pre-allocate where the upper bound is known.
+- Avoid premature inline — let the compiler decide, then verify with benchmarks.
+
+### Constraints
+
+- Avoid `void*` casts without size tracking — type-unsafe and bug-prone.
+- Avoid variable-length arrays (VLAs) in production code — stack overflow risk.
+- Avoid macro-heavy logic that hides control flow (`goto` cleanup patterns are acceptable when simple).
+- Avoid ignoring compiler warnings — every warning is a potential bug.
+- Avoid global mutable state without synchronization.
+- Avoid relying on implementation-defined or undefined behavior for correctness.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                              | Load when                                                                                                      |
+| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
+| `references/memory-safety-and-build-checklist.md` | Memory ownership patterns, sanitizer configuration, build system hygiene, or ABI boundary review is needed.    |
+| `references/common-ub-and-portability.md`         | Undefined behavior patterns, implementation-defined traps, or cross-platform portability decisions are needed. |
+| `references/build-systems-and-toolchains.md`      | CMake/Meson setup, cross-compilation, CI matrix configuration, or toolchain pinning is needed.                 |
+| `references/posix-and-platform-apis.md`           | POSIX system calls, file I/O, signal handling, or platform abstraction layer design is needed.                 |
+| `references/debugging-with-sanitizers.md`         | AddressSanitizer, UBSan, ThreadSanitizer configuration, or crash diagnosis workflow is needed.                 |
+
+## 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 c pro best practices in this project"
+- "Review my c pro implementation for issues"

package/workflows/powers/c-pro/references/build-systems-and-toolchains.md

@@ -0,0 +1,148 @@
+# Build Systems and Toolchains
+
+## CMake Modern Practices
+
+```cmake
+# CMakeLists.txt — modern CMake (3.21+)
+cmake_minimum_required(VERSION 3.21)
+project(mylib VERSION 1.0.0 LANGUAGES C)
+
+# Set C standard project-wide
+set(CMAKE_C_STANDARD 23)
+set(CMAKE_C_STANDARD_REQUIRED ON)
+set(CMAKE_C_EXTENSIONS OFF)  # disable GNU extensions for portability
+
+# Library target
+add_library(mylib
+    src/core.c
+    src/parser.c
+    src/util.c
+)
+
+target_include_directories(mylib
+    PUBLIC  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
+    PRIVATE src/
+)
+
+# Compiler warnings as errors
+target_compile_options(mylib PRIVATE
+    $<$<C_COMPILER_ID:GNU,Clang>:-Wall -Wextra -Wpedantic -Werror>
+    $<$<C_COMPILER_ID:MSVC>:/W4 /WX>
+)
+
+# Sanitizers for debug builds
+if(CMAKE_BUILD_TYPE STREQUAL "Debug")
+    target_compile_options(mylib PRIVATE -fsanitize=address,undefined -fno-omit-frame-pointer)
+    target_link_options(mylib PRIVATE -fsanitize=address,undefined)
+endif()
+
+# Tests
+enable_testing()
+add_executable(test_core tests/test_core.c)
+target_link_libraries(test_core PRIVATE mylib)
+add_test(NAME test_core COMMAND test_core)
+
+# Install rules
+install(TARGETS mylib EXPORT mylibTargets)
+install(DIRECTORY include/ DESTINATION include)
+```
+
+## Meson Build System
+
+```meson
+# meson.build — lightweight alternative to CMake
+project('mylib', 'c',
+    version: '1.0.0',
+    default_options: ['c_std=c23', 'warning_level=3', 'werror=true']
+)
+
+src = files('src/core.c', 'src/parser.c', 'src/util.c')
+inc = include_directories('include')
+
+mylib = library('mylib', src, include_directories: inc)
+mylib_dep = declare_dependency(link_with: mylib, include_directories: inc)
+
+# Tests
+test_core = executable('test_core', 'tests/test_core.c', dependencies: mylib_dep)
+test('core', test_core)
+```
+
+## Cross-Compilation
+
+```cmake
+# toolchain-arm.cmake — cross-compile for ARM
+set(CMAKE_SYSTEM_NAME Linux)
+set(CMAKE_SYSTEM_PROCESSOR arm)
+
+set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc)
+set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g++)
+
+set(CMAKE_FIND_ROOT_PATH /usr/arm-linux-gnueabihf)
+set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
+set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
+set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+```
+
+```bash
+# Build with cross-compilation toolchain
+cmake -B build-arm -DCMAKE_TOOLCHAIN_FILE=toolchain-arm.cmake
+cmake --build build-arm
+```
+
+## CI Matrix Configuration
+
+```yaml
+# GitHub Actions — multi-compiler, multi-platform
+jobs:
+  build:
+    strategy:
+      matrix:
+        os: [ubuntu-latest, macos-latest]
+        compiler: [gcc-13, clang-17]
+    runs-on: ${{ matrix.os }}
+    steps:
+      - uses: actions/checkout@v4
+      - name: Configure
+        run: |
+          cmake -B build \
+            -DCMAKE_C_COMPILER=${{ matrix.compiler }} \
+            -DCMAKE_BUILD_TYPE=Debug
+      - name: Build
+        run: cmake --build build
+      - name: Test
+        run: ctest --test-dir build --output-on-failure
+      - name: Sanitizer build
+        run: |
+          cmake -B build-san \
+            -DCMAKE_C_COMPILER=${{ matrix.compiler }} \
+            -DCMAKE_BUILD_TYPE=Debug \
+            -DENABLE_SANITIZERS=ON
+          cmake --build build-san
+          ctest --test-dir build-san
+```
+
+## Dependency Management
+
+```cmake
+# FetchContent for pinned dependencies
+include(FetchContent)
+
+FetchContent_Declare(cjson
+    GIT_REPOSITORY https://github.com/DaveGamble/cJSON.git
+    GIT_TAG        v1.7.17  # pin exact version
+)
+FetchContent_MakeAvailable(cjson)
+target_link_libraries(mylib PRIVATE cjson)
+
+# vcpkg for larger dependency sets
+# Install: cmake -B build -DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake
+```
+
+## Reproducible Builds Checklist
+
+1. Pin compiler version in CI (e.g., `gcc-13`, not `gcc`).
+2. Pin all external dependencies to exact versions or commit hashes.
+3. Use deterministic build flags (`-frandom-seed=`, `-ffile-prefix-map=`).
+4. Commit `CMakePresets.json` or equivalent for consistent local/CI builds.
+5. Disable compiler plugins and extensions that vary by environment.
+6. Verify with two independent builds and `diffoscope` or binary hash comparison.