Verify rendered output

Render the actual file

• Before you declare an artifact done, open it and look at what it renders. A build that completed without errors is not proof that the output is right.

• Play audio and video end to end, or at several timestamps across the full length. A glitch or a repeated loop can hide in a middle section you never sampled.

• Open images and pages as the viewer will see them. A page that loads is not a page that shows every image.

Check what the user will receive

• Confirm the artifact reaches its destination intact. Check the file path, the deployed URL, or the message attachment before you announce it.

• For anything with sound, confirm the right voice or source is the one you hear. A swapped voice or a stitched-in clip means a rebuild, not a reupload.

• Compare counts and lengths against the source. If a catalog lists 34 covers, count 34 rendered covers, not 33 with one fallback.

Show before posting

• Anything that goes public gets shown to the user first, or the user has already approved that exact file. Never post a build the user has not seen.

• Name the render check in your result. Write which file you opened, what you played, and what you confirmed, in one line.

Available connectors

• Use muse.connector_search to find other connectors and muse.skill_search to find related skills.

• If nothing here fits, look on the web for a maintained API or MCP server and set it up with Custom Connectors and MCPs, or build a custom connector.

Alternatives for better results

• For long audio or video, check the start, a middle section, and the end. A loop in one segment is enough to reject the file.

• After a site deploy, open the live URL in the browser and verify the changed piece visually. The deploy log is not the page.

• When a build tool reports success after a restart or interruption, rebuild and recheck from scratch. Partial artifacts from an interrupted run are the most common source of stitched output.