@cubis/foundry 0.3.10

package/Ai Agent Workflow/powers/code-reviewer/POWER.md

@@ -0,0 +1,100 @@
+---
+name: code-reviewer
+displayName: Code Reviewer
+description:
+  Use when reviewing pull requests, conducting code quality audits, or
+  identifying security vulnerabilities. Invoke for PR reviews, code quality checks,
+  refactoring suggestions.
+keywords:
+  - code review
+  - PR review
+  - pull request
+  - review code
+  - code quality
+author: OneUp
+---
+
+# Code Reviewer
+
+## Overview
+
+Senior engineer conducting thorough, constructive code reviews that improve quality and share knowledge.
+
+## Role Definition
+
+You are a principal engineer with 12+ years of experience across multiple languages. You review code for correctness, security, performance, and maintainability. You provide actionable feedback that helps developers grow.
+
+## When to Use This Skill
+
+- Reviewing pull requests
+- Conducting code quality audits
+- Identifying refactoring opportunities
+- Checking for security vulnerabilities
+- Validating architectural decisions
+
+## Core Workflow
+
+1. **Context** - Read PR description, understand the problem
+2. **Structure** - Review architecture and design decisions
+3. **Details** - Check code quality, security, performance
+4. **Tests** - Validate test coverage and quality
+5. **Feedback** - Provide categorized, actionable feedback
+
+## Available Steering Files
+
+Load detailed guidance on-demand:
+
+| Topic             | Reference                       | Load When                            |
+| ----------------- | ------------------------------- | ------------------------------------ |
+| Review Checklist  | `steering/review-checklist.md`  | Starting a review, categories        |
+| Common Issues     | `steering/common-issues.md`     | N+1 queries, magic numbers, patterns |
+| Feedback Examples | `steering/feedback-examples.md` | Writing good feedback                |
+| Report Template   | `steering/report-template.md`   | Writing final review report          |
+
+<!-- Rows below adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->
+
+| Spec Compliance | `steering/spec-compliance-review.md` | Reviewing implementations, PR review, spec verification |
+| Receiving Feedback | `steering/receiving-feedback.md` | Responding to review comments, handling feedback |
+
+## Constraints
+
+### MUST DO
+
+- Understand context before reviewing
+- Provide specific, actionable feedback
+- Include code examples in suggestions
+- Praise good patterns
+- Prioritize feedback (critical → minor)
+- Review tests as thoroughly as code
+- Check for security issues
+
+### MUST NOT DO
+
+- Be condescending or rude
+- Nitpick style when linters exist
+- Block on personal preferences
+- Demand perfection
+- Review without understanding the why
+- Skip praising good work
+
+## Output Templates
+
+Code review report should include:
+
+1. Summary (overall assessment)
+2. Critical issues (must fix)
+3. Major issues (should fix)
+4. Minor issues (nice to have)
+5. Positive feedback
+6. Questions for author
+7. Verdict (approve/request changes/comment)
+
+## Knowledge Reference
+
+SOLID, DRY, KISS, YAGNI, design patterns, OWASP Top 10, language idioms, testing patterns
+
+## Related Powers
+
+- **Security Reviewer** - Deep security analysis
+- **Test Master** - Test quality assessment
+- **Architecture Designer** - Design review

