cfsa-antigravity 2.19.0 → 2.19.2

package/template/.claude/skills/brainstorming/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: brainstorming
+description: "Use before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design before implementation."
+version: 2.0.0
+source: self
+date_added: "2026-02-27"
+date_rewritten: "2026-03-14"
+---
+
+# Brainstorming Ideas Into Designs
+
+Turn raw ideas into **clear, validated designs** through structured dialogue **before any implementation begins**.
+
+## When to Use
+
+- User describes a new feature, component, or behavior change
+- Task involves creative decisions (not just execution of a clear spec)
+- Requirements are ambiguous or incomplete
+- Work could go in multiple valid directions
+
+## When NOT to Use
+
+- Task has a clear spec with acceptance criteria (just implement it)
+- Fixing a bug with obvious cause (just fix it)
+- During `/plan-phase` or `/implement-slice` (those have their own structure)
+- Trivial changes (rename a variable, fix a typo)
+
+## Operating Mode
+
+You are a **design facilitator**, not a builder. While this skill is active:
+
+- No coding, no file modifications
+- No speculative features — only design what's been discussed
+- No silent assumptions — every assumption gets stated explicitly
+- No skipping ahead — each gate must be passed before proceeding
+
+---
+
+## The Process
+
+### 1. Scan Context (Before Asking Anything)
+
+Read the relevant project state:
+- Existing code in the affected area
+- Related specs, plans, or prior decisions
+- Recent changes that might affect the design
+
+Note what already exists vs. what's proposed. Identify implicit constraints.
+
+**Do not design yet.**
+
+### 2. Understand the Idea
+
+**One question at a time.** Do not dump a list of 10 questions.
+
+Prefer multiple-choice when possible:
+> "Should this component handle errors inline or delegate to a parent error boundary?
+> A) Inline (self-contained)
+> B) Delegate (parent handles)
+> C) Hybrid (catch critical, delegate non-critical)"
+
+Focus on understanding:
+- **Purpose** — what problem does this solve?
+- **Users** — who uses it and how?
+- **Constraints** — performance, security, compatibility limits
+- **Success criteria** — how do we know it's working?
+- **Non-goals** — what is explicitly out of scope?
+
+### 3. Non-Functional Requirements
+
+Before any design, clarify or propose defaults for:
+
+| Requirement | If User Is Unsure |
+|-------------|-------------------|
+| Performance | Propose: "P95 < 200ms for API, <3s for page load" |
+| Scale | Propose: "Support 1K concurrent users initially" |
+| Security | Default: input validation, auth required, no PII in logs |
+| Reliability | Propose: "99.5% uptime, graceful degradation" |
+| Maintenance | "Maintained by your team, or handed off?" |
+
+Mark all proposals as **assumptions** that the user can override.
+
+### 4. Understanding Lock (Hard Gate)
+
+**Before proposing any design**, present:
+
+```markdown
+## Understanding Summary
+- **Building**: [what]
+- **Purpose**: [why]
+- **Users**: [who]
+- **Key constraints**: [limits]
+- **Non-goals**: [explicitly excluded]
+
+## Assumptions
+- [Each assumption stated clearly]
+
+## Open Questions
+- [Any unresolved items]
+```
+
+Then ask: *"Does this accurately reflect your intent? Please confirm or correct before we move to design."*
+
+**Do NOT proceed until confirmed.**
+
+### 5. Explore Design Approaches
+
+Present **2-3 viable approaches**:
+
+1. **Recommended** — lead with this, explain why
+2. **Alternative** — different tradeoff (simpler but less extensible, etc.)
+3. **Alternative** — if genuinely different from #2
+
+For each approach, cover:
+- Complexity estimate (low/medium/high)
+- Extensibility (how easy to evolve later)
+- Risk (what could go wrong)
+- Implementation effort (rough scope)
+
+Apply **YAGNI ruthlessly** — remove unnecessary features from all approaches.
+
+### 6. Present Design (Incrementally)
+
+Break the design into sections of **200-300 words max**. After each section:
+
+> "Does this look right so far?"
+
+Cover as relevant:
+- Architecture / component structure
+- Data flow and state management
+- Error handling and edge cases
+- Testing strategy
+- Integration points
+
+### 7. Decision Log
+
+Maintain a running log:
+
+```markdown
+| Decision | Alternatives | Rationale |
+|----------|-------------|-----------|
+| Use event-driven sync | Polling, webhooks | Lower latency, less server load |
+| SQLite over PostgreSQL | PostgreSQL | Single-user app, simpler deployment |
+```
+
+This log survives into the final design document.
+
+---
+
+## Exit Criteria
+
+You may exit brainstorming **only when ALL are true**:
+
+- [ ] Understanding Lock confirmed by user
+- [ ] At least one design approach explicitly accepted
+- [ ] Assumptions documented and acknowledged
+- [ ] Key risks identified
+- [ ] Decision Log complete
+
+If any criterion is unmet → continue refinement. Do NOT proceed to implementation.
+
+## After Brainstorming
+
+1. Write the design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
+2. Include: understanding summary, assumptions, decision log, final design
+3. Ask: "Ready to set up for implementation?"
+4. If yes, hand off to the appropriate pipeline command (`/plan-phase`, `/implement-slice`, etc.)
+
+## Key Principles
+
+1. **One question at a time** — never overwhelm
+2. **Multiple choice preferred** — easier to answer
+3. **Assumptions must be explicit** — never silently assume
+4. **YAGNI ruthlessly** — remove unnecessary features
+5. **Explore alternatives** — always 2-3 approaches
+6. **Incremental validation** — present in sections, validate each
+7. **Clarity over cleverness** — simple > smart

