@event4u/agent-config 6.1.0 → 7.0.0

package/dist/agent-src/skills/doc-coauthoring/evals/triggers.json

@@ -1,5 +1,6 @@
 {
   "skill": "doc-coauthoring",
+  "last_eval": "2026-06-16",
   "description": "5 should-trigger + 5 should-not-trigger queries. Should-trigger phrasings reflect real co-authoring asks for PRDs / specs / decision docs. Should-not-trigger near-misses share doc-writing vocabulary but route elsewhere (agent-docs-writing, readme-writing, adr-create, code docs, translations).",
   "queries": [
     {"q": "Help me draft a PRD for the new analytics feature — I have a lot of context but no structure yet", "trigger": true},

package/dist/agent-src/skills/eloquent/evals/triggers.json

@@ -1,5 +1,6 @@
 {
   "skill": "eloquent",
+  "last_eval": "2026-06-16",
   "description": "5 should-trigger + 5 should-not-trigger queries. A-class accepted ambiguity (e.g. 'User*' substring pulling eloquent alongside a non-Model intent) is marked with trigger=true and a note — the router loading eloquent is defensible, not a routing failure. Near-misses share Laravel/database vocabulary (migration, seeder, model, SQL) without being Model:: read/write tasks.",
   "queries": [
     {"q": "fetch all users with their latest order eagerly", "trigger": true},

package/dist/agent-src/skills/emit-tickets/SKILL.md

@@ -0,0 +1,198 @@
+---
+model_tier: high
+name: emit-tickets
+description: "Use when materialising a roadmap into a ticket bundle — 'turn this roadmap into tickets', 'materialise tickets', 'mach Tickets aus der Roadmap', 'emit tickets for this plan'."
+domain: process
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# emit-tickets
+
+Materialise a roadmap into an `agents/tickets/{slug}/` bundle — one ticket per
+buildable step — then wire the markers back and run the buildability gate.
+
+## When to use
+
+| Signal | Match |
+|---|---|
+| "turn this roadmap into tickets" | yes |
+| "materialise / emit tickets for \<roadmap\>" | yes |
+| "mach Tickets aus der Roadmap" | yes |
+| "plan the work for \<roadmap\>" | yes |
+| User wants a YAML ticket bundle, not a prose plan | yes |
+| Refining or splitting an existing ticket | no → use `refine-ticket` |
+| Estimating a single ticket | no → use `estimate-ticket` |
+
+**Upstream:** `roadmap-writing` — author the roadmap first.
+**Downstream:** `src/scripts/lint_ticket_buildable.ts` (the build-readiness gate). A ticket reaches a tracker by paste or MCP (ADR-102) — no export script.
+
+## Procedure
+
+Steps at a glance:
+
+1. Locate and parse the roadmap.
+2. Create `agents/tickets/{slug}/` and draft one ticket YAML per materializable step.
+3. Assign `model_tier` via the granularity floor; split oversized steps.
+4. Compute SHA refs for `adr_refs` / `source_refs`.
+5. Write `manifest.yml` with acyclic `dependency_graph` and empty `linear_state`.
+6. Append `<!-- ticket: T-NNN -->` markers back into the roadmap.
+7. (Re)generate `agents/tickets/_registry.yml`.
+8. Run `lint_ticket_buildable.py` until exit 0 (max 3 attempts).
+9. Tell the user the bundle is ready: paste a ticket into Linear/Jira, or have the agent create it via a tracker MCP server (ADR-102 — no API export).
+
+### §0 — Locate the roadmap
+
+Confirm the roadmap slug and open `agents/roadmaps/{slug}.md`. Identify all
+materializable steps (checkbox items that describe a code or docs change). Skip
+informational steps, phase headings, and acceptance-criteria prose.
+
+### §1 — Derive the bundle slug
+
+`agents/tickets/{slug}/` — same slug as the roadmap. Create the directory.
+
+### §2 — One ticket per step
+
+For each materializable step, draft a ticket YAML:
+
+~~~yaml
+id: T-NNN
+roadmap: {slug}
+phase: {N}
+title: "{step text, ≤80 chars}"
+status: ready
+model_tier: {lite | medium | high}   # see §3
+estimate: {story-points, integer}
+priority: {1=critical … 4=low}
+labels: []
+parent: null
+blocked_by: []
+adr_refs: []
+source_refs: []
+assets: none
+acceptance:
+  - "{measurable done criterion}"
+boundaries:
+  must_touch: []
+  may_touch: []
+  must_not_touch: []
+~~~
+
+Use `estimate-ticket`, `technical-specification`, or `refine-ticket` when a
+step needs deep estimation or spec work.
+
+### §3 — Assign model_tier by granularity floor
+
+Apply this floor **before** marking any ticket `lite`:
+
+| Criterion | Required for `lite` |
+|---|---|
+| Files touched | ≤ 5 |
+| Lines changed | ≤ 200 |
+| Isolation-testable | yes — no cross-module side effects |
+
+- All three pass → `lite`
+- Any miss → split the ticket further, or escalate to `medium`
+- Architectural / multi-module → `high` (use `adr-create` first)
+
+**Gate:** run `python3 src/scripts/lint_ticket_buildable.ts agents/tickets/{slug}/`
+and fix all errors before declaring any ticket `lite`. This is the only
+authoritative check — do not skip it.
+
+### §4 — Compute SHA refs
+
+For each `adr_refs` and `source_refs` entry:
+
+```bash
+git rev-parse HEAD:path/to/file
+```
+
+Fill the `sha:` field with the result, or `pending` for files not yet committed.
+
+### §5 — Write manifest.yml
+
+~~~yaml
+bundle: {slug}
+generated: {ISO-8601 date}
+dependency_graph:
+  T-001: []
+  T-002: [T-001]
+  # … acyclic; no circular deps
+linear_state: {}   # always empty at emit time
+~~~
+
+Verify acyclicity by tracing every `blocked_by` chain — no ticket may appear
+in its own transitive dependency set.
+
+### §6 — Write markers back into the roadmap
+
+For each materializable step in `agents/roadmaps/{slug}.md`, append
+`<!-- ticket: T-NNN -->` to the end of the step line:
+
+```
+- [ ] Add X to Y  <!-- ticket: T-003 -->
+```
+
+One marker per step; do not duplicate on re-run (check before appending).
+
+### §7 — (Re)generate _registry.yml
+
+Append or update the bundle entry in `agents/tickets/_registry.yml`:
+
+~~~yaml
+bundles:
+  - slug: {slug}
+    path: agents/tickets/{slug}/
+    status: draft
+    ticket_count: {N}
+~~~
+
+If the file does not exist, create it with the `bundles:` root.
+
+### §8 — Run the buildability gate
+
+```bash
+python3 src/scripts/lint_ticket_buildable.ts agents/tickets/{slug}/
+```
+
+Fix every reported error. Re-run until exit code 0. Max 3 attempts; if still
+failing, surface the linter output and ask for guidance.
+
+### §9 — Hand off (paste / MCP)
+
+Tell the user:
+
+> Bundle written to `agents/tickets/{slug}/`. Each ticket's body is
+> paste-ready Markdown for a Linear/Jira issue; or create issues via a
+> tracker MCP server. No API export (ADR-102).
+
+Do NOT auto-create tracker issues — paste/MCP is the user's call.
+
+## Output format
+
+1. `agents/tickets/{slug}/manifest.yml` — bundle manifest (acyclic graph, empty linear_state)
+2. `agents/tickets/{slug}/T-NNN-{slug}.md` — one file per ticket (YAML frontmatter)
+3. `agents/tickets/_registry.yml` — updated bundle registry
+4. Inline `<!-- ticket: T-NNN -->` markers in the source roadmap
+
+## Do NOT
+
+- Implement or invent ticket content not traceable to a roadmap step.
+- Touch `src/scripts/**` — orchestrate; do not reimplement.
+- Mark a ticket `lite` before `lint_ticket_buildable.py` passes.
+- Create a circular `dependency_graph` — verify acyclicity before writing.
+- Auto-create tracker issues — paste/MCP is the user's call (ADR-102, no API export).
+- Reuse T-NNN numbers from another bundle in the same registry.
+
+## Gotchas
+
+- **Re-run safety:** before appending `<!-- ticket: T-NNN -->` markers, grep
+  for existing markers so a re-run does not duplicate them.
+- **SHA = pending:** new files not yet committed get `sha: pending`; remind
+  the user to re-run after commit to update SHAs.
+- **Split signals:** if a step touches > 5 files or > 200 lines, split it
+  into two tickets and add a `blocked_by` dependency before continuing.
+- **Format contract:** `docs/contracts/ticket-bundle-format.md` is the
+  authoritative schema; `src/agent-src/templates/tickets.md` is the template.

package/dist/agent-src/skills/estimate-ticket/evals/triggers.json

@@ -1,5 +1,6 @@
 {
   "skill": "estimate-ticket",
+  "last_eval": "2026-06-16",
   "version": 1,
   "should_trigger": [
     "estimate PROJ-123",

package/dist/agent-src/skills/git-workflow/SKILL.md

@@ -23,6 +23,39 @@ Do NOT use when:
 - Code writing or review (use `php-coder` or `code-review` skill)
 - CI/CD pipeline changes (use `github-ci` skill)
 
+## Live remote state first — never from memory
+
+```
+BEFORE ANY MERGE / PUSH / PR / BRANCH ACTION — OR ANY CLAIM OR QUESTION
+ABOUT THEIR STATE — QUERY THE LIVE REMOTE. NEVER FROM MEMORY OR
+CONVERSATION HISTORY. A PR MAY ALREADY BE MERGED OR CLOSED REMOTELY.
+ASKING WHAT `gh pr view` ANSWERS IS A CHEAP QUESTION — CHECK, DON'T ASK.
+```
+
+Local branch view + conversation memory both go stale the moment anyone else — a
+maintainer, a parallel agent, an auto-merge rule — acts on the remote. Acting or
+asking on stale state is the recurring failure this kills (canonical: asking
+"shall I merge these 4 PRs?" when all four were already merged remotely). Run
+first, **every time**:
+
+```bash
+git fetch origin --quiet
+gh pr view <number> --json number,state,mergeStateStatus,mergedAt,baseRefName
+# state: OPEN | MERGED | CLOSED — act only on the live value
+```
+
+- **A state question is self-answering** — never ask "is it merged?",
+  "mergeable?", "did it push?", "still open?". `gh pr view` / `git fetch` answers
+  it; asking is a cheap question (per `no-cheap-questions`).
+- **`MERGED` / `CLOSED`** → nothing to merge or push; report the live state and
+  stop.
+- **Before merging** → re-fetch + re-read `state` + `mergeStateStatus` in the
+  **same turn**; never merge on a status seen earlier in the conversation.
+- **"Based on main" / "current"** → prove it with
+  `git rev-list --count HEAD..origin/main` (after `git fetch`); non-zero ⇒ behind
+  and **not** current — merge `main` in before opening a PR (see
+  [`/create-pr`](../../commands/pr/create.md) § 1b).
+
 ## Conventions
 
 → See guideline `docs/guidelines/php/git.md` for branch naming, commit messages, PR conventions.

package/dist/agent-src/skills/guideline-writing/SKILL.md

@@ -112,10 +112,10 @@ Above the split signal, break by sub-topic into sibling files in the same folder
 
 ### 6. Validate
 
-* Run `python3 scripts/skill_linter.py docs/guidelines/{topic}/{name}.md`
+* Run `./scripts-run src/scripts/skill_linter docs/guidelines/{topic}/{name}.md`
   → 0 FAIL (guidelines have relaxed linting but must still parse).
 * Run `bash scripts/condense.sh --sync` → projects updates.
-* Run `python3 scripts/check_references.py` → no broken links.
+* Run `./scripts-run src/scripts/check_references` → no broken links.
 * Run the full CI pipeline locally (see `Taskfile.yml` in this repo for
   the script list) — must exit 0 except for tolerated warnings.
 

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

@@ -0,0 +1,88 @@
+---
+model_tier: inherit
+name: iconography
+description: "Resolve an icon request to a concrete Iconify name and emit the embedding for the project's stack. Use when adding icons, picking an icon set, or wiring Lucide/Heroicons/Phosphor/Tabler."
+domain: product
+personas: []
+workspaces:
+  - engineering
+packs:
+  - frontend-design
+trust:
+  level: professional
+install:
+  removable: true
+execution:
+  type: manual
+---
+
+# iconography
+
+> Resolve an icon request to a verified Iconify name (`set:name`) and emit the
+> correct embedding for the project's stack — CSS class, inline SVG, or
+> framework component — while keeping icon-set usage consistent across the UI.
+
+## When to use
+
+- Adding any icon to a component or page.
+- Picking an icon set for a new project or feature area.
+- Wiring Lucide, Heroicons, Phosphor, or Tabler into a stack (React, Blade, Tailwind).
+- Auditing inconsistent icon usage across a UI surface.
+
+## Procedure
+
+1. **Identify the icon need** — what does the icon communicate? Name the semantic
+   intent (e.g., "download action", "warning state", "user profile") rather than
+   visual description alone.
+2. **Pick the icon set** per stack and brand context. Default open sets:
+   **Lucide** (clean, Tailwind-native), **Heroicons** (Tailwind/React first-party),
+   **Phosphor** (multi-weight, flexible), **Tabler** (comprehensive, stroke-based).
+   Brand/provider marks use **lobe-icons** (`lobe-icons:openai-color`, etc.).
+   Stack consumers: `react-shadcn-ui` → Lucide; `blade-ui` → Heroicons or Lucide;
+   `tailwind-engineer` → any web-font-friendly set.
+3. **Resolve to a concrete Iconify name** in `set:name` format, e.g.
+   `lucide:arrow-right`, `heroicons:user-solid`, `ph:warning-bold`,
+   `tabler:download`. Verify the name exists on
+   [iconify.design](https://iconify.design) before emitting.
+4. **Emit the embedding** matched to the stack:
+   - **CSS class (web-font path)** — `<span class="iconify" data-icon="lucide:arrow-right"></span>` plus the Iconify CDN or build-time bundle.
+   - **Inline SVG** — fetch the SVG from the Iconify API (`https://api.iconify.design/{set}/{name}.svg`) and embed directly.
+   - **Framework component** — `<Icon icon="lucide:arrow-right" />` via `@iconify/react`, `@iconify/vue`, or the stack's Iconify wrapper.
+5. **Verify** — check the resolved name on `iconify.design/icon/{set}:{name}`;
+   confirm the icon renders as expected before shipping.
+
+## Output format
+
+1. **Iconify name** — `set:name` string, e.g. `lucide:arrow-right`.
+2. **Embedding snippet** — the ready-to-paste code for the project's stack
+   (CSS class, inline SVG, or component import + usage).
+3. **Set/consistency note** — which set was chosen, why, and whether it matches
+   the icons already in use in this codebase.
+
+## Gotcha
+
+- **Mixing icon sets in one UI looks inconsistent.** Lucide and Heroicons have
+  different stroke weights and visual rhythm; mixing them without a deliberate
+  brand reason produces a jarring result. Audit the existing set before
+  introducing a second one.
+- **Nonexistent Iconify names 404 silently.** A name like `lucide:arrowRight`
+  (camelCase) or `heroicons:user` (missing `-solid`/`-outline` suffix) resolves
+  to nothing at render time — the slot is empty with no error. Always verify on
+  `iconify.design` before committing the snippet.
+
+## Do NOT
+
+- Do NOT mix multiple icon sets in the same UI surface without an explicit brand
+  reason and a note in the set/consistency output.
+- Do NOT inline hundreds of raw SVGs when a CSS-class web-font set is available —
+  the bundle cost is orders of magnitude higher than a single Iconify CDN include.
+- Do NOT invent Iconify names — every name must be verified to exist in the
+  Iconify registry; a plausible-sounding name that doesn't exist renders as
+  nothing.
+
+## See also
+
+- [`design-tokens`](../design-tokens/SKILL.md) — token system the icon color/size variables should reference.
+- [`typography-system`](../typography-system/SKILL.md) — sibling visual-consistency skill.
+- [`fe-design`](../fe-design/SKILL.md) — broader frontend design discipline.
+- [`icon-consistency`](../../rules/icon-consistency.md) — enforced rule for set discipline across the project.

package/dist/agent-src/skills/iconography/evals/triggers.json

@@ -0,0 +1,17 @@
+{
+  "skill": "iconography",
+  "last_eval": "2026-06-16",
+  "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers icon resolution, set selection, and embedding tasks. Should-not-trigger covers near-miss neighbors: typography-system (font/type choices), design-tokens (CSS variable authoring), image-provider-routing (AI-generated images), and a generic draw-an-icon image-gen request.",
+  "queries": [
+    {"q": "which icon should I use for a download action in Lucide?", "trigger": true},
+    {"q": "add a warning icon to this component — we use Heroicons", "trigger": true},
+    {"q": "pick an icon set for our new React app", "trigger": true},
+    {"q": "wire Phosphor icons into our Blade templates", "trigger": true},
+    {"q": "resolve the Iconify name for a user-profile icon in Tabler", "trigger": true},
+    {"q": "pick a font pairing for our marketing page", "trigger": false, "note": "font/type selection → typography-system"},
+    {"q": "author CSS variables for our color palette", "trigger": false, "note": "token authoring → design-tokens"},
+    {"q": "which AI image model should I use for a product icon illustration?", "trigger": false, "note": "AI image generation routing → image-provider-routing"},
+    {"q": "draw me an icon for a mobile app in Midjourney", "trigger": false, "note": "image-gen request, not Iconify/UI icon resolution"},
+    {"q": "set up dark mode token overrides for our design system", "trigger": false, "note": "dark-mode token authoring → design-tokens"}
+  ]
+}

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

@@ -1,5 +1,6 @@
 {
   "skill": "image-analyser",
+  "last_eval": "2026-06-16",
   "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers the analyse / canon-diff / accuracy-check / drift-find / bootstrap-from-portrait paths (DE + EN). Should-not covers the near-miss neighbours whose vocabulary overlaps: scene/motion review (video-director), non-character art (canvas-design), cross-scene token lock (character-consistency), generation (image-creator), and document OCR (generic).",
   "queries": [
     {"q": "analyse this character image down to the last detail", "trigger": true},

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

@@ -1,5 +1,6 @@
 {
   "skill": "image-creator",
+  "last_eval": "2026-06-16",
   "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers generate/render/to-spec/loop-fix paths (DE + EN). Should-not covers near-miss neighbours: analysis (image-analyser), scene/motion (video-director, motion-choreographer), non-character art (canvas-design), and token-lock (character-consistency).",
   "queries": [
     {"q": "generate Veikko in the forge scene, matched to the canon", "trigger": true},

package/dist/agent-src/skills/image-editing/SKILL.md

@@ -0,0 +1,100 @@
+---
+model_tier: inherit
+name: image-editing
+description: "Edit an existing image — inpaint, background swap, variation — via providers that support it. Use when editing/modifying/inpainting an image or making variations."
+domain: product
+personas: []
+workspaces:
+  - small-business
+packs:
+  - ai-image
+trust:
+  level: experimental
+install:
+  removable: true
+execution:
+  type: manual
+---
+
+# image-editing
+
+Edit or vary an existing image: inpaint masked regions, swap backgrounds, produce
+variations from a seed, or upscale — routed to providers that support the edit API,
+with governance applied before delivery. All adapters are scaffold-tier (dry-run) until promoted to `stable`.
+
+## When to use
+
+- User asks to edit, modify, inpaint, or make a variation of an existing image.
+- Background removal or swap on a provided asset.
+- Upscaling or restyling an existing render from a prior generation run.
+- Any task that starts from an image rather than a blank brief.
+
+## Procedure
+
+1. **Identify the edit type** — classify the request: `inpaint` (replace a masked
+   region), `background` (remove or swap), `variation` (alternate version of the
+   same subject), or `upscale` (resolution increase).
+2. **Confirm provider support** — not all providers support image editing. GPT Image 2
+   and `gemini-image` both expose an edit/inpaint endpoint. Flux and Recraft support
+   variation via seed/ref-image only; Ideogram is largely generate-only. Check
+   the provider's capability before proceeding.
+3. **Route the provider** via [`image-provider-routing`](../image-provider-routing/SKILL.md) —
+   route to a provider whose adapter exposes an edit endpoint for the required edit
+   type. Selecting a generate-only provider for an inpaint task will fail silently.
+4. **Author the edit instruction** via [`prompt-engineering-image`](../prompt-engineering-image/SKILL.md) —
+   write the edit prompt in the target provider's grammar. For inpaint, describe what
+   fills the masked region. For variation, carry the original seed/ref-image path forward.
+5. **Invoke the adapter (dry-run today)** — run
+   `src/scripts/ai-image/adapters/<provider>.sh` with the assembled params including
+   the source image path and, for inpaint, the mask path. Validate the returned
+   artifact path or dry-run confirmation. All adapters are `experimental`
+   (scaffold-tier); no live editing occurs until a maintainer promotes the adapter
+   via `provider-lifecycle-discipline`.
+6. **Apply rights and disclosure governance** — run the rights check
+   (`image-likeness-and-rights`) when the source image or edit instruction involves
+   a real person's likeness, a brand mark, or a named living artist's style. Attach
+   the AI-disclosure footer per `media-governance-routing` before delivering output.
+
+## Output format
+
+1. **Edit plan** — edit type, chosen provider, routing rationale, and prompt string
+   ready to copy.
+2. **Provider + params** — adapter file reference, source image path, mask path (if
+   inpaint), key params (aspect ratio, strength, seed/ref-image for variation).
+3. **Artifact path / dry-run note** — the path returned by the adapter, or an
+   explicit note: "adapter is experimental (scaffold-tier) — dry-run plan only; no
+   edited asset until promotion per `provider-lifecycle-discipline`."
+
+## Gotcha
+
+- **Scaffold-tier adapters produce plans, not pixels** — adapters for GPT Image 2,
+  `gemini-image`, Flux, and Recraft are **scaffold-tier** (dry-run only). This skill
+  produces the edit blueprint + dry-run confirmation; actual edits require a
+  maintainer to capture a smoke trace and promote the adapter to `stable`. Claiming
+  an edited asset exists when no adapter is stable misleads the caller.
+- **Not all providers support editing** — Ideogram and Recraft are primarily
+  generate-only; they do not expose a mask-based inpaint endpoint. Routing an
+  inpaint task to them silently falls back to generation from scratch, discarding the
+  source image entirely.
+- **Variation needs the original seed or ref-image** — requesting a variation without
+  carrying the seed value or ref-image path from the original generation will produce
+  a stylistically unrelated result. The seed/ref-image is the only reliable
+  continuity lever for variation workflows.
+
+## Do NOT
+
+- Do NOT assume every provider supports image editing — check provider capability
+  before routing; a generate-only provider will discard the source image.
+- Do NOT skip `image-likeness-and-rights` when the source image or edit prompt
+  involves a real person's face, a brand mark, or a named living artist's style.
+- Do NOT claim a live edit is produced while adapters are scaffold-tier — surface
+  the dry-run caveat explicitly every time.
+- Do NOT use this skill for generating a new image from scratch — route that to
+  [`image-generation`](../image-generation/SKILL.md) instead.
+
+## See also
+
+- [`image-generation`](../image-generation/SKILL.md) — generate a new image from a brief (not editing an existing one).
+- [`image-provider-routing`](../image-provider-routing/SKILL.md) — select the right provider before writing the prompt.
+- [`prompt-engineering-image`](../prompt-engineering-image/SKILL.md) — translate the edit brief into provider-specific prompt grammar.
+- [`image-likeness-and-rights`](../../rules/image-likeness-and-rights.md) — rights check before editing real-person likenesses or brand marks.

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

@@ -0,0 +1,17 @@
+{
+  "last_eval": "2026-06-16",
+  "true": [
+    "edit the background of this product shot to a white studio setting",
+    "inpaint the logo out of the upper-right corner of this image",
+    "make a variation of this hero image in a warmer colour palette",
+    "remove the person standing on the left side of the photo",
+    "modify this existing render — I want the sky replaced with a sunset"
+  ],
+  "false": [
+    "generate a new product shot from scratch — I have no existing image",
+    "which image provider should I use for this job?",
+    "create a logo for my company",
+    "how do I write a good prompt for Ideogram?",
+    "do I need a rights check before using a celebrity's likeness in my image?"
+  ]
+}

package/dist/agent-src/skills/image-generation/SKILL.md

@@ -0,0 +1,95 @@
+---
+model_tier: inherit
+name: image-generation
+description: "Generate an image from a brief — provider-agnostic blueprint then provider-specific translation, with ref-image/seed reuse for consistency. Use when generating/creating an image."
+domain: product
+personas: []
+workspaces:
+  - small-business
+packs:
+  - ai-image
+trust:
+  level: experimental
+install:
+  removable: true
+execution:
+  type: manual
+---
+
+# image-generation
+
+Generate an image end-to-end: capture the brief, route to the right provider, author
+a provider-specific prompt, reuse seeds for consistency, invoke the adapter, and apply
+governance. All adapters are scaffold-tier (dry-run) until promoted to `stable`.
+
+## When to use
+
+- User asks to generate, create, or produce an image from a brief.
+- End-to-end image production (routing + prompting + adapter invocation + governance).
+- When a consistent series of images needs seed/ref-image reuse across renders.
+
+## Procedure
+
+1. **Capture the brief** — extract: subject, output format (raster/vector/banner/icon),
+   style intent, any existing ref images or seed values for consistency.
+2. **Route the provider** via [`image-provider-routing`](../image-provider-routing/SKILL.md) —
+   match job shape (text-in-image → Ideogram, photoreal → Flux, vector → Recraft,
+   general → Gemini/GPT Image 2).
+3. **Author the prompt** via [`prompt-engineering-image`](../prompt-engineering-image/SKILL.md) —
+   apply provider-specific grammar (text-literal first for Ideogram, noun-phrase for Flux,
+   `style:` param for Recraft, natural language for Gemini/GPT).
+4. **Reuse ref-image / seed for consistency** — if the brief is part of a series, carry
+   the seed value or ref-image path forward. Seed reuse is the primary consistency lever;
+   re-describing the subject each time is not.
+5. **Invoke the adapter (dry-run today)** — run `src/scripts/ai-image/adapters/<provider>.sh`
+   with the assembled params. Validate the returned artifact path or dry-run confirmation.
+   All adapters are `experimental` (scaffold-tier); no live generation occurs until a
+   maintainer promotes the adapter via `provider-lifecycle-discipline`.
+6. **Apply governance** — run the rights check (`image-likeness-and-rights`) when the
+   brief names a real person, brand mark, or living artist's style. Attach the AI-disclosure
+   footer per `media-governance-routing` before delivering the output.
+
+## Output format
+
+1. **Blueprint** — provider choice + routing rationale + prompt string ready to copy.
+2. **Provider + prompt** — adapter file reference, key params (aspect ratio, style,
+   negative prompts), and any seed/ref-image value carried forward.
+3. **Artifact path / dry-run note** — the path returned by the adapter, or an explicit
+   note: "adapter is experimental (scaffold-tier) — dry-run plan only; no rendered
+   asset until promotion per `provider-lifecycle-discipline`."
+
+## Gotcha
+
+- **Scaffold-tier adapters produce plans, not pixels** — all four adapters (`ideogram.sh`,
+  `flux.sh`, `recraft.sh`, `gemini-image.sh`) are **scaffold-tier** (dry-run only). This
+  skill produces the blueprint + dry-run confirmation; actual renders require a maintainer
+  to capture a smoke trace and promote the adapter to `stable`. Claiming a rendered asset
+  exists when no adapter is stable misleads the caller.
+- **Seed reuse is the consistency lever** — re-describing the subject more precisely
+  in each prompt does not lock character or style; carrying the seed value or ref-image
+  path forward does. Drop the seed and character drift is inevitable across a series.
+
+**Good example:** Brief for a product-shot series → route to Flux (photoreal), author
+noun-phrase prompt, carry `seed: 42` across all five renders, invoke adapter, note
+"experimental — dry-run plan only."
+
+**Bad example:** Invoking the adapter and telling the user "here is your rendered image"
+while all adapters are still scaffold-tier.
+
+## Do NOT
+
+- Do NOT claim a rendered asset is produced while adapters are scaffold-tier — surface
+  the dry-run caveat explicitly every time.
+- Do NOT skip `image-likeness-and-rights` when the brief names a real person, a brand
+  mark, or a named living artist's style.
+- Do NOT bypass `image-provider-routing` — selecting the wrong provider for the job
+  shape (e.g. Flux for a text-in-image logo) produces garbled output.
+- Do NOT ignore seed/ref-image values when consistency across a series is required —
+  seed reuse is the only reliable consistency mechanism.
+
+## See also
+
+- [`image-provider-routing`](../image-provider-routing/SKILL.md) — select the right provider before writing the prompt.
+- [`prompt-engineering-image`](../prompt-engineering-image/SKILL.md) — translate the brief into provider-specific prompt grammar.
+- [`image-likeness-and-rights`](../../rules/image-likeness-and-rights.md) — rights check before generating real-person likenesses or brand marks.
+- [`provider-lifecycle-discipline`](../../rules/provider-lifecycle-discipline.md) — lifecycle tier gates; read before any adapter invocation.

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

@@ -0,0 +1,17 @@
+{
+  "skill": "image-generation",
+  "last_eval": "2026-06-16",
+  "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers end-to-end image generation requests (brief → render). Should-not-trigger covers near-miss neighbors: routing-only questions (image-provider-routing), prompt-writing-only (prompt-engineering-image), image editing (image-editing), logo-specific flows (logo-generation), and rights checks (image-likeness-and-rights).",
+  "queries": [
+    {"q": "generate an image of a product shot for our new coffee mug", "trigger": true},
+    {"q": "create a banner image for our bakery with the name on it", "trigger": true},
+    {"q": "I need an image generated for our website hero section", "trigger": true},
+    {"q": "produce a series of consistent character illustrations for our app onboarding", "trigger": true},
+    {"q": "generate a square social media image of a smiling barista", "trigger": true},
+    {"q": "which image model should I use for a logo with text?", "trigger": false, "note": "routing-only question → image-provider-routing"},
+    {"q": "write me an Ideogram prompt for this bakery banner brief", "trigger": false, "note": "prompt authoring only → prompt-engineering-image"},
+    {"q": "edit this photo to remove the background and add a sunset", "trigger": false, "note": "editing an existing image → image-editing"},
+    {"q": "create a vector SVG logo for our brand", "trigger": false, "note": "logo-specific flow → logo-generation"},
+    {"q": "can I use this celebrity's photo as a reference for my image prompt?", "trigger": false, "note": "rights / likeness check → image-likeness-and-rights"}
+  ]
+}