@cubis/foundry 0.3.67 → 0.3.68

package/workflows/skills/code-reviewer/SKILL.md

@@ -1,84 +0,0 @@
----
-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  | `references/review-checklist.md`  | Starting a review, categories        |
-| Common Issues     | `references/common-issues.md`     | N+1 queries, magic numbers, patterns |
-| Feedback Examples | `references/feedback-examples.md` | Writing good feedback                |
-| Report Template   | `references/report-template.md`   | Writing final review report          |
-
-<!-- Rows below adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->
-
-| Spec Compliance | `references/spec-compliance-review.md` | Reviewing implementations, PR review, spec verification |
-| Receiving Feedback | `references/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

package/workflows/skills/code-reviewer/references/common-issues.md

@@ -1,240 +0,0 @@
-# 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/workflows/skills/code-reviewer/references/feedback-examples.md

@@ -1,147 +0,0 @@
-# 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 |

package/workflows/skills/code-reviewer/references/receiving-feedback.md

@@ -1,241 +0,0 @@
-# Receiving Feedback
-
-> Reference for: Code Reviewer
-> Load when: responding to review comments, handling feedback, review response
-
----
-
-## Core Mindset
-
-> "Verify before implementing. Ask before assuming. Technical correctness over social comfort."
-
-Code review feedback is a technical discussion, not a social one. Focus on the code, not on feelings.
-
----
-
-## The Six-Step Process
-
-### Step 1: Read Completely
-
-**Without reacting.** Read the entire comment before forming any response.
-
-```markdown
-❌ BAD: Read first sentence → start typing defense
-✅ GOOD: Read entire comment → understand full context → then respond
-```
-
-### Step 2: Restate Requirements
-
-Rephrase the reviewer's feedback in your own words to confirm understanding.
-
-```markdown
-Reviewer: "This function is doing too much. It handles validation,
-transformation, and persistence all in one place."
-
-Your restatement: "You're suggesting I split this into three separate
-functions: validate(), transform(), and persist()?"
-```
-
-### Step 3: Check Against Codebase
-
-Verify the feedback against actual code conditions before responding.
-
-```typescript
-// Reviewer says: "This will throw if user is null"
-
-// Check the code:
-function getUsername(user: User): string {
-  return user.name;  // No null check - reviewer is correct
-}
-
-// Or discover context:
-function getUsername(user: User): string {
-  return user.name;  // TypeScript enforces User, null not possible
-}
-```
-
-### Step 4: Evaluate Technical Soundness
-
-Consider whether the feedback applies to your specific stack and context.
-
-```markdown
-Reviewer: "You should use useMemo here for performance"
-
-Evaluate:
-- Is this component re-rendering frequently? → Check React DevTools
-- Is the computation expensive? → Profile it
-- Does React 19's compiler auto-optimize this? → Check version
-```
-
-### Step 5: Respond with Substance
-
-Provide technical acknowledgment or reasoned objection.
-
-```markdown
-✅ GOOD: "Fixed. Split into validate(), transform(), persist()
-         at lines 24, 45, 67."
-
-✅ GOOD: "Respectfully disagree. This list has max 5 items
-         (see schema.ts:12), so filter performance is O(5)."
-
-❌ BAD: "You're absolutely right! Great catch!"
-❌ BAD: "I don't think that's necessary."
-```
-
-### Step 6: Implement One at a Time
-
-Address each piece of feedback individually with verification.
-
-```markdown
-Feedback item 1: Add null check
-→ Implement → Test → Commit → Verify → Move to next
-
-Feedback item 2: Extract helper function
-→ Implement → Test → Commit → Verify → Move to next
-
-NOT: Try to address all feedback in one massive commit
-```
-
----
-
-## Avoiding Agreement Theater
-
-### The Problem
-
-Performative agreement wastes time and provides no information. When you write "Great point!" you're adding noise, not signal.
-
-### Forbidden Phrases
-
-| Phrase | Why It's Wrong |
-|--------|----------------|
-| "You're absolutely right!" | Sycophantic, adds no information |
-| "Great point!" | Empty praise, not a response |
-| "Excellent feedback!" | Flattery, not engagement |
-| "Thanks for catching this!" | Unnecessary, just fix it |
-| "I really appreciate..." | Social fluff, not technical |
-
-### Actions Demonstrate Understanding
-
-```markdown
-❌ "You're absolutely right! Great catch on that null check!
-    Thanks so much for pointing this out!"
-
-✅ "Fixed. Added null check at line 42."
-```
-
-The code change shows you understood. Words are redundant.
-
-### When Acknowledgment IS Appropriate
-
-Brief, technical acknowledgment when learning something new:
-
-```markdown
-✅ "I wasn't aware of that edge case. Added handling at line 42."
-✅ "Good point about thread safety. Added mutex at line 67."
-```
-
----
-
-## When to Push Back
-
-### Valid Reasons to Disagree
-
-Push back with technical reasoning when feedback:
-
-| Situation | How to Respond |
-|-----------|----------------|
-| Breaks existing functionality | "This change would break Feature X (see test at tests/feature-x.spec.ts:34)" |
-| Lacks full codebase context | "This pattern exists because of Y (see architecture.md#constraints)" |
-| Violates YAGNI | "This flexibility isn't needed yet - only one caller exists" |
-| Is technically incorrect | "This actually works because of Z (link to docs)" |
-| Conflicts with established architecture | "This conflicts with our JWT approach (see auth/README.md)" |
-
-### Good Pushback Format
-
-```markdown
-## Template
-This conflicts with [X]. [Evidence]. Was that the intent, or should we [alternative]?
-
-## Example
-This conflicts with our JWT authentication architecture (see auth/token.js:45).
-Switching to sessions would require restructuring the API middleware.
-Was that the intent, or should we keep JWT?
-```
-
-### Bad Pushback
-
-```markdown
-❌ "I don't think that's right."
-❌ "That won't work."
-❌ "We've always done it this way."
-❌ "That's too much work."
-```
-
----
-
-## Verification Before Claiming Fixed
-
-### The Checklist
-
-Before writing "Fixed" or "Done":
-
-- [ ] Change is implemented
-- [ ] Tests pass (full suite, not just changed files)
-- [ ] Specific behavior mentioned in feedback is verified
-- [ ] Edge cases are tested
-- [ ] No unintended side effects introduced
-
-### Acceptable Responses
-
-```markdown
-✅ "Fixed. Added null check. Tests pass."
-✅ "Fixed at line 42. Verified with test case X."
-✅ "Implemented. All 47 tests pass."
-```
-
-### Unacceptable Responses
-
-```markdown
-❌ "I think this addresses your concern."
-❌ "Should be fixed now."
-❌ "Done, I believe."
-❌ "Fixed (probably)."
-```
-
-### When You Can't Verify
-
-If you cannot verify a fix:
-
-```markdown
-✅ "Implemented the change, but I'm unable to verify because
-    [specific reason]. Can you confirm on your end?"
-```
-
----
-
-## Quick Reference
-
-| Situation | Response |
-|-----------|----------|
-| Reviewer is correct | "Fixed. [What you changed]." |
-| You need clarification | "To confirm: you're suggesting [restatement]?" |
-| Reviewer is incorrect | "This works because [evidence]. [Link to proof]." |
-| You disagree on approach | "This conflicts with [X]. Should we [alternative]?" |
-| You learned something | "I wasn't aware of [X]. Fixed at line [N]." |
-| You can't verify | "Implemented. Unable to verify because [reason]." |
-
----
-
-## Anti-Patterns
-
-| Pattern | Problem | Fix |
-|---------|---------|-----|
-| Defensive responses | Creates conflict, wastes time | Assume good faith, respond technically |
-| Apologetic responses | Unprofessional, adds noise | Just fix it |
-| Delayed responses | Blocks review cycle | Respond within hours, not days |
-| Vague responses | Leaves reviewer uncertain | Be specific about changes |
-| Ignoring feedback | Disrespectful, creates friction | Address every point |
-
----
-
-*Content adapted from [obra/superpowers](https://github.com/obra/superpowers) by Jesse Vincent (@obra), MIT License.*