Capture visible states
Record pages at several widths, visible text, layout measurements and open controls to specify what the new project needs to do.
Craft Anything collects evidence from software you are allowed to study, passes a brief to a coding agent, and compares the new implementation against the reference.
Bring authorized screenshots and a short description of the interaction. Use Craft Anything’s evidence and comparison model to turn what you observed into checks the builder can run.
Name the page, supported viewport widths, and key states such as an open menu or error.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatPreview and copy the request. It is not sent automatically from this page.
Reference: Craft Anything https://github.com/storytold/craft-anything Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Study Craft Anything’s clean-room and comparison workflow. Use my desktop, tablet and phone screenshots of our pricing page to write a replacement brief. List observable behavior, specify our own assets, and create checks for the open menu and monthly/yearly toggle. Separate assumptions from evidence. Expected deliverable: A responsive prototype brief with an evidence list, asset boundaries, and a state-by-state test matrix.
A screenshot captures one moment. It leaves out mobile layouts, open menus and the behavior that makes a prototype useful. Craft Anything is an early-alpha Rust project that records observations and puts them alongside a new implementation and its comparison results. The desktop app, CLI and MCP interface expose the same underlying engine.
The default clean-room mode studies visible behavior, such as text, screenshots, spacing and menu states. Deep mode can inspect internals such as files or code when you are authorized to examine them. The mode does not isolate the operating system, and a coding agent still acts with its own permissions.
The useful pattern for a Floatboat workflow is to turn observable evidence into a brief and a set of acceptance checks. Choose assets and interactions you have permission to reuse, keep references separate from generated files, and record differences you want to fix or keep.
The project folder separates the capture, new implementation, and comparison results. Those artifacts make it possible to revisit one mismatch without reopening every design choice.
Record pages at several widths, visible text, layout measurements and open controls to specify what the new project needs to do.
Give an installed coding agent a brief and target stack. Upstream documents Claude Code as the first supported builder.
Review viewport checks and remaining mismatches against the source evidence, then decide which differences need another pass.
Choose a target you can examine and a small set of behaviors worth reproducing. The handoff should identify what was observed, where the brief leaves room for judgment, and how to evaluate the result.
Capture the current layout at desktop, tablet and phone widths, including a collapsed navigation state. Ask the builder to use your own copy and assets, then check overflow, element order and menu behavior at all three widths.
Work from a permitted copy and record how the window changes after an import, an empty file or a failed action. Turn the observations into acceptance cases for a replacement and list any behavior you could not reproduce.
Choose a mechanic you may study, such as a movement or scoring loop, and describe it using your own art and level design. Treat a runnable demo and a repeatable gameplay check as the handoff, with unresolved differences listed separately.
After reviewing a comparison, approve the intentional differences in writing and turn the rest into small fix requests. Rerun the affected checks so later reviewers can tell a deliberate redesign from an unresolved mismatch.
Start with a target you are authorized to inspect and a separate project folder. Confirm your platform’s release and your coding agent before committing to a larger rebuild.
Define what can be captured and what assets, copy or branding require separate permission.
Check the supported backend in the upstream status notes. Claude Code uses its own local installation and sign-in.
Pick representative screens or states and write down how you will compare them. Early-alpha support varies by target and tool.
Compare the workflows, operating requirements, and source licenses of these projects.