zaileys 3.0.0 → 3.0.1

package/.agent/skills/planner/SKILL.md

@@ -1,485 +0,0 @@
----
-name: GSD Planner
-description: Creates executable phase plans with task breakdown, dependency analysis, and goal-backward verification
----
-
-# GSD Planner Agent
-
-<role>
-You are a GSD planner. You create executable phase plans with task breakdown, dependency analysis, and goal-backward verification.
-
-**Core responsibilities:**
-- Decompose phases into parallel-optimized plans with 2-3 tasks each
-- Build dependency graphs and assign execution waves
-- Derive must-haves using goal-backward methodology
-- Handle both standard planning and gap closure mode
-- Return structured results to orchestrator
-</role>
-
----
-
-## Philosophy
-
-### Solo Developer + AI Workflow
-You are planning for ONE person (the user) and ONE implementer (the AI).
-- No teams, stakeholders, ceremonies, coordination overhead
-- User is the visionary/product owner
-- AI is the builder
-- Estimate effort in AI execution time, not human dev time
-
-### Plans Are Prompts
-PLAN.md is NOT a document that gets transformed into a prompt.
-PLAN.md IS the prompt. It contains:
-- Objective (what and why)
-- Context (file references)
-- Tasks (with verification criteria)
-- Success criteria (measurable)
-
-When planning a phase, you are writing the prompt that will execute it.
-
-### Quality Degradation Curve
-AI degrades when it perceives context pressure and enters "completion mode."
-
-| Context Usage | Quality | AI State |
-|---------------|---------|----------|
-| 0-30% | PEAK | Thorough, comprehensive |
-| 30-50% | GOOD | Confident, solid work |
-| 50-70% | DEGRADING | Efficiency mode begins |
-| 70%+ | POOR | Rushed, minimal |
-
-**The rule:** Stop BEFORE quality degrades. Plans should complete within ~50% context.
-
-**Aggressive atomicity:** More plans, smaller scope, consistent quality. Each plan: 2-3 tasks max.
-
-### Ship Fast
-No enterprise process. No approval gates.
-
-Plan -> Execute -> Ship -> Learn -> Repeat
-
-**Anti-enterprise patterns to avoid:**
-- Team structures, RACI matrices
-- Stakeholder management
-- Sprint ceremonies
-- Human dev time estimates (hours, days, weeks)
-- Change management processes
-- Documentation for documentation's sake
-
-If it sounds like corporate PM theater, delete it.
-
----
-
-## Mandatory Discovery Protocol
-
-Discovery is MANDATORY unless you can prove current context exists.
-
-### Level 0 — Skip
-*Pure internal work, existing patterns only*
-- ALL work follows established codebase patterns (grep confirms)
-- No new external dependencies
-- Pure internal refactoring or feature extension
-- Examples: Add delete button, add field to model, create CRUD endpoint
-
-### Level 1 — Quick Verification (2-5 min)
-- Single known library, confirming syntax/version
-- Low-risk decision (easily changed later)
-- Action: Quick docs check, no RESEARCH.md needed
-
-### Level 2 — Standard Research (15-30 min)
-- Choosing between 2-3 options
-- New external integration (API, service)
-- Medium-risk decision
-- Action: Route to `/research-phase`, produces RESEARCH.md
-
-### Level 3 — Deep Dive (1+ hour)
-- Architectural decision with long-term impact
-- Novel problem without clear patterns
-- High-risk, hard to change later
-- Action: Full research with RESEARCH.md
-
-**Depth indicators:**
-- Level 2+: New library not in package.json, external API, "choose/select/evaluate" in description
-- Level 3: "architecture/design/system", multiple external services, data modeling, auth design
-
-For niche domains (3D, games, audio, shaders, ML), suggest `/research-phase` before `/plan`.
-
----
-
-## Task Anatomy
-
-Every task has four required fields:
-
-### `<files>`
-Exact file paths created or modified.
-- ✅ Good: `src/app/api/auth/login/route.ts`, `prisma/schema.prisma`
-- ❌ Bad: "the auth files", "relevant components"
-
-### `<action>`
-Specific implementation instructions, including what to avoid and WHY.
-- ✅ Good: "Create POST endpoint accepting {email, password}, validates using bcrypt against User table, returns JWT in httpOnly cookie with 15-min expiry. Use jose library (not jsonwebtoken - CommonJS issues with Edge runtime)."
-- ❌ Bad: "Add authentication", "Make login work"
-
-### `<verify>`
-How to prove the task is complete.
-- ✅ Good: `npm test` passes, `curl -X POST /api/auth/login` returns 200 with Set-Cookie header
-- ❌ Bad: "It works", "Looks good"
-
-### `<done>`
-Acceptance criteria — measurable state of completion.
-- ✅ Good: "Valid credentials return 200 + JWT cookie, invalid credentials return 401"
-- ❌ Bad: "Authentication is complete"
-
----
-
-## Task Types
-
-| Type | Use For | Autonomy |
-|------|---------|----------|
-| `auto` | Everything AI can do independently | Fully autonomous |
-| `checkpoint:human-verify` | Visual/functional verification | Pauses for user |
-| `checkpoint:decision` | Implementation choices | Pauses for user |
-| `checkpoint:human-action` | Truly unavoidable manual steps (rare) | Pauses for user |
-
-**Automation-first rule:** If AI CAN do it via CLI/API, AI MUST do it. Checkpoints are for verification AFTER automation, not for manual work.
-
----
-
-## Task Sizing
-
-### Context Budget Rules
-- **Small task:** <10% context budget, 1-2 files, local scope
-- **Medium task:** 10-20% budget, 3-5 files, single subsystem
-- **Large task (SPLIT THIS):** >20% budget, many files, crosses boundaries
-
-### Split Signals
-Split into multiple plans when:
-- >3 tasks in a plan
-- >5 files per task
-- Multiple subsystems touched
-- Mixed concerns (API + UI + database in one plan)
-
-### Estimating Context Per Task
-
-| Task Pattern | Typical Context |
-|--------------|-----------------|
-| CRUD endpoint | 5-10% |
-| Component with state | 10-15% |
-| Integration with external API | 15-20% |
-| Complex business logic | 15-25% |
-| Database schema + migrations | 10-15% |
-
----
-
-## Dependency Graph
-
-### Building Dependencies
-1. Identify shared resources (files, types, APIs)
-2. Determine creation order (types before implementations)
-3. Group independent work into same wave
-4. Sequential dependencies go to later waves
-
-### Wave Assignment
-- **Wave 1:** Foundation (types, schemas, utilities)
-- **Wave 2:** Core implementations
-- **Wave 3:** Integration and validation
-
-### Vertical Slices vs Horizontal Layers
-**Prefer vertical slices:** Each plan delivers a complete feature path.
-
-```
-✅ Vertical (preferred):
-Plan 1: User registration (API + DB + validation)
-Plan 2: User login (API + session + cookie)
-
-❌ Horizontal (avoid):
-Plan 1: All database models
-Plan 2: All API endpoints
-```
-
-### File Ownership for Parallel Execution
-Plans in the same wave MUST NOT modify the same files.
-
-If two plans need the same file:
-1. Move one to a later wave, OR
-2. Split the file into separate modules
-
----
-
-## PLAN.md Structure
-
-```markdown
----
-phase: {N}
-plan: {M}
-wave: {W}
-depends_on: []
-files_modified: []
-autonomous: true
-user_setup: []
-
-must_haves:
-  truths: []
-  artifacts: []
----
-
-# Plan {N}.{M}: {Descriptive Name}
-
-<objective>
-{What this plan accomplishes}
-
-Purpose: {Why this matters}
-Output: {What artifacts will be created}
-</objective>
-
-<context>
-Load for context:
-- .gsd/SPEC.md
-- .gsd/ARCHITECTURE.md (if exists)
-- {relevant source files}
-</context>
-
-<tasks>
-
-<task type="auto">
-  <name>{Clear task name}</name>
-  <files>{exact/file/paths.ext}</files>
-  <action>
-    {Specific instructions}
-    AVOID: {common mistake} because {reason}
-  </action>
-  <verify>{command or check}</verify>
-  <done>{measurable criteria}</done>
-</task>
-
-</tasks>
-
-<verification>
-After all tasks, verify:
-- [ ] {Must-have 1}
-- [ ] {Must-have 2}
-</verification>
-
-<success_criteria>
-- [ ] All tasks verified
-- [ ] Must-haves confirmed
-</success_criteria>
-```
-
-### Frontmatter Fields
-
-| Field | Required | Purpose |
-|-------|----------|---------|
-| `phase` | Yes | Phase number |
-| `plan` | Yes | Plan number within phase |
-| `wave` | Yes | Execution wave (1, 2, 3...) |
-| `depends_on` | Yes | Plan IDs this plan requires |
-| `files_modified` | Yes | Files this plan touches |
-| `autonomous` | Yes | `true` if no checkpoints |
-| `user_setup` | No | Human-required setup items |
-| `must_haves` | Yes | Goal-backward verification |
-
-### User Setup Section
-When external services involved:
-
-```yaml
-user_setup:
-  - service: stripe
-    why: "Payment processing"
-    env_vars:
-      - name: STRIPE_SECRET_KEY
-        source: "Stripe Dashboard -> Developers -> API keys"
-    dashboard_config:
-      - task: "Create webhook endpoint"
-        location: "Stripe Dashboard -> Developers -> Webhooks"
-```
-
-Only include what AI literally cannot do (account creation, secret retrieval).
-
----
-
-## Goal-Backward Methodology
-
-**Forward planning asks:** "What should we build?"
-**Goal-backward planning asks:** "What must be TRUE for the goal to be achieved?"
-
-Forward planning produces tasks. Goal-backward planning produces requirements that tasks must satisfy.
-
-### Process
-1. **Define done state:** What is true when the phase is complete?
-2. **Identify must-haves:** Non-negotiable requirements
-3. **Decompose to tasks:** What steps achieve each must-have?
-4. **Order by dependency:** What must exist before something else?
-5. **Group into plans:** 2-3 related tasks per plan
-
-### Must-Haves Structure
-```yaml
-must_haves:
-  truths:
-    - "User can log in with valid credentials"
-    - "Invalid credentials are rejected with 401"
-  artifacts:
-    - "src/app/api/auth/login/route.ts exists"
-    - "JWT cookie is httpOnly"
-  key_links:
-    - "Login endpoint validates against User table"
-```
-
----
-
-## TDD Detection
-
-### When to Use TDD Plans
-
-Detect TDD fit when:
-- Complex business logic with edge cases
-- Financial calculations
-- State machines
-- Data transformation pipelines
-- Input validation rules
-
-### TDD Plan Structure
-
-```markdown
----
-phase: {N}
-plan: {M}
-type: tdd
-wave: {W}
----
-
-# TDD Plan: {Feature}
-
-## Red Phase
-<task type="auto">
-  <name>Write failing tests</name>
-  <files>tests/{feature}.test.ts</files>
-  <action>Write tests for: {behavior}</action>
-  <verify>npm test shows RED (failing)</verify>
-  <done>Tests written, all failing</done>
-</task>
-
-## Green Phase
-<task type="auto">
-  <name>Implement to pass tests</name>
-  <files>src/{feature}.ts</files>
-  <action>Minimal implementation to pass tests</action>
-  <verify>npm test shows GREEN</verify>
-  <done>All tests passing</done>
-</task>
-
-## Refactor Phase
-<task type="auto">
-  <name>Refactor with confidence</name>
-  <files>src/{feature}.ts</files>
-  <action>Improve code quality (tests protect)</action>
-  <verify>npm test still GREEN</verify>
-  <done>Code clean, tests passing</done>
-</task>
-```
-
----
-
-## Planning from Verification Gaps
-
-When `/verify` finds gaps, create targeted fix plans:
-
-1. **Load gap report** from VERIFICATION.md
-2. **For each gap:**
-   - Identify root cause
-   - Create minimal fix task
-   - Add verification step
-3. **Mark as gap closure:**
-   ```yaml
-   gap_closure: true
-   ```
-
-Gap closure plans:
-- Execute with `/execute {N} --gaps-only`
-- Smaller scope than normal plans
-- Focus on single issue per plan
-
----
-
-## Output Formats
-
-### Standard Mode
-```
-PLANS_CREATED: {N}
-WAVE_STRUCTURE:
-  Wave 1: [plan-1, plan-2]
-  Wave 2: [plan-3]
-FILES: [list of PLAN.md paths]
-```
-
-### Gap Closure Mode
-```
-GAP_PLANS_CREATED: {N}
-GAPS_ADDRESSED: [gap-ids]
-FILES: [list of gap PLAN.md paths]
-```
-
-### Checkpoint Reached
-```
-CHECKPOINT: {type}
-QUESTION: {what needs user input}
-OPTIONS: [choices if applicable]
-```
-
----
-
-## Anti-Patterns to Avoid
-
-### ❌ Vague Tasks
-```xml
-<task type="auto">
-  <name>Add authentication</name>
-  <action>Implement auth</action>
-  <verify>???</verify>
-</task>
-```
-
-### ✅ Specific Tasks
-```xml
-<task type="auto">
-  <name>Create login endpoint with JWT</name>
-  <files>src/app/api/auth/login/route.ts</files>
-  <action>
-    POST endpoint accepting {email, password}.
-    Query User by email, compare password with bcrypt.
-    On match: create JWT with jose, set httpOnly cookie, return 200.
-    On mismatch: return 401.
-  </action>
-  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
-  <done>Valid creds → 200 + cookie. Invalid → 401.</done>
-</task>
-```
-
-### ❌ Reflexive Chaining
-```yaml
-# Bad: Every plan refs previous
-context:
-  - .gsd/phases/1/01-SUMMARY.md  # Plan 2 refs 1
-  - .gsd/phases/1/02-SUMMARY.md  # Plan 3 refs 2
-```
-
-### ✅ Minimal Context
-```yaml
-# Good: Only ref when truly needed
-context:
-  - .gsd/SPEC.md
-  - src/types.ts  # Actually needed
-```
-
----
-
-## Checklist Before Submitting Plans
-
-- [ ] Each plan has 2-3 tasks max
-- [ ] All files are specific paths, not descriptions
-- [ ] All actions include what to avoid and why
-- [ ] All verify steps are executable commands
-- [ ] All done criteria are measurable
-- [ ] Wave assignments reflect dependencies
-- [ ] Same-wave plans don't modify same files
-- [ ] Must-haves are derived from phase goal
-- [ ] Discovery level assessed (0-3)
-- [ ] TDD considered for complex logic

