@tiic-tech/openworkflow 0.1.0 → 0.1.2

package/skills/build-prototype/SKILL.md

@@ -1,40 +1,94 @@
 ---
 name: build-prototype
-description: Turn a validation artifact into a focused prototype discovery plan and todo list. Use when the user wants to build the smallest local prototype for a core assumption before creating specs, changes, Agent Teams, runtime state, or production implementation plans.
+description: Consume ready PROTO_PROMPT_PACK artifacts through prompt2proto and translate them into credible UI/UX prototype instructions and evidence. Use after build-proto-prompt has produced ready prompt text and before tune, proto2html, specs, changes, Agent Teams, runtime state, or production implementation plans.
 ---
 
 # Build Prototype
 
 ## Purpose
 
-Create and execute the prototype discovery loop for one validation target. This
-skill turns `VALIDATION.yaml` and `PROTOTYPE_BRIEF.md` into a constrained
-prototype plan and todo contract.
-
-Prototype work is not production work. It should answer the validation
-question quickly, often with hardcoded data, a single HTML file, or a small
-local demo.
+Consume ready prototype prompt-pack artifacts without starting production
+implementation. The preferred source behavior is image-first: accept a ready
+`PROTO_PROMPT_PACK`, verify its readiness and coherence gates, then use
+prompt2proto to translate the prompt pack into credible UI/UX prototype
+instructions, evidence, and downstream handoff facts.
+
+Prototype work answers a product uncertainty. It should not become a hidden
+production implementation plan.
+
+`/ow:proto` remains the user-facing orchestration command. It may run
+build-proto-prompt internally when a ready prompt pack is missing, then hand the
+ready prompt pack to build-prototype/prompt2proto. `build-prototype` itself is
+not the vision-to-prompt-pack compiler.
+
+The engine behind ready prompt-pack compilation belongs to build-proto-prompt:
+co-founder plus senior product-manager judgment generates strategically
+different prompt directions. Build-prototype starts after that point. Its
+engine is Chief PM plus Principal UI/UX judgment that translates the ready
+prompt pack into a credible prototype surface.
+
+Before any downstream prompt2proto handoff or visual prototype translation,
+switch from prompt-pack strategy generation into the build-prototype philosophy
+engine: Chief PM plus Principal UI/UX judgment. The Chief PM protects product
+intent, user decision context, domain fit, and evidence value. The Principal
+UI/UX lead protects visual hierarchy, density calibration, affordance clarity,
+interaction believability, and prototype credibility. This judgment layer
+decides what information is visible, grouped, collapsed, delayed, or drilled
+into based on industry, user role, task risk, screen size, task frequency, and
+reviewer attention.
 
 ## Inputs
 
 Required:
 
-- `.codex/validation/<validation_id>/VALIDATION.yaml`
-- `.codex/validation/<validation_id>/PROTOTYPE_BRIEF.md`
+- `.openworkflow/prototypes/<prototype_id>/PROTO_PROMPT_PACK.yaml` or an
+  equivalent ready prompt pack artifact
+- `prompt_text_manifest.status: ready_for_image_generation`
+- `prompt_text_manifest.paragraph_quality_status: pass`
+- `prompt_pack_integrity_gate.status: pass`
+- `prototype_reality_gate.status: pass`
+- `quality_rubric.prompt_executability.status: pass`
+- `prototype_system_contract` when multiple screens share a product shell
+- `post_validate.status: pass` for multi-direction packs, or `skipped` for an
+  explicit single-direction pack
+
+If a ready prompt pack is missing, thin, stale, or incoherent, build-prototype
+must refuse and route back to `/ow:build-proto-prompt` or the compatible
+`/ow:vision2prompt` compiler path. Do not repair strategic prompt text inside
+build-prototype.
 
 Optional:
 
