wicked-garden 12.27.0

package/skills/integration-discovery/refs/task-patterns.md

@@ -0,0 +1,206 @@
+---
+phase_relevance: ["bootstrap"]
+archetype_relevance: ["*"]
+---
+# Task Patterns
+
+Common task types and their typical capability mappings. Use as starting points—always verify availability.
+
+## Code Review
+
+**Task signals**: "review", "PR", "code quality", "check this code"
+
+| Need | Capability Type | Options |
+|------|-----------------|---------|
+| PR context | MCP | github, gitlab |
+| Code quality | Agent / inline | wicked-garden:crew:reviewer (or engineering review skill inline) |
+| Security check | Agent | wicked-garden:platform:security-engineer |
+| Test coverage | Agent / inline | wicked-garden:crew:reviewer (or engineering review skill inline) |
+| Link to ticket | MCP | atlassian, linear |
+
+**Recommended flow**:
+1. Get PR diff via MCP
+2. Run the engineering review skill inline (or dispatch crew:reviewer) for quality
+3. Spawn security-engineer if auth/data handling involved
+4. Store findings in ticket via MCP
+
+---
+
+## Security Audit
+
+**Task signals**: "security", "audit", "vulnerabilities", "penetration", "compliance"
+
+| Need | Capability Type | Options |
+|------|-----------------|---------|
+| Security expertise | Agent | wicked-garden:platform:security-engineer |
+| Compliance check | Agent | wicked-garden:platform:compliance-officer |
+| Privacy review | Agent | wicked-garden:platform:privacy-expert |
+| Test scenarios | Agent | wicked-garden:crew:gate-adjudicator |
+| Store findings | Skill | wicked-brain:memory |
+
+**Recommended flow**:
+1. Spawn security-engineer for primary audit
+2. Add compliance-officer if regulatory concerns
+3. Generate test scenarios for findings
+4. Store critical findings in wicked-brain:memory
+
+---
+
+## Architecture Design
+
+**Task signals**: "design", "architecture", "system design", "how should we build"
+
+| Need | Capability Type | Options |
+|------|-----------------|---------|
+| Solution design | Agent | wicked-garden:engineering:solution-architect |
+| Data modeling | Agent / Skill | wicked-garden:data:data-engineer (or data skill inline) |
+| Store decisions | Skill | wicked-brain:memory |
+| Document design | Agent | wicked-garden:engineering:api-documentarian (or docs skill inline) |
+
+**Recommended flow**:
+1. Spawn solution-architect for high-level design (it covers persistence/data shape too)
+2. Store decisions in wicked-brain:memory
+3. Document via api-documentarian or the engineering docs skill inline
+
+---
+
+## Bug Investigation
+
+**Task signals**: "bug", "error", "broken", "not working", "investigate"
+
+| Need | Capability Type | Options |
+|------|-----------------|---------|
+| Debugging | Skill | engineering debugging skill (inline root-cause analysis) |
+| Error tracking | MCP | sentry, datadog, rollbar |
+| Logs/traces | Skill | platform errors skill (inline) |
+| Codebase exploration | Agent | Explore |
+| Track fix | MCP | atlassian, github issues |
+
+**Recommended flow**:
+1. Check error tracking MCP for context
+2. Run the engineering debugging skill inline for systematic investigation
+3. Use Explore agent to understand code paths
+4. Track fix in issue tracker
+
+---
+
+## Feature Implementation
+
+**Task signals**: "implement", "build", "add feature", "create"
+
+| Need | Capability Type | Options |
+|------|-----------------|---------|
+| Requirements clarity | Agent | wicked-garden:product:requirements-analyst |
+| Design guidance | Agent | wicked-garden:engineering:solution-architect |
+| Implementation | Agent | wicked-garden:crew:implementer |
+| Test strategy | Agent | wicked-testing:test-strategist |
+| Track progress | MCP/Native | atlassian, TaskCreate/TaskUpdate |
+
+**Recommended flow**:
+1. Clarify requirements with requirements-analyst if vague
+2. Get design guidance from solution-architect
+3. Implement with crew:implementer; plan tests with wicked-testing:test-strategist
+4. Track via native TaskCreate or issue tracker
+
+---
+
+## Documentation
+
+**Task signals**: "document", "write docs", "README", "API docs"
+
+| Need | Capability Type | Options |
+|------|-----------------|---------|
+| Technical writing | Skill | engineering docs skill (inline narrative docs) |
+| API documentation | Agent | wicked-garden:engineering:api-documentarian |
+| Publish docs | MCP | confluence, notion |
+| Code understanding | Agent | Explore |
+
+**Recommended flow**:
+1. Use Explore to understand what needs documenting
+2. Dispatch api-documentarian for API/reference docs; run the docs skill inline for narrative docs
+3. Publish via documentation MCP if available
+
+---
+
+## Data Analysis
+
+**Task signals**: "analyze data", "query", "metrics", "report"
+
+| Need | Capability Type | Options |
+|------|-----------------|---------|
+| Data exploration | Agent / Skill | wicked-garden:data:data-engineer (or data skill inline) |
+| Query execution | MCP | snowflake, bigquery, databricks |
+| Local file analysis | Skill | data |
+| Visualization guidance | Skill | data analysis skill (inline) |
+
+**Recommended flow**:
+1. Check for data warehouse MCP
+2. If available, use for queries
+3. If not, use the data skill for local files
+4. Dispatch data-engineer (or run the data analysis skill inline) for interpretation
+
+---
+
+## Incident Response
+
+**Task signals**: "incident", "outage", "production issue", "pages"
+
+| Need | Capability Type | Options |
+|------|-----------------|---------|
+| Incident triage | Command/Skill | /wicked-garden:platform:incident (incident archetype, inline) |
+| Error context | MCP | sentry, datadog |
+| Log analysis | Skill | platform errors / observability skills (inline) |
+| Communication | MCP | slack, teams |
+| Post-mortem | Skill | wicked-brain:memory |
+
+**Recommended flow**:
+1. Run /wicked-garden:platform:incident (or the incident archetype) immediately
+2. Pull context from observability MCP
+3. Communicate status via chat MCP
+4. Store learnings in wicked-brain:memory
+
+---
+
+## Test Planning
+
+**Task signals**: "test", "QA", "test strategy", "what to test"
+
+| Need | Capability Type | Options |
+|------|-----------------|---------|
+| Test strategy | Agent | wicked-garden:crew:gate-adjudicator |
+| Test generation | Agent | wicked-garden:crew:implementer |
+| TDD guidance | Agent | wicked-testing:test-strategist |
+| Risk assessment | Agent | wicked-garden:platform:security-engineer |
+
+**Recommended flow**:
+1. Spawn gate-adjudicator to identify what to test
+2. Use security-engineer for risk priority
+3. Generate tests with implementer
+
+---
+
+## Quick Reference Matrix
+
+| Task Type | Primary Agent | Supporting | MCP Needs |
+|-----------|---------------|------------|-----------|
+| Code review | crew:reviewer | security-engineer | github/gitlab |
+| Security audit | security-engineer | compliance-officer | - |
+| Architecture | solution-architect | data-engineer | - |
+| Bug fix | engineering debugging skill (inline) | platform errors skill | error tracking |
+| Feature | requirements-analyst | solution-architect | project mgmt |
+| Docs | api-documentarian | engineering docs skill (inline) | confluence |
+| Data | data-engineer | data skill (inline) | warehouse |
+| Incident | platform incident (inline) | observability skill | observability |
+| Testing | wicked-testing:test-strategist | - | - |
+
+## When Capabilities Aren't Available
+
+If recommended capability isn't available:
+
+| Missing | Fallback |
+|---------|----------|
+| Domain agent | Use Explore + manual analysis |
+| MCP integration | Use built-in tools + manual steps |
+| Specific skill | Check for similar skill or use general approach |
+
+Always note gaps in recommendations so user knows what's missing.

