@cubis/foundry 0.3.63 → 0.3.65

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/code-reviewer/references/report-template.md

@@ -0,0 +1,112 @@
+# Report Template
+
+> Reference for: Code Reviewer
+> Load when: Writing final review report
+
+## Full Review Report Template
+
+```markdown
+# Code Review: [PR Title]
+
+## Summary
+[1-2 sentence overview of the changes and overall assessment]
+
+**Verdict**: [ ] Approve | [x] Request Changes | [ ] Comment
+
+## Critical Issues (Must Fix)
+
+### 1. [File:Line] Security: SQL Injection Risk
+- **Current**: String interpolation in query
+- **Suggested**: Use parameterized query
+- **Impact**: Potential data breach
+
+```typescript
+// Current (vulnerable)
+const query = `SELECT * FROM users WHERE id = ${id}`;
+
+// Suggested (secure)
+const query = 'SELECT * FROM users WHERE id = $1';
+db.query(query, [id]);
+```
+
+## Major Issues (Should Fix)
+
+### 1. [File:Line] Performance: N+1 Query
+- **Current**: Fetching users in loop
+- **Suggested**: Use eager loading with include
+- **Impact**: ~100 extra DB queries per request
+
+### 2. [File:Line] Logic: Missing edge case
+- **Current**: No handling for empty array
+- **Suggested**: Add guard clause
+- **Impact**: Potential runtime error
+
+## Minor Issues (Nice to Have)
+
+### 1. [File:Line] Naming: Unclear variable name
+- **Current**: `d`
+- **Suggested**: `createdDate`
+
+### 2. [File:Line] Style: Inconsistent formatting
+- **Current**: Mixed quotes
+- **Suggested**: Use single quotes consistently
+
+## Positive Feedback
+- Clean separation of concerns in service layer
+- Comprehensive input validation on DTOs
+- Good test coverage for edge cases
+- Excellent error messages
+
+## Questions for Author
+- What's the expected behavior when X happens?
+- Should this support pagination for large datasets?
+- Is the retry logic intentional or accidental?
+
+## Test Coverage Assessment
+- [ ] Happy path tested
+- [x] Error cases tested
+- [ ] Edge cases tested (missing empty array test)
+- [x] Integration tests present
+
+## Checklist
+- [x] No security vulnerabilities
+- [ ] Performance is acceptable (N+1 issue)
+- [x] Code is readable
+- [x] Tests are adequate
+- [x] Documentation is present
+```
+
+## Verdict Guidelines
+
+| Verdict | When to Use |
+|---------|-------------|
+| **Approve** | No blocking issues, minor suggestions only |
+| **Request Changes** | Critical or major issues must be fixed |
+| **Comment** | Questions need answers, no blocking issues |
+
+## Severity Definitions
+
+| Severity | Definition | Examples |
+|----------|------------|----------|
+| **Critical** | Security risk, data loss, crashes | SQL injection, auth bypass |
+| **Major** | Significant performance, maintainability | N+1 queries, god functions |
+| **Minor** | Style, naming, small improvements | Variable names, formatting |
+
+## Time Boxing
+
+| Section | Suggested Time |
+|---------|----------------|
+| Context & understanding | 5 minutes |
+| Critical/security review | 10 minutes |
+| Logic & performance | 15 minutes |
+| Tests review | 10 minutes |
+| Writing report | 10 minutes |
+| **Total** | ~50 minutes |
+
+## Quick Checks Before Submitting
+
+- [ ] All critical issues have clear remediation
+- [ ] Major issues explain the impact
+- [ ] At least one positive comment included
+- [ ] Questions are specific and answerable
+- [ ] Verdict matches the issues found

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/code-reviewer/references/review-checklist.md

