obsidian-wechat-converter: Command for Claude Code

OpenPrd Visual Compare

When UI work has a confirmed reference effect image or user-provided design, capture the implemented UI screenshot, then run openprd visual-compare . --reference <effect-image> --actual <implementation-screenshot> --locale <zh-CN|en>. Treat newly generated images as candidate references until the user confirms they match expectations, should be used for later effect-image vs implementation comparison, and should drive implementation. The command creates a side-by-side JPG under .openprd/harness/visual-reviews/ by default. Labels follow the current user language: Chinese contexts use 效果图 / 实现截图; English contexts use Reference / Implementation. Pass --locale <zh-CN|en> when the conversation language is known. When UI work has no reference image, first distinguish new UI from existing UI changes. For new screens, return to the pre-implementation three-direction visual review. For existing UI changes, capture the before screenshot first, implement the change, capture the after screenshot from the same entry, viewport, account, and data state, then run openprd visual-compare . --before <before-screenshot> --after <after-screenshot> --locale <zh-CN|en> for a before/after self-check whose labels follow the current user language. When one reference image contains multiple sub-images, grid cells, or objects, run openprd visual-prepare . --reference <effect-image> --grid <columns>x<rows> or --boxes <plan.json> first so the agent compares item by item instead of comparing the whole board blindly. When local detail matters more than the whole screen, prepare a board JSON and run openprd visual-compare . --board <board.json> --locale <zh-CN|en> to generate a focus-board with overview boxes plus numbered zoom panels. When the agent explores multiple optimization directions in parallel, use openprd visual-compare . --board <board.json> --locale <zh-CN|en> with mode=parallel-board to assemble screenshots, GIF first frames, and key metrics into one review board. When ordinary screenshots or Computer/Browser/Playwright checks are used as visual or runtime evidence, use openprd visual-compare . --board <board.json> --locale <zh-CN|en> with mode=verification-board to assemble screenshots, checked path, and checkpoints into one screenshot verification board. Board-visible text such as title, summary, labels, notes, and checks must follow the current user language. Raw screenshots are inputs, not final visual closeout evidence. When a new feature or visible change contains repeated homogeneous cards, lists, grids, or tables, or when the user reports misalignment, capture the real UI, overlay guide lines, measure both container-track spread and internal content-slot spread, and use openprd visual-compare . --board <board.json> --locale <zh-CN|en> with mode=alignment-board to assemble the screenshot, guides, and metrics into one alignment evidence board. Internal content slots include titles, subtitles, descriptions, tags, status, prices, buttons, icons, and action areas; measuring only card edges, columns, rows, or outer frames is not enough. When a single logo, icon, avatar, badge, button graphic, or image crop needs internal centering, visual-centroid review, or off-center diagnosis, crop the target if needed and use openprd visual-compare . --board <board.json> --locale <zh-CN|en> with mode=centering-board. The board must show the red canvas center, green active subject bounds, yellow visual centroid, and metadata for bounding-box center offset plus visual-centroid offset; a raw screenshot or subjective “looks centered” note is not enough. Lightweight visible UI fixes such as card width, spacing, whitespace, alignment, colors, border radius, font size, buttons, or icons still need visual evidence before claiming the UI is done; state the aesthetic intent and memory point first, then use evidence to check tone, hierarchy, color, type, spacing, surface role, and memory point. Builds, packages, dev-check, unit tests, and raw single screenshots are not substitutes. Inspect the generated image and keep iterating until there are no obvious structural or aesthetic differences before claiming completion. If the user says the implementation looks wrong, ugly, inconsistent, or asks for replication, do not claim you already compared it without producing at least one visual evidence artifact. For large UI changes before implementation, decide from user goal, information architecture change, visual decision cost, and validation risk. If an existing screen is available, capture the current in-product screen with Codex Computer Use; if this is a cold-start screen, create a design brief from the confirmed PRD, audience, first slice, visual goal, intended tone, constraints, and memory point. Generate at least three Image 2 directions from that screenshot or brief, each with a distinct aesthetic claim and anti-slop check, combine them into one horizontal numbered contact sheet as a candidate effect-image board, and ask the user whether it matches expectations, should be used for later comparison, and should drive implementation before you store the chosen reference-set under .openprd/harness/visual-reviews/.