package/skills/jam/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: jam
+description: |
+  Orchestrates AI-powered brainstorming sessions with dynamic focus groups.
+  quick sessions are ephemeral (no storage). brainstorm and council sessions
+  are tracked as native tasks (process) and stored in wicked-brain:memory (outcome).
+  Use when: "brainstorm this", "explore ideas", "get different perspectives",
+  "focus group", "what do you think about", "pros and cons", "quick check".
+context: fork
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+
+# Brainstorming Skill
+
+Generate diverse perspectives through structured focus group sessions.
+
+## Session Types
+
+- **quick** (`/wicked-garden:jam:quick`) — 4 personas, 1 forced round, brief synthesis. Ephemeral. Best for gut-checks and rapid exploration.
+- **brainstorm** (`/wicked-garden:jam:brainstorm`) — 4-6 personas, 2-3 rounds, evidence gathering, decision record storage. Best for important decisions and complex problems.
+- **council** (`/wicked-garden:jam:council`) — Structured verdict with external LLMs. Best for high-stakes calls requiring external challenge.
+
+## Quick-Start
+
+```
+# Fast gut-check (ephemeral, ~60s)
+/wicked-garden:jam:quick "Should we use feature flags or config files here?"
+
+# Full session with evidence and decision storage
+/wicked-garden:jam:brainstorm "Architecture approach for the new event bus"
+
+# High-stakes council with external LLM challenge
+/wicked-garden:jam:council "Go/no-go on the v9 storage migration"
+```
+
+## Agents
+
+- `agents/jam/quick-facilitator.md` — single-pass, 4 personas, no storage, no bus events (retained for scenarios; `jam:quick` now runs inline via `skills/jam/refs/quick.md`)
+- `agents/jam/brainstorm-facilitator.md` — multi-round, evidence gathering, transcript storage, decision record
+
+## References
+
+- `refs/facilitation-patterns.md` — persona archetype pool, session length guidance, anti-patterns
+- `refs/synthesis-patterns.md` — synthesis structure, quality checklist, decision record format

