Three small open-source apps that exercise the Seed Hypermedia developer surface end to end: reading a site's public API, signing in with a vault-delegated key, and writing signed changes back to the network. Together they make the extensibility argument concrete — every Seed site is an open API, the @seed-hypermedia/client SDK on npm is the same client the official apps use, and a weekend-sized project needs no API key, no OAuth registration, and no backend to sit at eye level with them.
All three were built by prompting Claude Code. This document reproduces the prompts verbatim, and describes what the agent did in between. It was itself written and published by the same agent — see the last section.
1. seed-login-example — Sign in with Seed
A self-contained site demonstrating the "Sign in with Seed" flow: the browser generates a non-extractable Ed25519 session key, the user's vault authenticates them and signs a Capability delegating the AGENT role to that key, and the site then signs and encrypts content locally — the account's private key never leaves the vault. All of the integration lives in one commented file, src/seed.ts.
Built in an earlier Claude Code session (two commits on August 17, 2026, co-authored by Claude Opus 5). The prompts from that session weren't preserved, but the commit history tells the story: a first pass ("example site for Sign in with Seed") and a refactor that consolidated the integration into a single readable file and vendored the client package so the repo stands alone.
2. SeedDashboardExample — reading a site
A team analytics dashboard over Develop Seed Hypermedia: activity charts by week, a most-active-participants leaderboard, active projects & tasks, and a recent-activity feed — every widget linking back into the site. A sync step crawls the space through the SDK (Query, ListChanges, ListComments, Account) into an incremental JSON cache keyed by content-addressed document versions, so a re-sync takes seconds. A build step renders one static, self-contained HTML file.
3. SeedKanbanExample — writing signed changes
A live kanban board over the same site's Task Tracker. It combines the other two: sign in with Seed (reusing the login example's flow), then drag a card — the move publishes a real setMetadata document change, prepared by the server against the task's base version, signed in the browser by the vault-delegated session key, and verified by the server against the capability chain. The edit is indistinguishable from one made in the official apps and shows up in the document's version history.
How they were made — the actual prompts
What follows are the exact prompts from the Claude Code session of August 28, 2026 (Claude Fable 5), unedited.
The dashboard
> create a new repo here called SeedDashboardExample and you will use the seed typescript SDK https://www.npmjs.com/package/@seed-hypermedia/client to create a dashboard with core information about https://seedteamtalks.hyper.media/ ... you can store some state in sqlite or json if you need to cache. make sure the dashboard has lots of links to the site.
>
> the dashboards should show things like: most active participants on the team, linking to their profiles. also show a graph of how active the team has been, how many comments and document updates, etc.
>
> also show a section of the dashboard about recent/active projects and tasks. make the dashboards feel very lively with nice colors, graphs, visuals, etc!
>
> have fun!
From that one prompt, the agent resolved the site's hm:// identity from its HTTP headers, read the SDK's request schemas out of the open-source Seed monorepo, probed the live API, crawled 1,624 documents / 8,374 changes / 9,683 comments into an incremental cache, validated its two-series chart palette for colorblind safety in light and dark modes, rendered the dashboard, and screenshot-tested both themes with a headless browser before calling it done.
Screenshots, README, GitHub
> take screenshots, make a nice readme that shows screenshots and clearly explains how to run it, publish this to my personal gh as a new repo. in the readme, give documentation about how it works, give the narrative that shm has a super elegant extensibility story.
The kanban board
> cool! lets make ANOTHER ONE! and this time its going to do the whole "sign in with seed" thing that this repo demonstrates: https://github.com/ericvicenti/seed-login-example
>
> and now! lets make a kanban board from this data source: https://seedteamtalks.hyper.media/tasks
>
> and important! as you drag the task to a different column, it must actually save it! use the seed sdk to sign the actual changes and push those changes to the server. so the status on the kanban will be dynamic. also when I am logged in with seed, it should show my name and avatar in the right corner and allow me to log out etc.
>
> glhf!
The agent studied the login example's seed.ts, discovered that the team's task documents already carry a Status metadata field (so the board's columns are just its values), dry-ran the server's PrepareDocumentChange against a real task to prove the write path before writing any UI, found how the official web app publishes the delegated Capability blob to the site after sign-in and mirrored it, then built the board and drove a headless browser through the sign-in click to verify the vault redirect carried a valid session key and proof. The only step left to a human was the actual authentication.
This document
> so you see we have 3 examples total, right? can you create a seed doc about the examples and explain exactly how they were created (prompts and everything!)
The agent wrote this markdown, found the account key in the local desktop vault, and published it to this site with the Seed CLI — seed-cli document create — as one more demonstration that the network is scriptable from end to end.
What "building on Seed" looked like in practice
No docs portal was needed. The agent learned the API by reading the SDK's zod schemas in the open seed-hypermedia/seed monorepo and by probing the site's /api/* endpoints directly — the same typed surface the official apps use.
The network answered every question. Which accounts are active, what a task looks like, whether a write would be accepted — all discoverable from public, content-addressed data, with no keys and no rate-limit negotiation.
Verification was cheap. Content-addressed versions made cache invalidation trivial; a prepared-but-unsigned change proved the write path without publishing anything; screenshots confirmed the UIs against live data.
Identity stayed where it belongs. Nothing in any of the three repos holds a secret. Sign-in is a key delegation; authorization is a signature chain the server verifies.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime