wicked-garden 12.27.0

package/skills/multi-model/refs/examples.md

@@ -0,0 +1,224 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Examples: Multi-AI Conversation Patterns
+
+Real-world examples and templates for multi-model collaboration.
+
+## Architecture Decision Record (ADR)
+
+After multi-model review, create an ADR capturing all perspectives:
+
+```markdown
+# ADR-001: Payment Gateway Selection
+
+## Status
+Accepted
+
+## Context
+Reviewed by Claude, Gemini, Codex, and OpenCode on 2026-01-23.
+
+The payment integration requires:
+- PCI DSS compliance
+- Support for subscriptions and one-time payments
+- Webhook-based async processing
+
+## Decision
+Use Stripe with webhook-based async processing.
+
+## Perspectives
+
+### Claude
+- Emphasized PCI compliance requirements
+- Recommended Stripe for mature compliance tooling
+- Suggested using Stripe Checkout for reduced PCI scope
+
+### Gemini
+- Flagged webhook retry complexity
+- Suggested idempotency keys for all mutations
+- Recommended dead letter queue for failed webhooks
+
+### Codex
+- Recommended repository pattern for payment abstraction
+- Suggested separating payment domain from order domain
+- Proposed event sourcing for payment state
+
+### OpenCode (GPT-4o)
+- Suggested circuit breaker for external API resilience
+- Recommended correlation IDs for distributed tracing
+- Flagged need for webhook signature verification
+
+## Consensus Points
+All models agreed on:
+1. Idempotency is non-negotiable
+2. Webhook signature verification required
+3. Need abstraction layer for future flexibility
+
+## Consequences
+- Must implement idempotency keys for all payment mutations
+- Need webhook signature verification (Stripe provides this)
+- Add payment abstraction layer (PaymentGateway interface)
+- Implement circuit breaker for Stripe API calls
+- Add correlation IDs for tracing across services
+
+## Related
+- [Payment Design Doc](../docs/payment-design.md)
+- [Task #42](link-to-task)
+```
+
+## wicked-crew Integration
+
+In wicked-crew's design or review phases, add multi-model review as a step:
+
+```yaml
+# Phase: design
+phase: design
+status: in_progress
+
+actions:
+  - name: gather_requirements
+    status: completed
+
+  - name: draft_design
+    status: completed
+    output: docs/payment-design.md
+
+  - name: multi_model_review
+    status: in_progress
+    config:
+      models: [claude, gemini, codex, opencode]
+      focus:
+        - security
+        - scalability
+        - maintainability
+      output: native_task_description
+
+  - name: synthesize_feedback
+    status: pending
+    depends_on: multi_model_review
+```
+
+## Code Review Example
+
+```markdown
+# Multi-Model Code Review: auth-service refactor
+
+## Context
+PR #123: Refactor authentication to use JWT
+
+## Claude's Review
+```
+Looking at the JWT implementation:
+
+1. **Token expiry**: 24h is too long for access tokens. Recommend:
+   - Access token: 15 minutes
+   - Refresh token: 7 days
+
+2. **Secret management**: Hardcoded secret on line 42.
+   Should use environment variable or secrets manager.
+
+3. **Algorithm**: Using HS256. Consider RS256 for
+   better key rotation support.
+```
+
+## Gemini's Review
+```
+Security concerns:
+
+1. **No token revocation**: Need blacklist for logout
+2. **Missing rate limiting**: Auth endpoints vulnerable to brute force
+3. **CORS too permissive**: Line 15 allows all origins
+
+Performance note:
+- JWT validation on every request adds ~2ms latency
+- Consider caching validated tokens briefly
+```
+
+## Codex's Review
+```
+Architecture feedback:
+
+1. **Single responsibility violation**: AuthService handles both
+   authentication AND authorization. Split into:
+   - AuthenticationService (login, tokens)
+   - AuthorizationService (permissions, roles)
+
+2. **Missing interface**: Direct class usage prevents testing.
+   Extract IAuthService interface.
+
+3. **Error handling**: Generic exceptions. Create specific:
+   - InvalidCredentialsException
+   - TokenExpiredException
+   - InsufficientPermissionsException
+```
+
+## Synthesis
+
+| Issue | Flagged By | Priority | Action |
+|-------|------------|----------|--------|
+| Token expiry too long | Claude | P0 | Reduce to 15min/7day |
+| Hardcoded secret | Claude | P0 | Use env var |
+| No token revocation | Gemini | P1 | Add blacklist |
+| No rate limiting | Gemini | P1 | Add rate limiter |
+| SRP violation | Codex | P2 | Refactor services |
+
+## Decision
+Block merge until P0 items resolved. P1 items in follow-up PR.
+```
+
+## Design Review Template
+
+```markdown
+# Multi-Model Design Review: [Feature Name]
+
+## Document Reviewed
+[Link to design doc]
+
+## Review Prompt
+"Review this design for security vulnerabilities, scalability concerns,
+and architectural issues. Be specific and actionable."
+
+## Perspectives
+
+### Claude
+[Paste Claude's analysis]
+
+### Gemini
+[Paste Gemini's output]
+
+### Codex
+[Paste Codex's output]
+
+### OpenCode
+[Paste OpenCode's output]
+
+## Consensus (flagged by 2+ models)
+- [ ] Issue 1
+- [ ] Issue 2
+
+## Unique Insights
+- **Claude only**: [insight]
+- **Gemini only**: [insight]
+- **Codex only**: [insight]
+
+## Action Items
+| Item | Owner | Due |
+|------|-------|-----|
+| | | |
+
+## Decision
+[Final decision and rationale]
+```
+
+## Storing Decisions in wicked-brain:memory
+
+After synthesis, persist the decision:
+
+```
+# Store the decision
+Skill(skill="wicked-brain:memory", args="store \"Payment gateway: Stripe with async webhooks.\nAll models agreed on idempotency requirement.\nCircuit breaker recommended by OpenCode.\" --type decision --tags payments,architecture,multi-model-review")
+
+# Store specific learnings
+Skill(skill="wicked-brain:memory", args="store \"JWT tokens: Use 15min access / 7day refresh.\n24h access tokens flagged as security risk by Claude.\" --type procedural --tags auth,jwt,security")
+```

package/skills/multi-model/refs/gemini.md

@@ -0,0 +1,185 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Gemini CLI — Usage Patterns
+
+Google Gemini CLI for AI-assisted tasks, long-context analysis, and multi-model collaboration.
+Gemini excels at long-context document review and broad analysis.
+
+## Installation and Setup
+
+```bash
+# Check if installed
+which gemini
+
+# Install
+npm install -g @google/gemini-cli
+# or: brew install gemini
+
+# Set API key
+export GEMINI_API_KEY="your-key"  # https://aistudio.google.com/apikey
+```
+
+## Core Usage Patterns
+
+### One-Shot Query (Non-Interactive)
+
+```bash
+# Simple query
+gemini "Explain this error: ${error_message}"
+
+# With file context (pipe content)
+cat src/auth.py | gemini "Review this authentication code for security issues"
+
+# Specific model
+gemini -m gemini-2.0-flash "Quick summary of this diff" < git_diff.txt
+
+# Review a diff
+git diff HEAD~1 | gemini "What are the risks of these changes?"
+```
+
+### Interactive Session
+
+```bash
+# Start interactive
+gemini
+
+# Start with initial prompt, continue interactively
+gemini -i "Let's review the checkout flow"
+
+# Resume previous session
+gemini -r
+```
+
+### Long-Context Analysis
+
+Gemini's primary strength is handling large documents and codebases:
+
+```bash
+# Review entire spec document
+cat docs/full-spec.md | gemini "Summarize key technical decisions and flag inconsistencies"
+
+# Cross-file analysis
+cat src/*.ts | gemini "Identify patterns and inconsistencies across these modules"
+
+# Large diff review
+git diff main...feature-branch | gemini "Review this entire feature branch for issues"
+```
+
+### Code Review
+
+```bash
+# Review a file
+cat src/checkout.ts | gemini "Review this code. Focus on:
+1. Error handling
+2. Edge cases
+3. Performance"
+
+# Review with specific concern
+cat src/auth.py | gemini "Security review: focus on authentication, session management, and injection"
+```
+
+## Multi-Model Collaboration
+
+Use Gemini for broad coverage and long-context review:
+
+```bash
+# Gemini for long docs (strength: context window)
+cat docs/architecture-200-pages.md | gemini "Summarize and flag concerns" > gemini_review.md
+
+# Pair with Codex for code-specific details
+cat src/auth.py | codex exec "Code-level security review"
+```
+
+## Native Task Tracking
+
+```
+# Create review task
+TaskCreate(
+  subject="Architecture review: payment service",
+  metadata={
+    "event_type": "task",
+    "chain_id": "payment-arch-review.root",
+    "source_agent": "multi-model:gemini",
+    "priority": "P1"
+  }
+)
+
+# Capture Gemini's perspective and append to the task description via TaskUpdate
+# GEMINI_REVIEW=$(cat docs/payment-design.md | gemini "Architecture critique")
+# TaskUpdate(taskId, description="{previous}\n\nGemini: ${GEMINI_REVIEW}")
+```
+
+## Options Reference
+
+| Option | Description |
+|--------|-------------|
+| `-m MODEL` | Model: `gemini-2.0-flash`, `gemini-1.5-pro`, `gemini-2.0-pro` |
+| `-i PROMPT` | Start interactive with initial prompt |
+| `-r` | Resume previous session |
+| `-y` | YOLO mode — auto-accept all actions |
+| `-s` | Sandbox mode |
+| `-e EXT` | Use specific extensions |
+
+## Strengths
+
+| Area | Description |
+|------|-------------|
+| Long context | Handles very large documents (1M+ tokens on Pro models) |
+| Broad analysis | Covers diverse aspects in a single pass |
+| Document review | Strong at spec review, ADR analysis, architecture docs |
+| Diff summaries | Effective at summarizing large diffs |
+
+## Best Practices
+
+1. **Pipe content** — Use stdin for context rather than describing files
+2. **Use for long docs** — Leverage Gemini's context window for large inputs
+3. **Be specific** — Focused prompts yield more actionable output
+4. **Compare perspectives** — Pair Gemini broad analysis with Codex code-specific review
+5. **Track decisions** — Use native TaskUpdate and wicked-brain:memory for team visibility
+
+## Session Management
+
+```bash
+# Start and continue a design review session
+gemini -i "Let's review the auth design"
+# ... interactive discussion ...
+# Resume later:
+gemini -r
+
+# When context gets stale, summarize first
+echo "Summarize our discussion in 5 bullet points" | gemini
+# Start fresh with summary as context
+```
+
+## Common Prompts
+
+```bash
+# Architecture review
+cat design.md | gemini "Architecture review: identify scalability concerns, missing components, and design risks"
+
+# Document inconsistency check
+cat docs/spec.md | gemini "Find inconsistencies, ambiguities, and missing requirements"
+
+# Security analysis
+cat src/auth/ | gemini "Security analysis: authentication, authorization, and data exposure risks"
+
+# API review
+cat docs/api-spec.yaml | gemini "Review API design for REST consistency, versioning, and breaking changes"
+
+# Cross-AI handoff
+echo "Prior analysis from Claude: ${CLAUDE_ANALYSIS}
+
+Build on this. What did Claude miss? What would you add?" | gemini
+```
+
+## Integration with wicked-crew
+
+```bash
+# Design phase: Gemini reviews architecture doc
+cat phases/design/arch.md | gemini "Review architecture for completeness and risks"
+
+# Review phase: Gemini reviews PR
+gh pr diff 123 | gemini "Code review: identify issues, missing tests, doc gaps"
+```

