@tiic-tech/openworkflow 0.1.1 → 0.1.2

package/skills/build-prototype/references/vision2prompt/01_input_contract.md

@@ -0,0 +1,84 @@
+# 01 Input Contract
+
+Use this reference before `/ow:vision2prompt` writes a strategic prototype
+prompt pack. The goal is to normalize product intent into fields that can
+survive handoff, validation, and image generation.
+
+## Required Inputs
+
+- Durable vision artifact: `VISION.md` and `VISION_CONTRACT.yaml` or current
+  vision session content.
+- Durable validation target: current `VALIDATION.yaml`.
+- Direction count policy: user-requested count or the `/ow:proto` resolved
+  default.
+
+Do not compile prompt text from chat memory alone.
+
+## Optional Inputs
+
+- `TARGET_TOOL`: image generator, Figma, v0, app builder, or human designer.
+- `OUTPUT_LANGUAGE`: default to the user's language for framing; prototype
+  prompts may be English when the target tool benefits from English prompts.
+- `DOMAIN`: infer from vision when missing.
+- `FIDELITY`: default to high-fidelity product prototype.
+- `CONSTRAINTS`: brand, platform, compliance, privacy, safety, or product
+  boundaries.
+
+## Dailin Workflow Mapping
+
+This file is the OW-owned equivalent of dailin
+`vision_to_strategic_prototype_prompt/reference/01_input_contract.md`.
+`/ow:vision2prompt` must preserve the same normalization behavior before
+writing any image-generation prompt paragraph:
+
+- treat durable vision and validation artifacts as the source of truth;
+- resolve direction count, target tool, output language, fidelity, domain, and
+  constraints before prompt writing;
+- infer conservative defaults only when the durable artifacts contain enough
+  strategy to proceed;
+- record assumptions compactly in the prompt pack rather than hiding them in
+  chat memory.
+
+The dailin `OUTPUT_PROMPT.md` examples are the minimum quality benchmark for
+the prompt paragraphs produced after this normalization step. The normalized
+input must therefore contain enough product strategy to support full
+prototype-generation briefs, not just short screen-state image instructions.
+
+## Normalized Input Fields
+
+Extract or conservatively infer:
+
+- `product_domain`
+- `primary_user`
+- `usage_context`
+- `current_alternative`
+- `core_pain`
+- `desired_behavior_change`
+- `strongest_success_signal`
+- `core_differentiator`
+- `emotional_value`
+- `functional_value`
+- `trust_requirements`
+- `privacy_requirements`
+- `non_goals`
+- `future_opportunities`
+- `validation_target`
+
+## Missing Input Policy
+
+Ask only when missing information would force invention of strategy. If the
+vision and validation target are specific enough, infer conservative defaults
+and record assumptions in the prompt pack.
+
+Return to `/ow:vision` or `/ow:validation` when any of these are missing:
+
+- target user
+- desired behavior change
+- core differentiator
+- trust/privacy boundary for sensitive or AI-mediated products
+- validation target
+
+## Output Boundary
+
+This step prepares inputs only. It must not write image assets, generated
+prototype files, design specs, production specs, or implementation backlog.

package/skills/build-prototype/references/vision2prompt/02_vision_decomposition.md

