wicked-garden 12.27.0

package/commands/data/ml.md

@@ -0,0 +1,18 @@
+---
+description: "ML model review and training pipeline design"
+argument-hint: "<subcommand> [args...] — review <path> | pipeline --type <classification|regression|ranking>"
+phase_relevance: ["design", "build"]
+archetype_relevance: ["*"]
+---
+
+# /wicked-garden:data:ml
+
+ML model `review` and training-`pipeline` design. NOT for ETL pipeline design
+(use `data:pipeline`) or data profiling (use `data:data`).
+
+## Run it inline (no dispatch)
+
+1. Parse `subcommand` (review|pipeline) and args (`<path>` for review, `--type` for pipeline).
+2. For `review`, read model files at `<path>`.
+3. `Read("${CLAUDE_PLUGIN_ROOT}/skills/data/refs/ml.md")` — the model review checklist, pipeline design template, deployment readiness checklist, and MLOps standards.
+4. Apply the rubric for the requested subcommand and emit structured markdown.

package/commands/data/ontology.md

@@ -0,0 +1,22 @@
+---
+description: Sample a dataset and recommend public or custom ontologies based on the data
+argument-hint: "<file-path>"
+phase_relevance: ["design", "build"]
+archetype_relevance: ["*"]
+---
+
+# /wicked-garden:data:ontology
+
+Sample a dataset (CSV/Excel/Parquet/JSON) and recommend matching public ontologies (Schema.org, Dublin Core, DCAT, FOAF, GoodRelations, SKOS) or a custom shape. Use this for ontology mapping. NOT for interactive analysis (use `data:analyze`) or quality reports (use `data:data`).
+
+## 1. Arg parse
+
+Extract `file-path` from arguments.
+
+## 2. Run recommender
+
+```bash
+cd "${CLAUDE_PLUGIN_ROOT}" && uv run python scripts/_run.py scripts/data/ontology_recommender.py "${file_path}"
+```
+
+Present the script's match table, column-mapping suggestions, and any custom-ontology fallback inline.

package/commands/data/pipeline.md

@@ -0,0 +1,17 @@
+---
+description: "Data pipeline design and review"
+argument-hint: "<subcommand> [args...] — design --source <src> --target <tgt> [--frequency <freq>] | review <path>"
+phase_relevance: ["design", "build"]
+archetype_relevance: ["*"]
+---
+
+# /wicked-garden:data:pipeline
+
+Data pipeline `design` and `review`. NOT for ML training pipelines (use `data:ml`)
+or one-off file analysis (use `data:analyze`).
+
+## Run it inline (no dispatch)
+
+1. Parse `subcommand` (design|review) and args. For `review`, read pipeline files at `<path>`. For `design`, capture `--source`, `--target`, `--frequency`.
+2. `Read("${CLAUDE_PLUGIN_ROOT}/skills/data/refs/pipeline.md")` — the design checklist, review rubric with P1/P2/P3 findings, and engineering standards.
+3. Apply the rubric for the requested subcommand and emit structured markdown.

package/commands/deliberate.md

