wicked-garden-archetype

Estrelas8

Forks2

Atualizado21 de julho de 2026 às 14:47

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

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

mikeparcewski

mikeparcewski/wicked-garden

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Outras ocupações de informáticaInformática e Matemática·SOC 15-1299

Explorador de arquivos

11 arquivos

SKILL.md

readonly

name	wicked-garden-archetype
context	fork
user-invocable	true
description	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).
allowed-tools	["*"]

wicked-garden-archetype

v11 entry point for work-shape archetypes. Each archetype is a complete unit with its own phase shape, produces, HITL discipline, and cost band. There is no universal pipeline.

When to use this skill

Invoke when:

A <wg archetype="X"> or <wg archetypes> system-reminder tag appears (emitted by the v11 prompt hook).
The user explicitly asks to "run the {archetype} archetype" or "do this as a {archetype}" workflow.
You're routing from triage to a real archetype after classifying the work.

Do not use this skill for:

Continuation tokens ("yes", "ok", "do it"). Those carry no new shape; keep going on the current archetype.
Simple-edit work (typos, single-line fixes, cosmetic changes). The v11 hook already suppresses archetype tags on simple-edit intent.

The archetypes

Archetype	Phases	Produces	HITL
triage	classify	routing decision	none
explore	frame → diverge → converge	option set / hypothesis	continuous
specify	elicit → structure → validate	SMART acceptance criteria	discrete:validate
decide	brief → options → score → record	ADR / decision artifact	discrete:select
ship	canary → ramp → full → soak	rollout verdict / SLO snapshot	discrete:ramp
review	scope → assess → findings → remediate-or-accept	verdict / remediation list	hard:final-verdict
incident	triage → investigate → mitigate → resolve → followup	mitigation / RCA / followup	hard:mitigate
build	plan → implement → test → review	shipped code / test report	discrete:review
migrate	plan → expand → backfill → cutover → contract	shape change / rollback proof	hard:cutover
modernize	discover → extract → blueprint → transform → parity → cutover	modernization blueprint / parity proof	hard:cutover

Direct invocation

This skill is also the user-facing entry point for each archetype (replacing the former /wicked-garden:archetype:{name} slash commands). Invoke it with archetype=<name> plus the user's arguments; the skill loads refs/{name}.md and runs that playbook.

archetype	argument hint	description
triage	`[prompt]`	Classify a prompt into a work-shape archetype and route to its playbook. When the prompt is empty, run the detector against the conversation context.
explore	`[problem statement]`	Explore an open problem space — diverge then converge. Produces an option set or hypothesis, NOT a decision.
specify	`[ask]`	Turn an ask into SMART acceptance criteria.
decide	`[decision context]`	Pick between options with an ADR-shaped decision artifact.
ship	`[release / change ref]`	Roll out an already-built change with widening blast radius.
review	`[artifact / PR / commit]`	Independent assessment with hard verdict (APPROVE/CONDITIONAL/REJECT) — the only review producing a binding verdict (scope notes in `refs/review.md`).
incident	`[INC-id or symptom]`	Live-fire production incident response — mitigate first, RCA second.
build	`[work description]`	Implement and ship a feature or fix — test rigor scales with signals.
migrate	`[migration description]`	Schema/API/data shape change with expand-contract pattern.
modernize	`[modernization target, e.g. "port this AngularJS app to Angular"]`	Port a legacy codebase to a new stack — legacy→new-stack porting, NOT in-place shape change (that is `migrate`).

Procedure

Identify the archetype. Read the <wg archetype> tag in the system reminder OR ask the user which archetype they want when ambiguous.
Load the playbook. Read refs/{archetype}.md for the phase-by-phase playbook, the produces contract, and the HITL discipline.
Execute the phases. Run each phase in order. At each phase boundary ask: "do I have what this phase produces?" Don't move on until yes.
Honor HITL. When the playbook marks a gate as hard:*, stop and ask the user before proceeding. discrete:* gates may auto-pass when the produces contract is met. none and continuous carry no gate.
Multi-archetype prompts. When the hook emitted <wg archetypes> with two co-firing matches (e.g. build + migrate for a schema-change feature), run them in dependency order: migrate shape work first, then build integration work. The dependency graph lives in each archetype's next_archetypes field in the catalog.

Catalog source of truth

.claude-plugin/archetypes.json is canonical. The detector lives at scripts/crew/archetypes_v11.py. The CLI shim:

sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" \
  "${CLAUDE_PLUGIN_ROOT}/scripts/crew/archetypes_v11.py" \
  detect --prompt "<text>" --signals '{"production_impact": true}' --steering

Refs

refs/triage.md — entry classification
refs/explore.md — diverge/converge for open problems
refs/specify.md — elicit + structure + validate ACs
refs/decide.md — ADR-shaped option scoring
refs/ship.md — canary/ramp rollout
refs/review.md — independent assessment with verdict
refs/incident.md — live-fire response
refs/build.md — plan/implement/test/review (the common case)
refs/migrate.md — expand/backfill/cutover/contract (in-place shape change)
refs/modernize.md — discover/extract/blueprint/transform/parity/cutover (legacy→new-stack port)

What v11 archetypes are NOT

They are not the v6.3 target-kind archetypes (code-repo, docs-only, config-infra, etc.). Those classify what is being changed; v11 classifies what shape of work is happening. Both stay; they answer different questions.
They are not rigor tiers (minimal | standard | full). v11 obsoletes the rigor-tier dial: each archetype owns its own cost band and HITL.
They are not phase slots in a universal pipeline. Each archetype's phases live only inside that archetype.

Mais deste repositório

