@event4u/agent-config 6.0.0 → 7.0.0

package/dist/agent-src/skills/premortem/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: premortem
+description: "Use before committing to a heavy or irreversible plan — imagine it's 6 months later and this failed; enumerate why, score each mode, derive early-warning signals and preventive guardrails."
+source: package
+domain: quality
+model_tier: high
+workspaces:
+  - engineering
+packs:
+  - analysis-workbench
+lifecycle: active
+trust:
+  level: professional
+  confidence: medium
+  human_review_required: false
+install:
+  default: false
+  removable: true
+---
+
+# premortem
+
+> Forward-looking imagined-failure analysis. Sibling of
+> [`blameless-post-mortem`](../blameless-post-mortem/SKILL.md) (which
+> analyses what actually went wrong after the fact) and
+> [`risk-officer`](../risk-officer/SKILL.md) (which scores pre-commit
+> risks per likelihood × impact). This skill adds the prospective frame:
+> "Assume total failure at horizon H — reconstruct why."
+
+## When to use
+
+Before committing to a plan that is:
+
+- Heavy to execute (multi-sprint, multi-team, or high coordination cost), or
+- Irreversible or costly to reverse (schema migration, public API change,
+  infrastructure restructure, major dependency swap, architecture decision).
+
+Trigger phrasing: "premortem this", "what if this fails?", "imagine it's 6
+months later and this shipped badly", "help me stress-test this plan".
+
+Do NOT use when:
+
+- The failure is already evidenced — root cause is known → use
+  [`systematic-debugging`](../systematic-debugging/SKILL.md).
+- Analysing something that already failed in the past →
+  use [`blameless-post-mortem`](../blameless-post-mortem/SKILL.md).
+- The plan is trivial or fully reversible — overhead exceeds value.
+
+## Procedure
+
+### 1. State the plan and set the horizon
+
+Summarise the plan in one sentence: *"We are doing X for outcome Y, touching
+Z."* Set the prospective-failure frame explicitly: *"Assume total failure at
+horizon H (e.g. 6 months post-launch). What went wrong?"*
+
+If the plan cannot be summarised in one sentence, it is not reviewable — stop
+and ask for scope clarification.
+
+### 2. Enumerate failure stories
+
+Generate failure scenarios across multiple angles (people, process, technical,
+external, timing). Each scenario is a short narrative in past tense: *"We
+shipped, but adoption collapsed because …"*
+
+For each scenario:
+
+- Invoke [`adversarial-review`](../adversarial-review/SKILL.md) to attack the
+  plan's assumptions and surface hidden coupling or over-engineering.
+- Invoke [`risk-officer`](../risk-officer/SKILL.md) to assign L × I (likelihood
+  × impact) scores to each failure mode.
+
+Do NOT re-implement L × I scoring inline — delegate to `risk-officer`.
+
+### 3. Derive early-warning signals and preventive guardrails
+
+For each top failure mode (sorted by L × I from `risk-officer`):
+
+1. **Early-warning signal** — what would you observe *first* if this failure
+   mode were activating? Name a concrete, observable indicator (metric, alert,
+   user behaviour, team signal). This is the load-bearing output.
+2. **Preventive guardrail** — one specific change to the plan, process, or
+   rollout strategy that reduces the likelihood of this failure mode. Keep it
+   executable; flag as `accept` if no practical guardrail exists.
+
+### 4. Optional memory write-back
+
+If the analysis surfaces a pattern worth preserving for future decisions:
+
+1. Run a dedup pre-check: call `retrieve()` over the same key-space (plan type,
+   affected paths, decision area). If a match is found, propose a
+   `frequency`/`supersedes` update to the existing entry rather than a new one.
+2. Draft a `historical-patterns` candidate and send it to `/memory propose` per
+   [`docs/contracts/analysis-memory-loop.md`](../../docs/contracts/analysis-memory-loop.md).
+3. Never auto-promote. Human action drives `/memory promote`.
+
+## Output format
+
+1. **Ranked prospective failure modes** — L × I ordered list (from `risk-officer`)
+2. **Early-warning signal per failure mode** — concrete, observable indicator
+3. **Preventive guardrails** — one per failure mode (or `accept` with rationale)
+4. **Optional memory candidate** — drafted to `/memory propose` if the pattern
+   clears the admission gate (≥ 2 distinct file paths OR ≥ 3 future decisions)
+
+## Do NOT
+
+- Do NOT invent strawman failure modes — each must be grounded in the actual
+  plan's structure, assumptions, or dependencies.
+- Do NOT re-implement L × I scoring — invoke `risk-officer`; don't duplicate
+  its five-lens framework inline.
+- Do NOT present speculation as evidence — premortem is imaginative framing,
+  not a prediction; label scenarios as prospective.
+- Do NOT auto-promote memory candidates — `/memory propose` is the intake;
+  `/memory promote` requires explicit human action and passes
+  `check_memory_proposal.py`.
+
+## Gotchas
+
+- Premortem is **forward-looking** — it imagines a future failure to improve
+  the present plan. `blameless-post-mortem` is backward-looking — it analyses
+  a past failure. Do not conflate them.
+- The **early-warning signal** is the load-bearing output, not the doom list.
+  A failure mode without a detectable signal cannot be caught in time — flag
+  it explicitly.
+- Failure stories in past tense ("we shipped, and then X happened") are more
+  generative than abstract risk statements. Force the past-tense narrative.
+
+## See also
+
+- [`risk-officer`](../risk-officer/SKILL.md) — L × I scoring; invoked in
+  Step 2. Not duplicated here.
+- [`adversarial-review`](../adversarial-review/SKILL.md) — assumption attack;
+  invoked in Step 2. Not duplicated here.
+- [`blameless-post-mortem`](../blameless-post-mortem/SKILL.md) — post-hoc
+  analysis of an actual failure; backward-looking counterpart to this skill.
+- Invocation surfaces: `/analyze premortem`, `feature:plan`, `roadmap-create`
+  (surface the premortem step as optional before committing to a plan).

