Comma

Share what Kiro produced

Kiro's whole shape is that it writes things down before it writes code. A task turns into a requirements document, then a design document, then a task list, all under .kiro/specs — which is genuinely the right way round, and creates one problem the spec-driven flow doesn't solve.

The documents are the part other people need. The PM who asked for the feature wants to read the requirements. The reviewer wants the design. The person who will operate it wants the task breakdown. None of them are going to clone the repository and open a markdown file in a folder called .kiro.

Let Kiro publish it

Attach Comma's MCP server in .kiro/settings/mcp.json with a scoped token, then add a steering file so the rule applies to every session in the workspace instead of being re-typed each phase:

<!-- .kiro/steering/publish-specs.md -->

# Publishing specs

When a spec phase completes — requirements, design, or tasks — publish the
document to Comma as an HTML report and give me the URL.

Use one report per spec. The id is recorded at the top of the spec's
`requirements.md`; update that report on later phases rather than creating a
new one, so a single link covers the whole spec as it evolves.

Now the requirements phase ends with a link you can paste into the ticket, and the design phase updates the same link rather than producing a second one.

Why this fits spec-driven work in particular

  • A spec is read by people without a checkout. That is the entire reason to write requirements down. A URL is the format that reaches them.
  • Comments anchor to the requirement. "This acceptance criterion contradicts EARS-4 above" stays pinned to that criterion — see commenting on HTML.
  • Kiro can read the replies through the same MCP server, so the next prompt is "revise the design to address the open comments" — see letting an agent respond to comments.
  • Revisions are the review trail. Requirements → design → tasks lands as three revisions at one address, which is what someone joining the review late actually needs to see.
  • It renders. Tables of acceptance criteria stay tables. Diagrams the agent emitted as SVG or Mermaid stay diagrams.

Worth knowing

  • Both scopes matter here. reports:write to publish; add comments:write only if you want Kiro replying in threads. See scoped tokens for AI agents.
  • Keep the markdown too. Publishing is for the audience; the spec in the repo is still the artifact your agent hooks read. This replaces neither.
  • Start private. A requirements document often names customers and dates. Publish private, widen once you have read it — see sharing & access control.
  • HTML body: 5 MB. A spec will never come close.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Attach the MCP server →

Related