@@ -0,0 +1,108 @@
+# 02 Vision Decomposition
+
+Use this reference to convert raw vision and validation artifacts into
+decision-ready strategy. Keep the decomposition compact in final artifacts, but
+make it precise enough that later prompt text does not invent product strategy.
+
+## Dailin Workflow Mapping
+
+This file is the OW-owned equivalent of dailin
+`vision_to_strategic_prototype_prompt/reference/02_vision_decomposition.md`.
+It maps dailin Step 2, "Extract Strategic Core", into durable OW prompt-pack
+fields. The decomposition must be strong enough that every later
+`directions[].prototype_prompt` and `screen_prompts[].prompt` can explain:
+
+- who the product serves;
+- what current alternative or pain it displaces;
+- what behavior should change;
+- what core mechanism and differentiator make the product worth testing;
+- what trust, privacy, and non-goal boundaries constrain the prototype;
+- what validation target the image prompt should make observable.
+
+If these elements are absent, a long prompt will still be strategically thin.
+Do not compensate by adding generic screen inventory, generic AI language, or
+visual style.
+
+## Perspective Engine
+
+Decomposition starts from a co-founder plus senior product-manager stance. Do
+not ask only "what screens are implied?" Ask:
+
+- what product should exist if this vision is true;
+- why the user would switch from the current alternative;
+- what transformation the product should create in the user's behavior,
+  confidence, control, or progress;
+- what form would make the thesis most legible;
+- what should be deliberately excluded so the product does not become generic.
+
+Carry this judgment forward as source material for prompts. The later reference
+files are tools that organize the judgment; they do not replace it.
+
+## Extraction Schema
+
+- `target_user`: who has the problem.
+- `context`: where and when the problem happens.
+- `current_alternative`: what the user does today.
+- `pain`: why the current alternative is insufficient.
+- `desired_behavior_change`: what the user should do more, less, faster, more
+  safely, or more consistently.
+- `strongest_success_signal`: what observable behavior proves progress.
+- `core_differentiator`: why this is not the current alternative with a new UI.
+- `emotional_value`: what the user should feel that makes repeated use likely.
+- `functional_value`: what concrete capability the product provides.
+- `trust_requirements`: what the product must show or constrain to earn trust.
+- `privacy_requirements`: what data must be visible, editable, deletable,
+  temporary, or off by default.
+- `non_goals`: what the prototype must not imply or include.
+- `future_opportunities`: adjacent features intentionally deferred.
+- `validation_target`: what the next prototype should prove or disprove.
+- `product_thesis`: the strongest argument for why this product should exist.
+- `user_transformation`: the change in behavior, confidence, control, or
+  progress that the prototype should make visible.
+- `form_point_of_view`: the PM judgment about the product form that best serves
+  the thesis, including why common defaults may be wrong.
+
+## Strategic Core Formula
+
+Compress the vision into:
+
+```text
+For [target user],
+who currently [current alternative / pain],
+the product helps them [desired behavior]
+through [core mechanism],
+while [trust boundary / non-goal].
+```
+
+## Central Uncertainty Patterns
+
+Classify the validation target with one or more uncertainty types:
+
+- Activation: what gets the user to start.
+- Engagement: what keeps the user moving in-session.
+- Retention: what brings the user back.
+- Trust: what makes the user allow data, memory, recommendation, automation, or
+  AI mediation.
+- Differentiation: what makes the product feel meaningfully better than the
+  current alternative.
+- Transfer: whether product behavior creates value outside the product.
+- Safety or boundary: whether the product can create value without violating
+  user control, privacy, emotional safety, or domain constraints.
+
+## Prototype-Relevant Compression
+
+When writing the prompt pack, carry forward at least:
+
+- target user
+- behavior change
+- strongest success signal
+- differentiator
+- product thesis
+- user transformation
+- form point of view
+- validation target
+- trust/privacy requirements
+- non-goals and anti-goals
+
+Anything not carried forward can disappear from downstream prototype
+generation.

package/skills/build-prototype/references/vision2prompt/03_strategy_hypothesis_generation.md

