@softspark/ai-toolkit 3.5.0 → 4.0.0

package/app/skills/hive-mind/SKILL.md

@@ -1,57 +0,0 @@
----
-name: hive-mind
-description: "Multi-agent swarm: consensus voting, output aggregation, file ownership, map-reduce. Triggers: swarm, hive mind, multi-agent, consensus, parallel agents, team of agents, agent voting."
-effort: medium
-user-invocable: false
-allowed-tools: Read
----
-
-# Hive Mind Skill
-
-You are part of a Swarm. You are not alone.
-
-## 🔴 Swarm Protocols
-
-### 1. Consensus (The Vote)
-When agents disagree:
-1. Each agent generates a solution + confidence score.
-2. **Weighted Voting**: Higher confidence = Higher weight.
-3. **Majority Rule**: >50% wins.
-
-### 2. Aggregation (The Merge)
-When multiple agents produce outputs:
-1. **Format Standardization**: Ensure all JSON/Markdown matches.
-2. **De-duplication**: Remove identical findings.
-3. **Synthesis**: Combine unique insights into one report.
-
-### 3. File Ownership (Agent Teams Mode)
-
-**With Agent Teams enabled**: File conflicts are prevented by **file ownership assignment** at spawn time. Each teammate gets distinct files/directories. No locking needed.
-
-- Lead assigns ownership when creating the team
-- Teammates respect boundaries in their prompts
-- Quality hooks verify completeness on `TaskCompleted`
-
-**Without Agent Teams** (fallback):
-1. Before editing a file: Check if another agent is editing.
-2. Use `touch .lock.{filename}`.
-3. Remove lock after edit.
-
-### 4. Communication (Agent Teams Mode)
-
-- **message**: Send to ONE specific teammate (targeted, low cost)
-- **broadcast**: Send to ALL teammates (use sparingly — costs N×)
-- **Shared task list**: `~/.claude/tasks/{team-name}/` — all agents can see/claim
-
-## Example Workflow (Map-Reduce)
-
-### With Agent Teams
-1. **Map**: Lead spawns 5 teammates, each scanning 20 files
-2. **Parallel**: All teammates execute simultaneously in tmux panes
-3. **Reduce**: Lead waits, collects results, applies Aggregation protocol
-4. **Report**: `final_report.md` synthesized from all findings
-
-### Without Agent Teams (Fallback)
-1. **Map**: "Scan 100 files for leaks." → 10 Agents × 10 Files.
-2. **Reduce**: Agents output `leaks_{i}.json`.
-3. **Hive Mind**: Merge all `leaks_*.json` → `final_report.json`.

package/app/skills/plan-writing/SKILL.md