package/dist/agent-src/skills/prompt-engineering-image/SKILL.md

@@ -0,0 +1,115 @@
+---
+model_tier: inherit
+name: prompt-engineering-image
+description: "Translate an image brief into provider-specific prompt grammar per model. Use when writing or refining an image-generation prompt for Ideogram, Flux, Gemini, GPT Image 2, or Recraft."
+domain: product
+personas: []
+workspaces:
+  - small-business
+packs:
+  - ai-image
+trust:
+  level: experimental
+install:
+  removable: true
+execution:
+  type: manual
+---
+
+# prompt-engineering-image
+
+Translate an image brief into a provider-specific prompt string. Each model
+has distinct prompt grammar — this skill applies the right structure per adapter.
+
+## When to use
+
+- Writing or refining a prompt for any `pack-ai-image` provider.
+- After `image-provider-routing` has selected the target provider.
+- When a prompt is underperforming and needs provider-specific tuning.
+
+## Per-provider prompt grammar
+
+### Ideogram (text-in-image: logos, banners, typographic art)
+
+- **Lead with the text literal** in quotes: `"BAKERY NAME" in bold serif on a cream background`.
+- Follow with visual context: background, color palette, style (flat, vintage, art-deco).
+- Avoid long scene descriptions — Ideogram renders text best with a focused layout brief.
+- Key params: `model: V_2`, `aspect_ratio: ASPECT_1_1` (square logo) or `ASPECT_16_9`
+  (banner), `magic_prompt_option: AUTO` (let Ideogram enrich).
+
+### Flux (photoreal: product shots, portraits, scenes)
+
+- **Descriptive noun phrase first**: subject → lighting → environment → camera.
+- Example: `"Close-up product shot of a ceramic coffee mug, soft studio lighting,
+  clean white background, 50 mm lens bokeh, ultra sharp"`.
+- Style descriptors: cinematic, hyperrealistic, 8K, golden hour, DSLR.
+- Negative prompts accepted: `--no cartoon, illustration, text`.
+- Routes through fal/Replicate — model slug: `fal-ai/flux-pro` or `black-forest-labs/flux-pro`.
+
+### Recraft (vector / SVG logos and icons)
+
+- **Style param is mandatory**: `style: vector_illustration` (SVG output),
+  `style: icon` (for simplified marks), `style: realistic_image` (raster fallback).
+- Keep prompt minimal — recraft interprets shape semantics: `"minimalist leaf icon, single color"`.
+- Avoid photographic language (lighting, bokeh, grain) — it has no effect on vector output.
+- Key params: `model: recraftv3`, `response_format: url`.
+
+### Gemini-image / GPT Image 2 (general art, edits, multimodal)
+
+- **Natural language** works well — no special syntax required.
+- Be explicit about style: `"watercolor illustration"`, `"flat design"`, `"oil painting"`.
+- For GPT Image 2 image editing: include the edit instruction after describing the target:
+  `"Remove the background and replace with a solid pastel blue"`.
+- Gemini: submit via `generateContent` (Nano Banana family) or `imagen-4.0:predict` (Imagen 4).
+
+## Procedure
+
+1. **Receive the brief** — extract: subject, style, output format (raster/vector/banner),
+   target provider (from `image-provider-routing` or explicitly stated).
+2. **Structure the prompt blocks** — subject · style · composition · technical params.
+3. **Apply provider grammar** from the section above for the target model.
+4. **Tune for the job shape** — text-literal first for Ideogram; noun-phrase first for Flux;
+   minimal + `style:` param for Recraft; natural language for Gemini/GPT.
+5. **Inspect the adapter header** — open `src/scripts/ai-image/adapters/<provider>.sh`
+   and confirm the param enums (aspect/style/model) the prompt relies on still match.
+6. **Emit the prompt** in the Output format below.
+
+## Output format
+
+1. **Target provider** — name + adapter file reference.
+2. **Prompt string** — the exact string to pass to the adapter, ready to copy.
+3. **Key params** — any model-specific fields (aspect ratio, style, negative prompts).
+4. **Variant** (optional) — one alternative phrasing when the brief is ambiguous.
+
+## Gotcha
+
+- **Per-provider param enums drift** — `aspect_ratio`, `style`, and `model` enum values
+  are ASSUMED from the adapter header comments. Verify against live API docs before
+  promotion; never hardcode these in production without a smoke trace.
+- **Adapters are scaffold-tier** — prompts authored here are not live-validated.
+  Actual rendering requires adapter promotion to `stable` per `provider-lifecycle-discipline`.
+- Recraft: photographic descriptors (`bokeh`, `lighting`, `grain`) silently have no effect
+  on vector output — strip them to avoid prompt budget waste.
+
+**Good example:** Ideogram brief for a bakery logo — lead with the text literal:
+`'"Le Four" in warm serif, vintage French patisserie style, cream and terracotta'.`
+
+**Bad example:** Sending a photorealism-heavy Flux prompt to Recraft — the style
+descriptors will be ignored and the vector output will be wrong.
+
+## Do NOT
+
+- Do NOT send photographic descriptors (`bokeh`, `lighting`, `grain`) to Recraft —
+  they have no effect on vector output and waste the prompt budget.
+- Do NOT hardcode ASSUMED param enums into a live run without a smoke trace —
+  verify against the adapter header / provider docs first.
+- Do NOT embed a real person's likeness, a trademarked brand mark, or a named living
+  artist's style in a prompt without the rights check (`image-likeness-and-rights`).
+- Do NOT write a prompt before the provider is chosen — route via `image-provider-routing` first.
+
+## See also
+
+- [`image-provider-routing`](../image-provider-routing/SKILL.md) — select the provider before writing the prompt.
+- [`provider-lifecycle-discipline`](../../rules/provider-lifecycle-discipline.md) — lifecycle tier gates live runs.
+- `src/scripts/ai-image/adapters/` — adapter header comments for param enums.
+- [`image-likeness-and-rights`](../../rules/image-likeness-and-rights.md) — rights check before generating real-person likenesses or brand marks.