-- `.codex/context/CONTEXT_MAP.yaml`
-- `.codex/vision/VISION_CONTRACT.yaml`
-- direct user constraints about the prototype medium or acceptance bar
+- `.openworkflow/context/CONTEXT_MAP.yaml` or `.codex/context/CONTEXT_MAP.yaml`
+- direct user constraints about selected direction, prototype medium, target
+  tool, viewport, language, platform, brand, or acceptance bar
+- `references/proto-redesign-artifact-contracts.md`
+- `skills/build-prototype/references/philosophy-engine.md`
+- `skills/prompt2proto/SKILL.md`
+- `skills/prompt2proto/references/01_input_contract.md`
+- `skills/prompt2proto/references/02_prompt_pack_readiness.md`
+- `skills/prompt2proto/references/03_visual_translation_workflow.md`
 
 Do not load unrelated specs, changes, runtime state, reviews, archives, or
-implementation history unless the validation question explicitly depends on
+implementation history unless the prototype question explicitly depends on
 them.
 
 ## Output
 
-Write prototype artifacts under:
+For image-first planning, write prototype translation artifacts under the active
+prototype or change path chosen by the workflow. The ready prompt pack remains
+the input artifact, not something build-prototype recreates.
+
+Expected build-prototype output families:
+
+```txt
+PROMPT2PROTO_TRANSLATION_PLAN.md
+PROMPT2PROTO_EVIDENCE.yaml
+NOTE.md
+EVIDENCE.yaml updates that reference accepted prompt-pack inputs
+```
+
+For local runnable prototypes, the legacy artifact shape remains valid:
 
 ```txt
 .codex/prototypes/<prototype_id>/
@@ -46,42 +100,112 @@ Write prototype artifacts under:
   archive/
 ```
 
-`TODO.yaml` is the machine-readable prototype contract. `PROTOTYPE_PLAN.md` is
-the human-readable execution plan. `RESULT.md` and `EVIDENCE.md` are updated
-after local review or user feedback.
-
 ## Workflow
 