@@ -1,228 +0,0 @@
----
-name: plan-writing
-description: "Implementation plans + pre-mortems: phases, success criteria, risks, rollback, acceptance tests. Triggers: implementation plan, pre-mortem, phased plan, task breakdown, risk register."
-effort: medium
-user-invocable: false
-allowed-tools: Read
----
-
-# Plan Writing Skill
-
-## Plan Structure
-
-### Basic Plan Template
-
-```markdown
-# [Project Name] - Implementation Plan
-
-## Overview
-- **Type**: [Project type]
-- **Stack**: [Tech choices]
-- **Complexity**: [Low/Medium/High]
-- **Estimated Effort**: [Days/Weeks]
-
-## Goals
-1. [Primary goal]
-2. [Secondary goal]
-
-## Requirements
-
-### Functional
-| ID | Requirement | Priority |
-|----|-------------|----------|
-| FR1 | [Requirement] | Must |
-| FR2 | [Requirement] | Should |
-
-### Non-Functional
-| ID | Requirement | Metric |
-|----|-------------|--------|
-| NFR1 | Performance | < 2s load |
-| NFR2 | Security | OWASP compliant |
-
-## Task Breakdown
-
-### Phase 1: Foundation
-- [ ] Task 1.1
-- [ ] Task 1.2
-
-### Phase 2: Core
-- [ ] Task 2.1
-- [ ] Task 2.2
-
-### Phase 3: Polish
-- [ ] Task 3.1
-- [ ] Task 3.2
-
-## Dependencies
-
-```mermaid
-graph TD
-    A[Database Schema] --> B[API Endpoints]
-    B --> C[UI Components]
-    C --> D[Tests]
-    D --> E[Deployment]
-```
-
-## Agent Assignment
-
-| Task | Agent | Dependencies |
-|------|-------|--------------|
-| Schema | database-architect | None |
-| API | backend-specialist | Schema |
-| UI | frontend-specialist | API |
-| Tests | test-engineer | UI |
-
-## Success Criteria
-- [ ] All tests passing
-- [ ] Performance targets met
-- [ ] Security review complete
-
-## Risks
-| Risk | Probability | Impact | Mitigation |
-|------|-------------|--------|------------|
-| [Risk] | High/Med/Low | High/Med/Low | [Plan] |
-```
-
----
-
-## Task Breakdown Principles
-
-### SMART Tasks
-- **S**pecific: Clear deliverable
-- **M**easurable: Done/not done
-- **A**ssignable: One owner
-- **R**ealistic: Achievable
-- **T**ime-bound: Estimated duration
-
-### Good vs Bad Tasks
-
-| ❌ Bad | ✅ Good |
-|--------|--------|
-| "Implement authentication" | "Create login API endpoint with JWT" |
-| "Build UI" | "Create user dashboard component" |
-| "Fix bugs" | "Fix login redirect on mobile" |
-| "Optimize" | "Reduce API response time to <200ms" |
-
----
-
-## Dependency Management
-
-### Dependency Types
-
-| Type | Example |
-|------|---------|
-| **Hard** | API must exist before UI can call it |
-| **Soft** | Tests can start when 50% features done |
-| **External** | Waiting for third-party API access |
-
-### Identifying Dependencies
-
-```
-For each task, ask:
-1. What must exist before this can start?
-2. What does this task produce?
-3. Who/what consumes that output?
-```
-
----
-
-## Estimation Patterns
-
-### T-Shirt Sizing
-
-| Size | Effort | Example |
-|------|--------|---------|
-| XS | <2 hours | Fix typo, add field |
-| S | 2-4 hours | Simple component, basic API |
-| M | 1-2 days | Feature with tests |
-| L | 3-5 days | Complex feature |
-| XL | 1-2 weeks | Major subsystem |
-
-### Cone of Uncertainty
-
-| Phase | Accuracy |
-|-------|----------|
-| Initial idea | 4x variance |
-| After discovery | 2x variance |
-| After design | 1.5x variance |
-| After development | 1.1x variance |
-
----
-
-## Phase Templates
-
-### MVP Launch
-
-```
-Phase 1: Core (Week 1-2)
-- Database schema
-- Authentication
-- Core feature 1
-
-Phase 2: Essential (Week 3-4)
-- Core feature 2
-- Basic UI
-- Critical integrations
-
-Phase 3: Launch (Week 5)
-- Testing
-- Deployment
-- Documentation
-```
-
-### Feature Addition
-
-```
-Phase 1: Preparation
-- Research existing code
-- Define acceptance criteria
-- Design solution
-
-Phase 2: Implementation
-- Backend changes
-- Frontend changes
-- Integration
-
-Phase 3: Validation
-- Testing
-- Code review
-- Deploy to staging
-```
-
----
-
-## Review Checklist
-
-Before finalizing plan:
-- [ ] All requirements captured
-- [ ] Tasks are SMART
-- [ ] Dependencies identified
-- [ ] Agents assigned
-- [ ] Risks documented
-- [ ] Success criteria defined
-
-## Rules
-
-- **MUST** include a Success Criteria section with measurable, verifiable conditions — subjective criteria are not criteria
-- **MUST** include a Rollback Plan for any work that touches production data or shared infrastructure
-- **MUST** write a Pre-Mortem when estimated effort exceeds 1 day — "what could go wrong" surfaces real risks cheaply
-- **NEVER** estimate in hours for work longer than a week. Use T-shirt sizes (S/M/L/XL) or tracer-bullet slices — precise long-horizon estimates are false confidence
-- **CRITICAL**: every risk has an owner AND a mitigation. A risk register with named risks but no mitigations is decorative.
-- **MANDATORY**: explicit scope boundaries — "not in this plan" is as important as "in this plan"
-
-## Gotchas
-
-- SMART criteria look complete but often omit the "relevant" dimension — a task can be Specific, Measurable, Achievable, Time-bound and still irrelevant to the outcome. Check relevance explicitly.
-- Pre-mortems feel pessimistic and get shortened under deadline pressure. Make the pre-mortem a first-class section with at least 5 named failure modes — a 2-bullet pre-mortem is theater.
-- Risk registers bloat when stakeholders add low-probability items to be safe. Cap the register at 10 risks ranked by (probability × impact); everything below line 10 is noise.
-- Plans authored by the person who will execute them are biased toward feasibility (they want to do it). Plans authored by someone who won't execute are biased toward ambition (they don't pay the cost). Mix both perspectives.
-- "Success criteria: deploy to production" is the weakest criterion — it measures effort, not outcome. Replace with user-facing or metric-based criteria ("20% reduction in p95 latency sustained for 7 days").
-
-## When NOT to Use
-
-- For **actually generating** a plan with phases and task breakdown — use `/plan`
-- For requirements capture before planning — use `/write-a-prd`
-- For turning a plan into filed issues — use `/prd-to-issues`
-- For stress-testing a plan's assumptions — use `/grill-me`
-- For executing plans with agents — use `/orchestrate` or `/workflow`
-- For a single-step fix that does not warrant a document — skip the plan entirely

