@oisincoveney/pipeline 1.27.14 → 1.27.16

package/README.md

@@ -241,7 +241,7 @@ runner.
 
 | Host | Generated files | Invocation |
 | --- | --- | --- |
-| OpenCode | `.opencode/commands/<entrypoint>.md`, `.opencode/agents/*.md`, `.opencode/skills/*/SKILL.md`, `.opencode/plugins/*.ts`, `.opencode/opencode.json` | `/quick <task>`, `/execute <task>`, `/inspect <task>` |
+| OpenCode | `.opencode/commands/<entrypoint>.md`, `.opencode/agents/*.md`, `.opencode/plugins/*.ts`, `.opencode/opencode.json` | `/quick <task>`, `/execute <task>`, `/inspect <task>` |
 
 The installer is idempotent, supports `--check` and `--dry-run`, and refuses to
 overwrite manually edited files unless `--force` is supplied.

package/dist/config.js

@@ -126,55 +126,38 @@ mcp_gateway:
 skills:
   execute:
     path: .agents/skills/execute/SKILL.md
-    source_root: package
   inspect:
     path: .agents/skills/inspect/SKILL.md
-    source_root: package
   quick:
     path: .agents/skills/quick/SKILL.md
-    source_root: package
   critique:
     path: .agents/skills/critique/SKILL.md
-    source_root: package
   doubt:
     path: .agents/skills/doubt/SKILL.md
-    source_root: package
   fix:
     path: .agents/skills/fix/SKILL.md
-    source_root: package
   library-first-development:
     path: .agents/skills/library-first-development/SKILL.md
-    source_root: package
   migrate:
     path: .agents/skills/migrate/SKILL.md
-    source_root: package
   optimize:
     path: .agents/skills/optimize/SKILL.md
-    source_root: package
   research:
     path: .agents/skills/research/SKILL.md
-    source_root: package
   schedule-graph-shaping:
-    path: .pipeline/skills/schedule-graph-shaping/SKILL.md
-    source_root: package
+    path: .agents/skills/schedule-graph-shaping/SKILL.md
   scope:
     path: .agents/skills/scope/SKILL.md
-    source_root: package
   secure:
     path: .agents/skills/secure/SKILL.md
-    source_root: package
   spec:
     path: .agents/skills/spec/SKILL.md
-    source_root: package
   test:
     path: .agents/skills/test/SKILL.md
-    source_root: package
   trace:
     path: .agents/skills/trace/SKILL.md
-    source_root: package
   verify:
     path: .agents/skills/verify/SKILL.md
-    source_root: package
 profiles:
   moka-orchestrator:
     runner: opencode

package/dist/index.js

@@ -210,7 +210,7 @@ function truncateMiddle(text, maxLength) {
 function createCliProgram() {
 	const configuredPipeline = loadConfiguredEntrypoints(process.env.PIPELINE_TARGET_PATH ?? process.cwd());
 	const program = new Command();
-	program.name("moka").description("Submit work to Momokaya").exitOverride();
+	program.name("moka").description("Submit work to Momokaya").version(readPackageVersion()).exitOverride();
 	const runAction = async (descriptionParts, flags) => {
 		await execute(descriptionParts.join(" "), {
 			entrypoint: flags.entrypoint,
@@ -303,6 +303,11 @@ function createCliProgram() {
 	} });
 	return program;
 }
+function readPackageVersion() {
+	const packageJson = JSON.parse(readFileSync(new URL("../package.json", import.meta.url), "utf8"));
+	if (typeof packageJson.version !== "string") throw new Error("Unable to read @oisincoveney/pipeline package version.");
+	return packageJson.version;
+}
 function addMokaSubmitOptions(command) {
 	return addRunnerArgoOptions(command.option("--quick", "submit the compact graph").option("--command", "treat input after -- as explicit argv").option("--schedule <path>", "approved schedule YAML to submit").option("--event-url <url>", "runner event sink URL").option("--task <text>", "task description for command-mode metadata"), { kubeconfig: true });
 }
@@ -418,10 +423,15 @@ function lintMissingFileReferences(config, projectRoot) {
 		if (!value || standardOutputSchemaNameFromPath(value) || existsSync(resolveLintPathReference(projectRoot, ref.ref))) return [];
 		return [{
 			ruleId: "missing-file-reference",
-			message: `${ref.path} references missing file '${value}'`
+			message: missingFileReferenceMessage(ref.path, value)
 		}];
 	});
 }
