# Share What Kiro Produced — Specs and Design Docs With a URL

Canonical: https://commareports.com/agents/share-kiro-output
Published: 2026-09-09

> Kiro writes requirements, design and task documents into .kiro/specs and nobody outside your editor reads them. Publish the spec to a link the PM and the reviewer can comment on.

# 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](/mcp) in `.kiro/settings/mcp.json` with a
[scoped token](/docs/api-tokens), then add a steering file so the rule applies
to every session in the workspace instead of being re-typed each phase:

```md
<!-- .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](/comment-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](/agents/let-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](/agents/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](/docs/sharing).
- **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 →](/mcp)**

### Related

- [Where should my agent post?](/agents/where-should-my-agent-post)
- [Share what Amazon Q produced](/agents/share-amazon-q-output) ·
  [Share what Cursor produced](/agents/share-cursor-output)
- [Give an agent feedback](/agents/give-an-agent-feedback) · [The API](/docs/api)