Inline README editing on the page (GitHub-style): show Edit logged-out, edit + commit as changelog when logged in

Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity

Closed feature request

John Lauer · 3d ago ·closed by Colby Knox

Let users edit a page's README inline, right on the wiki page, GitHub-style.

The pain (real, yesterday). I was sitting with Aditya and we wanted to fix the definitions page. We wanted to just edit it inline on the page and couldn't. So the only path was: go back to the AI, open a NEW Claude thread, and get it to start editing the page through the CLI. For a small wording fix that is absurd friction. This is a WIKI. The defining feature of a wiki is that you can edit the page you are looking at.

The ask, modeled on GitHub:

Always show an Edit button on the README/Overview, even when logged out.
If logged out, clicking Edit tells them they must log in first (and offers the login), rather than hiding the capability. Discoverability matters: people should see that editing is possible.
If logged in, Edit opens the README inline for editing right there on the page, no separate tool, no CLI, no new AI thread.
Save commits it as a changelog entry (a normal commit to the page's git repo, with a message), exactly like GitHub's "Commit changes" flow.
The page then refreshes to show the updated README.

This is precisely how GitHub lets you edit a file from the web UI: pencil icon, inline editor, commit with a message, done. Make it work like that.

Notes / how it fits what exists:

The page is already a git repo (the Files tab, repo push, commit history), so a web edit is just another commit to that repo. The plumbing is largely there; this is the missing UI on top.
Works for the README today; a natural extension is inline-editing any file in the Files tab.
For the logged-out to logged-in step, this leans on easy wiki login (see the auto-login / session work in issue #89) so the "log in to edit" path is one click, not a detour.
Custom readme.html pages are a designed artifact and probably out of scope for a naive inline editor; inline edit is for markdown READMEs (fall back to "edit the file in the Files tab" for html).

1 Reply

Colby Knox · 3h ago

Shipped to prod. Edit-on-the-page, GitHub-style, exactly the five points:

Edit button always on the Overview, even logged out (markdown READMEs; a custom readme.html stays a Files-tab edit as you noted).
Logged out -> a "you must be logged in to edit" notice with the login link, right there. Discoverable, not hidden.
Logged in + can edit -> inline editor opens on the page: a monospace textarea prefilled with the raw markdown, no CLI, no new AI thread. (Logged in but not a page manager -> a clear "you don't have write access" message rather than a silent 403.)
Save commits to the page's git repo with a commit message (default "Update README.md") through the normal /files push -- a real changelog commit, and it reindexes.
Page reloads showing the re-rendered README.

Someone who can edit can also create a README on a page that has none (the empty state offers Edit). Ctrl/Cmd+Enter commits, Esc cancels. Verified end to end in a real browser: anon sees the login notice (and the raw source is NOT shipped to anonymous loads), an author edits and commits, and the updated README renders.

This pairs with the browser-session magic link (#89, shipped): "log in to edit" is one navigate for any surface. The natural next step you flagged -- inline-editing any file in the Files tab -- is a clean follow-up on the same /files plumbing; say the word.