@@ -0,0 +1,133 @@
+# Review Checklist
+
+> Reference for: Code Reviewer
+> Load when: Starting a code review
+
+## Comprehensive Review Checklist
+
+| Category           | Key Questions                                                |
+| ------------------ | ------------------------------------------------------------ |
+| **Design**         | Does it fit existing patterns? Right abstraction level?      |
+| **Logic**          | Edge cases handled? Race conditions? Null checks?            |
+| **Security**       | Input validated? Auth checked? Secrets safe?                 |
+| **Performance**    | N+1 queries? Memory leaks? Caching needed?                   |
+| **Tests**          | Adequate coverage? Edge cases tested? Mocks appropriate?     |
+| **Naming**         | Clear, consistent, intention-revealing? File names standard? |
+| **Error Handling** | Errors caught? Meaningful messages? Logged?                  |
+| **Documentation**  | Public APIs documented? Complex logic explained?             |
+| **Code Smells**    | Dead code? Duplication? God objects? Divergent change?       |
+
+## Review Process
+
+### 1. Context (5 min)
+
+- [ ] Read PR description
+- [ ] Understand the problem being solved
+- [ ] Check linked issues/tickets
+- [ ] Note expected changes
+- [ ] Enforce strict rules in strict-rules.md
+
+### 2. Structure (10 min)
+
+- [ ] Review file organization
+- [ ] Check architectural fit
+- [ ] Verify design patterns used
+- [ ] Note any breaking changes
+
+### 3. Code Details (20 min)
+
+- [ ] Review logic correctness
+- [ ] Check edge cases
+- [ ] Verify error handling
+- [ ] Look for security issues
+- [ ] Check performance concerns
+- [ ] Review naming clarity
+- [ ] Flag code smells and unnecessary code
+- [ ] Check for race conditions and unsafe concurrency
+
+### 4. Tests (10 min)
+
+- [ ] Verify test coverage
+- [ ] Check test quality
+- [ ] Look for edge case tests
+- [ ] Ensure mocks are appropriate
+
+### 5. Final Pass (5 min)
+
+- [ ] Note positive patterns
+- [ ] Prioritize feedback
+- [ ] Write summary
+
+## Category Deep Dive
+
+### Design Questions
+
+- Does this change belong in this file/module?
+- Is the abstraction level appropriate?
+- Could this be simpler?
+- Does it follow existing patterns?
+- Is it extensible without modification?
+- Does it follow SOLID where relevant?
+- Is the solution KISS/YAGNI (not over-engineered)?
+
+### Design Principles Quick Check
+
+- **SOLID**: SRP, OCP, LSP, ISP, DIP where applicable
+- **KISS**: simplest working solution
+- **DRY**: no duplicated logic or configs
+- **YAGNI**: avoid speculative features
+- **Separation of Concerns**: clear boundaries between layers
+- **Composition over Inheritance**: favor small composable units
+
+### Logic Questions
+
+- What happens with null/undefined inputs?
+- Are boundary conditions handled?
+- Could there be race conditions?
+- Is the order of operations correct?
+- Are all code paths tested?
+
+### Security Questions
+
+- Is all user input validated?
+- Are SQL queries parameterized?
+- Is output properly encoded?
+- Are secrets handled safely?
+- Is authentication checked?
+- Is authorization enforced?
+
+### Performance Questions
+
+- Are there N+1 query patterns?
+- Is data fetched efficiently?
+- Are expensive operations cached?
+- Could this cause memory leaks?
+- Is pagination implemented?
+
+### Naming & Organization Questions
+
+- Are file names consistent with repo conventions?
+- Do file names describe responsibility clearly?
+- Are functions named with verbs and intent?
+- Are variables descriptive and scoped tightly?
+- Is there one primary concern per file?
+
+### Code Smell Questions
+
+- Is there duplicate logic that can be extracted (DRY)?
+- Is there dead/unused code?
+- Are there long functions/classes with mixed responsibilities (SRP)?
+- Are there “god” objects or utility dumping grounds?
+- Are there hidden side-effects or global state dependencies?
+
+## Quick Reference
+
+| Review Focus             | Time % |
+| ------------------------ | ------ |
+| Context & PR description | 10%    |
+| Architecture & design    | 20%    |
+| Code logic & details     | 40%    |
+| Tests & coverage         | 20%    |
+| Final review & summary   | 10%    |
+
+

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/code-reviewer/references/spec-compliance-review.md

