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](patch/SKILL.md) |

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](architecture/SKILL.md).

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.

1. Persona branch (only if --persona 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.

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

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

1. Read("${CLAUDE_PLUGIN_ROOT}/skills/engineering/refs/arch.md") — rubric, checklists, output

formats, and architecture principles for both module/service and system scope.

1. Map the directory layout, entry points, key dependencies, and data flow of the target.
2. Apply the scope-appropriate checklist from the rubric directly. Flag unauthorized architectural

changes or scope creep when reviewing a diff.

1. 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](../engineering-solution-architect/SKILL.md).

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

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

1. Apply the six-step process. Read relevant files at error locations, search for related patterns,

check logs if available.

1. Emit the standard Debug Analysis output format (Symptom, Root Cause with confidence, Evidence,

Reproduction Steps, Recommended Fix with rationale, Verification, Prevention).

1. If the user approves the fix, implement it, add a regression test, and verify resolution.

Patterns and deeper process live in the [debugging module](debugging/SKILL.md).

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

1. Read("${CLAUDE_PLUGIN_ROOT}/skills/engineering/refs/plan.md") — exploration checklist,

risk assessment checklist, plan output format, and security/performance heuristics.

1. Explore the affected code: entry points, key files, callers, existing patterns, test coverage.

Use wicked-garden:search:blast-radius {symbol} for impact analysis.

1. Apply the risk assessment checklist (breaking changes, performance, security, data integrity,

test gaps, deployment coordination).

1. Emit the Implementation Plan output format: Summary, Scope (in/out), Changes Required per

file, Risk Assessment table, Test Plan, Rollout Considerations, Open Questions.

1. 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 ` and --type` (api | readme | guide | inline). Infer if absent:

.ts/.py/.go → api or inline; top-level directory → readme; workflow request → guide.

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

1. Read the source code: public interfaces, function signatures, types, error conditions, and

existing docs (check for drift from implementation).

1. 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](../engineering-api-documentarian/SKILL.md).

1. 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](docs/SKILL.md).

Knowledge modules

[architecture](architecture/SKILL.md) · [backend](backend/SKILL.md) · [frontend](frontend/SKILL.md) · [integration](integration/SKILL.md) · [system-design](system-design/SKILL.md) · [debugging](debugging/SKILL.md) · [docs](docs/SKILL.md) · [large-scale-migration](large-scale-migration/SKILL.md) · [patch](patch/SKILL.md) · [unit-test-quality](unit-test-quality/SKILL.md)

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](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](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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: mikeparcewski
• Source: mikeparcewski/wicked-garden
• License: MIT
• Homepage: https://wg.wickedagile.com/

Install and usage instructions live in the source repository linked above.