Turn CI Runs Into Shareable HTML Review Packets

Table of contents

1. Why CI artifacts are not a great handoff
2. The two-layer pattern: raw artifact + review packet
3. What to include in the HTML packet
4. Where BinHTML fits (API vs MCP)
5. Final thought

Why CI artifacts are not a great handoff

GitHub Actions workflow artifacts are great for one job: preserving build outputs long enough for engineers to download and debug them. GitHub documents artifacts as a way to store files after a workflow run, using upload and download actions.

The problem is that artifacts are rarely a good handoff format:

• links are tied to a run UI
• the artifact is usually a zip or a folder dump, not a reader-friendly page
• retention and access are coupled to repo permissions
• context gets lost when the link is shared outside the team

If your CI generates an HTML report (for example Playwright’s HTML reporter), the report is useful. The delivery mechanism is what breaks down.

The two-layer pattern: raw artifact + review packet

A practical workflow is to split output into two layers.

1. Keep the raw CI output as a workflow artifact.

This is for engineers. It should include the full report directory, traces, screenshots, and anything else you might need when debugging.

1. Publish a single HTML review packet to BinHTML.

This is for reviewers. It should be one page that explains what happened and points to the right follow-ups.

This is the same shape as a good PR description: it does not paste every log line, but it lets a reviewer decide quickly whether the change is safe.

If you already use BinHTML for agent-generated HTML, the same model applies to CI output: publish a managed link that is easy to open, easy to share, and easy to revoke.

What to include in the HTML packet

Keep the packet focused on fast consumption. A good CI review packet usually contains:

• a one-paragraph summary (what ran and what failed)
• a short status table (suite, duration, pass/fail)
• the failing tests list (if any), with links to logs
• a small “what to verify next” checklist
• a link to the raw workflow artifact for deep debugging

If you are using Playwright, you can mention that the test runner supports an HTML reporter, and use the packet to link to the full report artifact when someone needs screenshots, videos, or traces.

The goal is not to replace your CI tooling. It is to make the human handoff clean.

Where BinHTML fits (API vs MCP)

There are two common ways to publish a CI review packet:

• Use the API docs and publish from a workflow step that already has access to the generated HTML file.
• Use the MCP docs if you want an agent to assemble the packet (for example: summarize logs, pick key failures, generate the HTML, then publish).

If your CI produces multiple related HTML pages, consider publishing them into one project link instead of pasting multiple URLs into a comment. See Project Links for AI-Generated HTML Workflows.

For review hygiene, pair this with a compare-first habit: generate v1 and v2 packets, then use Compare before you send the updated link.

Final thought

CI already generates a lot of useful data. The unlock is packaging the result into something people will actually open. Keep raw artifacts for debugging, but publish a clean HTML review packet for the handoff.