HTML Report

Turns findings into one calm, readable HTML page, and turns direction calls the user must make into a page whose answers land in state.json for the agent to read.

When to Use

• The user asks for a report, or implies one. Investigation or audit results, study material, a project or work summary, a comparison, or a plan meant to be read rather than applied. A request implies a report when the answer has several findings, sections, or sources and would run past about one screen of chat: "find out why the build got slow" ending in three causes, "sum up what we shipped this month", "teach me how this module works".
• A complex direction call needs the human. The agent cannot proceed until the user picks among options whose trade-offs must be shown side by side, approves or rejects a list, triages items, or comments 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 page that refreshes as the agent works.

When NOT to Use

• Short answers, or one question with obvious options: reply in chat or use the harness's question tool.
• Code, config, commands, or diffs the user will apply: put them in chat or in the files.
• Documents that live in git and get diffed (README, ADR, CHANGELOG): write Markdown, unless the user explicitly asks for an HTML page under docs/.
• Product UI, websites, or slide decks: those are frontend work with their own design system.

Hard Rules