package/template/.claude/skills/brand-guidelines/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: brand-guidelines
+description: "Apply the confirmed design direction to all visual surfaces. If `{{DESIGN_DIRECTION}}` still appears as a literal placeholder, the design direction has not been confirmed — run `/create-prd` first."
+---
+
+# {{PROJECT_NAME}} Brand Guidelines
+
+> **Status**: {{#if DESIGN_DIRECTION}}Active{{else}}⚠️ UNFILLED — Run /create-prd to confirm design direction before using this skill{{/if}}
+
+## Design Direction
+
+- **Confirmed direction**: {{DESIGN_DIRECTION}}
+- **Rationale**: {{DESIGN_DIRECTION_RATIONALE}}
+- **Primary audience**: {{DESIGN_AUDIENCE}}
+
+## Color Palette
+
+| Role | Value | Usage |
+|------|-------|-------|
+| Primary | {{PRIMARY_COLOR}} | Main brand color — buttons, links, key UI elements |
+| Secondary | {{SECONDARY_COLOR}} | Supporting color — secondary actions, accents |
+| Accent | {{ACCENT_COLOR}} | Highlight color — notifications, badges, emphasis |
+| Background | {{BACKGROUND_COLOR}} | Page/app background |
+| Text | {{TEXT_COLOR}} | Primary text color |
+
+## Typography
+
+| Role | Font | Usage |
+|------|------|-------|
+| Heading | {{HEADING_FONT}} | Page titles, section headers, display text |
+| Body | {{BODY_FONT}} | Paragraphs, descriptions, UI labels |
+| Mono | {{MONO_FONT}} | Code blocks, terminal output, technical values |
+
+## Motion Philosophy
+
+{{MOTION_PHILOSOPHY}}
+
+## Existing Brand Assets
+
+{{EXISTING_BRAND_ASSETS}}
+
+## What to Avoid
+
+{{DESIGN_AVOID}}

package/template/.claude/skills/clean-code/SKILL.md

@@ -0,0 +1,196 @@
+---
+name: clean-code
+description: "Applies battle-tested clean code principles to writing, reviewing, and refactoring code. Covers naming, functions, comments, error handling, class design, and the critical difference between clever code and clear code."
+version: 2.0.0
+---
+
+# Clean Code
+
+Code is read 10x more than it's written. Every naming choice, every function boundary, every abstraction layer either helps or hurts the next person who reads it — including future you.
+
+## When to Use
+
+- Writing any new code
+- Reviewing pull requests
+- Refactoring existing code
+- When code "works but feels wrong"
+
+## Stack-Specific References
+
+The principles below are language-agnostic. For idiomatic patterns and syntax, read the reference matching your surface's Languages column:
+
+| Language | Reference |
+|----------|-----------|
+| TypeScript / JavaScript | `references/typescript.md` |
+| Python | `references/python.md` |
+| Go | `references/go.md` |
+| Rust | `references/rust.md` |
+
+## Core Principles
+
+### 1. Names Are Documentation
+
+Names should reveal intent. If a name requires a comment to explain it, the name is wrong.
+
+| Bad | Good | Why |
+|-----|------|-----|
+| `d` | `elapsedDays` | What is `d`? |
+| `list` | `activeUsers` | What kind of list? |
+| `processData()` | `validateAndSaveOrder()` | What processing? |
+| `temp` | `filteredResults` | Temporary what? |
+| `flag` | `isEligibleForDiscount` | What flag? |
+| `doStuff()` | `sendWelcomeEmail()` | What stuff? |
+| `Manager` | `OrderProcessor` | Manager of what? |
+| `Utils` | `StringFormatter` | Util for what? |
+
+**Rules:**
+- Classes/types → nouns (`UserRepository`, `PaymentGateway`)
+- Functions → verbs (`calculateTotal`, `sendNotification`)
+- Booleans → questions (`isActive`, `hasPermission`, `canEdit`)
+- Constants → screaming snake with context (`MAX_RETRY_ATTEMPTS`, not `MAX`)
+- No abbreviations unless universally understood (`id`, `url`, `api` are fine; `usr`, `mgr`, `proc` are not)
+
+### 2. Functions Should Do One Thing
+
+A function that does one thing well is easy to name, test, and reuse. A function that does three things is hard to name, impossible to test independently, and couples three responsibilities.
+
+**The test:** Can you describe the function without using "and"? If not, split it.
+
+```
+❌ processOrder(order)
+   — validates order
+   — calculates total with tax
+   — saves to database
+   — sends confirmation email
+
+✅ validateOrder(order)        → throws if invalid
+   calculateOrderTotal(items) → returns numeric total
+   submitOrder(order)         → orchestrates the above
+```
+
+**Function size limits:**
+- **Ideal**: 5-15 lines
+- **Acceptable**: up to 30 lines
+- **Needs splitting**: 30+ lines
+- **Unacceptable**: 50+ lines (split immediately)
+
+### 3. Parameters
+
+- **0-2 parameters**: ideal
+- **3 parameters**: acceptable with named/destructured args
+- **4+ parameters**: use an options object/struct/dataclass
+- **Boolean parameters**: almost always a code smell — split into two functions
+
+```
+❌ createUser(name, isAdmin)
+✅ createUser(name)  /  createAdmin(name)
+
+❌ sendEmail(to, from, subject, body, cc)
+✅ sendEmail(options)   ← options is a structured type
+```
+
+### 4. Comments: Why, Not What
+
+Good code doesn't need comments to explain WHAT it does. Comments should explain WHY — the non-obvious reasoning, business rules, or constraints.
+
+```
+❌ // Increment counter by one
+   counter += 1
+
+❌ // Check if user is admin
+   if user.role == "admin"
+
+✅ // Stripe requires amount in cents, not dollars
+   amountInCents = round(price * 100)
+
+✅ // FDA regulation 21 CFR Part 11 requires audit trail
+   auditLog.record(changeEvent)
+
+✅ // WARNING: This query locks the orders table — avoid during peak hours
+   db.execute(batchUpdateQuery)
+```
+
+**Delete these comments immediately:**
+- `// TODO: fix this later` — fix it now or create a tracked issue
+- `// This is a hack` — then don't commit the hack
+- `// I don't know why this works` — figure it out before shipping
+- Commented-out code — delete it; version control has your history
+
+### 5. Error Handling
+
+Errors are not edge cases — they're expected behavior. Handle them explicitly.
+
+```
+❌ try { save(order) } catch { log("error") }
+   → What error? What happens to the order?
+
+❌ try { processPayment(order) } catch { throw Error("Something went wrong") }
+   → Useless to the caller
+
+✅ try {
+     processPayment(order)
+   } catch InsufficientFundsError:
+     return { success: false, code: "INSUFFICIENT_FUNDS", retry: false }
+   catch PaymentGatewayError:
+     logger.error("Payment gateway failure", { orderId: order.id })
+     return { success: false, code: "GATEWAY_ERROR", retry: true }
+   catch unknown:
+     rethrow  → Unknown errors bubble up
+```
+
+### 6. Don't Repeat Yourself (DRY) — But Don't Over-Abstract
+
+**DRY violation** — same logic copy-pasted in 3+ places:
+```
+tax1 = price1 * 0.08
+tax2 = price2 * 0.08
+tax3 = price3 * 0.08
+→ Extract: calculateTax(price)
+```
+
+**Over-abstraction** — premature DRY that couples unrelated things:
+```
+❌ handleEntity(type, action, data)  → "universal" handler for everything
+```
+
+**Rule of Three**: Duplicate once is acceptable. Duplicate twice means extract.
+
+### 7. Code Organization
+
+```
+                        High-level policy (business logic)
+                               │
+                               ▼
+                     ┌─────────────────────┐
+                     │   Domain Layer       │  Pure logic, no I/O
+                     │   (models, rules)    │
+                     └─────────────────────┘
+                               │
+                     ┌─────────────────────┐
+                     │   Application Layer  │  Orchestrates domain objects
+                     │   (use cases)        │
+                     └─────────────────────┘
+                               │
+                     ┌─────────────────────┐
+                     │   Infrastructure     │  I/O, databases, APIs
+                     │   (adapters)         │
+                     └─────────────────────┘
+                               │
+                        Low-level detail (frameworks, drivers)
+```
+
+- Dependencies point inward (infrastructure depends on domain, not reverse)
+- Business logic never imports from infrastructure
+- Test domain logic without databases, APIs, or frameworks
+
+## Quick Refactoring Checklist
+
+Before committing code, check:
+
+- [ ] Can I understand every function in <10 seconds?
+- [ ] Are there any functions >30 lines?
+- [ ] Are there any files >200 lines (components) or >300 lines (utilities)?
+- [ ] Do all names reveal intent without needing comments?
+- [ ] Is there any copy-pasted logic (3+ occurrences)?
+- [ ] Are errors handled specifically, not swallowed or genericized?
+- [ ] Would a new team member understand this without asking me?

package/template/.claude/skills/clean-code/references/typescript.md

@@ -0,0 +1,126 @@
+# TypeScript Clean Code Patterns
+
+Language-specific patterns for the `clean-code` skill. Read `SKILL.md` first for universal principles.
+
+---
+
+## Single Responsibility
+
+```typescript
+// ❌ Does three things
+function processOrder(order: Order): void {
+  if (!order.items.length) throw new Error("Empty order");
+  if (!order.customer) throw new Error("No customer");
+
+  let total = 0;
+  for (const item of order.items) {
+    total += item.price * item.quantity;
+    if (item.taxable) total += item.price * 0.08;
+  }
+
+  db.orders.insert({ ...order, total, status: "pending" });
+  emailService.send(order.customer.email, "Order confirmed");
+}
+
+// ✅ Each function does one thing
+function validateOrder(order: Order): void {
+  if (!order.items.length) throw new InvalidOrderError("Empty order");
+  if (!order.customer) throw new InvalidOrderError("No customer");
+}
+
+function calculateOrderTotal(items: OrderItem[]): number {
+  return items.reduce((total, item) => {
+    const subtotal = item.price * item.quantity;
+    const tax = item.taxable ? item.price * TAX_RATE : 0;
+    return total + subtotal + tax;
+  }, 0);
+}
+
+function submitOrder(order: Order): OrderConfirmation {
+  validateOrder(order);
+  const total = calculateOrderTotal(order.items);
+  const saved = db.orders.insert({ ...order, total, status: "pending" });
+  emailService.send(order.customer.email, "Order confirmed");
+  return { orderId: saved.id, total };
+}
+```
+
+## Options Objects Over Positional Args
+
+```typescript
+// ❌ Boolean flag parameter
+function createUser(name: string, isAdmin: boolean): User { ... }
+
+// ✅ Two clear functions
+function createUser(name: string): User { ... }
+function createAdmin(name: string): User { ... }
+
+// ❌ Too many positional args
+function sendEmail(to: string, from: string, subject: string, body: string, cc?: string): void { ... }
+
+// ✅ Options object
+interface SendEmailOptions {
+  to: string;
+  from: string;
+  subject: string;
+  body: string;
+  cc?: string;
+}
+function sendEmail(options: SendEmailOptions): void { ... }
+```
+
+## Error Handling
+
+```typescript
+// ❌ Swallowing errors
+try {
+  await saveOrder(order);
+} catch (e) {
+  console.log("error");
+}
+
+// ❌ Generic catch-all
+try {
+  await processPayment(order);
+} catch (e) {
+  throw new Error("Something went wrong");
+}
+
+// ✅ Specific, actionable error handling
+try {
+  await processPayment(order);
+} catch (error) {
+  if (error instanceof InsufficientFundsError) {
+    return { success: false, code: "INSUFFICIENT_FUNDS", retry: false };
+  }
+  if (error instanceof PaymentGatewayError) {
+    logger.error("Payment gateway failure", { orderId: order.id, error });
+    return { success: false, code: "GATEWAY_ERROR", retry: true };
+  }
+  throw error; // Unknown errors bubble up
+}
+```
+
+## Comments
+
+```typescript
+// ❌ Redundant
+// Increment counter by one
+counter += 1;
+
+// ❌ Obvious
+// Check if user is admin
+if (user.role === "admin") { ... }
+
+// ✅ Explains WHY
+// Stripe requires amount in cents, not dollars
+const amountInCents = Math.round(price * 100);
+
+// ✅ Business rule
+// FDA regulation 21 CFR Part 11 requires audit trail for all changes
+await auditLog.record(changeEvent);
+
+// ✅ Non-obvious consequence
+// WARNING: This query locks the orders table — avoid running during peak hours
+await db.execute(batchUpdateQuery);
+```

package/template/.claude/skills/code-review-pro/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: Code Review Pro
+description: Deep code analysis covering security, performance, maintainability, and best practices
+---
+
+# Code Review Pro
+
+Deep code analysis covering security, performance, maintainability, and best practices.
+
+## When to Use This Skill
+Activate when the user:
+- Asks for a code review
+- Wants security vulnerability scanning
+- Needs performance analysis
+- Asks to "review this code" or "audit this code"
+- Mentions finding bugs or improvements
+- Wants refactoring suggestions
+- Requests best practice validation
+
+## Instructions
+1. **Security Analysis (Critical Priority)**
+   - SQL injection vulnerabilities
+   - XSS (cross-site scripting) risks
+   - Authentication/authorization issues
+   - Secrets or credentials in code
+   - Unsafe deserialization
+   - Path traversal vulnerabilities
+   - CSRF protection
+   - Input validation gaps
+   - Insecure cryptography
+   - Dependency vulnerabilities
+
+2. **Performance Analysis**
+   - N+1 query problems
+   - Inefficient algorithms (check Big O complexity)
+   - Memory leaks
+   - Unnecessary re-renders (React/Vue)
+   - Missing indexes (database queries)
+   - Blocking operations
+   - Resource cleanup (file handles, connections)
+   - Caching opportunities
+   - Excessive network calls
+   - Large bundle sizes
+
+3. **Code Quality & Maintainability**
+   - Code duplication (DRY violations)
+   - Function/method length (should be <50 lines)
+   - Cyclomatic complexity
+   - Unclear naming
+   - Missing error handling
+   - Inconsistent style
+   - Missing documentation
+   - Hard-coded values that should be constants
+   - God classes/functions
+   - Tight coupling
+
+4. **Best Practices**
+   - Language-specific idioms
+   - Framework conventions
+   - SOLID principles
+   - Design patterns usage
+   - Testing approach
+   - Logging and monitoring
+   - Accessibility (for UI code)
+   - Type safety
+   - Null/undefined handling
+
+5. **Bugs and Edge Cases**
+   - Logic errors
+   - Off-by-one errors
+   - Race conditions
+   - Null pointer exceptions
+   - Unhandled edge cases
+   - Timezone issues
+   - Encoding problems
+   - Floating point precision
+
+6. **Provide Actionable Fixes**
+   - Show specific code changes
+   - Explain why change is needed
+   - Include before/after examples
+   - Prioritize by severity
+
+## Output Format
+```markdown
+# Code Review Report
+
+## 🚨 Critical Issues (Fix Immediately)
+### 1. [Issue Title] (line X)
+**Severity**: Critical
+**Issue**: [Description]
+**Impact**: [What could happen]
+
+**Current Code:**
+```
+[problematic code]
+```
+
+**Fixed Code:**
+```
+[corrected code]
+```
+
+**Explanation**: [Why this matters]
+
+## ⚠️ High Priority Issues
+### 2. [Issue] (line Y)
+[Details...]
+
+## 💡 Medium Priority Issues
+### 3. [Issue] (line Z)
+[Details...]
+
+## ✅ Low Priority / Nice to Have
+### 4. [Issue]
+[Details...]
+
+## 📊 Summary
+- **Total Issues**: N
+  - Critical: X
+  - High: Y
+  - Medium: Z
+  - Low: W
+
+## 🎯 Quick Wins
+Changes with high impact and low effort:
+1. [Fix 1]
+2. [Fix 2]
+
+## 🏆 Strengths
+- [Positive observation 1]
+- [Positive observation 2]
+
+## 🔄 Refactoring Opportunities
+1. **Extract Method**: Lines X-Y could be extracted into `functionName()`
+2. **Remove Duplication**: [specific code blocks]
+```
+
+## Best Practices
+- Always prioritize security issues first
+- Provide specific line numbers for issues
+- Include before/after code examples
+- Explain *why* something is a problem
+- Consider the language/framework context
+- Don't just criticize—acknowledge good code too
+- Suggest gradual improvements for large refactors
+- Link to documentation for recommendations
+- Consider project constraints (legacy code, deadlines)
+- Balance perfectionism with pragmatism
+- Focus on impactful changes
+- Group similar issues together
+- Make recommendations actionable