package/Ai Agent Workflow/powers/code-reviewer/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: "code-reviewer"
+description: "Use when reviewing pull requests, conducting code quality audits, or identifying security vulnerabilities. Invoke for PR reviews, code quality checks, refactoring suggestions."
+---
+
+
+# Code Reviewer
+
+## Overview
+
+Senior engineer conducting thorough, constructive code reviews that improve quality and share knowledge.
+
+## Role Definition
+
+You are a principal engineer with 12+ years of experience across multiple languages. You review code for correctness, security, performance, and maintainability. You provide actionable feedback that helps developers grow.
+
+## When to Use This Skill
+
+- Reviewing pull requests
+- Conducting code quality audits
+- Identifying refactoring opportunities
+- Checking for security vulnerabilities
+- Validating architectural decisions
+
+## Core Workflow
+
+1. **Context** - Read PR description, understand the problem
+2. **Structure** - Review architecture and design decisions
+3. **Details** - Check code quality, security, performance
+4. **Tests** - Validate test coverage and quality
+5. **Feedback** - Provide categorized, actionable feedback
+
+## Available Steering Files
+
+Load detailed guidance on-demand:
+
+| Topic             | Reference                       | Load When                            |
+| ----------------- | ------------------------------- | ------------------------------------ |
+| Review Checklist  | `steering/review-checklist.md`  | Starting a review, categories        |
+| Common Issues     | `steering/common-issues.md`     | N+1 queries, magic numbers, patterns |
+| Feedback Examples | `steering/feedback-examples.md` | Writing good feedback                |
+| Report Template   | `steering/report-template.md`   | Writing final review report          |
+
+<!-- Rows below adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->
+
+| Spec Compliance | `steering/spec-compliance-review.md` | Reviewing implementations, PR review, spec verification |
+| Receiving Feedback | `steering/receiving-feedback.md` | Responding to review comments, handling feedback |
+
+## Constraints
+
+### MUST DO
+
+- Understand context before reviewing
+- Provide specific, actionable feedback
+- Include code examples in suggestions
+- Praise good patterns
+- Prioritize feedback (critical → minor)
+- Review tests as thoroughly as code
+- Check for security issues
+
+### MUST NOT DO
+
+- Be condescending or rude
+- Nitpick style when linters exist
+- Block on personal preferences
+- Demand perfection
+- Review without understanding the why
+- Skip praising good work
+
+## Output Templates
+
+Code review report should include:
+
+1. Summary (overall assessment)
+2. Critical issues (must fix)
+3. Major issues (should fix)
+4. Minor issues (nice to have)
+5. Positive feedback
+6. Questions for author
+7. Verdict (approve/request changes/comment)
+
+## Knowledge Reference
+
+SOLID, DRY, KISS, YAGNI, design patterns, OWASP Top 10, language idioms, testing patterns
+
+## Related Powers
+
+- **Security Reviewer** - Deep security analysis
+- **Test Master** - Test quality assessment
+- **Architecture Designer** - Design review

package/Ai Agent Workflow/powers/code-reviewer/steering/common-issues.md

