@stella-studio/ck 1.0.0

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

@@ -0,0 +1,106 @@
+---
+name: code-review
+description: Review code quality, receive feedback with technical rigor, verify completion claims. Use before PRs, after implementing features, when claiming task completion. Includes scout-based edge case detection.
+---
+
+# Code Review
+
+Guide proper code review practices emphasizing technical rigor, evidence-based claims, and verification over performative responses.
+
+## Core Principle
+
+**YAGNI**, **KISS**, **DRY** always. Technical correctness over social comfort.
+**Be honest, be brutal, straight to the point, and be concise.**
+
+Verify before implementing. Ask before assuming. Evidence before claims.
+
+## Three Practices
+
+| Practice | When | Reference |
+|----------|------|-----------|
+| Receiving feedback | Unclear feedback, external reviewers, needs prioritization | `references/code-review-reception.md` |
+| Requesting review | After tasks, before merge, stuck on problem | `references/requesting-code-review.md` |
+| Verification gates | Before any completion claim, commit, PR | `references/verification-before-completion.md` |
+| **Edge case scouting** | After implementation, before review | `references/edge-case-scouting.md` |
+
+## Quick Decision Tree
+
+```
+SITUATION?
+│
+├─ Received feedback → STOP if unclear, verify if external, implement if human partner
+├─ Completed work → Scout edge cases → Request code-reviewer subagent
+└─ About to claim status → RUN verification command FIRST
+```
+
+## Receiving Feedback
+
+**Pattern:** READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
+
+**Rules:**
+- ❌ No performative agreement: "You're absolutely right!", "Great point!"
+- ❌ No implementation before verification
+- ✅ Restate, ask questions, push back with reasoning, or just work
+- ✅ YAGNI check: grep for usage before implementing "proper" features
+
+**Source handling:**
+- Human partner: Trusted - implement after understanding
+- External reviewers: Verify technically, check breakage, push back if wrong
+
+**Full protocol:** `references/code-review-reception.md`
+
+## Requesting Review
+
+**When:** After each task, major features, before merge
+
+**Process:**
+1. **Scout edge cases first** (see below)
+2. Get SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`
+3. Dispatch code-reviewer subagent with: WHAT, PLAN, BASE_SHA, HEAD_SHA, DESCRIPTION
+4. Fix Critical immediately, Important before proceeding
+
+**Full protocol:** `references/requesting-code-review.md`
+
+## Edge Case Scouting (NEW)
+
+**When:** After implementation, before requesting code-reviewer
+
+**Purpose:** Proactively find edge cases, side effects, and potential issues using scout skill.
+
+**Process:**
+1. Invoke `/scout` with edge-case-focused prompt
+2. Scout analyzes: affected files, data flows, error paths, boundary conditions
+3. Review scout findings for potential issues
+4. Address critical gaps before code review
+
+**Full protocol:** `references/edge-case-scouting.md`
+
+## Verification Gates
+
+**Iron Law:** NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+
+**Gate:** IDENTIFY command → RUN full → READ output → VERIFY confirms → THEN claim
+
+**Requirements:**
+- Tests pass: Output shows 0 failures
+- Build succeeds: Exit 0
+- Bug fixed: Original symptom passes
+- Requirements met: Checklist verified
+
+**Red Flags:** "should"/"probably"/"seems to", satisfaction before verification, trusting agent reports
+
+**Full protocol:** `references/verification-before-completion.md`
+
+## Integration with Workflows
+
+- **Subagent-Driven:** Scout edge cases → Review after EACH task → Verify before next
+- **Pull Requests:** Scout → Verify tests → Code-reviewer review → Merge
+- **General:** Verification gates before any status claims
+
+## Bottom Line
+
+1. Technical rigor over social performance
+2. Scout edge cases before review
+3. Evidence before claims
+
+Verify. Scout. Question. Then implement. Evidence. Then claim.

package/.claude/skills/code-review/references/code-review-reception.md

@@ -0,0 +1,113 @@
+---
+name: receiving-code-review
+description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement
+---
+
+# Code Review Reception
+
+**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
+
+## Response Pattern
+
+```
+1. READ: Complete feedback without reacting
+2. UNDERSTAND: Restate requirement (or ask)
+3. VERIFY: Check against codebase reality
+4. EVALUATE: Technically sound for THIS codebase?
+5. RESPOND: Technical acknowledgment or reasoned pushback
+6. IMPLEMENT: One at a time, test each
+```
+
+## Forbidden Responses
+
+❌ "You're absolutely right!" / "Great point!" / "Thanks for [anything]"
+❌ "Let me implement that now" (before verification)
+
+✅ Restate technical requirement
+✅ Ask clarifying questions
+✅ Push back with technical reasoning
+✅ Just start working (actions > words)
+
+## Handling Unclear Feedback
+
+```
+IF any item unclear:
+  STOP - don't implement anything
+  ASK for clarification on ALL unclear items
+
+WHY: Items may be related. Partial understanding = wrong implementation.
+```
+
+## Source-Specific Handling
+
+**Human partner:** Trusted - implement after understanding, no performative agreement
+
+**External reviewers:**
+```
+BEFORE implementing:
+  1. Technically correct for THIS codebase?
+  2. Breaks existing functionality?
+  3. Reason for current implementation?
+  4. Works all platforms/versions?
+
+IF wrong: Push back with technical reasoning
+IF can't verify: State limitation, ask direction
+IF conflicts with partner's decisions: Stop, discuss first
+```
+
+## YAGNI Check
+
+```
+IF reviewer suggests "implementing properly":
+  grep codebase for actual usage
+  IF unused: "This isn't called. Remove it (YAGNI)?"
+  IF used: Implement properly
+```
+
+## Implementation Order
+
+```
+1. Clarify unclear items FIRST
+2. Implement: blocking → simple → complex
+3. Test each individually
+4. Verify no regressions
+```
+
+## When To Push Back
+
+- Breaks existing functionality
+- Reviewer lacks full context
+- Violates YAGNI (unused feature)
+- Technically incorrect for stack
+- Legacy/compatibility reasons
+- Conflicts with architectural decisions
+
+**How:** Technical reasoning, specific questions, reference working tests
+
+## Acknowledging Correct Feedback
+
+✅ "Fixed. [Brief description]"
+✅ "Good catch - [issue]. Fixed in [location]."
+✅ Just fix it (actions > words)
+
+❌ ANY gratitude or performative expression
+
+## Correcting Wrong Pushback
+
+✅ "You were right - checked [X], it does [Y]. Implementing."
+❌ Long apology, defending, over-explaining
+
+## Quick Reference
+
+| Mistake | Fix |
+|---------|-----|
+| Performative agreement | State requirement or act |
+| Blind implementation | Verify against codebase |
+| Batch without testing | One at a time |
+| Assuming reviewer right | Check if breaks things |
+| Avoiding pushback | Technical correctness > comfort |
+
+## Bottom Line
+
+External feedback = suggestions to evaluate, not orders.
+Verify. Question. Then implement.

package/.claude/skills/code-review/references/edge-case-scouting.md

@@ -0,0 +1,119 @@
+---
+name: edge-case-scouting
+description: Use after implementation, before code review to proactively find edge cases, side effects, and potential issues via scout skill - catches problems code-reviewer might miss
+---
+
+# Edge Case Scouting
+
+Proactive detection of edge cases, side effects, and potential issues before code review.
+
+## Purpose
+
+Code reviews catch obvious issues but miss subtle side effects. Scout detects:
+- Files affected by changes reviewer might not check
+- Data flow paths that could break
+- Boundary conditions and error paths
+- Integration issues across modules
+
+## When to Use
+
+**Mandatory:** Multi-file features, shared utility refactors, complex bug fixes
+**Optional:** Single-file changes, docs, config
+
+## Process
+
+### 1. Identify Changed Files
+```bash
+git diff --name-only HEAD~1
+```
+
+### 2. Invoke Scout
+```
+/scout edge cases for recent changes.
+
+Changed: {files from git diff}
+
+Find:
+1. Files importing/depending on changed modules
+2. Data flow paths through modified functions
+3. Error handling paths not tested
+4. Boundary conditions (null, empty, max)
+5. Race conditions in async code
+6. State management side effects
+```
+
+### 3. Analyze & Act
+
+| Finding | Action |
+|---------|--------|
+| Affected file not in scope | Add to review |
+| Data flow risk | Verify or add test |
+| Edge case | Add test or verify |
+| Missing test | Add before review |
+
+### 4. Document for Review
+```
+Scout findings:
+- {issues found}
+- Verified: {what checked}
+- Addressed: {what fixed}
+- Needs review: {remaining}
+```
+
+## Scout Prompts
+
+**Feature:**
+```
+Scout edge cases for {feature}.
+Changed: {files}
+Find: consumers, error states, untested inputs, performance, compatibility
+```
+
+**Bug fix:**
+```
+Scout side effects of fix in {file}.
+Bug: {description}, Fix: {approach}
+Find: other paths using logic, dependent features, similar bugs
+```
+
+**Refactor:**
+```
+Scout breaking changes in {module}.
+Before: {old}, After: {new}
+Find: importers, behavior diffs, removed functionality
+```
+
+## What Scout Catches
+
+| Issue | Why Missed | Scout Detects |
+|-------|------------|---------------|
+| Indirect deps | Not in diff | Traces imports |
+| Race conditions | Hard static review | Analyzes flow |
+| State mutations | Hidden side effects | Tracks data |
+| Missing null checks | Assumed safe | Boundary analysis |
+| Integration breaks | Out of scope | Cross-module search |
+
+## Red Flags
+
+- Shared utility changed but only one caller tested
+- Error path leads to unhandled rejection
+- State modified in place without notification
+- Breaking change without migration
+
+## Example
+
+```
+1. Done: Add cache to UserService.getUser()
+2. Diff: src/services/user-service.ts
+3. Scout: "edge cases for caching in getUser()"
+4. Report:
+   - ProfileComponent expects fresh data on edit
+   - AdminPanel loops getUser() (memory risk)
+   - No cache clear on updateUser()
+5. Fix: Add invalidation, maxSize
+6. Document for code-reviewer
+```
+
+## Bottom Line
+
+Scout before review. Don't trust "simple changes" - scout them anyway.

package/.claude/skills/code-review/references/requesting-code-review.md

@@ -0,0 +1,116 @@
+---
+name: requesting-code-review
+description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches code-reviewer subagent to review implementation against plan or requirements before proceeding
+---
+
+# Requesting Code Review
+
+Dispatch code-reviewer subagent to catch issues before they cascade.
+
+**Core principle:** Scout first, review often.
+
+## When to Request Review
+
+**Mandatory:**
+- After each task in subagent-driven development
+- After completing major feature
+- Before merge to main
+
+**Optional but valuable:**
+- When stuck (fresh perspective)
+- Before refactoring (baseline check)
+- After fixing complex bug
+
+## How to Request
+
+**0. Scout edge cases first (NEW):**
+```
+Before dispatching code-reviewer, invoke /scout to find:
+- Files affected by changes (not just modified files)
+- Data flow paths that could break
+- Edge cases and boundary conditions
+- Potential side effects
+
+See: references/edge-case-scouting.md
+```
+
+**1. Get git SHAs:**
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Dispatch code-reviewer subagent:**
+
+Use Task tool with `code-reviewer` type, fill template at `code-reviewer.md`
+
+**Placeholders:**
+- `{WHAT_WAS_IMPLEMENTED}` - What you just built
+- `{PLAN_OR_REQUIREMENTS}` - What it should do
+- `{BASE_SHA}` - Starting commit
+- `{HEAD_SHA}` - Ending commit
+- `{DESCRIPTION}` - Brief summary
+
+**3. Act on feedback:**
+- Fix Critical issues immediately
+- Fix Important issues before proceeding
+- Note Minor issues for later
+- Push back if reviewer is wrong (with reasoning)
+
+## Example
+
+```
+[Just completed Task 2: Add verification function]
+
+You: Let me request code review before proceeding.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Dispatch code-reviewer subagent]
+  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
+  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+
+[Subagent returns]:
+  Strengths: Clean architecture, real tests
+  Issues:
+    Important: Missing progress indicators
+    Minor: Magic number (100) for reporting interval
+  Assessment: Ready to proceed
+
+You: [Fix progress indicators]
+[Continue to Task 3]
+```
+
+## Integration with Workflows
+
+**Subagent-Driven Development:**
+- Review after EACH task
+- Catch issues before they compound
+- Fix before moving to next task
+
+**Executing Plans:**
+- Review after each batch (3 tasks)
+- Get feedback, apply, continue
+
+**Ad-Hoc Development:**
+- Review before merge
+- Review when stuck
+
+## Red Flags
+
+**Never:**
+- Skip review because "it's simple"
+- Ignore Critical issues
+- Proceed with unfixed Important issues
+- Argue with valid technical feedback
+
+**If reviewer wrong:**
+- Push back with technical reasoning
+- Show code/tests that prove it works
+- Request clarification
+
+See template at: requesting-code-review/code-reviewer.md

package/.claude/skills/code-review/references/verification-before-completion.md

@@ -0,0 +1,139 @@
+---
+name: verification-before-completion
+description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
+---
+
+# Verification Before Completion
+
+## Overview
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating the spirit of this rule.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified | Test passes once |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+
+## Red Flags - STOP
+
+- Using "should", "probably", "seems to"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- Thinking "just this once"
+- Tired and wanting work over
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## Why This Matters
+
+From 24 failure memories:
+- your human partner said "I don't believe you" - trust broken
+- Undefined functions shipped - would crash
+- Missing requirements shipped - incomplete features
+- Time wasted on false completion → redirect → rework
+- Violates: "Honesty is a core value. If you lie, you'll be replaced."
+
+## When To Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+**Rule applies to:**
+- Exact phrases
+- Paraphrases and synonyms
+- Implications of success
+- ANY communication suggesting completion/correctness
+
+## The Bottom Line
+
+**No shortcuts for verification.**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.

package/.claude/skills/common/README.md

@@ -0,0 +1,120 @@
+# Common Skill Utilities
+
+This directory contains shared utilities used across multiple skills.
+
+## API Key Helper
+
+`api_key_helper.py` provides standardized configuration for all Gemini-based skills, supporting both Google AI Studio and Vertex AI endpoints.
+
+### Usage in Skills
+
+```python
+import sys
+from pathlib import Path
+
+# Add common directory to path
+common_dir = Path(__file__).parent.parent.parent / 'common'
+sys.path.insert(0, str(common_dir))
+
+from api_key_helper import get_api_key_or_exit
+
+# Get API key with automatic error handling
+api_key = get_api_key_or_exit()
+```
+
+### API Key Lookup Order
+
+The helper checks for `GEMINI_API_KEY` in this order:
+
+1. **Process environment variable** (recommended for development)
+   ```bash
+   export GEMINI_API_KEY='your-api-key'
+   ```
+
+2. **Project root `.env` file**
+   ```bash
+   echo 'GEMINI_API_KEY=your-api-key' > .env
+   ```
+
+3. **.claude/.env file**
+   ```bash
+   echo 'GEMINI_API_KEY=your-api-key' > .claude/.env
+   ```
+
+4. **.claude/skills/.env file** (shared across all Gemini skills)
+   ```bash
+   echo 'GEMINI_API_KEY=your-api-key' > .claude/skills/.env
+   ```
+
+5. **Skill directory `.env` file**
+   ```bash
+   echo 'GEMINI_API_KEY=your-api-key' > .claude/skills/your-skill/.env
+   ```
+
+### Vertex AI Support
+
+To use Vertex AI instead of Google AI Studio:
+
+```bash
+# Enable Vertex AI
+export GEMINI_USE_VERTEX=true
+export VERTEX_PROJECT_ID=your-gcp-project-id
+export VERTEX_LOCATION=us-central1  # Optional, defaults to us-central1
+```
+
+Or in `.env` file:
+```
+GEMINI_USE_VERTEX=true
+VERTEX_PROJECT_ID=your-gcp-project-id
+VERTEX_LOCATION=us-central1
+```
+
+### Using get_client() Helper
+
+For automatic client selection (AI Studio or Vertex AI):
+
+```python
+from api_key_helper import get_client
+
+# Get appropriate client based on configuration
+client_info = get_client()
+
+if client_info['type'] == 'vertex':
+    # Using Vertex AI
+    from vertexai.generative_models import GenerativeModel
+    model = GenerativeModel('gemini-2.5-flash')
+    response = model.generate_content("Hello")
+else:
+    # Using AI Studio
+    client = client_info['client']
+    response = client.models.generate_content(
+        model='gemini-2.5-flash',
+        contents="Hello"
+    )
+```
+
+### Using get_vertex_config() Helper
+
+For checking Vertex AI configuration:
+
+```python
+from api_key_helper import get_vertex_config
+
+vertex_config = get_vertex_config()
+if vertex_config['use_vertex']:
+    print(f"Using Vertex AI")
+    print(f"Project: {vertex_config['project_id']}")
+    print(f"Location: {vertex_config['location']}")
+```
+
+### Error Handling
+
+If the API key is not found, the helper will:
+- Print a clear error message
+- Show all available methods to set the API key
+- Provide the URL to obtain an API key
+- Exit with status code 1
+
+For Vertex AI, if `VERTEX_PROJECT_ID` is missing when `GEMINI_USE_VERTEX=true`, the helper will provide clear instructions.
+
+This ensures users get immediate, actionable feedback when configuration is missing.