package/app/skills/search/SKILL.md

@@ -1,64 +0,0 @@
----
-name: search
-description: "Searches the KB with semantic + hybrid modes. Triggers: search KB, semantic search, hybrid search, knowledge base query."
-user-invocable: true
-effort: medium
-argument-hint: "[query]"
-allowed-tools: Read, Grep, Glob
----
-
-# Knowledge Base Search
-
-$ARGUMENTS
-
-## Search Methods
-
-### Method 1: MCP Tools (requires rag-mcp MCP server)
-
-If the `rag-mcp` MCP server is configured, use these tools:
-
-| Tool | Best For | Speed |
-|------|----------|-------|
-| `smart_query` | Default (90% of queries), auto-routing | 2-4s |
-| `hybrid_search_kb` | Raw vector + text search | <1s |
-| `get_document` | Full document content | <1s |
-| `crag_search` | Vague queries (Corrective RAG) | 1-3s |
-| `multi_hop_search` | Complex multi-step reasoning | 20-30s |
-
-```python
-# Primary search
-smart_query("your search query", limit=10)
-
-# Full document retrieval
-get_document(path="kb/reference/architecture.md")
-```
-
-### Method 2: Local File Search (fallback, always available)
-
-If MCP tools are unavailable, use built-in tools:
-
-```
-# Search file contents
-Grep: pattern="your query" path="kb/"
-
-# Search file names
-Glob: pattern="kb/**/*.md"
-
-# Read specific document
-Read: "kb/reference/architecture.md"
-```
-
-## Search Tips
-
-1. **Be specific** - "nginx rate limiting" > "rate limiting"
-2. **Try MCP first**, fall back to Grep/Glob if unavailable
-3. **Use multi-hop** for "compare X with Y" questions (MCP only)
-4. **Always cite sources**: `[PATH: kb/reference/doc.md]`
-
-## Examples
-
-```
-/search rate limiting configuration
-/search how to deploy to production
-/search database migration patterns
-```

package/app/skills/teams/SKILL.md

