create-avg

Name: create-avg
Author: Neta

Platformneta-skills/create-avg

Use it in Cohub

Paste this into your agent's chat — it fetches the skill and follows it.

Use the skill: create-avg. Run `npx -y @neta-art/neta-search-cli@latest skills use neta-skills/create-avg --via site` and follow what it prints. Read its complete output, redirecting it to a temporary file first if necessary, and resolve relative paths from the skill directory it prints.

Use in Neta Studio Open it in Neta Studio and see what people made with it.

Install from a terminal

npx -y @neta-art/neta-search-cli@latest skills use neta-skills/create-avg

Summary

Turn a story idea into a playable visual novel with branching choices and character art.

Makes a game you open and play in its own window, with dialogue choices that change the story.
Generates character portraits and backgrounds to match your world, from a single striking character to a full cast.
Asks one decision at a time: the story first, then whether to tune the art style or start building right away.
Works best when you have a premise with clear emotional stakes: a rivalry, a secret, a choice that changes everything.
Delivers a shareable link you can send to players; they click and the game runs in their browser.

SKILL.md

# Plan-first AVG Creator

This skill guides a user from a rough story idea to a playable AVG / visual novel / text adventure, using a **Plan Mode first, Build Mode second** workflow.

Core principle:

```text
Agent owns the flow.
User owns taste, canon, and final approval.
```

The agent must actively lead the process. Do not wait for the user to know the next step. At every stage, identify the current phase, summarize what is known, state the main gap, recommend the next action, and provide defaults when the user is unsure.

## Asking Contract (this skill owns how it asks)

Plan Mode's guided turns ARE this skill's asking contract: one turn, one main decision, within a 5-question budget (`references/conversation-style.md` -> Plan Question Budget).

```text
Do NOT run the questionnaire skill for an AVG build.
Not on the first turn, not before the brief, not at the Plan/Build handoff.
```

A consolidated question round and Plan Mode are the same job done twice: both settle scope, style, and gameplay direction before production. Running both makes the user answer the same decisions in two formats, and it front-loads the choices Plan Mode is designed to reach one at a time, with defaults and visual references attached.

Default to infer-first: if the premise can reasonably carry a default, produce the combined brief (Phase 2) and let the user correct it. Only ask a brief single question when the story premise is genuinely unreadable, or when a wrong guess would send the whole build off track — and ask it as one Plan Mode question, not a round.

Infer-first settles *what to ask*, not *whether to stop*. Every new game's first turn is Stage ① and ends on its yes/no — including when the opener is detailed or imperative ("make me a game where…", a full cast and plot, a named chapter) and whatever it leaves open (scope, look, how it plays): fill those gaps with defaults in the design doc, then stop. Only the user's reply to *this session's* Stage ① question opens the Fast Build Path. A `GAME-DESIGN.md` or game folder already in the world from an earlier session is not that reply — it is not this user's confirmation, and it is not yours to overwrite: start a fresh `works/games/<slug>/` and leave the old one untouched.

## Output Ownership (do not hand off to create-roleplay)

This skill owns the playable output end to end — planning, assets, runtime, and publishing.

```text
Do NOT run the create-roleplay skill as part of an AVG build.
```

The two are separate work types, not stages of one pipeline. An AVG is a Work with a screen of its own, branching nodes, and generated art; a roleplay is a persisted narrative space a game master runs turn by turn. Reaching for create-roleplay mid-build produces a second, competing artifact for the same idea and leaves the user unsure which one is their game.

If the user's real want turns out to be a chat roleplay, say so and switch skills outright — do not run both.

## Path Rule

All paths in this skill are **relative to the directory containing `SKILL.md`**.

Examples:

```text
references/workflow.md
runtime/avg-standard/
assets/style-cases/ui/INDEX.md
templates/gameplay-node-map/
```

Do not treat external workspace paths or public URLs as required dependencies for the main workflow. The bundled resources in this package are the default source of truth.

**No absolute paths, in docs or in code.** This skill is a portable package and may be mounted anywhere, so a literal mount point is a defect, not a fact about the environment — it fails mid-build in any install that differs. Shell examples use variables that are resolved once per round, and the tools derive their own location from `import.meta.url`:

