@caddis/cli 0.4.9 → 0.4.11

package/bundles/antigravity-plugin-extras/skills/raffle-winner-picker/SKILL.md

@@ -1,159 +0,0 @@
----
-name: raffle-winner-picker
-description: Picks random winners from lists, spreadsheets, or Google Sheets for giveaways, raffles, and contests. Ensures fair, unbiased selection with transparency.
----
-
-# Raffle Winner Picker
-
-This skill randomly selects winners from lists, spreadsheets, or Google Sheets for giveaways and contests.
-
-## When to Use This Skill
-
-- Running social media giveaways
-- Picking raffle winners at events
-- Randomly selecting participants for surveys or tests
-- Choosing winners from contest submissions
-- Fair distribution of limited spots or resources
-- Random team assignments
-
-## What This Skill Does
-
-1. **Random Selection**: Uses cryptographically random selection
-2. **Multiple Sources**: Works with CSV, Excel, Google Sheets, or plain lists
-3. **Multiple Winners**: Can pick one or multiple winners
-4. **Duplicate Prevention**: Ensures the same person can't win twice
-5. **Transparent Results**: Shows the selection process clearly
-6. **Winner Details**: Displays all relevant information about winners
-
-## How to Use
-
-### From Google Sheets
-
-```
-Pick a random row from this Google Sheet to select a winner 
-for a giveaway: [Sheet URL]
-```
-
-### From Local File
-
-```
-Pick 3 random winners from entries.csv
-```
-
-### From List
-
-```
-Pick a random winner from this list:
-- Alice (alice@email.com)
-- Bob (bob@email.com)
-- Carol (carol@email.com)
-...
-```
-
-### Multiple Winners
-
-```
-Pick 5 random winners from contest-entries.xlsx, 
-make sure no duplicates
-```
-
-## Example
-
-**User**: "Pick a random row from this Google Sheet to select a winner for a giveaway."
-
-**Output**:
-```
-Accessing Google Sheet...
-Total entries found: 247
-
-Randomly selecting winner...
-
-🎉 WINNER SELECTED! 🎉
-
-Row #142
-Name: Sarah Johnson
-Email: sarah.j@email.com
-Entry Date: March 10, 2024
-Comment: "Love your newsletter!"
-
-Selection method: Cryptographically random
-Timestamp: 2024-03-15 14:32:18 UTC
-
-Would you like to:
-- Pick another winner (excluding Sarah)?
-- Export winner details?
-- Pick runner-ups?
-```
-
-**Inspired by:** Lenny's use case - picking a Sora 2 giveaway winner from his subscriber Slack community
-
-## Features
-
-### Fair Selection
-- Uses secure random number generation
-- No bias or patterns
-- Transparent process
-- Repeatable with seed (for verification)
-
-### Exclusions
-```
-Pick a random winner excluding previous winners: 
-Alice, Bob, Carol
-```
-
-### Weighted Selection
-```
-Pick a winner with weighted probability based on 
-the "entries" column (1 entry = 1 ticket)
-```
-
-### Runner-ups
-```
-Pick 1 winner and 3 runner-ups from the list
-```
-
-## Example Workflows
-
-### Social Media Giveaway
-1. Export entries from Google Form to Sheets
-2. "Pick a random winner from [Sheet URL]"
-3. Verify winner details
-4. Announce publicly with timestamp
-
-### Event Raffle
-1. Create CSV of attendee names and emails
-2. "Pick 10 random winners from attendees.csv"
-3. Export winner list
-4. Email winners directly
-
-### Team Assignment
-1. Have list of participants
-2. "Randomly split this list into 4 equal teams"
-3. Review assignments
-4. Share team rosters
-
-## Tips
-
-- **Document the process**: Save the timestamp and method
-- **Public announcement**: Share selection details for transparency
-- **Check eligibility**: Verify winner meets contest rules
-- **Have backups**: Pick runner-ups in case winner is ineligible
-- **Export results**: Save winner list for records
-
-## Privacy & Fairness
-
-✓ Uses cryptographically secure randomness
-✓ No manipulation possible
-✓ Timestamp recorded for verification
-✓ Can provide seed for third-party verification
-✓ Respects data privacy
-
-## Common Use Cases
-
-- Newsletter subscriber giveaways
-- Product launch raffles
-- Conference ticket drawings
-- Beta tester selection
-- Focus group participant selection
-- Random prize distribution at events
-

