mikeparcewski

v11 work-shape archetype runner. When a prompt has been routed to one of the archetypes (triage, explore, specify, decide, ship, review, incident, build, migrate, modernize), this skill is the entry point. It picks the right per-archetype playbook from refs/ and executes the phase shape declared in `.claude-plugin/archetypes.json`. Use when: a `<wg archetype="X">` or `<wg archetypes>` system-reminder tag appears, an explicit "let's run the X archetype" request, or a direct per-archetype ask — "triage this prompt", "review this PR / artifact", "build this feature", "decide between these options", "explore this problem", "handle this incident", "run this migration", "modernize / port this legacy app", "ship this release", "write acceptance criteria" (invoke with archetype=<name> plus the user's args — see the Direct invocation table).

Pattern-conformance agent-half: evaluates a produced artifact or diff against a set of architectural/design pattern rules from the conformance-rule store (wicked_governance schema). Returns structured findings with rule ID, severity, and rationale — the deterministic half (mechanical rule recall) is done by the guard pipeline; this is the semantic evaluation step. Triggered by: the guard_pipeline `outgov_pattern` check (session-close), or explicitly by an engineering review when WICKED_OUTGOV_RULES_DIR is populated. NOT a replacement for the full `engineering` review skill — focuses only on conformance to stored Pattern rules; architecture and code-quality checks live in the `engineering` skill. Semantic evaluation reuses `wicked-garden-qe-semantic-reviewer` as the designated agent-half evaluator (per garden#983 spec). This skill is the orchestrating wrapper that loads applicable Pattern rules and delegates the per-rule semantic judgment to qe-semantic-reviewer.

Coverage evaluator + pre-build threat model for the domain-extraction workflow (CONTRACT-3 §2). Emits `coverage-report.json` from the estate store, then adversarially reviews the extracted domain model: hunts missing error paths, ungrounded rules, reason-less drops, cross-cluster smears, and coverage holes. Use when: dispatched as the `coverage` phase of a domain-extraction workflow run. The phase runs in a git worktree; WICKED_ESTATE_DB points at the live estate store. NOT for mining rules (domain-extractor) or grouping domains (domain-modeler). This worker EMITS coverage evidence AND CRITIQUES the domain model.

Core utility surface for the wicked-garden plugin: help/overview, first-run setup + codebase onboarding, the wicked-* peer installer, selective state reset, the where-am-i path manifest, and structured issue filing. Use when: "wicked-garden help", "show wicked-garden commands", "what can wicked-garden do", "set up wicked-garden", "setup", "--reconfigure", "onboard this codebase", "install wicked tools", "add peers", "install layers", "reset wicked-garden", "clear state", "--list-projects", "where am I", "path manifest", "report issue", "file a bug", "--list-unfiled", or any former /wicked-garden:{help|setup|install|reset| where-am-i|report-issue} invocation.

Rule-extraction fork worker for the FOUNDATIONAL domain-model capability. Mines testable business rules from a codebase — each with a numeric confidence and a provenance{source, ref, source_kinds} — and annotates them into the estate store so wicked-core can build the domain-model requirements graph (coverage-gated). This is a substrate, not a modernization tool: the `modernize` archetype DERIVES from it, and build / migrate / review / specify / explore can consume the same domain model — none OWN it. Use when: dispatched by wicked-garden-domain to mine the business_rules of a codebase (or a module); "extract the domain rules", "what does this system require", building the requirements half of a domain model. NOT for grouping into domains (that is domain-modeler) or judging coverage (that is domain-coverage — a seat-distinct evaluator).

Domain-graph fork worker for the modernize archetype. Groups the estate's Louvain communities into business domains, attaches each requirement to its cluster (advisory cluster_id provenance), and invokes wicked-core's domain-graph build (which reads the annotated estate store, recomputes coverage fail-closed, and builds the requirements graph) — then validates core's output against the vendored schema. Use when: dispatched by wicked-garden-domain after rule extraction to turn a flat rule set into cluster-keyed domains; "group these into domains", "build the requirements graph", "translate clusters into a domain model". NOT for mining the rules themselves (that is domain-extractor) or threat-modeling (that is domain-coverage).

The FOUNDATIONAL domain-model capability: extract a codebase's domain — testable business rules (with confidence + provenance), entities, requirements — as a schema-conformant model on the estate graph. The workers annotate the store; wicked-core reads it and builds the requirements graph, coverage-gating fail-closed. Steers three fork workers. A shared substrate, not a modernization tool. The `modernize` archetype DERIVES from it; build / migrate / review / specify / explore consume the SAME domain model — none OWN it. Understanding a codebase's domain is upstream of almost everything else garden does. Use when: "extract the business rules / domain model from this codebase", "build a requirements graph from the code", "what does this system actually require", "reverse-engineer the domain before we build/port/migrate". Works on ANY codebase (modern or legacy) — the value is the domain model, not the porting. NOT the code transform itself (that is the archetype consuming this model). This skill produces the

Role-plays as focus group personas and synthesizes brainstorming discussions. Use when: brainstorming, ideation, running a full jam session with evidence gathering, discussion rounds, and decision record storage — dispatched by the wicked-garden-jam skill's brainstorm sub-action.

Evidence-gated acceptance testing with three-agent separation of concerns. Writer designs test plans, Executor collects artifacts, Reviewer evaluates independently. Eliminates false positives from self-grading. Use when: "acceptance test", "verify it works", "did it pass", "run acceptance", "test this scenario", "acceptance criteria", "validate the feature", "/wicked-testing:acceptance"

Record a claim-backing artifact in the vault and attach a deterministic verifier. Use when capturing evidence that "tests pass", "build clean", a commit exists, or a file's contents back a claim — and when replacing stale evidence via supersede. Covers --run vs --artifact, verifier syntax, and contract pinning.

Repo-local structural validator for wicked-testing. Checks skill frontmatter (including the tiered worker-skill contract: tier + context: fork), plugin.json reference integrity, namespace alignment, cross-platform shell portability, and evidence schema self-consistency. Zero LLM cost. Run before publishing or after structural changes. Use when: validating wicked-testing's own skills/plugin.json, pre-publish sanity check, after adding new skills to this repo.

Accessibility specialist — axe-core + pa11y, WCAG 2.1 AA / 2.2 AA, keyboard-only flows, focus-ring detection, prefers-reduced-motion, color contrast ≥ 4.5:1. Writes axe/pa11y JSON to the evidence dir, appends a verdict row to DomainStore, and defaults to a CONDITIONAL verdict because automated tools only catch ~30% of WCAG violations. Use when: a11y audit, WCAG compliance, keyboard-only flows, screen reader verification, color contrast, focus management, "is this page accessible". <example> Context: Reviewer wants a WCAG 2.1 AA check on a new checkout flow. user: "Run an accessibility pass on https://staging.example.com/checkout." <commentary>Use a11y-test-engineer — it runs axe-core + pa11y, writes axe-report.json + pa11y-report.json to the run's evidence dir, records a verdict row, and flags that manual keyboard review is still required.</commentary> </example>

Follows structured wicked-testing test plans step-by-step, collecting evidence artifacts. Executes and captures only — does not judge or grade pass/fail. Writes evidence files to .wicked-testing/evidence/{run-id}/. Use when: acceptance test execution, evidence collection, test plan execution <example> Context: Test plan is ready and needs to be executed step by step. user: "Execute the acceptance test plan for the file upload feature." <commentary>Use acceptance-test-executor for mechanical step execution and evidence capture without judging results.</commentary> </example>

Evaluates evidence artifacts against test plan assertions independently. CRITICAL ISOLATION: Receives ONLY evidence file paths. Never sees execution context. Catches semantic bugs that self-grading misses. Use when: acceptance test review, evidence evaluation, test verdict <example> Context: Executor produced evidence and it needs independent evaluation. user: "Review the evidence from the file upload acceptance tests and render a verdict." <commentary>Use acceptance-test-reviewer for independent, unbiased verdict on test evidence.</commentary> </example>

Reads wicked-testing acceptance scenarios and produces structured, evidence-gated test plans. Transforms qualitative criteria into concrete, verifiable artifact requirements. Use when: acceptance testing, test plan generation, scenario verification design <example> Context: New feature scenario needs a structured test plan. user: "Write an acceptance test plan for the 'user can export data as CSV' scenario." <commentary>Use acceptance-test-writer to produce structured, evidence-gated test plans from scenarios.</commentary> </example>

Tier-2 specialist — testing LLM-backed features. Prompt-injection probes (direct / indirect / payload-smuggling / multi-turn), jailbreak library (DAN, grandma, token-smuggling, base64), refusal-rate regression, hallucination drift against a caller-provided golden set, output-drift monitors (JSON-schema, token length, citation fidelity). Use when: LLM feature under test, prompt-injection review, jailbreak sweep, refusal-rate check, hallucination regression, RAG citation audit, "does this AI feature still behave after the prompt change". NOT THIS WHEN: - Post-deploy LLM cost/latency monitoring — use `production-quality-engineer` - Classical model-accuracy metrics (precision/recall on labelled data) — use `data-quality-tester` - Security bugs in the surrounding app (authz, secrets) — use `security-test-engineer`; AI-specific attack surface stays here <example> Context: Reviewer wants to verify a support-bot didn't regress after a system-prompt change. user: "Run the prompt-injection + refusal-rate suite a

Validates the requirements graph against the wicked-estate code graph before the blueprint phase. Checks every requirement's legacy field resolves to a real program node in the graph (not a JCL step), finds uncaptured behavior-bearing nodes with business logic that need requirements, and flags duplicate program references. Blocks if errors are found; warns and requires human review if only gaps remain. Run after extraction/graph-translator, before blueprint. Use when: "validate requirements graph", "audit the graph", "check graph accuracy", "are we missing any programs", "graph audit before dev", "validate before blueprint".

Apply structural lenses to the legacy code graph to identify entry points, domain boundaries, shared data coupling, operational modes (batch vs online), and risk hotspots. Queries the wicked-estate code graph via the helper (never raw SQLite, never legacy_graph.json). Produces an analysis report. Use when: "analyze the legacy code", "identify entry points", "find domain boundaries", "what are the hotspots", "classify the programs".

Pre-build threat modeler — the adversarial half of the Phase Execution Protocol (PEP, AGENTS.md §10). Given a phase plan and its threat surface, generates a structured threat list BEFORE the producer runs so the producer can address each threat in its output rather than discovering the gap post-build. CRITICAL threats block the phase from advancing until the producer acknowledges them (fix or documented waiver). MEDIUM/MINOR are advisory. Distinct from anti-legacy:adversarial-review (which reviews rendered output AFTER production) — the antagonist attacks the plan BEFORE production, while it is still cheap to change. Use when: any phase producer is about to run; "antagonist check"; "threat model this phase"; "what could go wrong"; PEP step 3 in orchestrate.

The anti-legacy pipeline internals SME, and the home of the shared antilegacy_core Python library. Use when: understanding or operating the pipeline core, diagnosing a core module (estate seam, requirements-graph builder, coverage, manifest state machine, validator), checking pipeline readiness, or extending antilegacy_core.

Map the Requirements Graph to a target state architecture blueprint. Defines the modern package structure, API surface (REST/gRPC), database schemas, class boundaries, and repository patterns for the target stack. Produces blueprint.json + blueprint.md. Use when: "design the target architecture", "create the blueprint", "map requirements to target stack", "design the Spring Boot structure", "what does the modern version look like".

Render the full stakeholder DELIVERABLES package once the requirements graph is ready — product requirements (PRD), architecture diagrams, detailed test strategy, functional test scripts, end-to-end migration plan, and the living risk / decisions / evidence logs — into .anti-legacy/deliverables/, then compile an index. Register-only; does not advance the pipeline. Use when: "produce the deliverables", "generate all the deliverables", "the deliverables package", "PRD + diagrams + plan + risk/decision logs".

Package and deploy the modernized application to the configured deployment target. Supports GCP Cloud Run, AWS ECS/Fargate, Azure AKS, and generic Kubernetes. Generates Dockerfile, CI/CD pipeline config, and deployment manifests. Requires GATE_4_UAT to be cleared. Use when: "deploy the app", "generate the Dockerfile", "create CI/CD config", "package for Cloud Run", "generate Kubernetes manifests", "deployment".

Guide the agent in modifying the plugin's code, templates, or skills to address learnings and gaps found in UAT/semantic validation. Use when: "update the plugin", "fix parsing bug", "modify translation rule", "develop the plugin", "self-correct code translator based on learning".

Universal code intelligence via LSP. Queries language servers for definitions, references, symbols, call hierarchies, hover info, and diagnostics. Auto-installs language servers when missing. Use when: "where is X defined", "who uses X", "what type is X", "list symbols in", "find symbol", "who calls X", "code diagnostics", "lsp health".

Synthesize wiki articles from brain chunks. Dispatches a compile subagent that identifies concept clusters in chunks and writes structured wiki articles with backlinks and source attribution. Use when: "compile the brain", "write wiki articles", "synthesize knowledge", "brain compile".

This skill should be used when the user says "configure brain CLI", "update CLAUDE.md from brain", "write brain orientation", or "regenerate brain config". Reads brain state and writes contextual instructions into the active CLI's agent config file. Run after onboarding, major ingests, or consolidation.

Multi-pass brain consolidation - archive noise, promote patterns, merge duplicates, build synonym map. Use when: brain needs maintenance, after significant ingestion, or reviewing consolidation_hint entries in log.jsonl.

Inspect, replay, or drop dead-lettered events from wicked-brain's bus subscriber. The auto-memorize subscriber consumes `wicked.garden.fact.extracted` and dead-letters events that exhaust their retry budget. Without this skill, those events sit untouched forever — a fixable handler bug silently loses every fact. Use when: "show DLQ", "replay dead letters", "what events failed", "drop dead letter", "memory subscriber DLQ", "stuck fact events".

Fill gaps in brain knowledge. Dispatches an enhance subagent that identifies thin areas and writes inferred chunks to expand coverage. Use when: "enhance the brain", "fill gaps", "brain enhance", "what's missing in the brain".

Archive or delete a memory (or any indexed document) by id or path. Removes the document from the FTS index and renames the file with an `.archived-{timestamp}` suffix so the data is recoverable. Use when: "forget this memory", "archive this", "drop this decision", "remove from brain", "brain forget".

Initialize a new digital brain. Creates the directory structure, brain.json, and config. Auto-triggered on first use of any brain skill when no config exists. Use when: "set up a brain", "create a brain", "brain init", or when any brain skill detects no config.

Generate a wiki skill (agent-loadable) from repo-intelligence analysis artifacts into the per-repo store at $ARTIFACTS_DIR/skills/{repo-slug}-wiki/ and install it via npx skills add. Also generates viewer.html on demand from ~/.wicked-understanding/ data. Trigger on: "generate wiki", "build wiki", "document this repo", "create the wiki skill", "build docs", "show me the wiki", "open the viewer". Requires analysis artifacts from repo-analyst.

Orchestrate all repo-intelligence lens skills with diff-awareness and parallel execution. Use when someone wants to analyze a repo (fully or partially), refresh outdated analysis, or run the full pipeline before forging a skill or building a wiki. Automatically detects which lenses are stale using manifest files and only re-runs what has changed. Runs all needed lenses in parallel when subagents are available. The lens subagents always produce the analysis by reading the repo at HEAD — that is the accurate, current source of truth. wicked-brain is an OPT-IN, additive build-time enricher (via `--enrich-from-brain`, default off): after the lens artifacts exist, it can append supplementary design rationale (ADRs, recorded decisions) the lenses cannot see; it never replaces a lens or overrides a lens fact. Trigger on: "analyze this repo", "refresh the analysis", "update the knowledge base for X", "run the pipeline on Y", "analyze and generate wiki", or whenever repo-skill-forge or repo-wiki-planner is about to ru

Generate or refresh the always-in-context agent context doc (CLAUDE.md / AGENTS.md / GEMINI.md) for an analyzed repo, distilled from the lens artifacts and routing agents to the generated task skills + wiki. This is the cheapest always-loaded surface: it orients every session in a few dozen lines and points at the curated skills instead of re-exploring the codebase. Merge-safe — augments a managed block, never clobbers hand-written rules. Trigger on "generate the context doc", "write the CLAUDE.md", "create AGENTS.md from the analysis", "orient agents to this repo", or after the skills + wiki are generated.

Generate task-oriented workflow skills for a codebase into the per-repo store and install them via npx skills add. Produces fix-bug, add-feature, verify, write-tests, add-domain, and scaffold skills — each tailored to this repo's specific patterns, file paths, and conventions. The verify skill describes what each capability should observably do and how to prove it, so anyone can test the repo without reading the code. Skills progressively load deeper context from the wiki refs as the agent needs it. Trigger on: "build the skills", "generate the workflow skills", "make the dev skills", "forge the skills", or after repo-analyst completes analysis.

Analyze the architecture of a code repository — component structure, layering, data flow, dependency direction, and cross-cutting concerns. Run independently whenever someone wants to understand how a codebase is structured, needs an architecture diagram, or wants to review architectural patterns. Requires a survey (run repo-surveyor first if `survey.md` doesn't exist). Writes `architecture.md` and a manifest sidecar so repo-analyst can detect when this lens needs refresh.

Analyze the functional domain and business logic of a code repository — entities, operations, invariants, workflows, and external integrations. Run independently when someone needs to understand what a system does (not how it's built), review domain logic, or map business rules. Requires a survey; run repo-surveyor first if needed. Writes `domain.md` and a manifest sidecar. Trigger on phrases like "what does this system do", "explain the business logic", "what are the domain entities", "how does the billing/auth/ordering work".

Analyze the operational setup of a code repository — how to install, run, build, test, debug, and deploy it. Run independently when someone needs to set up the project, understand the CI/CD pipeline, work with environment configuration, or debug operational issues. Requires a survey; run repo-surveyor first if needed. Writes `ops.md` and a manifest sidecar. Trigger on phrases like "how do I run this", "how do I set it up", "what are the environment variables", "how does deployment work", "how do I run tests".

Perform a fast, structured survey of any code repository to understand its technology stack, file structure, entry points, dependencies, and key files. Use whenever someone asks to understand, explore, or get oriented in a codebase — even casually. Always the mandatory first step before any lens skill or repo-analyst. Triggers on any repo path, GitHub URL, or uploaded archive regardless of language or framework. Run this even if you think you already know the stack — the survey feeds all downstream skills.

Emit events to the wicked-bus. Use when publishing events from a plugin, logging activity to the bus, or integrating a new system with the event bridge. Covers both programmatic (Node.js) and CLI usage.

Guide for naming wicked-bus events — helps choose event_type, domain, and subdomain when emitting events. Use when creating new events, integrating a plugin with the bus, or reviewing event naming for consistency.

Query and debug the wicked-bus. Use when checking bus health, inspecting events, debugging delivery issues, tracing event flow, or investigating why a subscriber isn't receiving events. Covers status, replay, and direct SQLite queries.

Initialize wicked-bus or connect to an existing instance. Use when setting up the bus for the first time, checking if it's running, or configuring a project to use it. Auto-triggered when any wicked-bus skill detects no config.

Show wicked-bus health, statistics, and diagnostics. Event counts, subscriber lag, provider list, database size, and configuration. Use when: "bus status", "is the bus healthy", "how many events", "show bus stats", or when diagnosing delivery issues.

Subscribe to wicked-bus events. Use when consuming events from the bus, setting up event listeners, polling for new events, or integrating as a subscriber. Covers registration, polling, acknowledgment, and filter patterns.

Check for and install wicked-bus updates. Compares installed version against npm registry, updates skills across all detected CLIs. Use when: "update wicked-bus", "check for bus updates", "wicked-bus update", or periodically to stay current.

Declare a consumer-authored contract and get a mechanical PASS/REJECT verdict for a scope+phase by re-deriving every required artifact. Use when answering "is this claim actually backed by evidence that still holds?" — gate logic, release readiness, or merge checks. Fail-closed when no contract is declared.

Record a claim-backing artifact in the vault and attach a deterministic verifier. Use when capturing evidence that "tests pass", "build clean", a commit exists, or a file's contents back a claim — and when replacing stale evidence via supersede. Covers --run vs --artifact, verifier syntax, and contract pinning.

Have an INDEPENDENT party analyze whether recorded evidence actually meets its frozen acceptance criteria, and record the judgment as a hash-bound, append-only attestation (mutation-detecting; durable tamper-evidence is the committed git history). Use when judging free-form criteria a deterministic check can't express ("does this adequately address the failure modes"), or producing a third-party sign-off that defeats self-graded "done". Runs a model (non-reproducible, costs a call). For the cheap deterministic integrity check, use wicked-vault:verify-evidence instead.

Initialize a wicked-vault in a repository so claims can be backed by re-derivable evidence. OPTIONAL ceremony — record/declare-contract/supersede create the vault automatically; use init only to scaffold explicitly. A read command reporting code VAULT_NOT_FOUND means no evidence exists yet, which record (not init) fixes.

Check for and install wicked-vault updates. Compares the installed version against the npm registry, updates the published CLI, and refreshes the skills across all detected AI CLIs (Claude Code, Gemini, Copilot, Codex, Cursor, Kiro, Antigravity). Use when: "update wicked-vault", "check for vault updates", "wicked-vault update", or periodically to stay current.

Deterministically re-derive a single recorded artifact's integrity — recompute the payload/criteria/envelope hashes and re-run its pure verifier. Model-free, reproducible, CI-gate-safe. Use to confirm a piece of evidence is still intact and its deterministic check passes, or to detect tamper. Never trusts the cached status. For an INDEPENDENT judgment of whether the evidence MEETS its criteria, use wicked-vault:analyze-evidence.

Be the supervising agent in the wicked-interactive feedback loop. Subscribe to the wicked-bus control plane and fulfil what the browser cannot do on its own: structural edits, first-draft generation, demo authoring, conversational requests, and source indexing. Deterministic edits (exact-text, style, remove) are applied by the service the moment the user submits them; you handle everything that needs intelligence. Use when: "assist the builder", "watch for edits", "be the agent in the loop", "fulfill structural edits", "respond to the chat", "the UPDATE button is spinning", "process feedback requests", "stay in the loop", invoked automatically after `serve`

Start the wicked-interactive builder: launch the local service, open the browser, and put THIS Claude session into the supervising-agent loop so the in-browser feedback loop actually works. The one command a business user runs. Use when: "start wicked-interactive", "open the builder", "launch the editor", "build an interactive page", "build a presentation I can edit in the browser", "let me review and edit a deck", "serve my documents", "open my docs in the browser", "start the interactive builder", "I want to edit HTML by clicking on it"

Drive the wicked-crew governed execution daemon — the harness for your coding-agent harnesses — from its command line. Launch, observe, gate, and resume durable multi-agent runs where "done" is re-derived from evidence and the agent that evaluates work is structurally never the one that created it. Use when: the user wants to put a feature, bug fix, or migration through governed execution — "run this through crew", "kick this off as a crew run", "have crew do this", "governed run"; check the state or progress of a run — "what's crew doing", "is the run done", "show crew status", "poll the run"; approve, reject, or amend a crew gate — "approve the gate", "reject that step", "the gate is waiting on me", "steer the run"; or resume an interrupted or paused session — "pick the run back up", "resume that crew session".