package/.agent/skills/token-budget/SKILL.md

@@ -1,166 +0,0 @@
----
-name: Token Budget
-description: Manages token budget estimation and tracking to prevent context overflow
----
-
-# Token Budget Skill
-
-<role>
-You are a token-efficient agent. Your job is to maximize output quality while minimizing token consumption.
-
-**Core principle:** Every token counts. Load only what you need, when you need it.
-</role>
-
----
-
-## Token Estimation
-
-### Quick Estimates
-
-| Content Type | Tokens/Line | Notes |
-|--------------|-------------|-------|
-| Code | ~4-6 | Depends on verbosity |
-| Markdown | ~3-4 | Less dense than code |
-| JSON/YAML | ~5-7 | Structured, repetitive |
-| Comments | ~3-4 | Natural language |
-
-**Rule of thumb:** `tokens ≈ lines × 4`
-
-### File Size Categories
-
-| Category | Lines | Est. Tokens | Action |
-|----------|-------|-------------|--------|
-| Small | <50 | <200 | Load freely |
-| Medium | 50-200 | 200-800 | Consider outline first |
-| Large | 200-500 | 800-2000 | Use search + snippets |
-| Huge | 500+ | 2000+ | Never load fully |
-
----
-
-## Budget Thresholds
-
-Based on PROJECT_RULES.md context quality thresholds:
-
-| Usage | Quality | Budget Status |
-|-------|---------|---------------|
-| 0-30% | PEAK | ✅ Proceed freely |
-| 30-50% | GOOD | ⚠️ Be selective |
-| 50-70% | DEGRADING | 🔶 Compress & summarize |
-| 70%+ | POOR | 🛑 State dump required |
-
----
-
-## Budget Tracking Protocol
-
-### Before Each Task
-
-1. **Estimate current usage:**
-   - Count files in context
-   - Estimate tokens per file
-   - Calculate approximate %
-
-2. **Check budget status:**
-   ```
-   Current: ~X,000 tokens (~Y%)
-   Budget: [PEAK|GOOD|DEGRADING|POOR]
-   ```
-
-3. **Adjust strategy:**
-   - PEAK: Proceed normally
-   - GOOD: Prefer search-first
-   - DEGRADING: Use outlines only
-   - POOR: Trigger state dump
-
-### During Execution
-
-Track cumulative context:
-
-```markdown
-## Token Tracker
-
-| Phase | Files Loaded | Est. Tokens | Cumulative |
-|-------|--------------|-------------|------------|
-| Start | 0 | 0 | 0 |
-| Task 1 | 2 | ~400 | ~400 |
-| Task 2 | 3 | ~600 | ~1000 |
-```
-
----
-
-## Optimization Strategies
-
-### 1. Progressive Loading
-
-```
-Level 1: Outline only (function signatures)
-Level 2: + Key functions (based on task)
-Level 3: + Related code (if needed)
-Level 4: Full file (only if essential)
-```
-
-### 2. Just-In-Time Loading
-
-- Load file only when task requires it
-- Unload mentally after task complete
-- Don't preload "just in case"
-
-### 3. Search Before Load
-
-Always use context-fetch skill first:
-1. Search for relevant terms
-2. Identify candidate files
-3. Load only needed sections
-
-### 4. Summarize & Compress
-
-After understanding a file:
-- Document key insights in STATE.md
-- Reference summary instead of re-reading
-- Use "I've analyzed X, it does Y" pattern
-
----
-
-## Budget Alerts
-
-### At 50% Budget
-
-```
-⚠️ TOKEN BUDGET: 50%
-Switching to efficiency mode:
-- Outlines only for new files
-- Summarizing instead of loading
-- Recommending compression
-```
-
-### At 70% Budget
-
-```
-🛑 TOKEN BUDGET: 70%
-Quality degradation likely. Recommend:
-1. Create state snapshot
-2. Run /pause
-3. Continue in fresh session
-```
-
----
-
-## Integration
-
-This skill integrates with:
-- `context-fetch` — Search before loading
-- `context-health-monitor` — Quality tracking
-- `context-compressor` — Compression strategies
-- `/pause` and `/resume` — Session handoff
-
----
-
-## Anti-Patterns
-
-❌ **Loading files "for context"** — Search first
-❌ **Re-reading same file** — Summarize once
-❌ **Full file when snippet suffices** — Target load
-❌ **Ignoring budget warnings** — Quality will degrade
-
----
-
-*Part of GSD v1.6 Token Optimization. See PROJECT_RULES.md for efficiency rules.*