@@ -0,0 +1,181 @@
+---
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+  - Task
+  - Skill
+  - AskUserQuestion
+description: "Critically analyze any work request before implementation — challenge assumptions, find root causes, identify opportunities, and propose better approaches."
+argument-hint: "<description or GH#number> [--deep] [--batch]"
+phase_relevance: ["*"]
+archetype_relevance: ["*"]
+---
+
+# /wicked-garden:deliberate
+
+Analyze any work request through the five-lens deliberate framework before jumping to implementation. Works for bugs, features, content, design, architecture — anything.
+
+## Arguments
+
+- `description` (required): Issue description, GitHub issue number (e.g., `#42`), or quoted text
+- `--deep`: Run blast-radius and lineage analysis for affected areas
+- `--batch`: Process multiple issues (comma-separated numbers)
+
+## Instructions
+
+### 1. Parse Input
+
+If the argument is a GitHub issue number (`#N` or just a number):
+
+```bash
+gh issue view {number} --json title,body,labels,comments 2>/dev/null
+```
+
+Extract title, body, and any discussion context. If not a GH issue, use the raw description.
+
+### 2. Gather Context
+
+**Read project descriptors** (if they exist):
+- `CLAUDE.md`, `README.md` for project context
+- Recent git log for related changes:
+  ```bash
+  git log --oneline -20
+  ```
+
+**Search for affected areas** :
+- Extract key references from the description
+- Use `wicked-brain:search` for symbol search
+- If `--deep` flag: use `/wicked-garden:search:blast-radius` on key symbols
+
+**Recall relevant memories**:
+```
+Skill(skill="wicked-brain:memory", args="\"{key terms}\" --limit 5")
+```
+
+### 3. Detect Context and Load Lens
+
+Determine what kind of work this is (code, content, design, architecture, or mixed) and load the appropriate domain lens from the deliberate skill refs:
+
+- Code changes → `refs/code-lens.md`
+- Content/docs → `refs/content-lens.md`
+- Design/UX → `refs/design-lens.md`
+- Architecture/system → `refs/architecture-lens.md`
+
+Multiple lenses can apply. Load what's relevant.
+
+### 4. Apply Five Lenses
+
+Dispatch to an Explore agent for thorough analysis:
+
+```
+Task(
+  subagent_type="Explore",
+  prompt="Analyze this work request through five critical lenses. Read relevant files to ground your analysis.
+
+REQUEST: {title}
+DESCRIPTION: {body}
+AFFECTED AREAS: {files/pages/components from context gathering}
+CONTEXT TYPE: {code/content/design/architecture}
+
+Apply each lens:
+
+**Lens 1 — Is This Real?**
+- Is this actually a problem, or working as intended?
+- Is this a symptom or the root cause? Would fixing it just move the pain?
+- What evidence exists? Observed or theoretical?
+- What's the cost of doing nothing?
+
+**Lens 2 — What's Actually Going On?**
+- Trace to the real origin — don't stop at the first layer
+- Is the framing itself wrong?
+- What else shares the same root cause?
+
+**Lens 3 — What Else Can We Improve?**
+- Are adjacent areas suffering from the same weakness?
+- Can we generalize instead of point-fixing?
+- Is there duplication to consolidate?
+- Would a structural change prevent similar asks?
+
+**Lens 4 — Should We Rethink the Approach?**
+- Would a different structure make this disappear?
+- Are we patching around a flawed model?
+- What would we build if starting fresh?
+
+**Lens 5 — Is There a Better Way?**
+- Can we solve by removing instead of adding?
+- Can we solve with configuration instead of implementation?
+- Is there a simpler approach that covers 90% of cases?
+
+Return a structured Deliberation Brief with:
+- Assessment (validity, root cause, blast radius)
+- Opportunities (cleanup, generalization, rethink)
+- Recommendation (fix/redesign/generalize/defer/close + rationale)
+- Scope change (expand/contract/same)
+- Guidance (specific next steps)"
+)
+```
+
+### 5. Present Deliberation Brief
+
+Format the agent's findings:
+
+```markdown
+## Deliberation Brief: {title}
+
+### Assessment
+**Validity**: {Real problem / Symptom / Not a problem / Wrong framing}
+**Root cause**: {actual cause, not what was reported}
+**Blast radius**: {what else is affected}
+
+### Opportunities
+**Cleanup**: {what can be improved alongside}
+**Generalization**: {can we abstract or consolidate?}
+**Rethink**: {should we redesign the approach?}
+
+### Recommendation
+**Strategy**: {Fix / Redesign / Generalize / Defer / Close}
+**Rationale**: {why this approach over alternatives}
+**Scope**: {Expand / Contract / Same — what changed from original ask}
+
+### Guidance
+{specific direction for whoever does the work}
+```
+
+### 6. Store Deliberation
+
+Store as a memory for future reference:
+
+```
+Skill(skill="wicked-brain:memory", args="\"Deliberation: {title} — {strategy}: {one-line rationale}\" --type decision --tags deliberation,{project}")
+```
+
+### 7. Crew Integration
+
+If a crew project is active, update the project with resolution findings:
+
+```bash
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/scripts/_run.py" scripts/crew/phase_manager.py {project} update \
+  --data '{"deliberations": [{"issue": "{title}", "strategy": "{strategy}", "scope_change": "{change}"}]}' \
+  --json
+```
+
+## Batch Mode
+
+When `--batch` is used with multiple issue numbers:
+
+1. Fetch all issues in parallel
+2. Run the five-lens analysis on each
+3. Cross-reference: do any issues share root causes?
+4. Present a consolidated deliberation table with individual briefs
+
+## Examples
+
+```bash
+/wicked-garden:deliberate "Auth tokens expire too early on mobile"
+/wicked-garden:deliberate #281
+/wicked-garden:deliberate --batch "280,281"
+/wicked-garden:deliberate --deep "Navigation feels confusing on the settings page"
+/wicked-garden:deliberate "README is outdated and contradicts the API docs"
+```