package/skills/multi-model/refs/goose.md

@@ -0,0 +1,112 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Goose CLI — Usage Patterns
+
+Block's open-source AI agent. Goose is designed to *do things* — run tools, execute commands, read files — not just answer questions.
+
+> **Registry is source of truth.** The council's headless invocation for goose
+> lives in `scripts/jam/agentic_cli_registry.py` (`goose run -t "{PROMPT}"`,
+> `model_flag_style: config-only`, auth via `goose configure`). The stdin/`-i -`
+> and `--system` forms below are valid alternatives, but the registry `-t`
+> prompt-arg form is what the council renders.
+
+## Installation and Setup
+
+```bash
+# Install
+brew install block-goose-cli
+
+# Check the setup
+goose doctor
+
+# Configure provider
+goose configure
+# ...walks you through picking provider (OpenAI, Anthropic, Gemini, Ollama, Bedrock, Azure)
+# ...and model
+# ...writes ~/.config/goose/config.yaml
+```
+
+## Core Usage Patterns
+
+### Non-Interactive (instructions from stdin)
+
+```bash
+# Read scaffold from stdin
+cat scaffold.md | goose run -i -
+
+# Pin a system prompt + read scaffold
+cat scaffold.md | goose run -i - \
+  --system "Answer the 4 questions precisely and concisely."
+
+# Instructions inline
+goose run -t "Evaluate Option A vs Option B for JWT session storage."
+
+# From a file
+goose run -i scaffold.md --system "Answer precisely."
+```
+
+### Sessions + Recipes (NOT used for council)
+
+```bash
+# Interactive agent session
+goose session start
+
+# Recipe — reusable parameterized agent
+goose run --recipe design-review.yaml
+
+# Scheduled jobs, terminal integration, MCP — outside council scope
+goose sched list
+goose term
+goose mcp ...
+```
+
+## Goose's Distinct Role in Multi-Model Sessions
+
+Goose has a stronger *agentic* reflex than the other CLIs — it tends to think about tools, MCP servers, and execution paths. That produces trade-off framings that notice automation surface and integration friction. Complementary to aider's edit-level reasoning and Pi's human-factor framing.
+
+```bash
+# Agentic framing in the council mix
+cat "$SCAFFOLD" | codex exec "Architectural review"
+cat "$SCAFFOLD" | goose run -i - --system "Evaluate with emphasis on automation, \
+  tool integration, and operational blast radius."
+```
+
+## Strengths
+
+| Area | Description |
+|------|-------------|
+| Agentic framing | Naturally reasons about tools, automation, and blast radius |
+| Multi-provider | OpenAI, Anthropic, Gemini, Ollama, Bedrock, Azure |
+| MCP-native | Can run as an ACP / MCP server; first-class tool-use integration |
+| Recipes | YAML-defined agents for repeatable review scenarios |
+| Open source | Apache-2.0, actively maintained by Block |
+
+## Important Flags for Council Use
+
+| Flag | Purpose |
+|------|---------|
+| `-i FILE` | Instruction file — use `-` for stdin |
+| `-t TEXT` | Inline instruction text |
+| `--system TEXT` | Additional system prompt |
+| `--recipe NAME` | Named recipe file |
+| `--params KEY=VALUE` | Parameters passed to the recipe |
+| `--explain` | Show recipe metadata without running |
+
+## Caveats
+
+1. **Goose is an agent.** Without a narrow system prompt it may try to use tools, call MCP servers, or read the current directory. Pin `--system "Answer precisely, do not use tools"` when the council needs a pure response.
+2. **Config is machine-wide.** `~/.config/goose/config.yaml` sets the provider + model. Switching per-invocation is possible via env overrides but less ergonomic than `llm -m` or `aichat -m`.
+3. **Heavier install.** Binary + assets weigh ~280 MB vs ~10 MB for `aichat` / `llm`. Worth it for the agent surface; overkill for pure Q&A.
+
+## Command Reference (council subset)
+
+| Command | Description |
+|---------|-------------|
+| `goose run -t TEXT` | One-shot instruction |
+| `goose run -i FILE` | Instructions from file |
+| `cat FILE \| goose run -i -` | Instructions from stdin |
+| `goose run --system TEXT -i FILE` | System prompt + instructions |
+| `goose configure` | Pick provider + model |
+| `goose doctor` | Verify config |