| Variable | Is | Resolved by |
|---|---|---|
| `$AVG_SKILL` | the directory containing `SKILL.md` | substituted once at the start of the round |
| `$NETA` | the Neta CLI binary | `tools/resolve-paths.mjs neta` — `NETA_CLI`, then `PATH`, then `NETA_HOME` |
| `$CUTOUT_WRAPPER` | the background-removal wrapper | `tools/resolve-paths.mjs cutout` — `BACKGROUND_REMOVAL_CUTOUT`, then the sibling skill |
| `<skill-space-path>` | this directory relative to the **space** root, for `cohub spaces files cat` only | substituted per install; not the same as `$AVG_SKILL` |

Neither resolver carries a built-in fallback path. Unresolved means blocked: report the gap and stop, rather than guessing a location or improvising a substitute method. Setup lines are in `BUILD-CARD.md` and `references/build-mode.md`; host log directories resolve from the workspace root the round runs in.

## How to Read This Skill (progressive disclosure)

This skill is large. Do not read everything before starting — read the card for the mode
you are in, and read the long references only when the round leaves the default path.

**Two cards, one per mode — start here:**

| Mode | Default round | Required reading |
|---|---|---|
| **Plan Mode** (first turn, Stage ①) | premise → brief + one concept image + design doc + yes/no | **`PLAN-CARD.md`** + `references/conversation-style.md` |
| **Build Mode** (after the user says yes) | one chapter, two images, no BGM, LLM on | **`BUILD-CARD.md`** + `runtime/avg-standard/src/story/STORY-SCHEMA.md` |

Each card is self-contained for its default round: the round shape, every command in order,
the fixed scope, and the gates. Reading the full reference set for a default round costs
roughly eleven round trips before any work begins.

**Read the long references when the round leaves the default path.** Any of these means the
card is not enough: Plan Mode output beyond Stage ① (`references/workflow.md` is required
in full before it), a round that is not the first delivery, more than one character or any
expression variant, BGM, custom mechanics layered on the AVG loop, a Style Probe Gallery,
or any failure whose cause is not obvious from the gate output. Each card's closing table
maps each situation to the file that owns it. When in doubt, read the long doc: the cost of
over-reading is round trips, and the cost of under-reading is a wrong delivery.

**Required before Plan Mode output beyond Stage ①.** Read `references/workflow.md` in full
before producing any Plan Mode response past the first turn. The stage list below is a
summary index for orientation; it is not a substitute for the phase-by-phase execution
rules, gates, and required artifacts defined in `references/workflow.md`.

**Verbatim contracts.** Three items are verbatim contracts and are never satisfied by a
card's summary of them — read them at the source before the turn they belong to:

| Contract | Source |
|---|---|
| Opening announcement text | `references/build-mode.md` "Opening the build" |
| Closing handover text | `references/build-mode.md` "After every delivery" |
| Terminology rewrite rules | `references/conversation-style.md` |

## Bundled Resources

The skill is self-contained. Its mainline dependencies are bundled here:

| Need | Path |
|---|---|
| **Default Plan Mode round (start here)** | **`PLAN-CARD.md`** |
| **Default Build Mode round (start here)** | **`BUILD-CARD.md`** |
| Full workflow | `references/workflow.md` |
| Plan mode conversation style | `references/conversation-style.md` |
| Resource map | `references/resource-index.md` |
| Visual style planning | `references/visual-planning.md` |
| Image/video generation method (Neta CLI) | `references/generation-method.md` |
| Visual display mechanism (CDN link + markdown) | `references/visual-display.md` |
| Asset production requirements | `references/asset-models.md` |
| Gameplay planning | `references/gameplay-planning.md` |
| Build mode | `references/build-mode.md` |
| Build Mode dependency preflight (run first) | `tools/preflight.mjs` |
| Portable path/CLI resolver (`$NETA`, cutout wrapper, skill root) | `tools/resolve-paths.mjs` |
| Download + cutout + alpha assertion for a generated image | `tools/fetch-and-cutout.mjs` |
| Publish + verify wrapper (fail-closed) | `tools/publish-avg-work.mjs` |
| Design-doc publish at Stage ① (Work card + GDD output file) | `tools/publish-design-doc.mjs` |
| Declared Work output file (the GDD card shown beside the Work) | `tools/work-outputs.mjs` |
| LLM-path acceptance (real cohub-completion turn) | `tools/verify-work-llm.mjs` |
| LLM-off acceptance (reachability + assets) | `tools/verify-work-static.mjs` |
| Output artifact formats | `references/output-artifacts.md` |
| Bundled AVG runtime base | `runtime/avg-standard/` |
| Story authoring contract (fields, placeholders, no-numbers rule) | `runtime/avg-standard/src/story/STORY-SCHEMA.md` |
| Bundled Studio/Cohub LLM guide | `runtime/avg-standard/COHUB-WORK-LLM.md` |
| Bundled server-side Cohub prompt proxy | `runtime/avg-standard/server.mjs` |
| App Action LLM entrypoint (ships in the published artifact) | `runtime/avg-standard/.cohub/actions/llm.mjs` |
| Bundled UI style library | `assets/style-cases/ui/` |
| Bundled image style libraries | `assets/style-cases/image/` |
| Gameplay Node Map template | `templates/gameplay-node-map/` |
| Style Probe Gallery template | `templates/style-probe-gallery/` |