package/dist/agent-src/skills/prompt-engineering-image/evals/triggers.json

@@ -0,0 +1,17 @@
+{
+  "skill": "prompt-engineering-image",
+  "last_eval": "2026-06-16",
+  "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers translating a brief into provider-specific prompt grammar. Should-not-trigger covers near-miss neighbors: provider selection (image-provider-routing), direct adapter invocation, media rights checks (media-governance-routing / image-likeness-and-rights), and general image editing.",
+  "queries": [
+    {"q": "write me an Ideogram prompt for a bakery logo with the name on it", "trigger": true},
+    {"q": "how do I structure a Flux prompt for a photoreal product shot?", "trigger": true},
+    {"q": "my Recraft prompt isn't generating SVG — what params am I missing?", "trigger": true},
+    {"q": "tune this prompt for Gemini image generation: artisan bread, rustic kitchen", "trigger": true},
+    {"q": "what's the right prompt grammar for GPT Image 2 when editing a background?", "trigger": true},
+    {"q": "which image provider should I use for a logo with text?", "trigger": false, "note": "provider selection question → image-provider-routing"},
+    {"q": "run the Ideogram adapter with my prompt", "trigger": false, "note": "direct adapter invocation — not prompt authoring"},
+    {"q": "can I put a celebrity's face in this image?", "trigger": false, "note": "likeness rights question → media-governance-routing / image-likeness-and-rights"},
+    {"q": "remove the background from this photo", "trigger": false, "note": "editing request, not prompt authoring for a provider"},
+    {"q": "what lifecycle tier is the Recraft adapter?", "trigger": false, "note": "lifecycle tier query → provider-lifecycle-discipline"}
+  ]
+}