package/commands/engineering/add-field.md

@@ -0,0 +1,77 @@
+---
+description: Add a field to an entity/class and propagate to all affected files
+phase_relevance: ["design", "build"]
+archetype_relevance: ["*"]
+---
+
+# /wicked-garden:engineering:add-field
+
+Add a field to an entity/class and propagate to all affected files.
+
+## Arguments
+
+- `symbol_id` (required): Target symbol ID (e.g., `path/Entity.java::EntityName`)
+- `--name` (required): Field name
+- `--type` (required): Field type (String, Integer, Boolean, Date, etc.)
+- `--column`: Database column name (defaults to SNAKE_CASE of name)
+- `--label`: UI label for form fields
+- `--required`: Mark field as non-nullable
+- `--output`, `-o`: Save patches to JSON file
+- `--apply`: Apply patches immediately
+- `--verbose`, `-v`: Show full diffs
+
+## Instructions
+
+Run the patch CLI:
+
+```bash
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/scripts/engineering/patch/patch.py" add-field "<symbol_id>" \
+  --name "<name>" \
+  --type "<type>" \
+  [--column "<column>"] \
+  [--required] \
+  [--verbose]
+```
+
+## Examples
+
+```bash
+# Add email field to User entity
+/wicked-garden:engineering:add-field "User.java::User" --name email --type String --column USER_EMAIL
+
+# Add required date field
+/wicked-garden:engineering:add-field "Order.java::Order" --name createdAt --type datetime --required
+
+# Save patches for review
+/wicked-garden:engineering:add-field "Entity.java::Entity" --name foo --type String -o patches.json
+```
+
+## Output
+
+Shows generated patches grouped by file:
+
+```
+═══════════════════════════════════════════════════════════
+GENERATED PATCHES
+═══════════════════════════════════════════════════════════
+
+Change: add_field
+Target: User.java::User
+Files affected: 3
+Patches: 5
+
+PATCHES:
+
+  User.java
+    [45-44] Add field 'email' (String)
+    [98-97] Add getter for 'email'
+    [99-98] Add setter for 'email'
+
+  user-form.jsp
+    [67-66] Add form field for 'email'
+
+  migration.sql
+    [10-9] Add column 'EMAIL' to 'USERS'
+
+═══════════════════════════════════════════════════════════
+```

package/commands/engineering/apply.md

@@ -0,0 +1,58 @@
+---
+description: Apply patches from a saved JSON file
+phase_relevance: ["design", "build"]
+archetype_relevance: ["*"]
+---
+
+# /wicked-garden:engineering:apply
+
+Apply patches from a saved JSON file.
+
+## Arguments
+
+- `patches_file` (required): Path to patches JSON file
+- `--dry-run`: Show what would be done without applying
+
+## Instructions
+
+```bash
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/scripts/engineering/patch/patch.py" apply "<patches_file>" [--dry-run]
+```
+
+## Workflow
+
+```bash
+# 1. Generate patches and save
+/wicked-garden:engineering:add-field SYMBOL --name foo --type String -o patches.json
+
+# 2. Review the patches
+cat patches.json
+
+# 3. Dry-run to verify
+/wicked-garden:engineering:apply patches.json --dry-run
+
+# 4. Apply for real
+/wicked-garden:engineering:apply patches.json
+```
+
+## Patches File Format
+
+```json
+{
+  "change_type": "add_field",
+  "target": "User.java::User",
+  "files_affected": ["User.java", "migration.sql"],
+  "patch_count": 3,
+  "generated_at": "2024-01-15T10:30:00",
+  "patches": [
+    {
+      "file": "User.java",
+      "line_start": 45,
+      "line_end": 44,
+      "old": "",
+      "new": "    private String email;",
+      "description": "Add field 'email'"
+    }
+  ]
+}
+```

package/commands/engineering/arch.md