@@ -0,0 +1,261 @@
+# Spec Compliance Review
+
+> Reference for: Code Reviewer
+> Load when: reviewing implementations, PR review, spec verification
+
+---
+
+## Two-Stage Review Architecture
+
+```
+                    ┌─────────────────────┐
+                    │   Implementation    │
+                    └──────────┬──────────┘
+                               │
+                    ┌──────────▼──────────┐
+                    │  STAGE 1: Spec      │
+                    │  Compliance Review  │
+                    └──────────┬──────────┘
+                               │
+              ┌────────────────┴────────────────┐
+              │                                  │
+      ┌───────▼───────┐                ┌────────▼────────┐
+      │   ✗ Issues    │                │   ✓ Compliant   │
+      │     Found     │                │                 │
+      └───────┬───────┘                └────────┬────────┘
+              │                                  │
+              │                        ┌────────▼────────┐
+              │                        │  STAGE 2: Code  │
+              │                        │  Quality Review │
+              │                        └────────┬────────┘
+              │                                  │
+              │                    ┌─────────────┴─────────────┐
+              │                    │                           │
+              │            ┌───────▼───────┐         ┌────────▼────────┐
+              │            │   ✗ Issues    │         │   ✓ Approved    │
+              │            │     Found     │         │                 │
+              │            └───────┬───────┘         └─────────────────┘
+              │                    │
+              └────────────────────┴────────────────────┐
+                                                        │
+                                              ┌─────────▼─────────┐
+                                              │ Return to Author  │
+                                              └───────────────────┘
+```
+
+**Critical:** Complete Stage 1 (spec compliance) BEFORE Stage 2 (code quality). Never review code quality for functionality that doesn't meet the specification.
+
+---
+
+## Stage 1: Spec Compliance Review
+
+### Core Directive
+
+> "The implementer finished suspiciously quickly. Their report may be incomplete, inaccurate, or optimistic."
+
+Approach every review with professional skepticism. Verify claims independently.
+
+### The Three Verification Categories
+
+#### Category 1: Missing Requirements
+
+**Check for features that were requested but not implemented.**
+
+| Question | How to Verify |
+|----------|---------------|
+| Did they skip requested features? | Compare PR to original requirements line by line |
+| Are edge cases handled? | Check error paths, empty states, boundaries |
+| Were error scenarios addressed? | Look for try/catch, error boundaries, validation |
+| Is the happy path complete? | Trace through primary use case manually |
+
+```markdown
+## Example Review Finding
+
+**Missing Requirement:** Issue #42 requested "password must be at least 8 characters"
+
+**Found in code:**
+```typescript
+// No length validation present
+function validatePassword(password: string) {
+  return password.length > 0;  // Only checks non-empty
+}
+```
+
+**Status:** ❌ Incomplete - minimum length validation missing
+```
+
+#### Category 2: Unnecessary Additions
+
+**Check for scope creep and over-engineering.**
+
+| Question | How to Verify |
+|----------|---------------|
+| Features beyond specification? | Compare to original requirements |
+| Over-engineering? | Is complexity justified by requirements? |
+| Premature optimization? | Is performance cited without measurements? |
+| Unrequested abstractions? | Are there helpers/utils for one-time use? |
+
+```markdown
+## Example Review Finding
+
+**Unnecessary Addition:** Added caching layer not in requirements
+
+**Found in code:**
+```typescript
+// Original requirement: "Fetch user by ID"
+// Actual implementation:
+class CachedUserRepository {  // Not requested
+  private cache = new Map();
+  private ttl = 60000;
+
+  async getUser(id: string) {
+    if (this.cache.has(id)) { ... }
+    // 50 lines of cache logic
+  }
+}
+```
+
+**Status:** ⚠️ Scope creep - discuss before merging
+```
+
+#### Category 3: Interpretation Gaps
+
+**Check for misunderstandings of requirements.**
+
+| Question | How to Verify |
+|----------|---------------|
+| Different understanding of requirements? | Ask author to explain their interpretation |
+| Unclarified assumptions? | Look for comments like "assuming..." |
+| Ambiguous specs resolved incorrectly? | Compare to similar existing features |
+
+```markdown
+## Example Review Finding
+
+**Interpretation Gap:** "Sort by date" implemented as ascending
+
+**Requirement stated:** "Sort by date" (ambiguous)
+
+**Author implemented:** Oldest first (ascending)
+
+**Expected:** Most recent first is typical UX pattern
+
+**Status:** ❓ Clarify - which sort order was intended?
+```
+
+---
+
+## Why Order Matters
+
+### Stage 1 Must Come First
+
+| Scenario | Waste from Wrong Order |
+|----------|------------------------|
+| Skip Stage 1 | Review 500 lines of code quality, then discover wrong feature was built |
+| Stage 2 First | Suggest refactoring, then realize the code shouldn't exist |
+| Combined | Mix concerns, miss systematic issues |
+
+### Separation of Concerns
+
+- **Stage 1 (Spec):** Does it do the right thing?
+- **Stage 2 (Quality):** Does it do the thing right?
+
+Code quality review is meaningless if the code doesn't implement the correct functionality.
+
+---
+
+## Spec Compliance Checklist
+
+### Before You Start
+
+- [ ] Read the original issue/ticket completely
+- [ ] Identify all explicit requirements
+- [ ] Identify implicit requirements from context
+- [ ] Note any acceptance criteria listed
+
+### During Review
+
+**Missing Requirements:**
+- [ ] All required features present
+- [ ] Edge cases covered (empty, null, max values)
+- [ ] Error handling as specified
+- [ ] Happy path fully functional
+- [ ] UI matches mockups/specs if provided
+
+**Unnecessary Additions:**
+- [ ] No unrequested features
+- [ ] No speculative abstractions
+- [ ] No premature optimizations
+- [ ] Scope matches requirements exactly
+
+**Interpretation Gaps:**
+- [ ] Author's understanding matches spec
+- [ ] Ambiguities resolved correctly
+- [ ] Assumptions are documented and valid
+- [ ] Behavior matches similar existing features
+
+### After Review
+
+- [ ] Document all findings with file:line references
+- [ ] Categorize as missing/unnecessary/interpretation
+- [ ] Prioritize: blocking vs. non-blocking issues
+
+---
+
+## Output Format
+
+### Compliant Result
+
+```markdown
+## Spec Compliance Review: ✅ PASS
+
+All requirements verified:
+- ✅ User can upload profile image (req #1)
+- ✅ Image resized to 200x200 (req #2)
+- ✅ Invalid formats rejected with error message (req #3)
+- ✅ Progress indicator during upload (req #4)
+
+**Proceed to:** Code Quality Review
+```
+
+### Issues Found
+
+```markdown
+## Spec Compliance Review: ❌ ISSUES FOUND
+
+### Missing Requirements
+
+1. **Progress indicator not implemented** (req #4)
+   - File: `ProfileUpload.tsx`
+   - Expected: Progress bar during upload
+   - Found: No progress indication
+
+2. **Error messages not user-friendly** (req #3)
+   - File: `ProfileUpload.tsx:45`
+   - Expected: "Please upload a JPG or PNG file"
+   - Found: "Error: INVALID_FORMAT"
+
+### Unnecessary Additions
+
+1. **Image cropping feature not requested**
+   - File: `ImageCropper.tsx` (new file, 150 lines)
+   - Impact: Adds complexity, delays delivery
+   - Recommendation: Remove or create separate PR
+
+**Action Required:** Address missing requirements before code quality review
+```
+
+---
+
+## Common Mistakes to Avoid
+
+| Mistake | Why It's Wrong |
+|---------|----------------|
+| Reviewing code style before spec compliance | Wasted effort if wrong thing was built |
+| Assuming spec was followed | Verify independently |
+| Skipping edge cases | Bugs hide in boundaries |
+| Accepting "we can add it later" | Technical debt accumulates |
+| Missing scope creep | Unreviewed code enters codebase |
+
+---
+
+*Content adapted from [obra/superpowers](https://github.com/obra/superpowers) by Jesse Vincent (@obra), MIT License.*

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/code-reviewer/references/strict-rules.md

@@ -0,0 +1,69 @@
+# Strict Code Review Rules
+
+> Reference for: Code Reviewer
+> Load when: Enforcing strict review standards
+
+## Core Standard (Non‑Negotiable)
+
+- **Correctness first**: reject changes that introduce incorrect behavior, regressions, or incomplete edge cases.
+- **Readability is a feature**: if code is hard to understand, request changes.
+- **Consistency over preference**: match existing style and patterns within the codebase.
+
+## Change Size & Scope
+
+- **Small, focused changes**: large or multi‑purpose changes must be split.
+- **No scope creep**: remove unrequested features and speculative abstractions.
+- **Spec first**: if requirements are ambiguous, request clarification before approval.
+
+## Naming & File Organization
+
+- **Intention‑revealing names**: names must convey responsibility and behavior.
+- **One primary concern per file**: avoid “utility dump” files.
+- **Consistent file naming**: follow repo conventions strictly (case, separators).
+- **Acronyms as words**: prefer `UserId` over `UserID`, `HttpClient` over `HTTPClient`.
+
+## Error Handling & Reliability
+
+- **No empty catch blocks**: handle or rethrow with context.
+- **Avoid catch‑all**: don’t catch overly broad exceptions unless at top‑level boundary.
+- **Fail fast with clear errors**: avoid silent failures and partial updates.
+
+## Concurrency & Race Conditions
+
+- **Atomicity required**: read‑modify‑write must be transactional or atomic.
+- **Shared state must be protected**: use locks/transactions/queues as appropriate.
+- **Idempotency for retries**: requests and jobs should be safe to retry.
+
+## Design Principles (Strict)
+
+- **SRP**: split large classes/functions by responsibility.
+- **KISS**: prefer the simplest solution that meets requirements.
+- **DRY**: remove duplicated logic or clearly justify it.
+- **YAGNI**: no speculative features or “just in case” hooks.
+- **Composition over inheritance**: avoid deep inheritance chains.
+
+## Testing Requirements
+
+- **Critical paths covered**: happy path + failure path + edge cases.
+- **Concurrency tests**: required when shared state or ordering is involved.
+- **No flaky tests**: reject non‑deterministic tests.
+
+## Logging & Observability
+
+- **No sensitive data in logs**: redact secrets and PII.
+- **Log sparingly**: avoid noisy logs and repeated errors.
+- **Actionable logs**: include enough context to debug without leaking data.
+
+## Security Baseline
+
+- **Input validation** everywhere input crosses trust boundaries.
+- **Least privilege** for services, DB access, and API scopes.
+- **No unsafe defaults**: defaults must be secure, explicit opt‑in for risky behavior.
+
+## References
+
+- Google Engineering Practices – Code Review (reviewer): https://google.github.io/eng-practices/review/reviewer/
+- Google Engineering Practices – CL Author Guide: https://google.github.io/eng-practices/review/developer/
+- Google Style Guides (naming/style consistency): https://google.github.io/styleguide/
+- AOSP Code Style (strict rules + exceptions): https://source.android.com/docs/setup/contribute/code-style
+- Microsoft C# Coding Conventions (enforceable style): https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/csharp-pro/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: "csharp-pro"
+description: "Use for modern C# backend/application engineering with C# 14 and .NET 10-era production practices."
+license: MIT
+metadata:
+  version: "1.0.0"
+  domain: "language"
+  role: "specialist"
+  stack: "csharp"
+  baseline: "C# 14 / .NET 10"
+---
+
+# C# Pro
+
+## When to use
+
+- Building APIs, workers, and services in .NET.
+- Refactoring legacy C# into modern, testable architecture.
+- Improving async correctness and operational resilience.
+
+## When not to use
+
+- Frontend-only browser work with no .NET runtime.
+- Database-only tuning where query/schema evidence is the primary task.
+- Tiny scripting tasks better served by existing shell or project tooling.
+
+## Core workflow
+
+1. Confirm target framework/runtime constraints.
+2. Define clean contracts (DTOs, domain, persistence boundaries).
+3. Implement async-first I/O and cancellation-aware flows.
+4. Validate with tests, analyzers, and profiling.
+
+## Baseline standards
+
+- Use nullable reference types and treat warnings as actionable.
+- Use `async`/`await` with `CancellationToken` in public async APIs.
+- Keep exception handling consistent and observable.
+- Use dependency injection with explicit lifetimes.
+- Keep API contracts versioned and backward-compatible.
+
+## Debugging and observability
+
+- Use structured logs with correlation/request IDs on service boundaries.
+- Keep exception-to-response mapping explicit and non-leaky.
+- Prefer `dotnet test`, analyzers, and targeted traces before speculative rewrites.
+
+## Performance and reliability
+
+- Measure allocation hotspots before changing data structures.
+- Propagate `CancellationToken` through request and worker paths.
+- Bound retries/timeouts explicitly for network and queue work.
+
+## References
+
+| File | Load when |
+| --- | --- |
+| `references/operational-baseline.md` | You need current async, logging, testing, and deployment guardrails for C#/.NET services. |
+
+## Avoid
+
+- Sync-over-async (`.Result`, `.Wait()`) in request paths.
+- Fat controllers with business logic and persistence mixed.
+- Global static mutable state in multi-request services.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/csharp-pro/references/operational-baseline.md

@@ -0,0 +1,9 @@
+## Operational baseline
+
+Load when: service-level logging, async boundaries, dependency injection, or production verification need explicit guardrails.
+
+- Keep nullable reference types enabled and treat warnings as design feedback.
+- Use `CancellationToken` in public async APIs and propagate it through external I/O.
+- Prefer structured logging with request/job correlation IDs.
+- Keep transport contracts separate from domain and persistence models.
+- Validate with `dotnet test`, analyzers, and targeted profiling before shipping.