## Operating Modes

### Plan Mode

Use Plan Mode until the user confirms the final production plan.

Default flow — TWO layers, the same flow as `references/workflow.md`. The stage
layer is what the user sees; the phase layer is agent-internal execution detail.

User-facing stages (4). These are the agent's internal routing backbone; they are
NOT front-loaded as an opening roadmap and NOT counted out to the user as "step N
of 4". Keep them identical everywhere and speak them in plain language only
(story / visual / gameplay / production, in the user's language, never stage/phase
numbers or backstage names; gameplay is `what you mainly do in each stretch`,
never "loop"):

```text
① Story → one prose brief (1-2 paragraphs, story + setting), text only, then one yes/no: start making it?
② Visual → recommend, (show a preview only if the look needs eyes), lock the visual style
③ Gameplay → recommend, (show a logic view only if the rules need eyes), lock the gameplay
④ Build → plan, then generate / wire / QA / publish
```

Stages ② and ③ are **on-request only**. The default route is ① → ④ — the brief
turn's yes/no sends the user straight into building. Shared rhythm for ② ③ when
they are reached: `propose → (show, only if the decision needs visual judgement) → lock`.
Stage ① always ships the brief, the concept image, and the design doc path,
and ends in that single question.

Agent-internal phase layer (unchanged execution spine, never spoken to the user):

```text
① Story = 1. Story intake + 2. Creative brief, delivered as ONE turn:
1-2 paragraphs of prose telling the story and its setting (no field list),
then exactly ONE concept image, then the path to `GAME-DESIGN.md`
(a design doc written into a new project folder), ending in ONE yes/no
question — start making it now? Default is yes.
The concept image is a composed mock in the runtime UI framing; the design
doc carries the agent's art / gameplay / scope calls. Both ship on this turn.
② Visual = 3. Visual style recommendation with visible reference cases
4. Style Probe step: always ask whether to view a Style Probe; if the user agrees,
generate the probe images AND assemble them into the bundled
`templates/style-probe-gallery/` HTML page (not a plain image dump) — see `references/visual-planning.md`
5. Visual confirmation
③ Gameplay = 6. Gameplay loop guidance
7. Gameplay Node Map when rules need confirmation
8. Gameplay confirmation
④ Build = 9. Production Plan 10. Build Checklist 11. User confirms transition to Build Mode
```

**No front-loaded roadmap, no ordinal progress cue.** Do NOT open the first Plan
reply with a "here's the whole 4-step process" announcement. The first turn leads
with the prose brief + the single yes/no; that sets expectations better than
reciting a pipeline. The 4 stages remain the agent's internal routing backbone,
surfaced through neither an agenda nor a step count — since the default route
skips ② and ③, a "step N of 4" cue would misdescribe the flow, and it is
removed. On later Plan turns (reached only when the user asked to settle the look
or the mechanics) close with one short natural line on what is being settled now
and what follows — plain words, no numbering. Only lay the 4 steps out explicitly
if the user asks how the whole process works. Full rules and wording are in
`references/conversation-style.md`; the brief-leads-the-opening rule is in
`references/workflow.md` Phase 1.

**Stage gate rule.** Advance exactly one phase at a time. Do not produce the artifacts of a later phase until the user has responded to the current phase's artifact or question. Producing multiple phases' final artifacts in a single turn is a violation of Plan Mode, even when the agent already knows what those later phases will contain — knowing the likely outcome of a later phase is not the same as that phase being confirmed.

