@cubis/foundry 0.3.71 → 0.3.72

package/workflows/powers/auth-architect/POWER.md

@@ -0,0 +1,69 @@
+````markdown
+---
+inclusion: manual
+name: auth-architect
+description: "Use when designing or reviewing authentication and authorization for backend systems, including sessions, tokens, OAuth or OIDC, RBAC or ABAC, passkeys, service-to-service auth, and policy enforcement boundaries."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI
+---
+
+# Auth Architect
+
+## Purpose
+
+Use when designing or reviewing authentication and authorization for backend systems, including sessions, tokens, OAuth or OIDC, RBAC or ABAC, passkeys, service-to-service auth, and policy enforcement boundaries.
+
+## When to Use
+
+- Designing or reviewing login, session, token, and policy architecture.
+- Choosing between session-based auth, JWTs, OAuth or OIDC, passkeys, or service credentials.
+- Defining RBAC, ABAC, tenant isolation, or field-level authorization boundaries.
+- Hardening auth flows in REST, GraphQL, NestJS, FastAPI, Node, or managed-platform backends.
+
+## Instructions
+
+1. Clarify actors, trust boundaries, clients, and the assets each flow protects.
+2. Choose the credential and session model that fits the product and operational constraints.
+3. Separate authentication, authorization, and audit responsibilities instead of blending them together.
+4. Make token, session, policy, and recovery behavior explicit at service boundaries.
+5. Verify revocation, rotation, least privilege, and failure behavior before shipping.
+
+### Baseline standards
+
+- Prefer server-owned sessions when revocation simplicity matters more than statelessness.
+- Treat OAuth or OIDC as delegated identity plumbing, not a substitute for local authorization rules.
+- Keep authorization policy close to the resource or resolver that owns the decision.
+- Design service-to-service identity and secret rotation as first-class operational concerns.
+- Make account recovery, MFA, and passkey fallback behavior explicit.
+
+### Constraints
+
+- Avoid mixing authentication and authorization into one vague middleware concept.
+- Avoid issuing long-lived bearer tokens with no rotation or revocation story.
+- Avoid duplicating policy rules across clients, gateways, and services with no clear owner.
+- Avoid treating passkeys, sessions, or JWTs as universal defaults independent of product constraints.
+
+## 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/session-token-policy-checklist.md` | You need a deeper checklist for session vs token choice, OAuth or OIDC, passkeys, tenant isolation, service auth, and policy enforcement boundaries. |
+
+## 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 auth architect best practices in this project"
+- "Review my auth architect implementation for issues"
+````

package/workflows/powers/auth-architect/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: auth-architect
+description: "Use when designing or reviewing authentication and authorization for backend systems, including sessions, tokens, OAuth or OIDC, RBAC or ABAC, passkeys, service-to-service auth, and policy enforcement boundaries."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI
+---
+
+# Auth Architect
+
+## Purpose
+
+Use when designing or reviewing authentication and authorization for backend systems, including sessions, tokens, OAuth or OIDC, RBAC or ABAC, passkeys, service-to-service auth, and policy enforcement boundaries.
+
+## When to Use
+
+- Designing or reviewing login, session, token, and policy architecture.
+- Choosing between session-based auth, JWTs, OAuth or OIDC, passkeys, or service credentials.
+- Defining RBAC, ABAC, tenant isolation, or field-level authorization boundaries.
+- Hardening auth flows in REST, GraphQL, NestJS, FastAPI, Node, or managed-platform backends.
+
+## Instructions
+
+1. Clarify actors, trust boundaries, clients, and the assets each flow protects.
+2. Choose the credential and session model that fits the product and operational constraints.
+3. Separate authentication, authorization, and audit responsibilities instead of blending them together.
+4. Make token, session, policy, and recovery behavior explicit at service boundaries.
+5. Verify revocation, rotation, least privilege, and failure behavior before shipping.
+
+### Baseline standards
+
+- Prefer server-owned sessions when revocation simplicity matters more than statelessness.
+- Treat OAuth or OIDC as delegated identity plumbing, not a substitute for local authorization rules.
+- Keep authorization policy close to the resource or resolver that owns the decision.
+- Design service-to-service identity and secret rotation as first-class operational concerns.
+- Make account recovery, MFA, and passkey fallback behavior explicit.
+
+### Constraints
+
+- Avoid mixing authentication and authorization into one vague middleware concept.
+- Avoid issuing long-lived bearer tokens with no rotation or revocation story.
+- Avoid duplicating policy rules across clients, gateways, and services with no clear owner.
+- Avoid treating passkeys, sessions, or JWTs as universal defaults independent of product constraints.
+
+## 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/session-token-policy-checklist.md` | You need a deeper checklist for session vs token choice, OAuth or OIDC, passkeys, tenant isolation, service auth, and policy enforcement boundaries. |
+
+## 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 auth architect best practices in this project"
+- "Review my auth architect implementation for issues"