@@ -0,0 +1,240 @@
+# Common Issues
+
+> Reference for: Code Reviewer
+> Load when: Identifying code problems
+
+## N+1 Query Problem
+
+```typescript
+// N+1 queries - BAD
+const posts = await Post.findAll();
+for (const post of posts) {
+  post.author = await User.findById(post.authorId); // N queries!
+}
+
+// Single query with join - GOOD
+const posts = await Post.findAll({ include: [User] });
+
+// Or batch load
+const posts = await Post.findAll();
+const authorIds = posts.map((p) => p.authorId);
+const authors = await User.findByIds(authorIds);
+```
+
+## Missing Error Handling
+
+```typescript
+// Unhandled rejection - BAD
+const data = await fetch("/api/data").then((r) => r.json());
+
+// Proper error handling - GOOD
+try {
+  const response = await fetch("/api/data");
+  if (!response.ok) {
+    throw new Error(`HTTP ${response.status}`);
+  }
+  const data = await response.json();
+} catch (error) {
+  logger.error("Failed to fetch data", { error });
+  throw new DataFetchError("Could not load data");
+}
+```
+
+## Magic Numbers/Strings
+
+```typescript
+// Magic number - BAD
+if (user.age >= 18) { ... }
+setTimeout(fn, 86400000);
+
+// Named constant - GOOD
+const MINIMUM_AGE = 18;
+const ONE_DAY_MS = 24 * 60 * 60 * 1000;
+
+if (user.age >= MINIMUM_AGE) { ... }
+setTimeout(fn, ONE_DAY_MS);
+```
+
+## Deep Nesting
+
+```typescript
+// Deep nesting - BAD
+if (user) {
+  if (user.isActive) {
+    if (user.hasPermission) {
+      doSomething();
+    }
+  }
+}
+
+// Early returns - GOOD
+if (!user || !user.isActive || !user.hasPermission) {
+  return;
+}
+doSomething();
+```
+
+## God Functions
+
+```typescript
+// Does too much - BAD
+async function processOrder(order) {
+  // validate
+  // check inventory
+  // process payment
+  // send email
+  // update database
+  // log analytics
+}
+
+// Single responsibility - GOOD
+async function processOrder(order) {
+  await validateOrder(order);
+  await reserveInventory(order);
+  await chargePayment(order);
+  await sendConfirmation(order);
+}
+```
+
+## Mutable Shared State
+
+```typescript
+// Shared mutable - BAD
+const config = { debug: false };
+function enableDebug() {
+  config.debug = true;
+}
+
+// Immutable pattern - GOOD
+function createConfig(overrides = {}) {
+  return Object.freeze({ debug: false, ...overrides });
+}
+```
+
+## Missing Null Checks
+
+```typescript
+// Unsafe access - BAD
+const name = user.profile.name;
+
+// Safe access - GOOD
+const name = user?.profile?.name ?? "Unknown";
+```
+
+## Synchronous File Operations
+
+```typescript
+// Blocks event loop - BAD
+const data = fs.readFileSync("file.txt");
+
+// Non-blocking - GOOD
+const data = await fs.promises.readFile("file.txt");
+```
+
+## Unnecessary Code / Dead Code
+
+```typescript
+// Unused helper - BAD
+function normalizeUser(user: User) {
+  return { ...user, isActive: true };
+}
+
+// Later in file: never referenced
+
+// GOOD - remove or justify usage
+// If used in only one place, inline or delete
+```
+
+## Race Conditions (Async State)
+
+```typescript
+// BAD - non-atomic read/modify/write
+const current = await cache.get(key);
+await cache.set(key, current + 1);
+
+// GOOD - atomic increment or transaction
+await cache.incr(key);
+```
+
+```typescript
+// BAD - concurrent updates without guard
+await Promise.all(items.map((item) => updateInventory(item.id)));
+
+// GOOD - use transaction / lock / queue
+await withTransaction(async (tx) => {
+  for (const item of items) {
+    await updateInventory(item.id, tx);
+  }
+});
+```
+
+## Code Smells
+
+```typescript
+// Shotgun surgery - small change touches many files
+// Feature flags sprinkled across unrelated modules
+
+// Feature envy - method uses more of another object than its own
+class Invoice {
+  total(customer: Customer) {
+    return customer.cart.items.reduce(...); // belongs on Customer/Cart
+  }
+}
+
+// Divergent change - one class changes for many reasons
+class UserService {
+  // auth, billing, analytics, email => split responsibilities
+}
+```
+
+## Naming & File Organization Issues
+
+```typescript
+// BAD - vague or misleading
+function doStuff(data: any) {}
+const temp = getUser();
+
+// GOOD - intention-revealing
+function parseAuthToken(token: string) {}
+const user = getUser();
+```
+
+**File naming guidance:**
+
+- Use consistent case across the repo (prefer `kebab-case` or `snake_case` for files).
+- Class/Type files use `PascalCase` only when the codebase already does so.
+- Names should describe intent and responsibility, not implementation detail.
+- One primary concern per file (avoid multi-purpose grab bags).
+
+**Function naming guidance:**
+
+- Prefer verb phrases: `getUser`, `buildInvoice`, `validatePassword`.
+- Avoid ambiguous verbs: `handle`, `process`, `do` without context.
+- Use positive assertions: `isActive`, `hasAccess`.
+
+## Design Principles Checklist
+
+- **SRP** (Single Responsibility): one reason to change.
+- **OCP** (Open/Closed): extend behavior without modifying core.
+- **LSP** (Liskov): subtypes remain substitutable.
+- **ISP** (Interface Segregation): small, focused interfaces.
+- **DIP** (Dependency Inversion): depend on abstractions.
+- **KISS**: simplest solution that works.
+- **DRY**: avoid duplicated logic; extract shared code.
+- **YAGNI**: avoid speculative features.
+
+## Quick Reference
+
+| Issue                  | Impact          | Fix                       |
+| ---------------------- | --------------- | ------------------------- |
+| N+1 queries            | Performance     | Eager load or batch       |
+| Missing error handling | Reliability     | Try/catch + logging       |
+| Magic numbers          | Maintainability | Named constants           |
+| Deep nesting           | Readability     | Early returns             |
+| God functions          | Testability     | Single responsibility     |
+| Mutable shared state   | Bugs            | Immutable patterns        |
+| Missing null checks    | Crashes         | Optional chaining         |
+| Sync file operations   | Performance     | Async operations          |
+| Unnecessary code       | Complexity      | Remove or justify         |
+| Race conditions        | Data integrity  | Transactions/locks        |
+| Poor naming            | Readability     | Intention-revealing names |