+function missingFileReferenceMessage(path, value) {
+	const base = `${path} references missing file '${value}'`;
+	if (path.startsWith("skills.") && value.startsWith(".agents/skills/")) return `${base}. Run \`moka init\` to install project-local skills with \`npx --yes skills add oisincoveney/skills\`.`;
+	return base;
+}
 function resolveLintPathReference(projectRoot, ref) {
 	if (ref?.source_root === "package") return resolvePackageAssetPath(ref.path);
 	return resolve(projectRoot, ref?.path ?? "");

package/dist/install-commands.js

@@ -1,4 +1,3 @@
-import { resolveFileReference } from "./path-refs.js";
 import { DEFAULT_OPENCODE_ECOSYSTEM_MANIFEST, loadPipelineConfig } from "./config.js";
 import { compileWorkflowPlan } from "./workflow-planner.js";
 import { renderOpenCodeGatewayConfig } from "./mcp/gateway.js";
@@ -315,49 +314,6 @@ function localPluginDefinitions() {
 		}];
 	});
 }
-function opencodeSkillProjections(config, cwd) {
-	return [...profileSkillIds(config)].sort((a, b) => a.localeCompare(b)).map((id) => {
-		const configured = config.skills[id];
-		const path = configured?.path ?? `.agents/skills/${id}/SKILL.md`;
-		return {
-			description: skillDescription(cwd, configured, path, id),
-			id,
-			path
-		};
-	});
-}
-function profileSkillIds(config) {
-	return new Set(Object.values(config.profiles).flatMap((profile) => profile.skills ?? []));
-}
-function skillDescription(cwd, configured, path, id) {
-	const absolutePath = configured?.source_root === "package" ? resolvePackageAssetPath(path) : resolveFileReference(cwd, path);
-	if (existsSync(absolutePath)) {
-		const parsed = matter(readFileSync(absolutePath, "utf8"));
-		if (typeof parsed.data.description === "string") return parsed.data.description;
-	}
-	return `Pipeline skill ${id} projected from ${path}.`;
-}
-function opencodeSkillDefinition(skill) {
-	return {
-		content: markdown({
-			compatibility: "opencode",
-			description: skill.description,
-			metadata: { "pipeline-source": skill.path },
-			name: skill.id
-		}, [
-			header("opencode").trimEnd(),
-			"",
-			`This is the package-owned OpenCode projection for pipeline skill \`${skill.id}\`.`,
-			"",
-			`Canonical source: \`${skill.path}\`.`,
-			"",
-			"Load this skill when a generated pipeline agent grants it through `permission.skill`."
-		].join("\n")),
-		host: "opencode",
-		invocation: invocationForHost("opencode"),
-		path: `.opencode/skills/${skill.id}/SKILL.md`
-	};
-}
 function opencodeDefinitions(config, cwd) {
 	const orchestrator = orchestratorProfile(config);
 	return [
@@ -425,7 +381,6 @@ function opencodeDefinitions(config, cwd) {
 			invocation: invocationForHost("opencode"),
 			path: `.opencode/agents/${nativeAgentIdForHost("opencode", id)}.md`
 		})),
-		...opencodeSkillProjections(config, cwd).map(opencodeSkillDefinition),
 		...localPluginDefinitions(),
 		projectAgentsMdDefinition(cwd, "opencode")
 	];