package/skills/jam/refs/facilitation-patterns.md

@@ -0,0 +1,125 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Facilitation Patterns
+
+Match persona archetypes to problem types for effective brainstorming sessions.
+
+## Problem → Persona Map
+
+### Architecture Decisions
+**When**: choosing between technical approaches, evaluating trade-offs, designing systems
+
+| Persona | Why They Matter |
+|---------|----------------|
+| Pragmatic Engineer | Builds it — knows what's realistic |
+| System Architect | Sees structural consequences 5 years out |
+| Ops/SRE | Lives with the decision in production |
+| New Team Member | Tests learnability and documentation needs |
+
+**Session type**: Full brainstorm (2 rounds). Round 1: independent assessment. Round 2: challenge each other's assumptions.
+
+### Product Scope Decisions
+**When**: deciding what to build, prioritizing features, defining MVP
+
+| Persona | Why They Matter |
+|---------|----------------|
+| Product Manager | Balances business value vs effort |
+| End User | Experiences the outcome directly |
+| Support Engineer | Sees the failure modes |
+| Skeptic | Challenges assumptions about demand |
+
+**Session type**: Full brainstorm (2-3 rounds). Include a "what would we cut?" round.
+
+### Process / Workflow Changes
+**When**: changing how the team works, adopting tools, modifying release processes
+
+| Persona | Why They Matter |
+|---------|----------------|
+| Team Lead | Manages the human impact |
+| Individual Contributor | Does the actual work under the process |
+| Maintainer | Thinks about long-term sustainability |
+| External Stakeholder | Affected by the change but has no control |
+
+**Session type**: Quick jam (1 round). Process decisions benefit from speed — long debates create analysis paralysis.
+
+### Creative / Naming / Positioning
+**When**: naming things, writing copy, positioning a product, crafting messaging
+
+| Persona | Why They Matter |
+|---------|----------------|
+| Marketing Strategist | Knows what resonates in the market |
+| Developer Advocate | Bridges technical accuracy and approachability |
+| Casual User | Tests whether the name/message is intuitive |
+| Brand Skeptic | Catches cringe, overreach, or inauthenticity |
+
+**Session type**: Quick jam. Creative decisions die in committee — one round forces decisive opinions.
+
+### Risk Assessment / Incident Response
+**When**: evaluating risk, planning for failure, post-incident analysis
+
+| Persona | Why They Matter |
+|---------|----------------|
+| Security Engineer | Sees attack vectors |
+| SRE | Knows what breaks at scale |
+| Compliance Officer | Knows what's legally required |
+| Customer Advocate | Represents the user impact of failures |
+
+**Session type**: Full brainstorm. Risk needs thoroughness — optimism bias is the enemy.
+
+### Greenfield / Exploration
+**When**: starting from scratch, exploring a new space, evaluating feasibility
+
+| Persona | Why They Matter |
+|---------|----------------|
+| Visionary | Imagines the best possible outcome |
+| Pragmatist | Anchors to what's buildable today |
+| Skeptic | Asks "why would this fail?" |
+| User Researcher | Asks "does anyone actually want this?" |
+
+**Session type**: Full brainstorm (2 rounds). Round 1: dream. Round 2: reality-check.
+
+## Anti-Patterns
+
+### Avoid These Persona Combinations
+
+- **All technical personas** — produces technically elegant solutions nobody wants
+- **All business personas** — produces strategies that can't be built
+- **All agreeable personas** — produces consensus without insight (strawman risk)
+- **More than 6 personas** — produces noise; diminishing returns after 5-6
+
+### Facilitation Mistakes
+
+- **Summarizing instead of synthesizing** — synthesis finds the non-obvious connection between viewpoints; summary just lists them
+- **Resolving tension too early** — productive disagreement between personas is the point; don't smooth it over in round 1
+- **Ignoring the quiet persona** — if a persona has nothing to say, the panel is wrong for the problem, not the persona
+- **Skipping confidence levels** — "HIGH confidence" vs "LOW confidence" is the most valuable signal in synthesis
+
+## Adapting Session Length
+
+| Signal | Recommendation |
+|--------|---------------|
+| User says "quick" or "gut check" | Quick jam — 1 round, 4 personas |
+| User says "important" or "strategic" | Full brainstorm — 2-3 rounds, 5-6 personas |
+| Complexity score >= 4 in crew | Full brainstorm with domain-specific personas |
+| Ambiguity detected in clarify phase | Full brainstorm focused on framing the problem |
+| Time pressure ("we need to decide today") | Quick jam — speed > thoroughness |
+| User says "converge fast" or "get to the point" | Full brainstorm with `--converge fast` — personas + early exit |
+
+## Convergence Assessment
+
+After each discussion round, the facilitator should assess convergence before proceeding:
+
+**Converged (skip remaining rounds in fast mode):**
+- 2+ actionable insights have emerged
+- Personas broadly agree on direction (details may differ)
+- Remaining disagreements are well-characterized trade-offs, not confusion
+
+**Not converged (continue to next round):**
+- Personas are talking past each other (different framing, different assumptions)
+- Key tensions are unresolved and unclear
+- No actionable insight has emerged yet
+- A persona raised a concern that others have not addressed
+
+The goal is to reach synthesis as soon as the discussion has produced enough signal. Extra rounds that merely reinforce existing positions waste time without adding insight.