-1. Load the validation contract and prototype brief.
-2. Keep the core question unchanged.
-3. Convert prototype `include` scope into a short todo list.
-4. Preserve `exclude` scope as hard boundaries.
-5. Prefer the smallest artifact that a user can experience locally.
-6. Initialize artifacts with `scripts/init_prototype.py`.
-7. Implement the prototype directly when the user asks for execution and the
-   scope remains small enough for the main agent.
-8. Use subagents only for narrow parallel work; prototype orchestration does not
-   require `/ow:team`.
-9. Record what was tested in `EVIDENCE.md` and the user-facing outcome in
-   `RESULT.md`.
+1. Load the ready prompt pack and prompt2proto input/readiness references.
+2. Refuse missing, thin, stale, or incoherent prompt packs. Route repair to
+   `/ow:build-proto-prompt` or compatible `/ow:vision2prompt`; do not invent
+   strategy in build-prototype.
+3. Verify prompt-pack readiness, paragraph quality, prototype reality,
+   screen_manifest linkage, prototype_system_contract, and post_validate before
+   visual translation.
+4. Use prompt2proto to preserve product strategy and technical screen
+   coherence while translating the ready prompt pack into UI/UX prototype
+   instructions and evidence.
+5. Before accepting prototype instructions, use
+   `skills/build-prototype/references/philosophy-engine.md` to calibrate
+   density, information hierarchy, domain object emphasis, trust controls, and
+   UI/UX credibility.
+6. If the user asks to tune accepted baseline screens or an accepted prompt
+   pack, hand off to `skills/tune-prototype/SKILL.md`.
+7. Run `npm run validate` when the repository validator exists.
+
+## Ready Prompt-Pack Consumption
+
+1. Accept only prompt packs whose prompt text is ready for image generation and
+   whose integrity, reality, executability, paragraph quality, and
+   post-validation gates pass.
+2. Preserve the prompt-pack strategy: product thesis, target user
+   transformation, primary loop, non-goals, trust boundaries, and direction
+   reasons to exist.
+3. Preserve `prototype_system_contract` as the source of technical screen
+   coherence: stable app shell, navigation taxonomy, data vocabulary, object
+   anatomy, action bar, audit pattern, copy tone, and allowed screen deltas.
+4. Apply the Chief PM plus Principal UI/UX philosophy engine to decide visual
+   hierarchy, density, affordances, interaction believability, and UI/UX
+   credibility.
+5. Write provider-agnostic prototype instructions and evidence. Keep provider
+   image generation, human visual review, visual parity, proto2html, specs,
+   changes, teams, and runtime work out of scope.
+
+## Build-Prototype Philosophy Engine
+
+Use this engine after strategic prompt assets are ready and before downstream
+visual translation is accepted:
+
+- Chief PM lens: decide what the prototype must prove, what user decision is at
+  stake, which domain objects matter, what trust boundary must be visible, and
+  what information would change the next action.
+- Principal UI/UX lens: decide the screen's hierarchy, density, layout anatomy,
+  scan path, affordance clarity, interaction feedback, and inspection quality.
+- Density is not a prompt length target. It is a product/design decision:
+  operational users may need dense comparison surfaces, while sensitive or
+  consumer flows may need fewer visible choices and stronger reassurance.
+- Use `prototype_system_contract` for technical screen coherence. Use this
+  philosophy engine for density and visual information judgment.
+
+Reject both sparse mockups that hide the operating decision and overstuffed
+concept posters that make everything equally important.
+
+## Strategic Direction Rules
+
+- Strategic direction generation belongs to build-proto-prompt. Build-prototype
+  may choose which already-ready direction or screens to translate, but must
+  not create new strategic directions.
+- If ready directions differ only by visual style, route back to
+  build-proto-prompt repair instead of treating them as valid prototype
+  strategy.
+- Preserve explicit non-goals, trust boundaries, privacy requirements, and user
+  controls.
+- Convert category anti-patterns into negative visual constraints, especially
+  generic AI dashboards, consulting-report screens, or card walls when the
+  product category calls for a richer operational shell.
+- Consumed prompts must already specify screens, journeys, interactions,
+  states, AI/system behavior, trust controls, privacy boundaries, visual
+  direction, anti-goals, desired user feeling, and concrete sample content.
+- The prompt text itself must pass paragraph quality; adjacent YAML fields do
+  not rescue a terse `screen_prompts[].prompt`.
+- The output is prototype translation evidence, not a new prompt pack,
+  production spec, or task backlog.
+
+## Local Prototype Path
+
+Use local runnable prototype behavior only when the user asks to execute a
+prototype or when validation requires an interactive artifact. Keep it small:
+hardcoded data, single HTML files, local-only assets, mocked LLM output, fake
+in-memory persistence, and narrow UI paths are acceptable.
 
 ## Forbidden Defaults
 
 - Do not create `SPEC.yaml`, `CHANGE.yaml`, `.codex/runtime/`, or Agent Team
   artifacts from this skill.
 - Do not add auth, persistence, deployment, billing, admin, upload, or full AI
-  integration unless the validation contract names that as the core assumption.
+  integration unless those are the existential assumption.
 - Do not expand the prototype to cover later features.
-- Do not treat code completeness as validation success; success means the core
-  question can be answered.
+- Do not treat code completeness as validation success.
+- Do not add `/ow:proto2html`.
+- Do not skip durable `/ow:validation` when validation is missing.
+- Do not tune accepted baseline screens here; use `tune-prototype`.
 
 ## Handoff
 
-After user review, hand off to `/ow:decision`.
+After user review, hand off to `/ow:decision`, `/ow:tune`, design/spec
+planning, or another candidate change.
 
-Expected decision outcomes:
+Expected outcomes:
 
-- `continue`: prototype is strong enough to become a focused production slice
+- `continue`: prototype direction is strong enough for production planning
+- `tune`: generate a refined prompt pack from the accepted baseline
 - `pivot`: adjust the vision or validation target
 - `stop`: archive or clean the prototype path
-- `needs_more_evidence`: revise the prototype scope and test again
+- `needs_more_evidence`: revise the prompt pack or build a smaller local test

package/skills/build-prototype/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Build Prototype"
-  short_description: "Create a focused prototype from validation artifacts"
-  default_prompt: "Use /ow:prototype to turn a validation target into a local prototype plan."
+  short_description: "Create strategic prototype prompt packs"
+  default_prompt: "Use /ow:proto to turn vision or validation context into strategic image-first prototype prompt packs for review."