@@ -491,7 +446,6 @@ function selectedHosts(host) {
 const GENERATED_RESOURCE_ROOTS = { opencode: [
 	".opencode/commands",
 	".opencode/agents",
-	".opencode/skills",
 	".opencode/plugins"
 ] };
 async function listFiles(root) {

package/dist/pipeline-init.js

@@ -1,20 +1,39 @@
-import { resolvePackageAssetPath } from "./package-assets.js";
 import { installCommands } from "./install-commands.js";
-import { dirname, join } from "node:path";
-import { cp, mkdir } from "node:fs/promises";
+import { execa } from "execa";
 //#region src/pipeline-init.ts
-async function installDefaultSkillsFromPackage(cwd) {
-	const source = resolvePackageAssetPath(".agents/skills");
-	const target = join(cwd, ".agents", "skills");
-	await mkdir(dirname(target), { recursive: true });
-	await cp(source, target, {
-		force: true,
-		recursive: true
-	});
+const DEFAULT_SKILL_INSTALL_SOURCE = "oisincoveney/skills";
+const DEFAULT_SKILL_INSTALL_ARGS = [
+	"--agent",
+	"opencode",
+	"--agent",
+	"codex",
+	"--agent",
+	"claude-code",
+	"--skill",
+	"*",
+	"--yes",
+	"--copy"
+];
+async function installDefaultSkills(cwd) {
+	try {
+		await execa("npx", [
+			"--yes",
+			"skills",
+			"add",
+			DEFAULT_SKILL_INSTALL_SOURCE,
+			...DEFAULT_SKILL_INSTALL_ARGS
+		], {
+			cwd,
+			stdio: "inherit"
+		});
+	} catch (error) {
+		const cause = error instanceof Error ? `: ${error.message}` : "";
+		throw new Error(`Failed to install default skills from ${DEFAULT_SKILL_INSTALL_SOURCE}${cause}. If this is a private repository, authenticate GitHub access for npx skills add and rerun \`moka init\`.`);
+	}
 }
 async function initPipelineProject(options = {}) {
 	const cwd = options.cwd ?? process.cwd();
-	await (options.skillInstaller ?? installDefaultSkillsFromPackage)(cwd);
+	await (options.skillInstaller ?? installDefaultSkills)(cwd);
 	return { files: (await installCommands({
 		cwd,
 		force: true,

package/docs/config-architecture.md

@@ -151,19 +151,18 @@ receive explicit grants:
 - `network`: inherited or disabled.
 - `output`: text, JSON, JSONL, or JSON Schema output.
 
-Package-owned default skills may resolve from the installed package asset root
-instead of the target repository root:
+Default skills resolve from project-installed skill files created by
+`moka init` via `npx --yes skills add oisincoveney/skills`:
 
 ```yaml
 skills:
   verify:
     path: .agents/skills/verify/SKILL.md
-    source_root: package
 ```
 
-Project-authored skill and rule paths still resolve from the project root and
-must exist. The package default loader does not relax missing-file validation;
-it validates package assets against the package root.
+Project-authored skill and rule paths resolve from the project root and must
+exist for runtime use. If default skill files are missing, run `moka init` to
+install them before executing workflows.
 
 MCP-enabled profiles use one gateway grant:
 
@@ -190,8 +189,8 @@ OpenCode host resources are generated from the same profile registry:
 
 - `.opencode/agents/*.md` declares native agents with `mode`, `description`,
   resolved model, explicit permissions, and task access to generated agents only.
-- `.opencode/skills/*/SKILL.md` projects package-granted skills for native
-  OpenCode discovery.
+- `.opencode/skills/*/SKILL.md` is installed by `skills add`; Moka only
+  generates agents, commands, plugins, and project config.
 - `.opencode/plugins/pipeline-goal-context.ts` projects package-owned
   continuation context into OpenCode compaction.
 - `.opencode/opencode.json` contains the gateway MCP config, enables LSP, and

package/docs/operator-guide.md

@@ -269,7 +269,7 @@ Codex:    $quick, $execute, $inspect
 - `.opencode/commands/<entrypoint>.md` for `/quick`, `/execute`, and `/inspect`
 - `.opencode/agents/*.md` for primary and subagent profiles with explicit
   `permission` maps, `task` grants, and denied ungranted tools
-- `.opencode/skills/*/SKILL.md` for package-granted skills
+- `.opencode/skills/*/SKILL.md` from `npx skills add`, not Moka generation
 - `.opencode/plugins/pipeline-goal-context.ts` for goal-loop compaction context
 - `.opencode/opencode.json` with LSP, the singleton `pipeline-gateway` MCP
   server, and pinned package-selected plugins

package/docs/slash-command-adapter-contract.md

@@ -15,7 +15,7 @@ moka install-commands --host all --check
 
 | Host     | Generated resources                                            | Invocation                        | Mechanical path                                                                                       |
 | -------- | -------------------------------------------------------------- | --------------------------------- | ----------------------------------------------------------------------------------------------------- |
-| OpenCode | `.opencode/commands/<entrypoint>.md`, `.opencode/agents/*.md`, `.opencode/skills/*/SKILL.md`, `.opencode/opencode.json` | `/quick <task>`, `/execute <task>`, `/inspect <task>` | Project commands run a primary orchestrator and OpenCode native subagents with package-owned skill, MCP, permission, and LSP projection. |
+| OpenCode | `.opencode/commands/<entrypoint>.md`, `.opencode/agents/*.md`, `.opencode/opencode.json` | `/quick <task>`, `/execute <task>`, `/inspect <task>` | Project commands run a primary orchestrator and OpenCode native subagents with package-owned skill, MCP, permission, and LSP projection. |
 
 ## Projection Rules
 
@@ -31,9 +31,9 @@ moka install-commands --host all --check
 - OpenCode agents project package profiles as markdown agents with `mode`,
   `description`, resolved `model`, `permission`, `hidden`, and task permission
   maps. The primary orchestrator may call only generated package profile agents.
-- OpenCode skill projection is generated from package profile grants into
-  `.opencode/skills`. Skill files point back to package-owned source paths and
-  per-agent `permission.skill` maps deny ungranted skills.
+- OpenCode skill files are installed by `npx skills add` during `moka init`;
+  Moka does not generate `.opencode/skills`. Generated agent
+  `permission.skill` maps still deny ungranted skills.
 - `.opencode/opencode.json` includes the singleton `pipeline-gateway` MCP
   server and enables OpenCode LSP. CLI lint, typecheck, tests, and configured
   gates remain the blocking verification path; LSP is editor/runtime assistance.

package/package.json

@@ -100,8 +100,6 @@
     }
   },
   "files": [
-    ".agents/skills",
-    ".pipeline/skills",
     "defaults",
     "dist",
     "docs",
@@ -120,7 +118,7 @@
     "prepack": "bun run build:cli"
   },
   "type": "module",
-  "version": "1.27.14",
+  "version": "1.27.16",
   "description": "Config-driven multi-agent pipeline runner for repository work",
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",

package/.agents/skills/add-dark-mode/SKILL.md

@@ -1,79 +0,0 @@
----
-name: add-dark-mode
-description: Add dark mode with colors, shadows, and surfaces handled the way a designer would.
----
-
-# Add Dark Mode
-
-Use this when the user wants to add dark mode support to an existing UI.
-
-## Activation
-
-### Use For
-
-- adding dark mode to a page, section, component, or site
-- improving an existing dark mode treatment
-- converting a light-mode-only UI to support dark mode
-
-### Do Not Use For
-
-- brand-new design or layout work
-- standalone image dark-mode conversion
-- responsive behavior, component organization, or general visual polish without dark mode
-
-## Load First
-
-- No companion files are required.
-- Dark-mode design guidance is inline below.
-
-## Progress Updates
-
-Keep the user informed so longer runs do not look stuck.
-
-- One-line status update before each major phase.
-- Concrete and lightweight: what you are doing now, not verbose logs.
-
-## Workflow
-
-1. Inspect the existing UI and project Tailwind conventions.
-2. Convert markup to include appropriate dark-mode classes.
-3. Audit rasterized images for dark-mode variants.
-4. For each rasterized image that needs a dark-mode variant, hand off to `dark-mode-image`, which MUST load and use the `imagegen` skill before creating or editing image assets.
-5. Save generated dark-mode images alongside the originals and wire them into the dark-mode UI.
-
-## Dark Mode Rules
-
-### Design Rules
-
-- Dark mode is about maintaining the same contrast ratios as light mode, not simply inverting colors
-- Dark mode doesn't need to preserve every detail of the light mode design — it just needs to look good
-- Default dark mode to follow the operating system's `prefers-color-scheme` setting (Tailwind's built-in `dark:` behavior); only add a manual toggle when the user explicitly asks for one
-- Remove all shadows in dark mode — use `dark:shadow-none`
-- On dark-mode-only sites, add the `scheme-only-dark` class to `<html>` or the top-level element — ensures native elements like scrollbars, form controls, and `color-scheme` render in dark mode
-
-### Component Rules
-
-- Never keep large branded/colored panels in dark mode; instead use the same background color and add a light divider between sections
-- Style cards only slightly lighter than the page background (e.g. `dark:bg-gray-900` on a `dark:bg-gray-950` page); add a `dark:inset-ring dark:inset-ring-white/5` for definition
-- Make decorative quote marks in testimonials very faint (e.g. `dark:text-white/5`)
-- Never use multiple heading text colors in dark mode (e.g. dark gray + brand color); use a single light color like `white` or `gray-100` for all heading text
-
-### Raster Image Rules
-
-- When adding or improving dark mode, audit the page for rasterized images that need dark-mode versions: photos, screenshots, product mockups, decorative backgrounds, textures, and rasterized illustrations
-- Never use CSS filters (`invert`, `brightness`, `contrast`, `opacity`) as the final dark-mode treatment for raster images; always create real dark-mode image files
-- Generate dark-mode raster image variants with the `dark-mode-image` skill, which MUST load and use the `imagegen` skill before creating or editing any raster image assets
-
-### SVG Rules
-
-- For inline `<svg>` elements, style dark mode with Tailwind `dark:*` classes (e.g. `dark:fill-*`, `dark:stroke-*`, `dark:text-*`)
-- For external SVG files referenced via `<img>`, always create a dark-mode version alongside the original (e.g. `logo.svg` and `logo-dark.svg`); never substitute CSS filters (`invert`, `brightness`) or opacity adjustments for a true dark variant
-
-## Guardrails
-
-- Do not generate, edit, or replace raster image assets directly from this skill; `dark-mode-image` owns that work and MUST use the `imagegen` skill.
-- Require the `dark-mode-image` + `imagegen` handoff even when the image change seems simple, decorative, or incidental.
-
-## Verify
-
-- Check light and dark modes for contrast, missing variants, and images that still assume a light background.

package/.agents/skills/brand-kit/SKILL.md

@@ -1,61 +0,0 @@
----
-name: brand-kit
-description: Generate a complete visual identity and marketing-site mockup board from a product idea.
----
-
-# Brand Kit
-
-## Overview
-
-Run the brand kit workflow from concept to one finished 3840 x 2160 image. This skill wraps [Brand Kit Prompt](./brand-kit-prompt.md) and then renders the generated prompt directly through the `imagegen` skill.
-
-Use this workflow when the output should emphasize memorable frontend art direction, distinctive website composition, production-grade public-facing marketing pages, and avoidance of generic AI aesthetics. The final image should follow the fixed structure defined by [Brand Kit Prompt](./brand-kit-prompt.md): two large website page mockups plus a narrow design-system rail that documents only typography and hierarchical color values.
-
-## Load First
-
-- Read [Brand Kit Prompt](./brand-kit-prompt.md) before generating the intermediate image prompt.
-- Load and follow the `imagegen` skill before rendering the final image.
-
-## Workflow
-
-1. Treat the user's concept, brief, notes, constraints, references, audience, tone, avoid-list items, and attached images as the source input.
-2. Use [Brand Kit Prompt](./brand-kit-prompt.md) with the source input to generate one production-ready mockup-first image prompt. If images are attached, describe them as visual inspiration only using the rules in `Attached Images`.
-3. Capture the full prompt text from step 2 as intermediate working content. Do not present it as the final answer unless the user explicitly asks to see it.
-4. Use `$imagegen` with the full generated prompt from step 2 as its input, including any attached images as visual references when the imagegen interface supports reference images.
-5. Generate exactly one high-quality 3840 x 2160 px 16:9 landscape image: a fixed three-column marketing-site case-study board with page mockup 1 in the left 40%, page mockup 2 in the middle 40%, and a right-side design-system details rail in the final 20%.
-6. Return the rendered image. Keep final commentary minimal.
-
-## Attached Images
-
-If the user attaches images, use them as design inspiration only:
-
-- Use attached images to infer aesthetic direction, composition style, visual density, color atmosphere, type mood, spacing feel, texture, lighting, layout rhythm, and interaction/presentation patterns.
-- Do not copy or recreate attached-image content, logos, wordmarks, brand marks, icons, mascots, characters, product names, readable text, photography subjects, proprietary UI, exact layouts, or distinctive artwork.
-- Do not treat attached images as mandatory content for the generated brand kit unless the user explicitly says the image is their own brand asset and asks to use it.
-- When passing the generated prompt to `$imagegen`, explicitly state that attached images are style references only and must not be replicated.
-- If attached images conflict with the user's written concept, preserve the written concept and use the images only for visual direction.
-
-## Routing Rules
-
-- If the user provides only a thin but usable concept, make careful creative inferences in the prompt-generation step.
-- Ask a follow-up only when there is no usable brand, product, company, idea, or concept information.
-- Preserve all user-supplied constraints through both steps, especially names, audience, positioning, tone, visual references, attached-image inspiration, required deliverables, and avoid-list items.
-- If the user asks for the image plus the generated prompt, render the image first, then include the prompt text afterward.
-- If the prompt-generation step produces multiple boards, extra alternatives, a flexible metadata placement, or any output shape other than the fixed structure, normalize the result to match `brand-kit-prompt` before passing it to `imagegen`.
-- Do not route this workflow through `brand-kit-images`.
-
-## Output Discipline
-
-- Do not stop after producing the intermediate prompt.
-- Do not summarize or rewrite the intermediate prompt so heavily that brand details are lost.
-- Treat [Brand Kit Prompt](./brand-kit-prompt.md) as the source of truth for image structure and content. If this wrapper conflicts with that file, follow [Brand Kit Prompt](./brand-kit-prompt.md).
-- Do not generate a separate design-system board.
-- Do not generate multiple images, a contact sheet, or a two-board split.
-- Do not copy attached images or import their content, logos, text, brand marks, exact layouts, or proprietary UI into the generated image.
-- Do not generate a 2:1 board, a 4096 x 2048 board, or a flexible metadata strip/sidebar/footer/overlay layout.
-- Make the final image exactly two large public-facing website page mockups plus the right-side design-system rail.
-- Include a consistent logo, wordmark, or brand mark inside the page mockups where a production website would naturally show one.
-- Keep the design-system rail compact but legible at full 4K size, preserving only font names/typeface directions, dominant color values, supporting color values, palette hierarchy, and short color role labels.
-- In the rail, distinguish dominant/load-bearing colors from infrequent supporting accents. Dominant colors should appear larger, grouped as the main palette, and labeled by role; supporting/accent/signal colors should appear as smaller chips.
-- Do not put logo notes, spacing scales, border radius, grid specs, motion notes, component inventories, component state details, icon notes, elevation/shadow specs, or arbitrary brand copy in the design-system rail.
-- Do not create extra files or resource directories for this wrapper skill.

package/.agents/skills/brand-kit/brand-kit-prompt.md

@@ -1,158 +0,0 @@
----
-name: brand-kit-prompt
-description: Generate an image prompt for one fixed-structure 4K marketing-site brand case-study board with two large page mockups and a narrow design-system rail documenting typography and hierarchical colors. Use when Codex is asked to write a brand kit prompt, website mockup prompt, marketing site prompt, landing page prompt, product mockup prompt, or image-generation prompt for a visual brand identity.
----
-
-# Brand Kit Prompt
-
-## Purpose
-
-Generate one complete, production-ready image prompt for a fixed-structure 4K marketing-site brand case-study image. Output prompt text only; do not generate images.
-
-This skill prioritizes distinctive frontend art direction, production-grade public-facing marketing website mockups, generous whitespace, and consistent side-by-side comparison. Even when the concept is a web app, desktop app, mobile app, SaaS product, or other software interface, the board should show the public marketing site for that product. The final image must feel like two real, spacious website surfaces plus a concise typography/color rail, not a cramped moodboard, component inventory, app UI board, or traditional brand-system sheet.
-
-## Source Handling
-
-- Use only the user's concept, brief, notes, constraints, references, attached images, audience, tone, required pages, and avoid-list items.
-- If the input is thin but usable, make careful creative inferences.
-- Ask a question only when there is no usable brand, product, company, idea, or concept.
-- Preserve user-supplied vocabulary, constraints, page requests, examples, references, attached-image inspiration, and avoid-list items.
-- Output only the final prompt, with no preamble, rationale, commentary, follow-up, or setup text.
-
-## Attached Images
-
-If the user attaches images, inspect them and translate their visual qualities into prompt language. Use them as design inspiration only:
-
-- Extract aesthetic direction, composition style, visual density, color atmosphere, type mood, spacing feel, texture, lighting, layout rhythm, and interaction/presentation patterns.
-- Do not copy or recreate attached-image content, logos, wordmarks, brand marks, icons, mascots, characters, product names, readable text, photography subjects, proprietary UI, exact layouts, or distinctive artwork.
-- Do not treat attached images as mandatory content for the generated brand kit unless the user explicitly says the image is their own brand asset and asks to use it.
-- If attached images conflict with the written concept, preserve the written concept and use the images only for visual direction.
-- In the final prompt, include a short "Reference Image Use" note when images are attached: describe the style inspiration to borrow and explicitly state that attached images are style references only, not content or logo sources.
-
-## Workflow
-
-1. Infer the purpose, audience, positioning, product context, and brand personality.
-2. Choose one clear, memorable aesthetic direction that fits the concept.
-3. Choose the two public marketing-site page examples:
-   - Page mockup 1 defaults to the homepage.
-   - Page mockup 2 defaults to a concept-appropriate supporting page with a different content pattern from the homepage.
-   - If the user asks for specific pages, use those instead.
-   - If the concept is an app or software product, choose pages that can naturally show product screenshots inside the marketing site.
-4. If images are attached, summarize their reusable visual qualities using `Attached Images`.
-5. Assemble one internally consistent image-generation prompt using the structure in `Final Prompt Structure`.
-
-## Canonical Board Spec
-
-The generated prompt must request this exact image structure unless the user explicitly asks for a different structure:
-
-- Canvas: one single 3840 x 2160 px, 16:9 landscape, high-quality 4K image.
-- Layout: three full-height vertical columns with clean gutters.
-- Widths: page mockup 1 = 40%, page mockup 2 = 40%, design-system rail = 20%; equivalent ratio 2 : 2 : 1.
-- Left column: page mockup 1.
-- Middle column: page mockup 2.
-- Right column: design-system details rail.
-- The two page mockups must dominate and read as large, inspectable website pages.
-- The rail must be quieter than the mockups but legible at full 4K size.
-- Keep the page mockups spacious and breathable, with clear margins, open section rhythm, and enough negative space that the design does not feel busy.
-- Do not add extra panels, page thumbnails, floating device mockups, moodboard imagery, standalone logo explorations, component inventories, callout overlays, or decorative filler.
-- Do not generate a separate design-system board, a two-board split, multiple images, unreadably tiny UI fragments, or a dashboard/workspace/app UI board unless the user explicitly requests an interface-only board instead of a marketing site.
-
-## Page Mockups
-
-The two mockups should be substantial public-facing marketing website pages with generous spacing, strong breathing room, and restrained content density. Treat an app concept as a product that needs a marketing site, not as permission to make the board an app UI study. Product/app UI may appear only as supporting content embedded inside a page mockup.
-
-If the concept is a web app, desktop app, mobile app, SaaS product, marketplace, creator tool, productivity tool, or other software product, include at least one realistic screenshot or framed view of the app inside the marketing pages. These screenshots should help explain the product and provide brand inspiration, while the surrounding page remains the main subject.
-
-Page mockup 1:
-
-- Default to the homepage.
-- Make it the clearest expression of the marketing promise.
-- Include primary navigation with an appropriate logo, wordmark, or brand mark; a strong hero system; primary CTA; and enough below-the-fold content to show section pacing.
-- For app/software concepts, include a prominent but embedded product screenshot, device frame, desktop/webapp frame, mobile screen, or interface crop.
-
-Page mockup 2:
-
-- Default to a supporting page that reveals a different side of the system.
-- Prefer pages that add new content patterns: pricing, booking, signup, product/service detail, collection/category, editorial/content, comparison, case study, lead-capture, checkout, account creation, search/results, commerce, structured data, forms, tables, cards, proof blocks, dense typography, or screenshot-led feature explanation.
-- Reuse the same logo, wordmark, or mark from the homepage in realistic page chrome when appropriate.
-
-For each page, define:
-
-- Page type and purpose.
-- Layout structure, hierarchy, key components, and copy tone.
-- Logo/wordmark/mark placement when a real site would include one.
-- Product screenshot placement when the concept is an app/software product.
-- Visible design behavior: grid/composition, generous spacing feel, low-to-moderate density, type scale, navigation, CTAs, forms, cards, pricing tables, proof blocks, product tiles, filters, commerce modules, editorial modules, or other relevant components.
-- Whitespace strategy: wide margins, clear gutters, open hero composition, fewer simultaneous content blocks, and section pacing that feels calm rather than crowded.
-- Distinctive frontend composition: asymmetry, overlap, strict grid, dense utility, editorial pacing, diagonal flow, immersive media, tactile states, active/hover states, scroll moments, or another concept-appropriate idea.
-
-## Design-System Rail
-
-The right rail documents only values that are hard to recover from the mockups without OCR.
-
-Include:
-
-- Typography: display/headline, body, and UI/label/numeric/mono typeface names or typeface directions; include brief hierarchy, casing, weight, tracking, or pairing notes only when useful.
-- Color: dominant/core colors separated from supporting/accent colors; approximate hex-style values; short role labels such as background, foreground, primary, surface, border, signal, accent, semantic, or category.
-- Color hierarchy: dominant/load-bearing colors shown as larger swatches or bars; supporting/accent/signal colors shown as smaller grouped chips.
-- Rail text optimized for full-4K readability: short labels, large enough type, clear spacing, no dense captions.
-
-Do not include in the rail:
-
-- Logo, wordmark, mark construction, lockups, logo notes, logo variations, or logo-spec content.
-- Spacing scales, border radius, grid specs, motion notes, component inventories, component states, icon notes, elevation/shadow specs, or arbitrary brand copy.
-- Slogans, positioning paragraphs, mood words, or any text that does not directly document typography or color values used in the page mockups.
-
-## Creative Direction
-
-Choose a bold but concept-appropriate aesthetic direction, such as brutally minimal, maximalist, retro-futuristic, organic, luxury, playful, editorial, brutalist, art deco, soft, industrial, utilitarian, or another direction inferred from the brief.
-
-Define:
-
-- Purpose: what visitors should understand, trust, and do.
-- Marketing focus: how the site introduces, explains, proves, and sells the brand.
-- Tone: 3-5 strong adjectives, not a neutral default.
-- Differentiation: the one visual, typographic, interaction, material, motif, or page-structure idea someone would remember.
-- Constraints: production-grade, functional, accessible, plausible for a real frontend.
-- Intensity: maximalist systems may be rich; refined systems should rely on restraint, proportion, and precision.
-- Spacing: preserve generous whitespace even for expressive or maximalist concepts; use scale, contrast, and composition for impact instead of cramming in more modules.
-
-Avoid:
-
-- Defaulting to Inter, Roboto, Arial, system fonts, or overused neutral typography unless requested.
-- Cliche purple-blue gradients on white, generic glassmorphism, bland SaaS dashboards, default rounded cards, cookie-cutter component layouts, unrelated gradient blobs, or decorative effects unrelated to the brand.
-- Cramped layouts, busy collages, overfilled sections, dense rows of tiny cards, excessive annotations, or too many simultaneous UI fragments.
-- Reusing the same trendy typefaces or color systems across concepts.
-
-## Final Prompt Structure
-
-Assemble the final answer as the image prompt itself, using these sections:
-
-1. Brand Positioning
-   - Target audience, market positioning, 3-5 tone adjectives, brand personality, relevant comparables/references, and avoid list.
-2. Aesthetic Concept
-   - Core frontend art direction in one vivid phrase, why it fits, memorable design idea, intensity/restraint, and what makes it specific to this brand.
-3. Reference Image Use
-   - Include only when images are attached. Summarize reusable visual qualities and state that references are for style inspiration only, not for copied content, logos, text, exact layouts, or proprietary UI.
-4. Board Layout
-   - Restate the canonical 3840 x 2160, 40% / 40% / 20%, three-column layout and the prohibition on extra panels or alternate layouts.
-5. Page Mockups
-   - Define the homepage and supporting page using the `Page Mockups` requirements, or use the user's requested pages.
-6. Design-System Rail
-   - Define only the typography block and hierarchical color block using the `Design-System Rail` requirements.
-7. Visual Style Constraints
-   - State what to avoid, what to emphasize, anti-generic constraints, generous whitespace requirements, and that the fixed layout still applies even when the aesthetic is expressive.
-8. Rendering / Style Hints
-   - End with one concise rendering line: one 3840 x 2160 px 16:9 high-quality 4K presentation image; fixed 40% page mockup 1 / 40% page mockup 2 / 20% typography-and-color rail; crisp readable UI and rail text; production-grade marketing website mockups; bold concept-specific art direction; generous margins, open section rhythm, and calm whitespace; realistic polished visual design.
-
-## Rules
-
-- Be specific and concrete; maintain internal consistency across all sections.
-- Make the aesthetic direction memorable and concept-specific.
-- Keep the website mockups spacious; do not trade readability and whitespace for extra content.
-- Use specific typeface names or precise typeface directions and approximate color values.
-- Specify which colors are dominant/load-bearing and which are supporting/rare accents, and require that hierarchy to be visible.
-- Keep all visible rail text short enough for image generation to render legibly.
-- Do not hardcode examples from one concept into another concept.
-- Do not ask for a separate design-system board or two images.
-- Do not explain your reasoning.