**Stage ① is the one exception, and it is internal to that stage.** Phases 1, 2 and 2.5 are one turn by design: intake, prose brief, and the concept image + design doc path + question ship together. That is not a gate violation — the gate sits at the end of Stage ①, where the single yes/no is. The exception does not widen: it does not license touching Stage ②, ③ or ④ artifacts on that turn, and `PRODUCTION-PLAN.md` / `BUILD-CHECKLIST.md` are still Stage ④ work.

**Image placement in Stage ①.** The prose half is text only — no image inline between the paragraphs. After the prose, the reply order is: concept image, then the doc's path, then the question (see `references/workflow.md` Phase 2.5 "What the user sees, in order"). The image goes above the path, not below it — the picture is what the user reacts to before being pointed at a file. Work order differs from display order: the image is generated FIRST, launched in the background before the prose is written, and displayed SECOND (see `references/visual-planning.md` "Concept Preview Image"). One image, lowest-latency tier. A second render is a violation; so is skipping it silently when it succeeded.

**The design-doc line carries the one emoji this skill uses.** 🕹️, fixed, and only on that line — the link otherwise renders in a pale colour readers pass over. Say what is inside the doc (cast, endings, art and music calls), not just where it is. **The link target must be absolute from the workspace root**: `[GAME-DESIGN.md](/workspace/works/games/<slug>/GAME-DESIGN.md)`. A relative target renders as `GAME-DESIGN.md [blocked]`; backticks or a code fence render grey and unclickable. Same rule for every other path this skill links for the user. No other output in this skill uses an emoji. Full rule in `references/workflow.md` Phase 2.5 "Show the path".

**This link rule holds in every mode.** Stage ① publishes the design doc as a Work
output file (see `references/workflow.md` "Publish the design doc as a Work card"),
so a card appears on the board from the start. The path link in the reply and the
card are two routes into the same doc: the link is what the user clicks right now,
the card is what stays on the board. Always include the link — if the design-doc
publish failed, the link is the only route, and a reply written as though the card
were guaranteed leaves the user with no way in. See "After every delivery" in
`references/build-mode.md`.

**The card only appears on the turn that first creates the Work.** Canvas placement
fires once — on the first `work init` for that work-ref. A republish of an
already-placed Work updates its content but does not trigger a new placement, so the
card will not reappear in a later turn's "From this turn". This is why the publish
belongs at Stage ① on a fresh work-ref, not retroactively on a Work that Build Mode
already created. Full rule in `references/workflow.md` "Publish the design doc as a
Work card" -> "This must be the first `work init`".

**The image must be downloaded before it can be shown or recorded.** Generation writes only descriptor JSON, no image file (`references/generation-method.md` "What generation does and does not write"). Save it to `works/games/<slug>/design/concept.webp`, resolve THAT file with `cohub spaces files cat`, and use the `https://sessions.cohub.run/...` link it returns — in the chat reply and as the line directly under `GAME-DESIGN.md`'s H1. Pasting the generator's own URL, or recording a `.json` descriptor path as if it were the image, are both defects that have shipped.

**Fast Build Path (the default route).** When the user answers yes to Stage ①'s
closing question, or later asks to start making the game (e.g. "start making it",
"just build it this way"), OR replies vaguely or merely approvingly, take this
path — it is the default, not a branch of a menu. Treat entering it as explicit
authorization to enter Build Mode — the "ask before Build Mode" gate is satisfied.
On this path: reuse `GAME-DESIGN.md` as confirmed Story input, copy the runtime into
the project folder that already exists (without overwriting the planning docs in it),
auto-fill `PRODUCTION-PLAN.md` and `BUILD-CHECKLIST.md` from that doc rather than
re-deriving the art / gameplay / scope calls (do not re-walk each field),
downgrade the Style Probe ask from a
blocking gate to non-blocking Build Mode visual progress, and enter Build Mode.
Full rules in `references/workflow.md` "Fast Build Path".

Plan Mode is allowed to produce intermediate planning artifacts. These are planning artifacts, not the final playable game.

**Plan Mode rules index.** The detailed Plan Mode rules live in their respective
reference files, not here. This list is an index so you know where to look:

