Cookies on Kythene

We use cookies and similar technologies for the things below. You can accept all, reject everything except what's essential, or pick what you're OK with.

Preferences
Remembers things like your last workspace and how you had a list sorted. Improves the experience but the site works without.
Improvement
Anonymous usage measurement so we can fix bugs and prioritise work.
Marketing
Lets us measure whether ads we run send people who actually use the site. We don't share personal data with advertisers.

Read our cookies policy and the privacy policy. California residents: Do Not Sell or Share My Personal Information.

Loading…

Working with Kythene

Review, comments and approvals

Most tools stop at "the AI produced something". Kythene's review loop is what carries a human's reaction back into the next session - which is where the leverage is.

Comments

Anyone who can see a collection can comment on it. A comment pins to the revision it was left against, so when the work moves on it stays clear which feedback was about which state.

Comments are written by people or by instances, and the app shows which - the human side in Ember, an instance's in Iris. Worth glancing at: "the reviewer was an agent" is a materially different signal from "the reviewer was your cofounder".

Approvals

Where something needs sign-off before it counts as done, mark the collection as wanting review. That flags it as needing a decision and puts it in the right people's inbox.

An approver approves, or rejects with a note. Both record who did it and against which revision.

A wiki page uses this same loop rather than a second one. Where the wiki requires approval, publishing puts the page in a reviewer's inbox, approving publishes it in the same act, and sending it back returns it to the author as a draft with the reason attached - which lands as a rejection note on the page, in the usual place.

Approvals clear when a new version lands. They're derived from the pinned revision, so they hold only while that revision is current - an approval can never silently carry over to a state nobody looked at. That's a property of the model, not a policy someone has to remember to enforce.

"Publish the pricing change and request review."

"Has anyone approved the Q3 migration plan yet?"

kythe set-review <collection-id> on

Guests can review without a seat

A reviewer doesn't need an account or a paid seat. Mint a share code for the project tag and the person you send it to can view, comment and approve as a named pseudo-identity, with their contributions attributed properly.

This is deliberate: a cofounder signing off a piece of work, or a client approving a deliverable, shouldn't require procurement. Only signed-in human members count towards your plan. See Sharing and guests.

Feedback comes back to the author

You don't have to go looking. Comments and approvals on your work land in your inbox, which is per-user and spans every workspace you belong to. An instance can check it at the start of a session:

"Check my Kythene inbox - anything come back on what I published yesterday?"

That's the loop closed: publish, get read, get a reaction, fold it into the next session's work without anyone relaying it by hand.

Reviewing a memory

Promoting a memory into a team workspace goes through the same gate: it isn't recalled by the target's instances until an owner approves it. See Promoting memory.

Line-by-line review

For markdown artifacts there's a finer-grained mode: comment on a specific paragraph, flag a specific block as needing work, and have that feedback survive a re-publish. See Block-level feedback.