@@ -0,0 +1,26 @@
+---
+description: |
+  Use when reviewing an existing system's architecture — evaluating component boundaries, coupling, layer
+  violations, or recommending design patterns. Outputs ADR-style analysis with trade-offs.
+  NOT for greenfield design (use the architecture skill) or code-level review (use engineering:review).
+argument-hint: "[component or system] [--scope module|service|system]"
+phase_relevance: ["design", "build"]
+archetype_relevance: ["*"]
+---
+
+# /wicked-garden:engineering:arch
+
+Architecture analysis of a component, service, or system. Use `engineering:arch` for
+component/system-level review; use `engineering:review` for code-level review.
+
+## Run it inline (no dispatch)
+
+1. Parse `[target]` and `--scope` (module | service | system; infer if absent from directory depth
+   and file count).
+2. `Read("${CLAUDE_PLUGIN_ROOT}/skills/engineering/refs/arch.md")` — rubric, checklists, output
+   formats, and architecture principles for both module/service and system scope.
+3. Map the directory layout, entry points, key dependencies, and data flow of the target.
+4. Apply the scope-appropriate checklist from the rubric directly. Flag unauthorized architectural
+   changes or scope creep when reviewing a diff.
+5. Emit the scope-appropriate output format (strengths, concerns table, recommendations,
+   trade-off table, ADR candidates for system scope).

package/commands/engineering/debug.md

@@ -0,0 +1,27 @@
+---
+description: |
+  Use when you have a bug, error, or unexpected behavior and need structured hypothesis-driven diagnosis —
+  root cause, reproduction steps, fix, and prevention. NOT for code review (use engineering:review)
+  or architecture analysis (use engineering:arch).
+argument-hint: "<error message, symptom, or issue description>"
+phase_relevance: ["design", "build"]
+archetype_relevance: ["*"]
+---
+
+# /wicked-garden:engineering:debug
+
+Start a systematic debugging session to diagnose issues, trace root causes, and develop fixes.
+
+## Run it inline (no dispatch)
+
+1. Parse the error message, symptom, or issue description from the argument.
+2. Use `Skill("superpowers:systematic-debugging")` — the full hypothesis-driven debugging
+   methodology (gather context, form hypothesis, test, document root cause).
+3. `Read("${CLAUDE_PLUGIN_ROOT}/skills/engineering/refs/debug.md")` for garden-specific heuristics:
+   check the wicked-bus first, loom/vault availability for gate failures, cross-platform hook issues,
+   and the standard debug output format.
+4. Apply the six-step process. Read relevant files at error locations, search for related patterns,
+   check logs if available.
+5. Emit the standard Debug Analysis output format (Symptom, Root Cause with confidence, Evidence,
+   Reproduction Steps, Recommended Fix with rationale, Verification, Prevention).
+6. If the user approves the fix, implement it, add a regression test, and verify resolution.

package/commands/engineering/docs.md

@@ -0,0 +1,27 @@
+---
+description: |
+  Use when generating API docs, READMEs, guides, or inline comments from existing code, or improving
+  documentation that has drifted from implementation. NOT for architecture docs (use engineering:arch).
+argument-hint: "<file or component> [--type api|readme|guide|inline]"
+phase_relevance: ["design", "build"]
+archetype_relevance: ["*"]
+---
+
+# /wicked-garden:engineering:docs
+
+Generate documentation from code or improve existing documentation. Supports API docs, READMEs,
+guides, and inline comments.
+
+## Run it inline (no dispatch)
+
+1. Parse `<file or component>` and `--type` (api | readme | guide | inline). Infer if absent:
+   `.ts/.py/.go` → api or inline; top-level directory → readme; workflow request → guide.
+2. `Read("${CLAUDE_PLUGIN_ROOT}/skills/engineering/refs/docs.md")` — type-routing table,
+   pre-generation checklist, API/README/guide/inline checklists, OpenAPI template, and quality
+   standards.
+3. Read the source code: public interfaces, function signatures, types, error conditions, and
+   existing docs (check for drift from implementation).
+4. Apply the type-appropriate checklist and generate the documentation inline following the
+   output template in the rubric.
+5. Present the documentation for user review before writing to file. When writing: API docs →
+   `docs/api/`; READMEs → component root; guides → `docs/guides/`; inline → Edit tool in-file.