| Rule | Source |
|---|---|
| Conversation style, progressive disclosure, no front-loaded roadmap, where-we-are line, brief confirm | `references/conversation-style.md` |
| Phase-by-phase execution, stage gates, Stage ① hard stop, Fast Build Path | `references/workflow.md` |
| Forward guidance, plan coverage budget, visible confirmation, reference binding, visual confirmation intent, gameplay visualization intent | `references/workflow.md` + `references/conversation-style.md` + `references/visual-planning.md` + `references/gameplay-planning.md` |
| Terminology rewrite (speak the user's language) | `references/conversation-style.md` |
| Concept preview image, Style Probe Gallery, character sprite default | `references/visual-planning.md` |
| Final plan gate (PRODUCTION-PLAN.md, BUILD-CHECKLIST.md) | `references/output-artifacts.md` |
| Display mechanism (CDN link before markdown image) | `references/visual-display.md` |

### Build Mode

Only enter Build Mode after the user confirms the Production Plan or clearly asks to start building.

Build Mode stages:

```text
0. Send the opening announcement — REQUIRED, before any file, asset, or command
1. Run `tools/preflight.mjs` — the dependency check, before anything else
2. Copy `runtime/avg-standard/` into an isolated project folder
3. Write story and rules into `src/story/story.json` — work in the project copy only
4. Generate visual assets and BGM (first round: 1 background + 1 sprite, no BGM)
5. Apply UI skin and frontend/audio adjustments (not on the default first round)
6. Wire assets and BGM into UI/runtime (first round: those two files)
7. Smoke-test rules, fallback boundaries, and music playback
8. Run the asset gate (`npm run qa:page`) — pure Node, no browser
9. Publish via the `publish-avg-work.mjs` wrapper (fail-closed; runs
init/register/publish + verify, and re-declares the GDD as a Work output
file — the same work-ref Stage ① already published); two-port proxy is fallback
10. Write host-workspace logs if required
11. Hand over: the link plus what this round covers and what is still open — REQUIRED
```

Stages 4 and 6 run on the default first round but on a two-image subset — one background
(the opening scene's, which is the first screen the player sees) and one character sprite,
no BGM. Stage 5 (UI skin) does NOT run on the default first round — the first delivery
ships on the runtime's own look, and skinning is a follow-up round, deferred the same way
BGM is. The exception is a user who already confirmed a look — that round skins. See
"First delivery scope" in `references/build-mode.md`. Stage 3 is still where
most of the round's time goes.

Stage 0 is a gate, not a courtesy: see "Opening the build" in `references/build-mode.md`
for the required text. If the first Build Mode turn contains a tool call before that
announcement, the flow was entered wrong — send the announcement and continue from stage 1
in the same turn.

Stage 11 closes the same loop — see "After every delivery" in `references/build-mode.md`.
A link handed over with no account of what is done and what is open is an incomplete
delivery, on every round.

**What this skill delivers: one web Work** — the playable AVG at `works/games/<slug>/`,
published by `publish-avg-work.mjs` and handed over as that Work's link. The Stage ①
concept image (the generator saves every image as an image Work) and the design-doc card
are planning artifacts that ride along; never hand either over as the game or close a
build on them. Blocked image generation (credits, provider error) does not block the
build: do not make the yes/no or the build wait on refilled credits — ship the playable
Work on the runtime's own look and name the missing art as still open. Hand the game over as
a Work card on its own line — an `interaction-components` Link block whose target is
`studio-route` / `work` with this world's id and the `cohubWorkId` the wrapper printed this
round — not as an inline markdown link (shape in `references/build-mode.md` "After every
delivery"). If the wrapper
exits non-zero after `work publish` printed a successful result, read its message and fix
that cause; do not move build files around or hand-edit `meta.json` to get past it.

**Leave the world as you found it.** An AVG build never changes world settings: no
`neta config set` (not `visualStyle`, not any other `worldConfig` field) — the game's art
direction lives in `GAME-DESIGN.md` and in the generation prompts, so a world with no
`visualStyle` stays that way. Never delete or overwrite files that were in the world before
the round — another game's folder included.

Build Mode runs under this skill's own acceptance gate: `npm test`, `npm run build`, `npm run qa:page`, and live proof on the published URL (every deployed file returns 200, and one real turn reaches terminal `llm` rather than `fallback`). Treat the AVG as delivered only after all four pass. `qa:page` is pure Node and takes no screenshots — browser QA is not part of the default gate; reach for it only when a round earns it (see `references/build-mode.md` "Browser QA is not part of the default gate"). `npm run smoke` belongs one step earlier, paired with `npm run validate` right after the story is written — it drives the shipped story through the real engine and prints the winning route, the dead ends, and which intent every choice resolved to, so a mis-bound choice costs one edit instead of a rebuild. It fails on a click trap (a button sequence that strands the player away from every ending) or a press that re-offers the same buttons with nothing changed. Read its printed report, not only its exit code: a story whose endings can only be typed exits 0 with a warning, and no gate blocks that on a default build. Do not re-run it inside the gate — `npm test` already carries every blocking assertion it makes. Details in `references/build-mode.md` -> "What each check actually covers" and Publishing. The `game-maker` protocol is optional here — run it only when the user asks for it, or when this AVG is one part of a larger `game-maker` task already keeping those records.

Build Mode's 14 recorded steps are a record of what must happen, not a count of tool calls. Merge independent calls into one message and chain shell commands with `&&` so the round lands in about 8 round trips. Image generation is submitted as `--async` early in the round (seconds each) and renders in the background while the story is written; the round reconciles both images in a single blocking call before downloading, cutting out, and wiring them. The budget, the merges deliberately not made, and the hard gates it must never compress are in `references/build-mode.md` -> "Round-trip budget" and "Submit async, reconcile later".

**Runtime policy.** The standard LLM path for new Studio-facing AVG builds is the
published Work runtime, released via the bundled `publish-avg-work.mjs` wrapper.
There is exactly one Cohub LLM call shape: `space.completion()`. On a published
Work it is served by the `cohub-action` provider, which dispatches the `llm` App
Action (`.cohub/actions/llm.mjs`) so `space.completion()` runs server-side as the
App owner — no viewer consent popup, owner-funded, with `cohub-completion` as the
viewer-authorized fallback. Do not make new builds depend on front-end OAuth
login; do not hardcode or expose model API keys in the browser; do not add a
`space.prompt()` / session-turn provider. The full provider order, the
`neta-direct` probe rule, the two valid delivery shapes, the `--verify-static-only`
/ `--llm-off` distinction, and the fail-closed publishing rule are in
`references/build-mode.md` "Runtime Policy" — read that section before the first
publish, and follow `runtime/avg-standard/COHUB-WORK-LLM.md` for the exact steps.

## Related Skills

Do not invoke a related skill before its phase is reached in the current stage sequence, even if the output would be useful later or the agent already knows it will be needed:

| Task | Skill |
|---|---|
| Generate visual assets, style probes, UI mock images, character/background concepts | `generate-image` — run via the Neta CLI, see `references/generation-method.md` |
| Generate a video (trailer, animated key art, motion background) when the project needs one | `video-maker` — run via the Neta CLI, see `references/generation-method.md` |
| Browser QA on a live link, when a round earns it | `agent-browser` — not part of the default gate, see `references/build-mode.md` "Browser QA is not part of the default gate" |
| Publish files / pages / ports as shareable Works | the host workspace share/publish flow when available |
| Generate sprite assets / GIFs only if the project needs animated sprites | `production-spritesheet-builder` or related sprite skills |

The generation method for every image and video in this skill is the Neta CLI (`node /mods/neta/neta generate image` / `generate video`, never `--model`). Read `references/generation-method.md` for the command, parameters, the auto-written work JSON / media artifact conventions, and the async-default rule before generating.

**Image/video parameters are declaration-driven, without exception.** Run `node /mods/neta/neta generate image params` (or `generate video params`) before every generation and pass only the keys that declaration lists, each as `--param key=value`. The legacy flags `--aspect` / `--size` / `--quality` / `--duration` do not exist and are rejected by the CLI, so any call carrying one fails outright. Do not translate, rename, or guess parameter names or values; if the declaration cannot be read, stop and report the error. Full contract and failure handling: `references/generation-method.md`.
| Build-Mode QA + publish gate | this skill's own gate — `npm test`, `npm run build`, `npm run qa:page` (pure Node, no browser), live proof on the published URL (`npm run validate && npm run smoke` runs one step earlier, at story-writing time; see `references/build-mode.md` -> Publishing) |

## Host Workspace Policies

If the host workspace has project-level rules such as logs, records, public share, or path conventions, obey them.

In this workspace, changes must also be recorded in `logs/`, but that is a host-workspace rule rather than a dependency of this skill package.

Skills

Skills Leaderboard

Built-in

create-avg