package/skills/build-prototype/references/philosophy-engine.md

@@ -0,0 +1,61 @@
+# Build-Prototype Philosophy Engine
+
+Use this reference after prompt-pack strategy is ready and before prototype
+instructions are accepted for downstream visual translation.
+
+## Role Pair
+
+Operate as a Chief PM plus Principal UI/UX product design lead.
+
+The Chief PM asks:
+
+- What product decision must this prototype make observable?
+- Which user role, domain object, risk, and next action matter most?
+- Which trust, approval, privacy, or audit boundary must be visible?
+- What information changes the user's next decision, and what is only support?
+
+The Principal UI/UX lead asks:
+
+- What is the primary visual hierarchy and scan path?
+- Which information belongs on the main canvas, side panel, drawer, modal, or
+  drill-down?
+- Which affordances need to be obvious without explanatory text?
+- Does the screen feel like a credible product surface for its industry rather
+  than a generic dashboard, card wall, report, or concept poster?
+
+## Density Calibration
+
+Choose density from product context:
+
+- Industry: operational, financial, civic, clinical, and developer tools can
+  carry more inspectable data when comparison drives work.
+- User role: expert repeat users can scan denser surfaces than first-time or
+  consumer users.
+- Task risk: high-risk actions need visible consequence, approval, provenance,
+  and reversal controls.
+- Screen size: mobile density must prioritize the next decision; desktop can
+  show relationships, side panels, and comparison rows.
+- Task frequency: frequent tasks should optimize scanning and next action;
+  rare tasks should slow down and explain consequences.
+
+## Visibility Rules
+
+- Visible: information that changes the user's next decision.
+- Grouped: fields that must be compared or understood together.
+- Collapsed: secondary detail that remains inspectable.
+- Delayed: information that only matters after the user expresses intent.
+- Drilled into: detail that would overload the main canvas but is required for
+  trust, review, or audit.
+
+## Quality Bar
+
+The result should make a reviewer understand the product form, the user's work,
+the selected object or state, the next action, and the trust boundary without
+reading a separate explanation.
+
+Reject:
+
+- under-specified mockups that hide workflow anatomy;
+- overstuffed screens where every element has equal priority;
+- decorative AI dashboards with no accountable user action;
+- visual concepts that ignore the prompt-pack coherence contract.

package/skills/build-prototype/references/strategic-prompt-pack-protocol.md