mesmo repositório

wicked-garden-engineering-conformance-reviewer

mikeparcewski/wicked-garden

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.

2026-07-168

wicked-garden-domain-coverage

mikeparcewski/wicked-garden

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.

2026-07-168

wicked-garden-core

mikeparcewski/wicked-garden

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.

2026-07-158

wicked-garden-domain-extractor

mikeparcewski/wicked-garden

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

2026-07-158

wicked-garden-domain-modeler

mikeparcewski/wicked-garden

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

2026-07-158

wicked-garden-domain

mikeparcewski/wicked-garden

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

2026-07-158

name	wicked-garden-archetype
context	fork
user-invocable	true
description	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).
allowed-tools	["*"]

wicked-garden-archetype

v11 entry point for work-shape archetypes. Each archetype is a complete unit with its own phase shape, produces, HITL discipline, and cost band. There is no universal pipeline.

When to use this skill

Invoke when:

A <wg archetype="X"> or <wg archetypes> system-reminder tag appears (emitted by the v11 prompt hook).
The user explicitly asks to "run the {archetype} archetype" or "do this as a {archetype}" workflow.
You're routing from triage to a real archetype after classifying the work.

Do not use this skill for:

Continuation tokens ("yes", "ok", "do it"). Those carry no new shape; keep going on the current archetype.
Simple-edit work (typos, single-line fixes, cosmetic changes). The v11 hook already suppresses archetype tags on simple-edit intent.

The archetypes

Archetype	Phases	Produces	HITL
triage	classify	routing decision	none
explore	frame → diverge → converge	option set / hypothesis	continuous
specify	elicit → structure → validate	SMART acceptance criteria	discrete:validate
decide	brief → options → score → record	ADR / decision artifact	discrete:select
ship	canary → ramp → full → soak	rollout verdict / SLO snapshot	discrete:ramp
review	scope → assess → findings → remediate-or-accept	verdict / remediation list	hard:final-verdict
incident	triage → investigate → mitigate → resolve → followup	mitigation / RCA / followup	hard:mitigate
build	plan → implement → test → review	shipped code / test report	discrete:review
migrate	plan → expand → backfill → cutover → contract	shape change / rollback proof	hard:cutover
modernize	discover → extract → blueprint → transform → parity → cutover	modernization blueprint / parity proof	hard:cutover

Direct invocation

archetype	argument hint	description
triage	`[prompt]`	Classify a prompt into a work-shape archetype and route to its playbook. When the prompt is empty, run the detector against the conversation context.
explore	`[problem statement]`	Explore an open problem space — diverge then converge. Produces an option set or hypothesis, NOT a decision.
specify	`[ask]`	Turn an ask into SMART acceptance criteria.
decide	`[decision context]`	Pick between options with an ADR-shaped decision artifact.
ship	`[release / change ref]`	Roll out an already-built change with widening blast radius.
review	`[artifact / PR / commit]`	Independent assessment with hard verdict (APPROVE/CONDITIONAL/REJECT) — the only review producing a binding verdict (scope notes in `refs/review.md`).
incident	`[INC-id or symptom]`	Live-fire production incident response — mitigate first, RCA second.
build	`[work description]`	Implement and ship a feature or fix — test rigor scales with signals.
migrate	`[migration description]`	Schema/API/data shape change with expand-contract pattern.
modernize	`[modernization target, e.g. "port this AngularJS app to Angular"]`	Port a legacy codebase to a new stack — legacy→new-stack porting, NOT in-place shape change (that is `migrate`).

Procedure

Identify the archetype. Read the <wg archetype> tag in the system reminder OR ask the user which archetype they want when ambiguous.
Load the playbook. Read refs/{archetype}.md for the phase-by-phase playbook, the produces contract, and the HITL discipline.
Execute the phases. Run each phase in order. At each phase boundary ask: "do I have what this phase produces?" Don't move on until yes.
Honor HITL. When the playbook marks a gate as hard:*, stop and ask the user before proceeding. discrete:* gates may auto-pass when the produces contract is met. none and continuous carry no gate.
Multi-archetype prompts. When the hook emitted <wg archetypes> with two co-firing matches (e.g. build + migrate for a schema-change feature), run them in dependency order: migrate shape work first, then build integration work. The dependency graph lives in each archetype's next_archetypes field in the catalog.

Catalog source of truth

.claude-plugin/archetypes.json is canonical. The detector lives at scripts/crew/archetypes_v11.py. The CLI shim:

sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" \
  "${CLAUDE_PLUGIN_ROOT}/scripts/crew/archetypes_v11.py" \
  detect --prompt "<text>" --signals '{"production_impact": true}' --steering

Refs

refs/triage.md — entry classification
refs/explore.md — diverge/converge for open problems
refs/specify.md — elicit + structure + validate ACs
refs/decide.md — ADR-shaped option scoring
refs/ship.md — canary/ramp rollout
refs/review.md — independent assessment with verdict
refs/incident.md — live-fire response
refs/build.md — plan/implement/test/review (the common case)
refs/migrate.md — expand/backfill/cutover/contract (in-place shape change)
refs/modernize.md — discover/extract/blueprint/transform/parity/cutover (legacy→new-stack port)

What v11 archetypes are NOT

They are not the v6.3 target-kind archetypes (code-repo, docs-only, config-infra, etc.). Those classify what is being changed; v11 classifies what shape of work is happening. Both stay; they answer different questions.
They are not rigor tiers (minimal | standard | full). v11 obsoletes the rigor-tier dial: each archetype owns its own cost band and HITL.
They are not phase slots in a universal pipeline. Each archetype's phases live only inside that archetype.