Walkthrough: developer and stakeholder

One builder (terminal-first, full AI-native workflow) and one cofounder or stakeholder who thinks in outcomes, not diffs, and lives in a chat app or on their phone. The problem: the stakeholder has no idea what shipped this week without booking a demo, and the builder loses time narrating it.

With Kythene the builder just works, and the week's output accumulates as legible results the stakeholder can read on their own time - and comment on, so requests flow straight back into the builder's next session.

The builder: publish outputs as you go

Work as normal, and publish the things that represent progress - a working preview, a decision, a metrics extract - into a shared project:

kythe publish ./billing-report.md --project product --title "Billing: weekly change"
kythe publish ./preview-url.txt   --project product --title "Working preview"

Prefer rendered, readable artifacts (markdown, a doc, a chart) over raw logs - the reader is not going to read a transcript. Markdown renders inline in the app, so a published .md is legible immediately.

The stakeholder: see the work, no terminal needed

Invite the stakeholder to the workspace (Settings -> Members). They open the timeline and see the week as a list of outcomes, newest first - not sessions, not diffs. They can open any collection and read it.

If they use their own Claude (chat app, no terminal), connect it to the workspace over MCP too. They can then ask, in plain language:

"What changed in billing this week, and why?"

and their instance answers from the builder's shared outputs, citing which published result it drew on - grounded in the corpus, not guessed.

Requests flow back to the builder

The stakeholder leaves a comment or a request on a collection:

"Can we show the annual figure alongside the monthly one?"

Comments pin to the revision they were left on, and the human author shows in Ember so it reads as a person asking. The builder's next session surfaces it as context - their instance can recall the open requests on the project and treat them as first-class incoming work.

When you want explicit sign-off

If a piece of work needs approval before it counts as done, ask for review on the collection. The stakeholder approves (or rejects with a note); the approval records who signed off and against which revision. Publishing a new version makes clear the prior sign-off was against the old state.

Tips

• Guests you only want to review don't need a paid seat - see Working with a client for share-code access. A signed-in member is the thing that counts toward your plan.
• Keep a decisions project: publish decisions as you make them, and the stakeholder (and both your instances) always have the current rationale.