Attach show-me visualizations of the spec and plan to planning output

[rochecompaan]

Summary

Include output from the show-me skill in Patchmill's planning output so the
spec and plan get attached to the issue in a visual form. This helps
reviewers understand the spec and plan faster than reading prose alone.

Skill reference:
https://github.com/humanlayer/skills/tree/main/plugins/show-me/skills/show-me

Motivation

Reviewers must build a mental model of the spec and plan before they can
judge it. Diagrams, trees, and focused visuals give them that model directly
and shorten the review loop.

Proposal

• During planning, run the show-me skill over the spec and plan to produce
  visual summaries (Mermaid diagrams, file or component trees, diffs, or a
  focused HTML artifact).
• Attach the result to the GitHub issue alongside the spec and plan.

Explore: how to attach the output

GitHub issue bodies render Markdown but not raw HTML, so the attachment
mechanism needs a decision. Options to evaluate:

• Inline Mermaid in a comment or the issue body. GitHub renders Mermaid
  natively; no artifacts to host. Covers diagrams but not HTML artifacts.
• Rendered images (PNG/SVG screenshots of diagrams or the HTML artifact)
  uploaded as issue assets. Visible inline; loses interactivity.
• HTML file upload as an issue attachment. Preserves the artifact but
  reviewers must download and open it locally; GitHub serves uploads as
  downloads, not rendered pages.
• Gist or external host for the HTML, linked from the issue. Renders in
  the browser but adds an external dependency and permissions surface.
• Committed artifact in the repo (for example under docs/), linked from
  the issue. Reviewable in the PR; less immediate for issue-only reviewers.

The issue should pick a primary mechanism (and a fallback) based on what
reviewers actually need to see.

Acceptance criteria

• Planning output includes a show-me visualization of the spec and plan.
• The visualization is attached to the issue through a chosen mechanism that
  works for HTML artifacts, with the trade-offs of the alternatives recorded.
• Reviewers can view the visualization without local tooling.

[rochecompaan]

This was generated by AI during triage.

Triage Notes

Classified as blocked.

Blocked by: #180

This is clear, agent-suitable work, but #180 is deciding whether specs and plans remain issue-published artifacts or move to a pull-request workflow. That decision determines the durable review surface and therefore the primary and fallback mechanism for publishing HTML-capable show-me visualizations. Implementing the attachment path first risks targeting a workflow that #180 replaces.

Once #180 records the planning-artifact publishing decision, this issue can return to agent-ready. Planning should then choose a visualization mechanism that reviewers can open without local tooling, record the alternatives' trade-offs, and cover visualization generation and publication failure paths.