package/skills/jam/refs/quick.md

@@ -0,0 +1,64 @@
+# jam:quick — Single-Pass Brainstorm Rubric
+
+Full rubric sourced from `agents/jam/quick-facilitator.md`.
+This is a forced-fast session: exactly 4 personas, exactly 1 round, then synthesize.
+Do NOT run additional rounds regardless of complexity. Do NOT store anything.
+
+## Constraints (hard)
+
+- EXACTLY 1 round — never extend
+- EXACTLY 4 personas — no more, no fewer
+- NO transcript storage — ephemeral output
+- NO bus events
+- NO multi-AI step
+- NO evidence gathering (no wicked-brain lookups)
+- Synthesis: concise, target ≤ 200 words total
+
+## Step 1: Pick 4 Personas
+
+Select personas that cover the topic's key tensions. Draw from:
+
+- Technical: Architect, Debugger, Optimizer
+- User-Focused: Power User, Newcomer, Support Rep
+- Business: Product Manager, Skeptic, Cost Optimizer
+- Process: Maintainer, Tester, Release Manager
+
+Cover at least 2 different archetype categories. Each persona must have a genuine concern, not a strawman.
+
+## Step 2: Single Round
+
+Each persona speaks in 2–4 sentences:
+
+```
+**[Persona Name]** ({archetype})
+{Position on topic. Key concern or trade-off. One concrete suggestion.}
+```
+
+No back-and-forth. No responses between personas. One pass only.
+
+## Step 3: Synthesis
+
+Write exactly these three sections:
+
+```markdown
+## Quick Jam: {Topic}
+
+### Key Insights
+- **[Persona]**: {one-line takeaway}
+- **[Persona]**: {one-line takeaway}
+- **[Persona]**: {one-line takeaway}
+- **[Persona]**: {one-line takeaway}
+
+### Action Items
+1. {Primary recommendation with rationale — fold the most important risk/tension in}
+2. {Secondary option, caveat, or follow-up}
+
+### Open Questions
+- {One unresolved question worth tracking if this goes deeper}
+```
+
+## Rules
+
+- No padding: if the answer is obvious after 2 personas, the remaining 2 still speak — but synthesis stays concise.
+- No convergence check (that's brainstorm-facilitator only).
+- Ephemeral by design. Callers wanting storage or multi-round depth → `jam:brainstorm`.

package/skills/jam/refs/synthesis-patterns.md

@@ -0,0 +1,114 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Synthesis Patterns
+
+How to transform raw persona discussions into actionable outcomes.
+
+## Synthesis Structure
+
+Every synthesis follows this skeleton:
+
+```markdown
+## Brainstorm: {Topic}
+
+### Key Insights
+1. **{Insight}** — {confidence: HIGH/MEDIUM/LOW}
+   {1-2 sentences explaining the non-obvious finding}
+2. ...
+3. ...
+
+### Action Items
+1. {Specific, actionable next step} — {who/when if known}
+2. ...
+
+### Open Questions
+- {What remains unresolved — honest about gaps}
+
+### Tensions
+- **{Position A}** vs **{Position B}** — {why this tension matters}
+```
+
+## Quality Checklist
+
+A good synthesis has:
+- [ ] 3-5 insights (not 10 — information overload kills action)
+- [ ] Confidence levels on every insight (HIGH/MEDIUM/LOW)
+- [ ] At least 1 non-obvious finding (something no single persona said alone)
+- [ ] Prioritized action items (not just a flat list)
+- [ ] Honest open questions (admitting what's unknown)
+- [ ] Named tensions (disagreements that matter, not smoothed over)
+
+A bad synthesis:
+- Just lists what each persona said (that's a transcript, not synthesis)
+- Has 8+ insights with no prioritization
+- Everything is "MEDIUM" confidence (lazy scoring)
+- No action items (interesting but not useful)
+- No tensions acknowledged (false consensus)
+
+## Synthesis Techniques
+
+### The Non-Obvious Connection
+
+Look for ideas that emerge from the intersection of two personas' viewpoints — something neither would have said alone.
+
+**Example**: The engineer says "we need a cache layer" and the user researcher says "users hate stale data." The synthesis insight is: "Cache with aggressive invalidation — latency matters but correctness matters more." Neither persona stated this directly.
+
+### The Surprising Agreement
+
+When personas who should disagree actually agree on something, that's a high-confidence signal.
+
+**Example**: The skeptic and the visionary both say "this needs to be simple." That's a stronger signal than either alone.
+
+### The Productive Tension
+
+Some disagreements shouldn't be resolved — they should be named as trade-offs for the decision-maker.
+
+**Example**: "Speed of delivery vs. test coverage. The team lead wants to ship Friday; QE wants integration tests. This is a risk decision, not a right answer."
+
+### The Missing Voice
+
+If no persona raised a concern that seems obvious, note it. The panel may have been wrong for this problem.
+
+**Example**: "No persona discussed data privacy implications. This gap should be addressed before implementation."
+
+## Decision Record Format
+
+When a brainstorm produces a clear decision, store it via wicked-brain:memory:
+
+```
+Decision: {what was decided}
+Chosen: {the selected option}
+Rationale: {why — rooted in evidence from the session}
+Alternatives considered: {what was rejected and why}
+Confidence: {HIGH/MEDIUM/LOW}
+Evidence used: {what data/experience informed the decision}
+Personas: {who participated}
+Tags: {topic tags for future recall}
+```
+
+This format enables future recall: "What did we decide about X?" returns the full decision context.
+
+## Examples of Good Synthesis
+
+### Architecture Decision
+> **Key Insight 1**: Event sourcing is the right pattern for audit requirements, but the team has no experience with it — HIGH confidence on the pattern choice, LOW confidence on execution timeline.
+>
+> **Action**: Spike on event sourcing with a bounded context (2 days) before committing to full adoption.
+>
+> **Tension**: Architect wants event sourcing everywhere; pragmatist wants it only for the audit domain. Resolve after the spike.
+
+### Product Scope
+> **Key Insight 1**: The top 3 requested features serve power users, but 80% of new signups churn before reaching power-user status — HIGH confidence.
+>
+> **Action**: Prioritize onboarding improvements over feature additions for Q2.
+>
+> **Open Question**: What does the conversion funnel look like between signup and first value moment? No persona had this data.
+
+### Process Change
+> **Key Insight 1**: The team unanimously agrees code review is too slow, but disagrees on the fix. The bottleneck is not the review process — it's that PRs are too large — HIGH confidence.
+>
+> **Action**: Adopt a "300 lines max" PR policy for 2 sprints as an experiment. Measure review turnaround.
+>
+> **Tension**: ICs want autonomy on PR size; lead wants consistency. The experiment resolves this empirically.