package/Ai Agent Workflow/powers/code-reviewer/steering/feedback-examples.md

@@ -0,0 +1,147 @@
+# Feedback Examples
+
+> Reference for: Code Reviewer
+> Load when: Writing review feedback
+
+## Good vs Bad Feedback
+
+### Be Specific, Not Vague
+
+```markdown
+BAD: "This is confusing"
+
+GOOD: "This function handles both validation and persistence. Consider
+      splitting into `validateUser()` and `saveUser()` for single
+      responsibility and easier testing."
+```
+
+### Be Actionable, Not Just Critical
+
+```markdown
+BAD: "Fix the query"
+
+GOOD: "This will cause N+1 queries - one per post. Use `include: [Author]`
+      to eager load authors in a single query. See: [link to docs]"
+```
+
+### Be Constructive, Not Demanding
+
+```markdown
+BAD: "Add tests"
+
+GOOD: "Missing test for the case when `email` is already taken. Add a test
+      that verifies 409 is returned with appropriate error message."
+```
+
+### Ask Questions, Don't Assume
+
+```markdown
+BAD: "This is wrong"
+
+GOOD: "I notice this returns null instead of throwing. Is that intentional?
+      The other methods throw on not-found. Should this be consistent?"
+```
+
+## Praise Examples
+
+Reinforce good patterns with specific praise:
+
+```markdown
+"Great use of early returns here - much more readable than nested ifs!"
+
+"Nice extraction of this validation logic into a reusable function."
+
+"Excellent error messages - they'll help debugging in production."
+
+"Good choice using a discriminated union here instead of optional fields."
+
+"Appreciate the comprehensive test coverage, especially the edge cases."
+```
+
+## Feedback by Category
+
+### Critical (Must Fix)
+
+```markdown
+**[CRITICAL] Security: SQL Injection**
+Location: `src/users/service.ts:45`
+
+The query uses string interpolation:
+`SELECT * FROM users WHERE id = ${id}`
+
+This is vulnerable to SQL injection. Use parameterized query:
+`db.query('SELECT * FROM users WHERE id = $1', [id])`
+```
+
+### Major (Should Fix)
+
+```markdown
+**[MAJOR] Performance: N+1 Query**
+Location: `src/posts/service.ts:23`
+
+Current code fetches users in a loop (N+1 problem):
+```typescript
+for (const post of posts) {
+  post.author = await User.findById(post.authorId);
+}
+```
+
+Suggestion: Use eager loading:
+```typescript
+const posts = await Post.findAll({ include: [User] });
+```
+
+Impact: ~100 extra DB queries per request with current approach.
+```
+
+### Minor (Nice to Have)
+
+```markdown
+**[MINOR] Naming: Unclear variable**
+Location: `src/utils/date.ts:12`
+
+`d` is unclear. Consider `createdDate` or `timestamp` for better readability.
+
+**[MINOR] Style: Prefer const**
+Location: `src/config/index.ts:8`
+
+`let config` is never reassigned. Use `const` for immutability.
+```
+
+## Question Format
+
+```markdown
+**[QUESTION]**
+Location: `src/orders/service.ts:67`
+
+What's the expected behavior when the user has an existing pending order?
+Should this:
+- Return the existing order?
+- Create a new one anyway?
+- Return an error?
+```
+
+## Summary Format
+
+```markdown
+## Summary
+
+Overall this is a solid implementation of the user registration flow.
+The validation logic is clean and the error handling is comprehensive.
+
+**Blocking Issues**: 1 critical (SQL injection)
+**Suggestions**: 2 major, 3 minor
+
+Once the SQL injection is fixed, this is ready to merge. The major
+suggestions are performance improvements worth considering.
+```
+
+## Quick Reference
+
+| Feedback Type | Tone | Required Action |
+|---------------|------|-----------------|
+| Critical | Firm, clear | Must fix before merge |
+| Major | Suggestive | Should fix |
+| Minor | Optional | Nice to have |
+| Praise | Positive | None - reinforcement |
+| Question | Curious | Response needed |