Agent Report

Turns findings into one calm HTML page for reading on a desktop screen, and turns decisions the user must make into a review page whose answers land in state.json for the agent to read.

The page is data-driven: you write report.json, and the renderer (fang2hou/agent-report-kit, cloned by Step 2) compiles it into a local interactive report or exports a self-contained index.html / PDF. You never write HTML, CSS, or JS for a page — content and chrome stay separated, and every page gets the same theme, fonts, and review machinery.

When to Use

• A request will produce several findings, even if nobody asked for a report. Users rarely name the format. They ask you to look into a bug, summarize recent work, explain how a subsystem works, audit dependencies, or compare approaches. Decide from the request, before you start the research: if the answer will have several causes, files, trade-offs, tables, or diagrams, plan a report from the start. Answer in the terminal only when one or two paragraphs will cover it. If a terminal answer grows past about one screen while you write it, stop and put it in a report instead.
• The user asks for a report, summary, audit, comparison, or study guide.
• A direction call needs the user. They must weigh options side by side, approve or reject a list, or comment per item. A page beats a chat question when there are three or more questions, or when each choice needs its trade-offs shown.
• A long task should show its progress in a browser tab that refreshes as the agent works.

When NOT to Use