@@ -0,0 +1,89 @@
+# 03 Strategy Hypothesis Generation
+
+Use this reference to create prototype directions that test different product
+strategy assumptions, not different visual skins.
+
+## Dailin Workflow Mapping
+
+This file is the OW-owned equivalent of dailin
+`vision_to_strategic_prototype_prompt/reference/03_strategy_hypothesis_generation.md`.
+It maps dailin Steps 3 and 4 into OW prompt-pack generation: create more
+candidate hypotheses than needed, score them, then select the resolved count by
+strategic diversity and prototypeability.
+
+The selected directions must justify different prompt paragraphs. A direction
+does not deserve its own `prototype_prompt` merely because it has a different
+screen title, scenario label, module name, layout, or visual mood.
+
+The hypothesis engine must behave like a senior product manager, not a prompt
+formatting script. Each candidate should make a product argument: what form it
+takes, why that form should exist, what user transformation it seeks, and what
+risk or learning it exposes.
+
+## Hypothesis Template
+
+```text
+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].
+```
+
+## Direction Differentiation Dimensions
+
+A direction is strategically distinct only when it differs from other selected
+directions on at least two dimensions:
+
+- product thesis
+- product form
+- user initiation trigger
+- interaction model
+- emotional driver
+- functional mechanism
+- retention mechanism
+- validation metric
+- main risk
+- trust model
+- privacy model
+- reason-to-exist
+
+## Candidate Pool
+
+Generate 5 to 8 candidate hypotheses before selecting the resolved count. Use
+patterns like these only as seeds:
+
+- Companion space: persistent home base, memory, low-pressure return.
+- Daily ritual: scheduled call, check-in, reminder, recap, or routine.
+- Scenario playground: real-life situations with branching support.
+- Progress mirror: recap, journal, timeline, or concrete evidence of progress.
+- Rescue-first interface: stuck-state recovery and scaffolding as the core UI.
+- Personalization engine: explicit memory, preference, and recommendation
+  controls.
+- Operations console: object selection, evidence, actions, owners, and audit.
+- Workspace or editor: create, review, revise, and publish inside one loop.
+
+## Selection Algorithm
+
+1. Score each candidate on vision alignment, distinctiveness, testability,
+   prototypeability, and risk reduction.
+2. Penalize candidates that only arrange screens without a clear product
+   thesis, user transformation, differentiated form, or reason-to-exist.
+3. Select the top `direction_count_policy.resolved_count` directions with
+   maximum diversity.
+4. Merge or replace directions that share the same product form and trigger.
+5. Decide whether scenario labels are true directions or screens/states inside
+   one product shell.
+
+## Rejection Rules
+
+Reject a direction when it:
+
+- changes only color, layout, tone, or component style;
+- ignores the strongest success signal;
+- omits the core differentiator;
+- violates non-goals or trust boundaries;
+- is too broad to prototype as screens and states;
+- cannot produce observable validation signals;
+- recreates the named current alternative;
+- is complete as a screen inventory but empty as a product thesis.

package/skills/build-prototype/references/vision2prompt/04_product_system_extraction.md

@@ -0,0 +1,78 @@
+# 04 Product System Extraction
+
+Use this reference before writing screen prompts. A dailin-grade prompt pack is
+a product prototype brief, not a single image description.
+
+## Dailin Workflow Mapping
+
+This OW-only step extends the dailin workflow between dailin Step 4, "Select N
+Directions", and Step 5, "Write Each Prototype Prompt". Dailin's prompts work
+because they describe a full product system: first-time setup, home, primary
+interaction surface, correction or system-response moment, memory/trust
+controls, recap, and follow-up. OW must make that product system explicit
+before writing paragraph prompts.
+
+For operations, workflow, dashboard, editor, map, inbox, or AI-mediated
+products, extract the equivalent system shell and journey stages. Do not jump
+from strategy directly to isolated screenshot prompts.
+
+## Product Experience Model
+
+Populate `product_experience_model` before selecting or finalizing directions:
+
+- `product_archetype`: category such as map-first dashboard, voice call ritual,
+  companion room, scenario playground, inbox, workspace, board, editor, console,
+  journal, or operations command center.
+- `primary_canvas`: the surface that should dominate the prototype, such as
+  map, call console, conversation room, timeline, board, editor, dashboard, or
+  object detail workspace.
+- `information_architecture`: navigation, hierarchy, product areas, and major
+  domains.
+- `domain_object_model`: concrete user-visible objects, records, entities,
+  files, memories, tasks, incidents, assets, messages, or business data.
+- `primary_task_loop`: the end-to-end workflow the prototype must make legible.
+- `interaction_state_model`: selected, expanded, empty, loading, warning,
+  blocked, permissioned, pending human confirmation, stuck, rescued, saved,
+  edited, or deleted states.
+- `data_realism_requirements`: sample fields, labels, metrics, values, copy,
+  timestamps, owners, statuses, and domain-specific examples.
+- `visual_language`: category-specific layout and component expectations.
+- `anti_generic_constraints`: patterns that would make the prototype false to
+  the product category.
+
+## Screen Group Manifest
+
+Derive a `screen_manifest` before writing final prompts. Each screen should
+carry:
+
+- `screen_id`
+- `screen_name`
+- `journey_stage`
+- `user_goal`
+- `system_state`
+- `selected_object` when relevant
+- `required_components`
+- `required_data_fields`
+- `primary_actions`
+- `ai_behavior` or explicit non-AI rationale
+- `trust_controls`
+- `example_copy`
+- `acceptance_criteria`
+
+If the product is a continuous workflow, screens should be state progression,
+not unrelated scenario slides.
+
+## Direction Versus Scenario Test
+
+A scenario is a direction only if it changes product form, trigger, interaction
+model, emotional driver, retention mechanism, validation metric, or main risk.
+
+Otherwise, model the scenario as a screen, module, layer, state, or object type
+inside one product shell.
+
+## Product Specificity Rule
+
+Every prompt pack must contain concrete domain objects and example content.
+Words like dashboard, metrics, AI, workflow, recommendation, memory, or coach
+are insufficient unless the artifact names the actual objects, fields, states,
+actions, and system behavior.

