@oisincoveney/pipeline 3.0.1 → 3.1.0

package/dist/commands/ticket-command.js

@@ -157,7 +157,10 @@ function runTicketScoperEffect(launchPlan, executor) {
 }
 function checkTicketGraphEffect(worktreePath, flags) {
 	return Effect.gen(function* () {
-		yield* writeLineEffect(`OK: ticket graph valid (${(yield* loadTicketGraphEffect(worktreePath, flags.root)).scopedIds.length} tickets)`);
+		const loaded = yield* loadTicketGraphEffect(worktreePath, flags.root);
+		const dangling = loaded.graph.danglingDependencies;
+		yield* writeLineEffect(`OK: ticket graph valid (${loaded.scopedIds.length} tickets)`);
+		if (dangling.length > 0) yield* writeLineEffect(`WARN: ${dangling.length} dependency reference(s) point to tasks absent from this backlog (treated as non-blocking): ${dangling.join("; ")}`);
 	});
 }
 function printTicketSequenceEffect(worktreePath, flags) {

package/dist/config/lint.js

@@ -34,7 +34,6 @@ function lintMissingFileReferencesEffect(config, projectRoot) {
 }
 function lintFileReferences(config) {
 	const refs = [];
-	for (const [skillId, skill] of Object.entries(config.skills)) pushLintPathRef(refs, `skills.${skillId}.path`, skill);
 	for (const [profileId, profile] of Object.entries(config.profiles)) {
 		pushLintPathRef(refs, `profiles.${profileId}.instructions.path`, { path: profile.instructions.path });
 		pushLintPathRef(refs, `profiles.${profileId}.output.schema_path`, { path: profile.output?.schema_path });

package/dist/config/schemas.d.ts

@@ -226,8 +226,8 @@ declare const configSchema: z.ZodObject<{
     policy: z.ZodOptional<z.ZodObject<{
       commands: z.ZodOptional<z.ZodEnum<{
         allow: "allow";
-        deny: "deny";
         "trusted-only": "trusted-only";
+        deny: "deny";
       }>>;
       modules: z.ZodOptional<z.ZodEnum<{
         allow: "allow";
@@ -255,8 +255,8 @@ declare const configSchema: z.ZodObject<{
       global: "global";
     }>>;
     mode: z.ZodEnum<{
-      local: "local";
       hosted: "hosted";
+      local: "local";
     }>;
     provider: z.ZodLiteral<"toolhive">;
     authorization_env: z.ZodDefault<z.ZodString>;
@@ -299,10 +299,10 @@ declare const configSchema: z.ZodObject<{
     }, z.core.$strict>>;
     output: z.ZodOptional<z.ZodObject<{
       format: z.ZodEnum<{
-        json_schema: "json_schema";
         text: "text";
         json: "json";
         jsonl: "jsonl";
+        json_schema: "json_schema";
       }>;
       repair: z.ZodOptional<z.ZodObject<{
         enabled: z.ZodOptional<z.ZodBoolean>;
@@ -371,10 +371,10 @@ declare const configSchema: z.ZodObject<{
         disabled: "disabled";
       }>>>;
       output_formats: z.ZodOptional<z.ZodArray<z.ZodEnum<{
-        json_schema: "json_schema";
         text: "text";
         json: "json";
         jsonl: "jsonl";
+        json_schema: "json_schema";
       }>>>;
       rules: z.ZodOptional<z.ZodBoolean>;
       skills: z.ZodOptional<z.ZodBoolean>;

package/dist/config/validate.js

@@ -37,7 +37,6 @@ function validatePipelineConfig(rawConfig, projectRoot, options = {}) {
 	validateHookConfig(config, issues, projectRoot, options);
 	validateTokenBudget(config, issues);
 	for (const [ruleId, rule] of Object.entries(config.rules)) validatePath(`rules.${ruleId}.path`, rule, projectRoot, issues, options);
-	for (const [skillId, skill] of Object.entries(config.skills)) validatePath(`skills.${skillId}.path`, skill, projectRoot, issues, options);
 	for (const [workflowId, workflow] of Object.entries(config.workflows)) validateWorkflow(workflowId, workflow, config, issues, projectRoot, options);
 	if (issues.length > 0) throw validationError(issues);
 	return config;

package/dist/planning/generate.js

@@ -7,8 +7,9 @@ import { normalizeRunnerOutput } from "../runner-output.js";
 import { compileWorkflowPlan } from "./compile.js";
 import { loadBacklogPlanningContext } from "../schedule/backlog-context.js";
 import { baselineScheduleArtifact } from "../schedule/baseline.js";
-import { isCoverageNode, isImplementationNode } from "../schedule/scheduling-roles.js";
+import { isCoverageNode, isImplementationNode, isWriteCapableParallelChild } from "../schedule/scheduling-roles.js";
 import { addGeneratedImplementationCoverage } from "../schedule/passes/coverage.js";
+import { integrateParallelWriteFanout } from "../schedule/passes/drain-merge.js";
 import { canonicalizeGeneratedScheduleIds } from "../schedule/passes/ids.js";
 import { SCHEDULE_PASS_ORDER } from "../schedule/passes/index.js";
 import { applyNodeCatalogModelFallbacks } from "../schedule/passes/models.js";
@@ -92,7 +93,7 @@ async function generateScheduleArtifact(options) {
 	const planningContext = { ...loadBacklogPlanningContext(options.task, options.worktreePath) };
 	const generatedArtifact = await planScheduleArtifact(baseline, policy.planner_profile, options, planningContext);
 	assertSchedulePassOrder();
-	const artifact = hydrateScheduleTaskContexts(canonicalizeGeneratedScheduleIds(applyNodeCatalogModelFallbacks(options.config, policy.node_catalog, addGeneratedImplementationCoverage(options.config, generatedArtifact))), planningContext);
+	const artifact = hydrateScheduleTaskContexts(canonicalizeGeneratedScheduleIds(applyNodeCatalogModelFallbacks(options.config, policy.node_catalog, integrateParallelWriteFanout(options.config, addGeneratedImplementationCoverage(options.config, generatedArtifact)))), planningContext);
 	validateScheduleArtifact(options.config, artifact, planningContext);
 	compileScheduleArtifact(options.config, artifact, options.worktreePath);
 	return {
@@ -103,6 +104,7 @@ async function generateScheduleArtifact(options) {
 function assertSchedulePassOrder() {
 	if (SCHEDULE_PASS_ORDER.join("\0") !== [
 		"coverage",
+		"drain-merge",
 		"models",
 		"ids",
 		"references"
@@ -281,12 +283,6 @@ function workflowNodeIssues(artifact, collectIssues) {
 		});
 	});
 }
-function isWriteCapableParallelChild(config, node) {
-	if (node.kind === "agent") return config.profiles[node.profile]?.filesystem?.mode === "workspace-write";
-	if (node.kind === "command") return true;
-	if (node.kind === "parallel") return node.nodes.some((child) => isWriteCapableParallelChild(config, child));
-	return false;
-}
 function hasDownstreamDrainMerge(nodeId, index) {
 	return hasReachableDependent(nodeId, index, (node) => node.kind === "builtin" && PARALLEL_MERGE_BUILTINS.has(node.builtin));
 }

package/dist/runtime/agent-node/agent-node.js

@@ -482,7 +482,12 @@ function renderPathReferenceEffect(id, registry, worktreePath) {
 		`Path: ${path}`,
 		"",
 		content.trimEnd()
-	].join("\n")));
+	].join("\n")), Effect.catchAllCause(() => Effect.succeed([
+		`## ${id}`,
+		`Path: ${path}`,
+		"",
+		"(install-managed harness asset; loaded by the host agent runtime)"
+	].join("\n"))));
 }
 function resolveRuntimePathReference(worktreePath, ref) {
 	if (ref?.source_root === "package") return resolvePackageAssetPath(ref.path ?? "");

package/dist/schedule/passes/drain-merge.js

@@ -0,0 +1,58 @@
+import { uniqueGeneratedId } from "../../strings.js";
+import { dependentsByNeed, hasReachableDependent } from "../../planning/graph.js";
+import { isWriteCapableParallelChild } from "../scheduling-roles.js";
+//#region src/schedule/passes/drain-merge.ts
+const DRAIN_MERGE_BUILTIN = "drain-merge";
+/**
+* A parallel node whose children mutate a shared worktree must hand its results
+* to a downstream `drain-merge` builtin (the schedule validator rejects it
+* otherwise). The planner is instructed to emit one, but the integration cannot
+* depend on planner cooperation: this pass deterministically inserts the missing
+* `drain-merge` after any parallel node with more than one write-capable child
+* that lacks one, and reroutes the parallel's existing dependents through it so
+* the merge is a true join point. Single-writer or already-integrated parallels
+* are left untouched.
+*/
+function integrateParallelWriteFanout(config, artifact) {
+	return {
+		...artifact,
+		workflows: Object.fromEntries(Object.entries(artifact.workflows).map(([id, workflow]) => [id, {
+			...workflow,
+			nodes: integrateNodeList(config, workflow.nodes)
+		}]))
+	};
+}
+function integrateNodeList(config, nodes) {
+	const index = dependentsByNeed(nodes);
+	const unintegrated = nodes.filter((node) => isUnintegratedWriteFanout(config, node) && !hasDrainMerge(node.id, index));
+	if (unintegrated.length === 0) return nodes;
+	const usedIds = new Set(nodes.map((node) => node.id));
+	return unintegrated.reduce((current, parallel) => insertDrainMerge(current, parallel.id, usedIds), nodes);
+}
+function isUnintegratedWriteFanout(config, node) {
+	return node.kind === "parallel" && node.nodes.filter((child) => isWriteCapableParallelChild(config, child)).length > 1;
+}
+function hasDrainMerge(parallelId, index) {
+	return hasReachableDependent(parallelId, index, (node) => node.kind === "builtin" && node.builtin === DRAIN_MERGE_BUILTIN);
+}
+function insertDrainMerge(nodes, parallelId, usedIds) {
+	const mergeId = uniqueGeneratedId(`generated-drain-merge-${parallelId}`, usedIds, "generated-drain-merge");
+	const rerouted = nodes.map((node) => rerouteNeed(node, parallelId, mergeId));
+	const mergeNode = {
+		builtin: DRAIN_MERGE_BUILTIN,
+		id: mergeId,
+		kind: "builtin",
+		needs: [parallelId]
+	};
+	return [...rerouted, mergeNode];
+}
+function rerouteNeed(node, from, to) {
+	if (!node.needs?.includes(from)) return node;
+	const needs = node.needs.map((need) => need === from ? to : need);
+	return {
+		...node,
+		needs: [...new Set(needs)]
+	};
+}
+//#endregion
+export { integrateParallelWriteFanout };

package/dist/schedule/passes/index.js

@@ -1,6 +1,7 @@
 //#region src/schedule/passes/index.ts
 const SCHEDULE_PASS_ORDER = [
 	"coverage",
+	"drain-merge",
 	"models",
 	"ids",
 	"references"

package/dist/schedule/prompts.js

@@ -35,6 +35,7 @@ function plannerPrompt(entrypointId, task, baseline, config, planningContext) {
 		"Shape the graph by intent, not by ticket count. Do not create a full RED/GREEN/ACCEPTANCE/VERIFY chain for each backlog ticket unless each step needs ticket-specific evidence.",
 		"Only add needs edges for real dependencies, shared constraints, or verification/review fan-in.",
 		"Use one RED node for a group of tickets when they share a test strategy, then fan out to parallel GREEN implementation nodes where the work can be implemented independently.",
+		"When a parallel node contains more than one write-capable (implementation/GREEN) child, it MUST be followed by a builtin drain-merge node that needs the parallel node, and the parallel's downstream consumers must depend on that drain-merge. The drain-merge integrates the concurrent children; a parallel of multiple writers without one is rejected.",
 		"Use one acceptance or verifier node for multiple GREEN nodes when the same acceptance checklist or real repository commands prove the group.",
 		"Only serialize ticket nodes when the backlog, a shared migration/schema/API dependency, or implementation risk requires it.",
 		"",

package/dist/schedule/scheduling-roles.js

@@ -15,5 +15,22 @@ function isImplementationNode(config, node) {
 function isCoverageNode(config, node) {
 	return hasSchedulingRole(config, node, "coverage");
 }
+/**
+* Whether a parallel child mutates the workspace, and therefore must not share a
+* worktree with sibling writers unless their results are integrated downstream
+* (a `drain-merge` builtin). Agent nodes are write-capable when their profile is
+* workspace-write; command nodes always are; a nested parallel is write-capable
+* when any descendant is. Single source of truth for both schedule normalization
+* (the drain-merge integration pass) and validation.
+*/
+function isWriteCapableParallelChild(config, node) {
+	if (node.kind === "command") return true;
+	if (node.kind === "parallel") return node.nodes.some((child) => isWriteCapableParallelChild(config, child));
+	if (node.kind === "agent") return isWorkspaceWriteProfile(config, node.profile);
+	return false;
+}
+function isWorkspaceWriteProfile(config, profileId) {
+	return config.profiles[profileId]?.filesystem?.mode === "workspace-write";
+}
 //#endregion
-export { isCoverageNode, isImplementationNode };
+export { isCoverageNode, isImplementationNode, isWriteCapableParallelChild };

package/dist/tickets/ticket-graph.js

@@ -6,8 +6,6 @@ var TicketGraphError = class extends Data.TaggedError("TicketGraphError") {};
 function buildTicketGraphEffect(tasks) {
 	return Effect.gen(function* () {
 		const graph = buildUncheckedTicketGraph(tasks);
-		const missingDependencies = missingDependencyMessages(graph);
-		if (missingDependencies.length > 0) return yield* Effect.fail(new TicketGraphError({ message: `Backlog dependency graph has missing references: ${missingDependencies.join("; ")}` }));
 		const cycles = alg.findCycles(graph.dependencyGraph);
 		if (cycles.length > 0) return yield* Effect.fail(new TicketGraphError({ message: `Backlog dependency graph contains cycle: ${cycles.map((cycle) => cycle.sort(compareTaskIds).join(" -> ")).join("; ")}` }));
 		return graph;
@@ -45,6 +43,7 @@ function buildUncheckedTicketGraph(tasks) {
 	const dependencyGraph = buildDependencyGraph(sortedTasks, tasksById);
 	return {
 		childrenByParentId: indexChildrenByParentId(sortedTasks),
+		danglingDependencies: missingDependencyMessages(sortedTasks, tasksById),
 		dependencyGraph,
 		tasksById
 	};
@@ -69,9 +68,9 @@ function addDependencyEdges(dependencyGraph, tasks, tasksById) {
 function addTaskDependencyEdges(dependencyGraph, task, tasksById) {
 	for (const dependency of task.dependencies) if (tasksById.has(dependency)) dependencyGraph.setEdge(dependency, task.id);
 }
-function missingDependencyMessages(graph) {
+function missingDependencyMessages(tasks, tasksById) {
 	const messages = [];
-	for (const task of graph.tasksById.values()) for (const dependency of task.dependencies) if (!graph.tasksById.has(dependency)) messages.push(`${task.id} depends on missing ${dependency}`);
+	for (const task of tasks) for (const dependency of task.dependencies) if (!tasksById.has(dependency)) messages.push(`${task.id} depends on missing ${dependency}`);
 	return messages;
 }
 function sequenceUncheckedTicketBatches(graph, ticketIds) {

package/package.json

@@ -108,7 +108,6 @@
     }
   },
   "files": [
-    ".agents/skills",
     "defaults",
     "dist",
     "docs",
@@ -127,7 +126,7 @@
     "prepack": "bun run build:cli"
   },
   "type": "module",
-  "version": "3.0.1",
+  "version": "3.1.0",
   "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.