package/workflows/powers/auth-architect/references/session-token-policy-checklist.md

@@ -0,0 +1,45 @@
+# Session, Token, And Policy Checklist
+
+Load this when auth work needs more depth than the root skill.
+
+## Boundary and threat framing
+
+- List actors, clients, trust boundaries, and the assets each flow protects.
+- Decide where authentication ends and authorization begins.
+- Make audit and incident-response requirements explicit for privileged flows.
+
+## Session vs token choice
+
+- Prefer server-owned sessions when revocation, rotation simplicity, or browser ergonomics matter most.
+- Prefer short-lived access tokens plus refresh controls only when stateless distribution or delegated clients justify the complexity.
+- Avoid bearer-token sprawl across browser, mobile, and service clients without separate threat assumptions.
+
+## OAuth, OIDC, and delegated identity
+
+- Use OAuth for delegated access and OIDC for identity; do not collapse them conceptually.
+- Scope tokens narrowly and document token audience, issuer, and rotation behavior.
+- Keep provider callbacks, consent, and account-linking behavior explicit.
+
+## Authorization and policy
+
+- Keep RBAC, ABAC, tenant boundaries, and field-level policy checks close to the owning service or resolver.
+- Avoid duplicating policy logic in frontend code as the only enforcement layer.
+- Make authorization failure semantics predictable and observable.
+
+## Passkeys, MFA, and recovery
+
+- Treat passkeys as a primary sign-in option where product fit exists, not just a marketing add-on.
+- Make MFA enrollment, recovery, device loss, and fallback channels explicit.
+- Keep recovery flows at least as hardened as the primary sign-in flow.
+
+## Service-to-service auth
+
+- Use dedicated service identities, narrow scopes, and explicit secret or key rotation.
+- Keep human auth, machine auth, and webhook verification separate.
+- Make internal trust assumptions visible instead of implied by network location.
+
+## Operational safety
+
+- Log auth decisions without leaking secrets or raw tokens.
+- Verify revocation, logout, secret rotation, and key rollover behavior.
+- Recheck caching, GraphQL field policy, and background-job privilege boundaries before finishing.

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

@@ -9,6 +9,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.
 
 ---
@@ -20,6 +21,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
@@ -27,6 +29,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:
 
@@ -48,6 +51,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
@@ -59,6 +63,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]
 
@@ -66,6 +71,7 @@ What resonates with you? Or should we explore a different direction?"
 ```
 
 **NOT:**
+
 ```
 "Building [feature]...
 
@@ -85,6 +91,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
@@ -92,6 +99,7 @@ Run `npm run dev` to test."
 - Prevent future occurrences
 
 **Output style:**
+
 ```
 "Investigating...
 
@@ -108,6 +116,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
@@ -115,6 +124,7 @@ Run `npm run dev` to test."
 - Acknowledge what's done well
 
 **Output style:**
+
 ```
 ## Code Review: [file/feature]
 
@@ -135,6 +145,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
@@ -142,6 +153,7 @@ Run `npm run dev` to test."
 - Check understanding
 
 **Output style:**
+
 ```
 ## Understanding [Concept]
 
@@ -165,6 +177,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
@@ -172,6 +185,7 @@ Run `npm run dev` to test."
 - Create deployment checklist
 
 **Output style:**
+
 ```
 ## Pre-Ship Checklist
 
@@ -197,35 +211,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
@@ -241,5 +331,6 @@ 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"