/**
 * The scaffolded guidance for `bitmagic reference` — the prose that teaches a creator's agent to
 * OFFER a concept image of the world, let the human iterate and decide, and understand what
 * accepting one changes.
 *
 * Its own module rather than more of project-files.ts for one blunt reason: that file sits near
 * the 2000-line ESLint ceiling, and guidance is the part that grows. The rendering rules are the
 * same as there — these strings land inside template literals ultimately emitted into scaffolded
 * markdown, so backticks are escaped exactly as project-files.ts escapes them.
 */
/** The `## Reference image` section of the scaffolded AGENTS.md, placed before the cover section. */
export declare const AGENTS_MD_REFERENCE_SECTION = "## Reference image \u2014 offer it when the idea has a strong setting\n\nWhen the idea names a **place or a look** \u2014 a tropical island, a neon city \u2014 offer to make a\nconcept image of the world before generating anything else:\n\n```\nbitmagic reference make                       # a candidate lands in .bitmagic/reference/\nbitmagic reference make --from <id> --prompt \"same island, but at dusk\"\nbitmagic reference accept <id>                # the human's call, never yours\n```\n\nThe prompt follows game.json's `artStyle`, so declare the medium first. Show the human each image\nfile and let THEM iterate and accept. Once accepted, it is the default\nstyle reference for `generate skybox|background|block-type|image`, `bitmagic cover` and\n`bitmagic forge` (whose designer literally sees the picture) \u2014 one look across the whole game;\n`--no-reference` exempts a call, and a picture the human hands you for ONE request rides that\ncall as `--reference-image <file>` instead. Accepting prints a durable URL: paste it into\n`GAME-DESIGN.md`'s world/look section, since `.bitmagic/` is not committed and\n`bitmagic reference accept <url>` is how a fresh clone gets it back. Details are in\n`.agents/skills/generating-assets/SKILL.md`; skip the offer when the idea has no visual identity\nyet.\n\n";
/** The planning skill's step-1 paragraph on offering a reference image. */
export declare const PLANNING_SKILL_REFERENCE_STEP1 = "If the idea describes a **place** \u2014 an island, a city, a specific look \u2014 offer a reference image\nbefore anything else is generated: `bitmagic reference make`, show the human the file it prints,\niterate with `--from <id>`, and run `accept` only when they choose one. Every skybox, block,\ncover and forge after that inherits the accepted image, so it is worth settling first \u2014 and worth\nskipping when the idea has no visual identity yet.\n\n";
/** The planning skill's step-4 list entry (rendered between the design-doc and cover steps). */
export declare const PLANNING_SKILL_REFERENCE_STEP4 = "3. `bitmagic reference make` / `accept` \u2014 only when the human wants one; it lands BEFORE\n   `bitmagic cover` and any forge, since both use the accepted image.\n";
/** The generating-assets skill's section on the project reference image. */
export declare const GENERATE_SKILL_REFERENCE_SECTION = "## The project reference image\n\n`bitmagic reference` manages a concept image of the game's world (see AGENTS.md for when to\noffer one). Its subcommands are `make`, `accept <id|url>`, `show` and `clear`; candidates\nlive in `.bitmagic/reference/` and the accepted choice in `.bitmagic/reference.json` \u2014\nnothing in `world.json`, and only `make` costs sparks (the same price as an image).\n\nOnce one is **accepted**, `generate skybox`, `generate background`, `generate block-type`,\n`generate image`, `bitmagic cover` and `bitmagic forge` all use it as their style reference\nby default \u2014 the command logs \"Using the project's reference image\" when that happens. Control it\nper call:\n\n- `--no-reference` \u2014 this asset should NOT look like the world (a hell-dimension portal in a\n  tropical game).\n- `--reference-image <file>` / `--reference-image-url <url>` \u2014 a DIFFERENT reference for this\n  call only; both override the accepted image.\n- `bitmagic reference show` \u2014 check what is accepted; `clear` stops using it entirely.\n\n**When the human hands you a picture** \u2014 \"create a world like this\", \"a skybox like this photo\" \u2014\nthat image IS the reference for that request: save it to a file and pass\n`--reference-image <path>` (or `--reference-image-url` if they gave a URL) on the command it\napplies to. The CLI uploads the file to the game's storage and forwards its URL; the accepted\nproject reference is not consulted. Only when they mean it as the game's overall look \u2014 \"make the\nwhole game look like this\" \u2014 run `bitmagic reference accept <file>` instead, which makes it the\nproject reference everything inherits.\n\n`make` itself never inherits the accepted image \u2014 each candidate starts fresh unless you pass\n`--from <id>` (or `--reference-image <file>` to iterate from the human's own picture), which is\nhow \"same island, but at dusk\" iterations work.\n\n";
/** The GAME-DESIGN.md template's hint, placed with the world/look prose. */
export declare const GAME_DESIGN_REFERENCE_HINT = "<!-- If a reference image was accepted (bitmagic reference show), paste its URL here so a fresh clone can re-accept it. -->";