package/bundles/antigravity-plugin-extras/skills/relay/SKILL.md

@@ -1,246 +0,0 @@
----
-name: relay
-description: Create or update a root relay.md session-continuation document for any repository. Use this skill whenever the user asks to preserve project context, resume later, hand work to a future session, create a session relay, summarize current implementation state, or generate a reusable continuation prompt. The workflow is generic and must discover project structure at runtime.
----
-
-# Relay Skill
-
-## Purpose
-
-Create or update `relay.md` at the target repository root with enough verified context for a future agent or developer to resume work without re-discovering the project from scratch.
-
-This skill is generic. Do not include project-specific assumptions, fixed folder names, fixed frameworks, or domain-specific terminology unless those facts are discovered in the target repository.
-
-## Core Rules
-
-- Write `relay.md` at the repository root by default.
-- Preserve only verified facts and verified file paths.
-- Do not invent plan names, phases, commands, architecture, owners, or completion state.
-- Do not assume `.github/plans`, `docs`, `src`, `tests`, package managers, branch models, or CI systems exist.
-- If evidence conflicts, describe the conflict and identify the files that disagree.
-- If a fact cannot be verified, mark it as `Unknown` or place it under open questions.
-- Do not commit changes unless the user explicitly asks.
-
-## When To Use
-
-Use this skill when the user asks for:
-
-- `/relay`
-- a session-continuation file
-- a context document for returning later
-- a resume prompt for a future agent
-- a summary of current project state and next steps
-- a clean handover between sessions
-
-## Discovery Workflow
-
-### 1. Establish Repository Root
-
-Identify the target repository root from the current workspace. If there are multiple candidate roots, choose the one containing the active user request or ask a concise clarifying question only if choosing would be risky.
-
-### 2. Gather Verified Signals
-
-Use lightweight scans first:
-
-```bash
-git status --short
-git branch --show-current
-git log --oneline -5
-```
-
-If git is unavailable, note that in `Validation State`.
-
-Read high-signal files only when they exist:
-
-- root overview files such as `README.md`, `CHANGELOG.md`, `STACK.md`, or equivalent
-- package, build, task, or CI configuration files
-- active plan, roadmap, TODO, or issue documents discovered by search
-- architecture or design documents that are referenced by active plans or recent work
-
-Search for likely workstream signals without assuming exact locations:
-
-```bash
-rg -n "TODO|Next Step|Phase|Status|In Progress|Current Plan|Roadmap|Backlog|Validation|Acceptance" .
-```
-
-Keep searches scoped enough to avoid generated folders, dependency folders, build output, and archives unless the archive is directly relevant.
-
-### 3. Infer Current Workstream
-
-Determine the current plan or workstream using evidence in this order:
-
-1. The user's latest instruction.
-2. Current conversation context.
-3. Recent file modifications or git status.
-4. Plan or roadmap files with active status markers.
-5. Recent commits.
-6. Root documentation.
-
-If several candidates remain plausible, list them and state which one appears most likely.
-
-### 4. Identify Validation Commands
-
-Discover validation commands from:
-
-- documented setup or test instructions
-- package scripts
-- make/task files
-- CI workflow files
-- test configuration files
-- commands already run in the current session
-
-Do not claim validation passed unless it was actually run or documented as already passing. If not run, say `Not run in this session`.
-
-## `relay.md` Format
-
-Use this exact filename at the repository root: `relay.md`.
-
-### Metadata Source Rules
-
-- Use full ISO 8601 UTC timestamps for `Creation Date` and `Last Updated`, for example `2026-05-21T13:30:00Z`.
-- Use the exact current model identifier or display name from the chat/runtime model selector or session metadata for `Creating Model` and `Last Model Used`, for example `gpt-5.4`, `gpt-5.3-codex`, or `GPT-5.5`.
-- Do not infer the model from the agent name, product name, or broad family. Generic agent, product, or family labels are not acceptable when the runtime exposes a precise model name.
-- If the runtime does not expose an exact model identifier, record the most precise deterministic runtime identity available and say the exact ID was unavailable, for example `Codex (GPT-5-based; exact runtime model ID unavailable)`.
-
-### New File Frontmatter
-
-When creating a new file:
-
-```yaml
----
-Original Author: <agent/user>
-Creation Date: YYYY-MM-DDTHH:MM:SSZ
-Creating Model: <exact runtime model identifier or display name>
----
-```
-
-### Existing File Frontmatter
-
-When updating an existing file:
-
-1. Preserve the original `Original Author`, `Creation Date`, and `Creating Model` values.
-2. Add or update the last-update fields above the original fields.
-3. Use this order:
-
-```yaml
----
-Last Author: <agent/user>
-Last Updated: YYYY-MM-DDTHH:MM:SSZ
-Last Model Used: <exact runtime model identifier or display name>
-Original Author: <preserved>
-Creation Date: <preserved>
-Creating Model: <preserved>
----
-```
-
-If an original field is missing and cannot be recovered, use `unknown` for that field rather than inventing a value.
-
-### Required Body Sections
-
-Use exactly these top-level headings:
-
-```
-# Relay
-
-## Purpose
-
-## Current Project Context
-
-## What Has Been Completed
-
-## Current Plan Or Workstream
-
-## Next Step
-
-## Important Files To Read First
-
-## Validation State
-
-## Open Questions Or Blockers
-
-## Resume Prompt
-```
-
-## Body Guidance
-
-### Purpose
-
-State that `relay.md` is the current session-continuation document and should be read first when resuming work.
-
-### Current Project Context
-
-Summarize the repository's goal and the current development direction. Cite only verified project facts.
-
-### What Has Been Completed
-
-List completed work visible from plans, documentation, git history, tests, or changed files. Prefer evidence-backed bullets:
-
-```
-- Completed <work> based on `<verified/path.md>`.
-```
-
-### Current Plan Or Workstream
-
-Name the active plan, phase, issue, branch, or workstream. If the plan is unclear, describe the ambiguity and likely candidates.
-
-### Next Step
-
-Provide one exact next action. Include a fallback action if the first next step is blocked.
-
-### Important Files To Read First
-
-List verified paths only:
-
-```
-- `<path>` - why it matters.
-```
-
-Do not list files that were not found.
-
-### Validation State
-
-Include:
-
-- commands discovered
-- commands run in the current session
-- pass/fail/not-run state
-- known failing checks or missing validation
-
-### Open Questions Or Blockers
-
-Capture decisions needed, missing access, conflicting docs, ambiguous plan state, or unverified assumptions.
-
-### Resume Prompt
-
-Provide a ready-to-paste prompt inside a bare fenced code block. The opening fence must be exactly three backticks with no language label.
-
-```
-Read `relay.md` first, then read the important files listed there. Continue from <current workstream>. The next step is <exact action>. Preserve unrelated user changes and run <validation command> when appropriate.
-```
-
-Keep the prompt short, specific, and free of unsupported claims.
-
-## Verification Checklist
-
-Before finishing:
-
-- [ ] `relay.md` exists at the repository root.
-- [ ] Required frontmatter fields are present.
-- [ ] `Creation Date` and `Last Updated` use full ISO 8601 UTC timestamps ending in `Z`.
-- [ ] `Creating Model` and `Last Model Used` use the exact runtime model identifier or display name when available, not only a generic model family.
-- [ ] Original metadata is preserved when updating an existing file.
-- [ ] All required body sections are present.
-- [ ] Every listed file path was verified.
-- [ ] Validation state distinguishes run, not run, pass, and fail.
-- [ ] The resume prompt names the next action and is wrapped in a bare fenced code block with no language label.
-- [ ] No project-specific terminology appears unless discovered in the target repository.
-
-## Final Response
-
-Tell the user:
-
-- where `relay.md` was written
-- the inferred current workstream
-- the next step
-- validation commands found or run
-- any remaining ambiguity