package/skills/multi-model/refs/llm.md

@@ -0,0 +1,124 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# llm CLI — Usage Patterns
+
+Simon Willison's `llm` — a pipe-native multi-provider aggregator. One command, many providers, everything via plugins. Ideal fit for council scaffolds: `cat scaffold | llm "prompt"` just works.
+
+## Installation and Setup
+
+```bash
+# Install
+brew install llm
+# or: pipx install llm
+
+# Configure providers via keys
+llm keys set openai
+llm keys set anthropic
+llm keys set gemini
+
+# Install plugin-backed providers
+llm install llm-anthropic
+llm install llm-gemini
+llm install llm-mistral
+llm install llm-groq
+llm install llm-ollama           # local models via Ollama
+
+# Set a default model
+llm models default claude-sonnet-4-5
+llm models default gpt-4o
+```
+
+## Core Usage Patterns
+
+### Non-Interactive (pipe-native)
+
+```bash
+# Simple pipe
+echo "Evaluate this trade-off..." | llm
+
+# Pipe with a system prompt
+cat scaffold.md | llm "You are evaluating options for a technical decision. \
+  Answer the 4 questions below precisely and concisely."
+
+# Pick a specific model for this call
+cat scaffold.md | llm -m claude-sonnet-4-5 "Evaluate options"
+cat scaffold.md | llm -m gpt-4o "Evaluate options"
+cat scaffold.md | llm -m groq/llama-3.3-70b "Evaluate options"
+cat scaffold.md | llm -m mistral-large "Evaluate options"
+
+# Inline prompt — no pipe
+llm "Which option do you recommend for session storage: JWT or sticky sessions?"
+```
+
+### Attach Files
+
+```bash
+# Attach the scaffold as an input, pass system prompt positionally
+llm -a scaffold.md "Answer the 4 questions in the attached file."
+
+# Multiple attachments (images, text, URLs)
+llm -a diagram.png -a spec.md "Critique this design."
+```
+
+### Conversational (for iteration, NOT council)
+
+```bash
+# Continue the previous exchange
+llm -c "Elaborate on the security angle."
+
+# Named conversation thread
+llm --cid design-review "Initial take?"
+llm --cid design-review -c "Now weigh in on cost."
+```
+
+## llm's Distinct Role in Multi-Model Sessions
+
+`llm` is the **universal adapter**. If the council needs a model no other CLI wraps — Groq's Llama 3.3, Mistral Large, a local Ollama model, a Bedrock endpoint — `llm` reaches it without adding a whole new tool to the roster.
+
+```bash
+# Council with local + cloud diversity via a single CLI
+cat "$SCAFFOLD" | llm -m claude-sonnet-4-5 "Evaluate"          # cloud
+cat "$SCAFFOLD" | llm -m ollama/llama3.1:70b "Evaluate"        # local
+cat "$SCAFFOLD" | llm -m groq/mixtral-8x22b "Evaluate"         # edge
+```
+
+## Strengths
+
+| Area | Description |
+|------|-------------|
+| Pipe-native | Designed for Unix composition; stdin in, text out |
+| Multi-provider | OpenAI, Anthropic, Gemini, Mistral, Groq, Bedrock, Ollama, Azure |
+| Plugin ecosystem | `llm install llm-*` adds providers without changing the CLI |
+| Persistent log | All prompts + responses saved to `~/.local/share/llm/logs.db` (SQLite) |
+| Templates | `llm -t template-name` stores reusable system prompts |
+
+## Important Flags for Council Use
+
+| Flag | Purpose |
+|------|---------|
+| `-m MODEL` | Override default model for this call |
+| `-s TEXT` | System prompt |
+| `-a FILE\|URL` | Attach a file or URL |
+| `--no-stream` | Disable streaming; return one block |
+| `-o KEY VALUE` | Provider-specific option (e.g. `-o temperature 0`) |
+| `-t NAME` | Apply a stored template |
+
+## Caveats
+
+1. **Default model matters.** `llm` uses whatever `llm models default` points at unless `-m` is given. Council dispatches should pin the model explicitly if provider attribution matters.
+2. **Logs everything.** All prompts go to `~/.local/share/llm/logs.db`. Disable with `--no-log` per call, or turn off globally with `llm logs off`.
+3. **Plugins are per-install.** `llm install llm-anthropic` is not automatic — check `llm plugins` before relying on a provider.
+
+## Command Reference (council subset)
+
+| Command | Description |
+|---------|-------------|
+| `llm "PROMPT"` | One-shot with default model |
+| `cat FILE \| llm "PROMPT"` | Pipe content as input |
+| `llm -m MODEL "PROMPT"` | Pick a specific model |
+| `llm -a FILE "PROMPT"` | Attach a file |
+| `llm models` | List available models |
+| `llm plugins` | List installed plugins |
+| `llm logs -n 5` | Last 5 logged prompts |