wicked-garden-archetype

Sterne8

Forks2

Aktualisiert21. Juli 2026 um 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).

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Quelle

mikeparcewski

mikeparcewski/wicked-garden

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

Sonstige ComputerberufeInformatik- und Mathematikberufe·SOC 15-1299

Datei-Explorer

11 Dateien

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.

Mehr aus diesem Repository

gleiches Repository

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.