@@ -0,0 +1,365 @@
+# Strategic Prompt Pack Protocol
+
+Use this reference when `/ow:proto` should produce high-fidelity prototype
+prompt directions from proto-ready vision and a durable validation target.
+
+`/ow:proto` is a strategy-to-prompt compiler. It preserves product intent,
+turns validation uncertainty into prototype directions, and writes prompts that
+an image-generation or design agent can execute without inventing strategy.
+
+The concrete quality target is dailin-grade prompt text. The dailin
+`OUTPUT_PROMPT.md` examples are the minimum passing benchmark for
+`directions[].prototype_prompt` and `screen_prompts[].prompt`: complete
+high-fidelity prototype-generation briefs with product context, journey,
+interaction behavior, system response, trust controls, anti-goals, visual
+direction, and desired user feeling. Short screen-state image instructions do
+not pass this protocol.
+
+## Perspective Engine
+
+Before running the reference pipeline, adopt a co-founder plus 15-year senior
+product-manager perspective. Treat the vision as a product opportunity, not as
+a request to fill screen fields. The job is to decide what product should
+exist, why it should exist, which form best expresses it, and what user
+transformation the prototype should make visible.
+
+The dailin-derived references are tools for this perspective engine. They help
+normalize, decompose, hypothesize, write, and check. They are not a substitute
+for taste, product judgment, or design philosophy. A prompt pack can satisfy
+all structural sections and still fail if it lacks a product thesis,
+reason-to-exist, differentiated product imagination, and clear PM judgment.
+
+Every selected direction must therefore include:
+
+- product thesis: the strongest argument for this product form;
+- user transformation: how the target user's behavior, confidence, control, or
+  progress changes;
+- differentiated form: why this is not just a dashboard, chatbot, card wall,
+  report screen, or visual skin unless that form is strategically necessary;
+- reason-to-exist: why this direction deserves prototype generation now;
+- PM judgment: what assumption it tests, what risk it exposes, and why the
+  reviewer should look at it first or later.
+
+## Vision2Prompt Reference Pipeline
+
+Before writing `PROTO_PROMPT_PACK.yaml` or `PROTO_PROMPT_PACK.md`, run the
+OW-owned dailin-grade pipeline under `references/vision2prompt/` in order:
+
+1. `01_input_contract.md`: normalize durable vision, validation, direction
+   count policy, target tool, fidelity, constraints, and missing-input rules.
+2. `02_vision_decomposition.md`: extract target user, current alternative,
+   behavior change, success signal, differentiator, trust/privacy requirements,
+   non-goals, and central uncertainty.
+3. `03_strategy_hypothesis_generation.md`: generate 5 to 8 candidate strategic
+   hypotheses and select only materially distinct directions.
+4. `04_product_system_extraction.md`: infer product experience model,
+   product-system constants, screen_manifest, domain object model, state model,
+   required data fields, trust controls, and anti-generic constraints.
+5. `05_prototype_prompt_schema.md`: write directly executable prototype prompts
+   with screen groups, states, actions, system behavior, example content,
+   negative prompts, and acceptance criteria.
+6. `06_output_templates.md`: keep YAML as source of truth and Markdown as the
+   readable view.
+7. `07_quality_rubric.md`: verify strategic distinctness, prompt
+   executability, product specificity, trust/safety, and integrity gates before
+   `prompt_text_manifest.status` becomes `ready_for_image_generation`.
+
+Do not collapse this pipeline into a short image prompt. A valid strategic
+prompt pack describes a product prototype system: product thesis, target user,
+primary loop, strategic directions, screen groups, state behavior, concrete
+data/copy, trust boundaries, negative constraints, and acceptance checks.
+
+Do not collapse the perspective engine into persona text. "Senior PM" is only
+useful when it changes the output: sharper product thesis, clearer user
+transformation, stronger form choice, and more opinionated anti-defaults.
+
+Do not hand off to `/ow:prompt2proto` until the actual prompt paragraphs pass
+the paragraph-quality gate. `quality_rubric.prompt_paragraph_quality` and
+`prompt_text_manifest.paragraph_quality_status` must prove the text itself
+contains product context, target user, journey, screen/component requirements,
+interaction behavior, system response, concrete content, trust or user-control
+surfaces, visual direction, anti-goals, desired user feeling, and the
+perspective engine.
+
+This pipeline intentionally mirrors dailin
+`vision_to_strategic_prototype_prompt` Steps 1-6:
+
+- normalize inputs;
+- extract the strategic core;
+- generate candidate strategic hypotheses;
+- select the most differentiated directions;
+- write each full prototype-generation prompt;
+- recommend build order with success and failure signals.
+
+## Validation Consumption
+
+Validation is required before prototype generation.
+
+- If a durable validation artifact exists, consume it and preserve its
+  include/exclude boundaries.
+- If validation is absent but vision exists, auto-run the same
+  artifact-producing `/ow:validation` pass first.
+- The auto-validation artifact must record `trigger.mode: agent_auto`,
+  `trigger.requested_command: /ow:proto`, and
+  `trigger.reason: missing_current_validation`.
+- Do not proceed with ephemeral `vision_only` context.
+- If validation conflicts with vision, stop for a decision instead of broadening
+  the prototype target silently.
+
+## Input Normalization
+
+Extract or infer:
+
+- product domain
+- primary user
+- usage context
+- current alternative
+- core pain
+- desired behavior change
+- strongest success signal
+- core differentiator
+- emotional value
+- functional value
+- trust or privacy constraints
+- non-goals
+- future opportunities
+- validation target or central uncertainty
+
+Record `validation_input.mode: validation_present` when consuming a current
+validation artifact. Use `validation_input.mode: agent_auto_generated` only when
+the proto command first created durable validation artifacts because none were
+current.
+
+## Strategic Core
+
+Represent the product as:
+
+```txt
+target user + behavior change + mechanism + differentiator + boundary conditions
+```
+
+Find the central uncertainty:
+
+- what makes the user start
+- what makes the user repeat
+- what makes the user trust the system
+- what makes the user switch from the current alternative
+- what must be true for the product to feel meaningfully different
+
+## Product Experience Model
+
+Before generating strategic directions, infer the product category and product
+shell that the vision implies. Record it as `product_experience_model`.
+
+Required dimensions:
+
+- `product_archetype`: the target product category, such as map-first smart city
+  operations dashboard, daily voice-call ritual, memory-centered companion room,
+  scenario playground, inbox, workspace, board, editor, or console.
+- `primary_canvas`: the main surface that should dominate the prototype, such
+  as map, call console, conversation room, timeline, board, editor, inbox, or
+  dashboard.
+- `information_architecture`: navigation model, major domains, hierarchy, and
+  product areas.
+- `domain_object_model`: concrete user-visible objects, records, entities, and
+  business data.
+- `primary_task_loop`: the end-to-end user workflow the screen group must make
+  understandable.
+- `interaction_state_model`: selected, expanded, hover, empty, loading,
+  warning, blocked, pending human confirmation, and other category-relevant
+  states.
+- `data_realism_requirements`: sample fields, labels, metrics, values, and
+  operational details that make the prototype feel like real product work.
+- `visual_language`: category-specific layout and component expectations.
+- `anti_generic_constraints`: forbidden generic patterns such as AI governance
+  report dashboards, consulting slide layouts, card walls, or chatbot shells
+  when they do not match the target category.
+
+Use this model to decide whether concepts from the vision are separate product
+directions or modules, scenarios, layers, workflows, or states inside one
+product shell. For example, planning approval, incident response, and asset
+capacity may be modules inside one smart-city operations dashboard rather than
+three separate prototype directions.
+
+## Hypothesis Generation
+
+Generate 5-8 candidate hypotheses, then choose the strongest directions.
+
+Template:
+
+```txt
+If the product is shaped as [product form]
+and uses [core mechanism]
+to reduce or increase [friction or motivation],
+then [target user] will [desired behavior]
+because [emotional or functional reason].
+```
+
+A direction is distinct only if it differs from others on at least two
+dimensions:
+
+- product form
+- user initiation trigger
+- interaction model
+- emotional driver
+- learning or usage mechanism
+- retention mechanism
+- validation metric
+- main risk
+
+Do not split directions by scenario labels alone. A scenario is a product
+direction only when it changes product form, product loop, trigger,
+interaction model, emotional driver, retention mechanism, validation metric, or
+main risk.
+
+Reject directions that only change colors, layout, visual tone, or component
+style.
+
+Each selected direction should name why it deserves prototype generation:
+what it tests, what it risks, what the user should feel, and which validation
+signal it can make observable.
+
+Reject directions that are structurally complete but strategically empty: they
+list screens and prompt anatomy, but do not make a product argument.
+
+## Prompt Pack Structure
+
+`PROTO_PROMPT_PACK.yaml` should follow `schemas/proto-prompt-pack.schema.json`
+and include:
+
+- `prompt_pack_type: strategic_proto_prompt_pack`
+- `source`
+- `validation_input`
+- `normalized_input`
+- `strategic_core`
+- `prototype_brief`: product name, positioning, target user, current
+  alternative, core idea, primary loop, trust boundaries, non-goals, and desired
+  feeling
+- `product_experience_model`
+- `prototype_system_contract` with stable app shell, navigation taxonomy, data
+  vocabulary, domain object anatomy, object/detail panel anatomy, action bar,
+  audit/trust pattern, copy tone, and allowed screen-specific deltas
+- `screen_manifest` with target screen ids, journey stages, user goals, system
+  states, required components, required data fields, primary actions, AI
+  behavior or explicit non-AI rationale, trust controls, example copy, and
+  acceptance criteria
+- `global_design_system_prompt`: visual language, layout system, component
+  vocabulary, information density, copy tone, responsive/canvas rules, and
+  negative visual patterns
+- screen-bound `screen_prompts` tied to `screen_manifest` ids, with standalone
+  prompt text, negative prompt, example copy, and acceptance criteria
+- `quality_rubric`: prompt executability, strategic distinctness, product
+  specificity, state coverage, trust-boundary coverage, and
+  prompt_paragraph_quality
+- `directions`
+- `build_recommendation`
+- `prompt_pack_integrity_gate`
+- `prototype_reality_gate`
+- `post_validate`
+- `negative_constraints`
+- `review_plan`
+
+`PROTO_PROMPT_PACK.md` should be the human-readable view.
+
+Each direction needs:
+
+- `direction_id`
+- `name`
+- `strategic_hypothesis`
+- `validates`
+- `main_risk`
+- `distinctness_rationale`
+- `prototype_prompt`
+- `screen_prompts`
+- `pm_judgment`
+- `product_thesis`
+- `user_transformation`
+- `reason_to_exist`
+
+When `prompt_text_manifest.status` becomes `ready_for_image_generation`,
+`prototype_system_contract` must state cross-screen invariants separately from
+screen-specific state deltas, and every direction screen prompt must resolve to
+a `screen_manifest.target_screen_id`.
+Do not mark prompt text ready when screen prompts are detached from the product
+journey, missing negative prompts or example copy, omit paragraph quality
+dimensions, or only restate a freeform `prototype_prompt`.
+
+## Prototype Prompt Requirements
+
+Each prompt must include:
+
+- product name
+- positioning
+- target user
+- core product idea
+- required screens
+- complete user journey
+- interaction requirements
+- system or AI behavior requirements
+- trust, privacy, and user control requirements
+- visual direction
+- anti-goals
+- desired user feeling
+- concrete sample content
+
+Prompt text must carry those requirements inside the actual paragraphs used for
+generation. Do not rely on adjacent YAML fields to rescue a terse
+`screen_prompts[].prompt`.
+
+Each screen prompt should be able to stand alone. It should name the journey
+stage, user goal, system state, selected object when relevant, required
+components, data fields, actions, AI/system behavior, trust controls, negative
+prompt, and acceptance criteria.
+
+Minimum screen prompt anatomy:
+
+- product and direction context;
+- journey stage and screen purpose;
+- target user goal and current system state;
+- visible components and domain objects;
+- realistic data, copy, labels, metrics, owners, timestamps, or messages;
+- primary user actions and system response;
+- trust, privacy, approval, memory, or user-control surfaces;
+- visual direction tied to the product category and primary canvas;
+- negative constraints and anti-goals;
+- screen-bound acceptance criteria and desired user feeling.
+
+The prompt should be specific enough that another agent can generate the first
+screen group without asking what the product is, who it serves, what behavior
+should change, what must be shown, what must not be shown, or what counts as a
+good prototype.
+
+## Build Recommendation
+
+Recommend the first direction to generate by weighing:
+
+- closeness to the strongest success signal
+- ability to validate the biggest unknown quickly
+- prototype feasibility
+- user behavior observability
+- risk reduction
+
+Include success signals, failure signals, and what to test next if it works.
+
+## Quality Gate
+
+Revise before finishing if:
+
+- directions are mostly visual variations
+- prompts are too abstract for a design tool
+- prompt text reads like a single screenshot description instead of a product
+  prototype brief
+- `screen_manifest` or screen-bound prompt content is missing for a
+  multi-screen prototype
+- `prototype_system_contract` is missing for a generation-ready multi-screen
+  prompt pack
+- concrete domain objects, data fields, example copy, actions, and state
+  behavior are absent
+- non-goals are not converted into anti-goals
+- AI/system behavior is missing for an AI-mediated product
+- trust/privacy controls are absent when memory, personalization, or sensitive
+  user data is involved
+- prompt pack integrity, prototype reality, or post-validate gates are missing
+  or failing while image generation is queued or complete
+- output drifts into implementation backlog or production spec
+- validation is missing, stale, or represented only as ephemeral context