@@ -1,63 +0,0 @@
----
-name: teams
-description: "Launches multi-agent teams for review, debugging, feature dev, security audits, migrations. Triggers: multi-agent workflow, agent teams, team review, parallel agent collaboration."
-effort: max
-user-invocable: true
-argument-hint: "<preset> [task-description]"
-allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Agent, TeamCreate, TeamDelete, SendMessage, TaskCreate, TaskList, TaskUpdate, TaskGet
----
-
-# /teams: Agent Teams Presets
-
-$ARGUMENTS
-
-Launches a pre-configured Agent Teams composition for your task. Requires `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`.
-
-## Available Presets
-
-| Preset | Agents | Use Case |
-|--------|--------|----------|
-| `review` | code-reviewer, security-auditor, performance-optimizer | PR code review |
-| `debug` | debugger, backend-specialist, incident-responder | Multi-file bug investigation |
-| `feature` | orchestrator, backend-specialist, frontend-specialist, test-engineer | Full feature implementation |
-| `fullstack` | backend-specialist, frontend-specialist, database-architect, devops-implementer | Full-stack task |
-| `research` | technical-researcher, data-analyst, prompt-engineer | Deep research task |
-| `security` | security-architect, security-auditor, backend-specialist | Security audit |
-| `migration` | database-architect, backend-specialist, devops-implementer | Database migration |
-
-See [reference/presets.md](reference/presets.md) for detailed ownership, aggregation strategies, and output formats for each preset.
-
-## Usage
-
-```
-/teams review              # Launch review team on current changes
-/teams debug               # Launch debug team for current issue
-/teams feature add auth    # Launch feature team with task context
-/teams security            # Launch security audit team
-```
-
-## Workflow
-
-1. **Parse** `$ARGUMENTS`: extract `<preset>` and optional `[task-description]`
-2. **Validate** preset is one of: review, debug, feature, fullstack, research, security, migration
-3. **Check environment**: verify `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is set; warn if missing
-4. **Display** team composition and ownership rules from [reference/presets.md](reference/presets.md)
-5. **Confirm** with user before launching
-6. **Launch agents**: spawn each agent with its assigned scope using the Agent tool:
-   ```
-   Agent({ description: "code-reviewer: PR review lead", prompt: "[task + ownership rules]" })
-   Agent({ description: "security-auditor: security findings", prompt: "[task + domain scope]" })
-   ```
-7. **Aggregate results**: apply the preset's aggregation strategy (consensus, relay, or map-reduce)
-8. **Produce output**: write the defined output document (e.g., `REVIEW.md`, `DEBUG_REPORT.md`)
-
-### Error Handling
-
-- If an agent fails or times out: log the failure, continue with remaining agents, note the gap in the output
-- If agents produce conflicting findings: the lead agent resolves conflicts; flag unresolved disagreements for user review
-
-## Environment
-
-```bash
-export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
-```

package/app/skills/teams/reference/presets.md

@@ -1,52 +0,0 @@
-# Agent Teams Preset Definitions
-
-Detailed configuration for each `/teams` preset. Each preset defines agents, ownership, aggregation strategy, and output format.
-
-## review
-
-- **Agents**: code-reviewer (lead), security-auditor, performance-optimizer
-- **Ownership**: code-reviewer owns review summary; others own their domain reports
-- **Aggregation**: consensus (flag issues found by 2+ agents as high priority)
-- **Output**: `REVIEW.md` with severity-ranked findings
-
-## debug
-
-- **Agents**: debugger (lead), backend-specialist, incident-responder
-- **Ownership**: debugger owns root-cause analysis; others own hypothesis testing
-- **Aggregation**: relay (debugger synthesizes findings from others)
-- **Output**: `DEBUG_REPORT.md` with root cause and fix
-
-## feature
-
-- **Agents**: orchestrator (lead), backend-specialist, frontend-specialist, test-engineer
-- **Ownership**: orchestrator owns plan; specialists own their files; test-engineer owns tests
-- **Aggregation**: map-reduce (orchestrator integrates all outputs)
-- **Output**: implemented feature + tests
-
-## fullstack
-
-- **Agents**: backend-specialist, frontend-specialist, database-architect, devops-implementer
-- **Ownership**: each agent owns their layer (API, UI, DB, infra)
-- **Aggregation**: relay (backend-specialist synthesizes integration)
-- **Output**: full stack implementation
-
-## research
-
-- **Agents**: technical-researcher (lead), data-analyst, prompt-engineer
-- **Ownership**: technical-researcher owns synthesis; others own domain findings
-- **Aggregation**: consensus (areas of agreement highlighted)
-- **Output**: `RESEARCH.md` with findings and recommendations
-
-## security
-
-- **Agents**: security-architect (lead), security-auditor, backend-specialist
-- **Ownership**: security-architect owns threat model; auditor owns findings; backend owns remediation
-- **Aggregation**: relay (security-architect integrates all)
-- **Output**: `SECURITY_AUDIT.md` with CVSS-scored findings
-
-## migration
-
-- **Agents**: database-architect (lead), backend-specialist, devops-implementer
-- **Ownership**: database-architect owns schema; backend owns code changes; devops owns deployment
-- **Aggregation**: relay (database-architect coordinates sequence)
-- **Output**: migration scripts + rollback plan + deployment runbook