package/dist/agent-src/skills/prompt-engineering-patterns/SKILL.md

@@ -144,7 +144,7 @@ Production prompts handle their own failure cases:
 
 ## Provenance
 
-- Adopted from: `Microck/ordinary-claude-skills@8f5c83174f7aa683b4ddc7433150471983b93131:skills_all/prompt-engineering-patterns/SKILL.md` (MIT, © 2025 Microck) — restructured into a decision-framework shape; vendor `prompt_optimizer` Python snippets dropped (project-specific to Microck).
+- Adopted from: an external reference (MIT, © 2025 an external reference) — restructured into a decision-framework shape; vendor `prompt_optimizer` Python snippets dropped (project-specific to an external reference).
 - Cross-linked: [`prompt-optimizer`](../prompt-optimizer/SKILL.md), [`refine-prompt`](../refine-prompt/SKILL.md), [`mcp-builder`](../mcp-builder/SKILL.md), [`async-python-patterns`](../async-python-patterns/SKILL.md).
 - Provenance registry: `agents/settings/contexts/skills-provenance.yml` (entry: `prompt-engineering-patterns`).
 - Iron-Law floor: `verify-before-complete`, `skill-quality`, `non-destructive-by-default`.

package/dist/agent-src/skills/prompt-validator/evals/triggers.json

@@ -1,5 +1,6 @@
 {
   "skill": "prompt-validator",
+  "last_eval": "2026-06-16",
   "description": "5 should-trigger + 5 should-not-trigger queries. Should-trigger covers the pre-spend batch-contradiction gate (style / character / physics / lip-sync ownership). Should-not-trigger covers near-miss neighbors: single-prompt craft (video-director), LLM prompt tuning (prompt-optimizer / prompt-engineering-patterns), and vocal-map validation (validate-vocal-map.sh path).",
   "queries": [
     {"q": "validate the prompts before we render", "trigger": true},

package/dist/agent-src/skills/react-shadcn-ui/SKILL.md

@@ -203,11 +203,18 @@ not the initial apply — it also emits:
   envelope on apply passes; the engine's `_apply_a11y_gate` only fires
   when a baseline is present.
 - `state.ui_review.preview` — `{render_ok: bool, screenshot_path?,
-  dom_dump_path?, error?, skipped?}`. `render_ok: false` with `error`
-  populated triggers the `preview_render_failed` halt; `render_ok: true`
-  with `screenshot_path` threads the screenshot into the delivery
-  report's `artifacts` list. Browser tooling (Playwright/Cypress/…) is
-  a consumer-project dependency — this package does not ship one.
+  dom_dump_path?, error?, skipped?, skip_reason?}`. **Render evidence is
+  required, not optional** on a review/polish pass: you MUST drive the
+  headless browser (Playwright + axe-core) against the rendered output and
+  write `render_ok`. Omitting it now triggers the `preview_render_required`
+  halt — a render-capable stack can no longer claim success without
+  rendering. `render_ok: false` with `error` populated triggers the
+  `preview_render_failed` halt; `render_ok: true` with `screenshot_path`
+  threads the screenshot into the delivery report's `artifacts` list. The
+  only no-render path is an **explicit, reasoned skip**: set `skipped: true`
+  plus a `skip_reason` (e.g. no Playwright runner in this env). Browser
+  tooling (Playwright/Cypress/…) is a consumer-project dependency — this
+  package does not ship one.
 
 Polish dispatch: when the dispatcher skips `review` because a previous
 review pass already returned `SUCCESS`, this skill MUST itself