# Add optional machine-readable workflow companions for image-to-code and redesign quality gates

[optimization2026]

Add optional machine-readable workflow companions for image-to-code and redesign quality gates

Summary

Some Taste Skill workflows are already multi-stage processes, not single prompts.

The clearest examples are:

image-to-code:
  generate / collect images first
  -> analyze images deeply
  -> implement frontend
  -> verify visual fidelity

redesign:
  scan existing project
  -> diagnose weak UI patterns
  -> apply targeted upgrades
  -> verify functionality is not broken

accessibility:
  inspect visual choices
  -> check contrast / type / focus / motion
  -> revise if needed

The current SKILL.md files are great as human/model-facing instructions.

This proposal is to add optional machine-readable workflow companions for the most complex visual workflows, so the key gates can be checked more consistently.

This would not replace SKILL.md.

It would only make the workflow structure easier to validate, test, and reuse.

Motivation

Taste Skill is strongest when it prevents the agent from skipping the hard parts:

do not start with freeform coding
do not skip image generation when the task is visual
do not implement from vague taste memory
do not redesign by rewriting everything
do not sacrifice readability for aesthetic mood
do not ship without checking visual fidelity

These are workflow gates.

They are easy for an agent to rationalize around unless they are explicit.

A companion workflow file could make the gates clearer:

which stage comes first
what output each stage must produce
what must be verified before moving on
what failure modes should block completion

Possible layout

skills/image-to-code-skill/
├── SKILL.md
└── aisop/
    └── image-to-code.aisop.json

or:

skills/redesign-skill/
├── SKILL.md
└── aisop/
    └── redesign-audit.aisop.json

Example: image-to-code workflow companion

A strict AISOP V1.0.0 companion could look like this:

[
  {
    "role": "system",
    "content": {
      "protocol": "AISOP V1.0.0",
      "axiom_0": "Human_Sovereignty_and_Wellbeing",
      "id": "image_to_code_visual_workflow",
      "name": "Image To Code Visual Workflow",
      "version": "1.0.0",
      "summary": "Machine-readable companion workflow for image-first frontend generation and visual fidelity checks.",
      "description": "Ensures that visual tasks start from image references, extract a visual system before coding, implement from the extracted design, and verify visual fidelity before completion.",
      "flow_format": "mermaid",
      "loading_mode": "node",
      "tools": ["filesystem"],
      "params": {
        "brief": "string",
        "image_reference_path": "string?",
        "target_project_path": "string?"
      },
      "system_prompt": "{system_prompt}"
    }
  },
  {
    "role": "user",
    "content": {
      "instruction": "RUN aisop.main",
      "user_input": "{user_input}",
      "aisop": {
        "main": "graph TD\n    classify[Classify visual task] --> image[Generate or collect reference images]\n    image --> analyze[Analyze visual system]\n    analyze --> implement[Implement frontend]\n    implement --> verify[Verify visual fidelity]\n    verify --> end_node((End))"
      },
      "functions": {
        "classify": {
          "step1": "Determine whether the task is visual enough to require image-first workflow.",
          "output_mapping": "visual_task_classification",
          "constraints": [
            "If the task is visual, do not start with freeform coding.",
            "If the task only changes copy, data wiring, or non-visual behavior, image generation may be unnecessary."
          ]
        },
        "image": {
          "step1": "Generate or collect enough reference images to make layout, typography, spacing, color, and visual hierarchy inspectable.",
          "output_mapping": "image_references",
          "constraints": [
            "Do not rely only on vague taste memory.",
            "Do not use tiny compressed images when section-level detail is needed.",
            "Generate separate section images when one full-page image would be too small to inspect.",
            "Image references are the design source for this workflow."
          ]
        },
        "analyze": {
          "step1": "Extract layout, typography, spacing, color, surface treatment, visual hierarchy, motion intent, and component patterns from image_references.",
          "output_mapping": "visual_analysis",
          "constraints": [
            "Do not implement before visual analysis exists.",
            "Do not replace concrete visual observations with generic design adjectives.",
            "Extract reusable design decisions, not only surface description."
          ]
        },
        "implement": {
          "step1": "Implement the frontend using visual_analysis as the design source.",
          "output_mapping": "implementation_result",
          "constraints": [
            "The image is the design source; code is the translation layer.",
            "Do not introduce unrelated template patterns that are absent from the visual analysis.",
            "Do not default to generic hero/card/grid patterns unless the visual source supports them."
          ]
        },
        "verify": {
          "step1": "Compare implementation_result against image_references and visual_analysis.",
          "step2": "Report mismatches in layout, spacing, typography, color, hierarchy, responsiveness, and accessibility.",
          "step3": "sys.assert('visual fidelity report exists', 'Visual fidelity verification is required')",
          "output_mapping": "visual_fidelity_report",
          "constraints": [
            "Do not call the implementation complete without a visual fidelity pass.",
            "Accessibility failures should block final approval.",
            "The final output should explain what changed from the visual source and why."
          ]
        },
        "end_node": {
          "step1": "Return implementation_result and visual_fidelity_report."
        }
      }
    }
  }
]

Why this helps

A companion workflow could help with:

1. preventing skipped image generation;
2. preserving the image-first pipeline;
3. making visual analysis an explicit stage;
4. adding an accessibility / readability gate;
5. creating tests for workflow structure;
6. keeping SKILL.md readable while exposing machine-checkable gates.

Non-goals

This should not:

1. replace SKILL.md;
2. require every skill to have a workflow companion;
3. make skill authoring harder;
4. force one protocol on the repo;
5. turn the creative process into a rigid framework.

The first experiment could be limited to one complex workflow:

skills/image-to-code-skill/

If it helps, the same pattern could later apply to:

skills/redesign-skill/
skills/accessibility-skill/
skills/brandkit/

The value is not the file format itself.

The value is making the important visual quality gates explicit enough that agents cannot silently skip them.