WorkBuddy tries to port design-to-code workflow for UI assets, but fields get messed up

At 3 AM, while revising a planning document, I came across an article about stitch-skills, saying that design-to-code workflows now rely on Agent Skills to link prompts, design drafts, and code together. My first reaction was whether WorkBuddy could provide me with a similar set of tools for daily tasks. I've been using WorkBuddy for about a month now; scheduled tasks and document organization can already handle some repetitive processes stably. But this time, I wanted to merge UI configurations exported from Unity, component names from Feishu spreadsheets I've been testing, and button states from the planning doc into a traceable checklist. Unfortunately, the semantic meaning of the fields still wasn't locked down.

Today, I tried following this approach. First, I created a checkpoint where WorkBuddy reads asset rows from Feishu docs and syncs them to Feishu spreadsheets. It ran through in about ten minutes. The issue wasn't layout, but semantic drift in fields: asset_type was often empty, status was sometimes stuffed with JSON fragments, and other times it reported missing fields. Initially, I suspected permission issues or misconfigured data source paths, but later realized I probably wrote instructions too vaguely like "help me organize UI assets," rather than defining schema constraints like in a code repository. After breaking the task down smaller, reading only one tab at a time, the output became more stable, but notes were still missing, indicating it hasn't treated "traceability" as a hard constraint yet.

Reflecting on it now, WorkBuddy does single-document aggregation well, acting like SSR assistance. But once you need cross-document, cross-spreadsheet, and cross-tool operations, field contracts must be defined upfront. The key to linking design-to-code is having clear input/output types at every step. UI assets are the same: component names, button states, Unity export paths, and planning doc notes cannot rely on ad-hoc natural language agreements.

Next, I plan to treat the checklist as a small data model. First, define a field table, specify enums or formats for each field, then break the checkpoints into three stages: extraction, validation, and backfilling. I won't expect a finished product from a single sync. I've just started using Feishu spreadsheets less than a week ago; templates are still being adjusted, and I'm preparing to hardcode the field rules first.