package/skills/build-prototype/references/vision2prompt/05_prototype_prompt_schema.md

@@ -0,0 +1,189 @@
+# 05 Prototype Prompt Schema
+
+Use this reference when writing the human-readable `PROTO_PROMPT_PACK.md` and
+the prompt text embedded in `PROTO_PROMPT_PACK.yaml`.
+
+## Dailin Workflow Mapping
+
+This file is the OW-owned equivalent of dailin
+`vision_to_strategic_prototype_prompt/reference/04_prototype_prompt_schema.md`.
+It maps dailin Step 5, "Write Each Prototype Prompt", into the concrete text
+requirements for `directions[].prototype_prompt` and
+`screen_prompts[].prompt`.
+
+The dailin `OUTPUT_PROMPT.md` examples are the minimum paragraph quality bar.
+They are not examples of length for its own sake; they are complete
+prototype-generation briefs with positioning, user context, required screens,
+journey, interaction behavior, system response, trust controls, visual
+direction, anti-goals, and desired user feeling. OW prompt text must meet or
+exceed that level before it can be treated as image-generation-ready.
+
+Prompt text must also carry a senior product-manager point of view. The
+paragraph should not merely enumerate UI. It should express the product thesis,
+why the chosen form deserves to exist, how the user should transform, and what
+design philosophy governs the prototype.
+
+## Required Prompt Structure
+
+```text
+Design a high-fidelity [platform] prototype for a product called "[Product Name]".
+
+Product positioning:
+[What the product is and what it is not.]
+
+Target user:
+[Specific user segment, context, pain, and motivation.]
+
+Core product idea:
+[Main mechanism, differentiator, and trust boundary.]
+
+Product thesis and reason-to-exist:
+[Why this product form should exist, what it tests, and why it is not a
+generic dashboard, chatbot, card wall, report screen, or visual skin unless
+that form is strategically necessary.]
+
+Design the following screens:
+
+1. [Screen Name]
+- Purpose: [why this screen exists]
+- Components: [visible UI elements]
+- State: [current and alternate states]
+- Data: [concrete fields, values, example content]
+- Actions: [what the user can do]
+- System response: [what the product or AI does next]
+- Acceptance: [what must be visible for this screen to pass]
+
+Interaction requirements:
+- [Complete flow]
+- [Critical states]
+- [Error, stuck, blocked, rescue, or approval behavior]
+
+System / AI behavior requirements:
+- [Behavior rules]
+- [Adaptation logic]
+- [Boundary rules]
+
+Trust, privacy, and user control:
+- [What is visible]
+- [What is editable, deletable, optional, or blocked]
+- [What cannot happen automatically]
+
+Visual direction:
+- [Product-category layout]
+- [Component vocabulary]
+- [Information density]
+- [What to avoid]
+
+Anti-goals:
+- [Things the prototype must not imply or include]
+
+Prototype journey:
+Show the complete flow:
+[Step 1] -> [Step 2] -> [Step 3] -> [Step 4]
+
+The prototype should make the user feel:
+[Desired emotional and behavioral response.]
+```
+
+## Long-Form Prompt Paragraph Anatomy
+
+Each direction-level `prototype_prompt` must read like a complete
+high-fidelity prototype brief, not a caption for one image. It must include, in
+natural prompt text or clearly equivalent structured sections:
+
+- product name and product positioning, including what the product is not;
+- target user, usage context, pain, motivation, and behavior change;
+- core product idea, mechanism, differentiator, and trust boundary;
+- product thesis, reason-to-exist, and target user transformation;
+- required screen group with journey stages, not unrelated screenshots;
+- interaction requirements, including user actions and critical state changes;
+- system, AI, workflow, or automation response after meaningful user actions;
+- concrete example copy, data, metrics, objects, labels, owners, timestamps, or
+  messages appropriate to the domain;
+- trust, privacy, safety, approval, memory, or user-control surfaces when
+  relevant;
+- visual direction tied to product category, primary canvas, component
+  vocabulary, density, and anti-generic patterns;
+- anti-goals converted into explicit prohibitions;
+- prototype journey and the intended user feeling or behavioral reaction.
+
+Each screen-level `screen_prompts[].prompt` must be standalone enough for an
+image-generation agent to create that screen without reading chat history. It
+may inherit from the direction, but it still must name the journey stage, user
+goal, system state, selected object when relevant, required components, example
+content, primary actions, system response, trust controls, negative prompt
+relationship, and acceptance criteria.
+
+The old M99-style screen-state prompt is insufficient:
+
+```text
+Show the same map shell with the incident detail panel open.
+```
+
+A dailin-grade screen prompt instead explains why the screen exists, what the
+operator or user is trying to do, what data and controls are visible, what the
+system does next, what must not be implied, and what feeling or behavior the
+image should create.
+
+The prompt should also be opinionated enough that another agent understands why
+this prototype is worth generating. If the paragraph can be moved to a
+different product by swapping names and labels, it has not carried the
+co-founder/senior-PM engine forward.
+
+## Screen Specification Rules
+
+Each screen must specify:
+
+- purpose
+- components
+- states
+- actions
+- system response
+- example content
+- acceptance criteria
+
+The screen prompt should bind these fields into image-generation text. Merely
+having the fields elsewhere in YAML is not enough when the prompt paragraph
+itself remains terse.
+
+Before handoff, the prompt text must satisfy
+`prompt_text_manifest.paragraph_quality_status: pass`. Required paragraph
+quality dimensions include product context, target user, journey,
+screens/components, interaction or system response, concrete content, trust or
+user control, visual direction, anti-goals, desired user feeling, and the
+senior product-manager perspective engine.
+
+## AI/System Behavior Rules
+
+If the product involves AI, memory, personalization, recommendation, coaching,
+workflow automation, or decision support, behavior must be explicit:
+
+- The AI should...
+- The AI must not...
+- When the user...
+- When data is stale, missing, private, or synthetic...
+- Before action is executed...
+- If the user is stuck, silent, blocked, or nervous...
+
+## Concrete Content Requirement
+
+Include examples of cards, messages, data fields, metrics, settings labels,
+buttons, empty states, notifications, privacy controls, audit rows, owners,
+timestamps, selected objects, and sample copy as appropriate for the domain.
+
+## Visual Direction Rule
+
+Visual direction must encode product strategy. Avoid vague prompts like
+"modern and beautiful." Name the layout system, component vocabulary,
+information density, primary canvas, and anti-generic patterns.
+
+When the obvious default would be a dashboard, chatbot, card wall, report page,
+or SaaS shell, state whether that default is strategically correct. If it is
+not, name the alternative product form and why it better serves the user
+transformation.
+
+## Anti-Goals as Constraints
+
+Convert non-goals into design prohibitions. If a product must not feel like a
+course, chatbot, governance report, card wall, romantic companion, autonomous
+approval system, or slide deck, state that directly in the prompt.

