Share what Cline produced
Cline is at its best on the long jobs: read the whole service, work out what the retry logic actually does under load, write it down. What you get back is the kind of document you would want three other people to read.
It is in a VS Code side panel. Approving each step gave you a good view of the work and a terrible artifact — a conversation, not a page.
Attach the server and write the rule
Cline takes remote MCP servers with headers, so Comma is a URL and a token — same block as VS Code setup, with the token from API tokens.
Then put the standing instruction in .clinerules so it survives across tasks:
When a task produces a document rather than a code change, publish it to Comma
as an HTML report and reply with the URL. Do not write it into the chat and do
not leave it as an untracked file. Reuse the id in `.cline/comma-report-id`.
Because Cline asks before it acts, you will see the publish call in the approval flow — which is the right amount of visibility for the one step that makes the work leave your machine.
Why a page rather than a file in the workspace
Cline writing report.html into the repo feels like sharing and is not. The
file has no URL, no access control, no comment thread, and it either pollutes a
diff or gets gitignored and lost.
- A published report has an address you can paste into the thread where the question was asked.
- It renders in a sandboxed iframe, so the tables and charts survive.
- Comments anchor to the paragraph they are about — see commenting on HTML.
- Revisions stack. The next run updates the same URL; last week's version is still there.
Worth knowing
- Approve the narrow token.
reports:writeis the whole requirement — see scoped tokens. - 5 MB per report body.
- A report never re-executes. For something that refreshes on a schedule, see routines.
Try it
Free — unlimited reports, commenters and revisions.