mikeparcewski/wicked-garden-engineering

Engineering

Senior engineering guidance on code quality, architecture, and implementation. The five actions below run inline (no dispatch); genuinely structural, migration, or API-reference work dispatches to the fork workers listed at the end.

Routing

| Ask | Action | |-----|--------| | Code-level quality review of files or a diff | § review | | Component/system-level architecture review | § arch | | Bug / error / unexpected-behavior diagnosis | § debug | | Implementation plan before writing code | § plan | | Generate or refresh documentation | § docs | | Multi-file mechanical change (add-field/rename/remove) | patch |

Review disambiguation: this skill reviews source code. For an AI agent system use agentic review, for a UI use product ux-review, and for a binding go/no-go verdict use archetype review (see docs/domains.md → "review appears in three domains"). arch is component/system-level review; review is code-level; greenfield design is the architecture module.

review — senior-engineer code review

1. Parse scope (path or git-diff target), --focus, --persona, and --scenarios.
2. Read("${CLAUDE_PLUGIN_ROOT}/skills/engineering/refs/review.md") — R1–R6 Bulletproof Coding Standards, T1–T6 Bulletproof Testing Standards, agent overstepping checklist, focus lane definitions, persona routing instructions, wicked-scenarios format, and output template.
3. Persona branch (only if --persona <name> present): resolve the persona via scripts/persona/registry.py --get {name} --json. If found, apply the review through that persona's frame. If not found, warn and fall through.
4. Read the target file(s) / diff. Apply R1–R6 to all code; add T1–T6 when --focus tests or reviewing test files. If --focus given, deepen that lane. Flag agent overstepping (scope creep, commented-out code, over-engineering) with file:line citations.
5. Emit the standard Engineering Review output (Strengths, Issues table with rule + location, Architecture Notes, Maintainability Concerns, Agent Overstepping, Recommendations). If --scenarios, append wicked-scenarios blocks for each Critical/High finding.

arch — architecture analysis

Use arch for component/system-level review; use review for code-level review.

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).

For genuinely structural greenfield design, dispatch wicked-garden-engineering-solution-architect.

debug — systematic debugging session

1. Parse the error message, symptom, or issue description.
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.

Patterns and deeper process live in the debugging module.

plan — implementation planning

Analyze a change request against the current codebase and produce a detailed implementation plan with specific file changes, risk assessment, and test recommendations. Distinct from the patch module's patch-plan (propagation preview for mechanical patches — see patch/SKILL.md); this plan produces a human implementation plan.

1. Parse the change request: identify goal, scope, and constraints. Ask a clarifying question if the request is too vague to scope (e.g. no target file or system identified).
2. Read("${CLAUDE_PLUGIN_ROOT}/skills/engineering/refs/plan.md") — exploration checklist, risk assessment checklist, plan output format, and security/performance heuristics.
3. Explore the affected code: entry points, key files, callers, existing patterns, test coverage. Use wicked-garden:search:blast-radius {symbol} for impact analysis.
4. Apply the risk assessment checklist (breaking changes, performance, security, data integrity, test gaps, deployment coordination).
5. Emit the Implementation Plan output format: Summary, Scope (in/out), Changes Required per file, Risk Assessment table, Test Plan, Rollout Considerations, Open Questions.
6. Present the plan and ask: "Ready to proceed with implementation, or would you like to adjust the approach?" Do not write any code until approved.

docs — documentation generation

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. API/reference docs dispatch to wicked-garden-engineering-api-documentarian.
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.

Audit (coverage metrics) and sync (stale-docs detection) modes live in the docs module.

Knowledge modules

architecture · backend · frontend · integration · system-design · debugging · docs · large-scale-migration · patch · unit-test-quality

Fork workers

| Skill | Dispatch for | |-------|-------------| | wicked-garden-engineering-solution-architect | System design, structural trade-offs, greenfield architecture, ADRs | | wicked-garden-engineering-migration-engineer | Production schema/data migrations, expand-contract, deprecation paths | | wicked-garden-engineering-api-documentarian | OpenAPI specs, endpoint reference docs |

Frontend (React/CSS/browser), backend (APIs/databases/server-side), and debugging (error investigation, root-cause analysis) are handled inline by this skill — apply the relevant checklist from refs/.

Key principles

• Code quality: clear naming and organization, DRY, SOLID, consistent style.
• Architecture: design patterns, separation of concerns, component boundaries, dependency management.
• Maintainability: easy to understand, modify, and test; well-documented; deliberate error handling.
• Performance: efficient algorithms and data structures, resource management, caching strategies.

Review process

Use comprehensive checklists covering structure (patterns, abstractions, dependencies), quality (naming, duplication, style), error handling (recovery, messages), maintainability (clarity, configuration), performance (queries, data structures), and agent overstepping (unnecessary changes, commented-out code, scope creep). See refs/engineering-checklists.md for detailed review checklists and severity guidelines.

Output formats

Structured guidance for implementation planning (approach + steps) and code reviews (strengths, issues, recommendations). See refs/engineering-templates.md for output templates and focus areas.

Integration with wicked-crew

Engaged during the build phase (implementation guidance and pattern recommendations), the review phase (code quality and architecture review), and error recovery (when issues are encountered during development).

Notes

• Always explain the "why" behind recommendations.
• Be constructive, not critical.
• Offer alternatives with tradeoffs.
• Encourage questions and discussion.