package/bundles/antigravity-plugin-extras/skills/requesting-code-review/SKILL.md

@@ -1,105 +0,0 @@
----
-name: requesting-code-review
-description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
----
-
-# Requesting Code Review
-
-Dispatch superpowers:code-reviewer subagent to catch issues before they cascade.
-
-**Core principle:** Review early, 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
-
-**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 superpowers: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 superpowers:code-reviewer subagent]
-  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
-  PLAN_OR_REQUIREMENTS: Task 2 from .caddis/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/bundles/antigravity-plugin-extras/skills/requesting-code-review/code-reviewer.md

@@ -1,146 +0,0 @@
-# Code Review Agent
-
-You are reviewing code changes for production readiness.
-
-**Your task:**
-1. Review {WHAT_WAS_IMPLEMENTED}
-2. Compare against {PLAN_OR_REQUIREMENTS}
-3. Check code quality, architecture, testing
-4. Categorize issues by severity
-5. Assess production readiness
-
-## What Was Implemented
-
-{DESCRIPTION}
-
-## Requirements/Plan
-
-{PLAN_REFERENCE}
-
-## Git Range to Review
-
-**Base:** {BASE_SHA}
-**Head:** {HEAD_SHA}
-
-```bash
-git diff --stat {BASE_SHA}..{HEAD_SHA}
-git diff {BASE_SHA}..{HEAD_SHA}
-```
-
-## Review Checklist
-
-**Code Quality:**
-- Clean separation of concerns?
-- Proper error handling?
-- Type safety (if applicable)?
-- DRY principle followed?
-- Edge cases handled?
-
-**Architecture:**
-- Sound design decisions?
-- Scalability considerations?
-- Performance implications?
-- Security concerns?
-
-**Testing:**
-- Tests actually test logic (not mocks)?
-- Edge cases covered?
-- Integration tests where needed?
-- All tests passing?
-
-**Requirements:**
-- All plan requirements met?
-- Implementation matches spec?
-- No scope creep?
-- Breaking changes documented?
-
-**Production Readiness:**
-- Migration strategy (if schema changes)?
-- Backward compatibility considered?
-- Documentation complete?
-- No obvious bugs?
-
-## Output Format
-
-### Strengths
-[What's well done? Be specific.]
-
-### Issues
-
-#### Critical (Must Fix)
-[Bugs, security issues, data loss risks, broken functionality]
-
-#### Important (Should Fix)
-[Architecture problems, missing features, poor error handling, test gaps]
-
-#### Minor (Nice to Have)
-[Code style, optimization opportunities, documentation improvements]
-
-**For each issue:**
-- File:line reference
-- What's wrong
-- Why it matters
-- How to fix (if not obvious)
-
-### Recommendations
-[Improvements for code quality, architecture, or process]
-
-### Assessment
-
-**Ready to merge?** [Yes/No/With fixes]
-
-**Reasoning:** [Technical assessment in 1-2 sentences]
-
-## Critical Rules
-
-**DO:**
-- Categorize by actual severity (not everything is Critical)
-- Be specific (file:line, not vague)
-- Explain WHY issues matter
-- Acknowledge strengths
-- Give clear verdict
-
-**DON'T:**
-- Say "looks good" without checking
-- Mark nitpicks as Critical
-- Give feedback on code you didn't review
-- Be vague ("improve error handling")
-- Avoid giving a clear verdict
-
-## Example Output
-
-```
-### Strengths
-- Clean database schema with proper migrations (db.ts:15-42)
-- Comprehensive test coverage (18 tests, all edge cases)
-- Good error handling with fallbacks (summarizer.ts:85-92)
-
-### Issues
-
-#### Important
-1. **Missing help text in CLI wrapper**
-   - File: index-conversations:1-31
-   - Issue: No --help flag, users won't discover --concurrency
-   - Fix: Add --help case with usage examples
-
-2. **Date validation missing**
-   - File: search.ts:25-27
-   - Issue: Invalid dates silently return no results
-   - Fix: Validate ISO format, throw error with example
-
-#### Minor
-1. **Progress indicators**
-   - File: indexer.ts:130
-   - Issue: No "X of Y" counter for long operations
-   - Impact: Users don't know how long to wait
-
-### Recommendations
-- Add progress reporting for user experience
-- Consider config file for excluded projects (portability)
-
-### Assessment
-
-**Ready to merge: With fixes**
-
-**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
-```