package/skills/build-prototype/references/vision2prompt/06_output_templates.md

@@ -0,0 +1,125 @@
+# 06 Output Templates
+
+Use these shapes when writing `PROTO_PROMPT_PACK.md`. The YAML source artifact
+should carry the same content structurally.
+
+## Dailin Workflow Mapping
+
+This file is the OW-owned equivalent of dailin
+`vision_to_strategic_prototype_prompt/reference/05_output_templates.md`.
+It maps dailin's Direction Map, full Prototype Prompt sections, PM Judgment,
+and Build Recommendation into OW's `PROTO_PROMPT_PACK.yaml` source and
+`PROTO_PROMPT_PACK.md` readable view.
+
+The Markdown view may be compact for handoff, but the YAML prompt text must not
+be compacted below dailin `OUTPUT_PROMPT.md` quality. If `PROTO_PROMPT_PACK.md`
+or `screen_prompts[].prompt` reads like a short screen-state instruction, the
+output template has failed even if all required keys exist.
+
+## Strategic Prompt Pack View
+
+```text
+# [N] Strategic Prototype Directions
+
+These directions are not the same product with different styling. They test
+different product hypotheses and validation risks.
+
+## Direction Map
+
+| Direction | Strategic Hypothesis | Validates | Main Risk |
+| --- | --- | --- | --- |
+| D1 | ... | ... | ... |
+| D2 | ... | ... | ... |
+
+## Global Product System
+
+- Product thesis:
+- Target user:
+- Current alternative:
+- Primary loop:
+- Product experience model:
+- Trust and privacy boundaries:
+- Anti-goals:
+
+## Direction D1: [Name]
+
+### Strategic Hypothesis
+
+...
+
+### What This Validates
+
+...
+
+### Prototype Brief
+
+```text
+[Full high-fidelity prototype prompt]
+```
+
+### Screen Manifest
+
+| Screen | Journey Stage | User Goal | System State | Required Data | Primary Actions |
+| --- | --- | --- | --- | --- | --- |
+
+### Screen Prompts
+
+#### D1-S1: [Screen name]
+
+```text
+[Standalone screen prompt]
+```
+
+Negative prompt:
+[What this screen must not show]
+
+Acceptance:
+- ...
+
+### PM Judgment
+
+...
+
+## Build Recommendation
+
+- First direction:
+- Why first:
+- Success signals:
+- Failure signals:
+- Next test if it works:
+```
+
+## Compact View
+
+Use only when output budget is tight. Keep the full YAML source complete.
+
+```text
+# Strategic Prototype Prompts
+
+## D1: [Name]
+Hypothesis: ...
+Prompt: ...
+Acceptance: ...
+
+## D2: [Name]
+...
+
+Recommendation: ...
+```
+
+## Tool Adaptation
+
+- Figma or image tools: emphasize screens, layout, components, state, visual
+  direction, and acceptance criteria.
+- v0 or frontend generators: include responsive layout, component hierarchy,
+  route assumptions, stateful examples, and realistic sample data.
+- App builders: include user flows, data objects, persistence assumptions,
+  settings, and simple backend expectations.
+- Human designers: include rationale, design principles, user emotions,
+  research questions, and validation plan.
+
+## Source Parity Rule
+
+`PROTO_PROMPT_PACK.md` is a readable view. `PROTO_PROMPT_PACK.yaml` remains the
+source of truth. If the Markdown contains richer direction, screen, state,
+copy, or acceptance content than YAML, the prompt pack is incomplete.