Launched this week
Skilldocs
Figma for markdown
137 followers
Figma for markdown
137 followers
Open a skill, and everyone is in it at once - real cursors, inline comments, and an editor that renders as you type. Then hand the whole conversation + diff back to the agent.
Product Hunt
Collaborating on .md files is a pain - we paste them into Notion, or open them locally and screenshare. Then after we edit and comment on them, there's no easy way to get the feedback back into the coding agents. So...I built Skilldocs.
I picked the best features of some of my favorite products: @HackMD 's mono viewer, @Figma 's live cursors + follow (no screenshare necessary), Google Docs' real-time highlighting and comments, and @Bear 's beautiful wysiwyg markdown editor. After working on the doc together, leaving comments, and editing it, you can easily copy the diff and comments and send them to your coding agent of choice.
I've started using it for collaborative docs in general. It's really fun having a meeting in it.
Minor features I love:
-Click on a teammates avatar to follow them through a doc or even through switching docs. It's like following in Figma - it feels like screenshare but snappier.
-You can cmd+click to create multiple carets and edit several lines at once (after @Sublime ).
Right now you can import skills via dropping a .md file, pasting markdown, importing from Github, or from your local machine via an MCP. Export is simple: copy the .md of the current doc, diff, or comments. I haven't built proper team source control yet but I've gotten a few requests - I'd love requests and suggestions here.
h/t to @mikekerzhner for early ideation, and @bernatfortet @teamcoscreen @heshamghandour for early testing!
Daily.co
This is awesome! I have the wrong mental model for the MCP server install, though, and could use some help. I clicked on the "Claude Code can work in here" and am following the instructions. To install the MCP server using this command, do I need to check out a local copy of skilldocs source code? (Very sorry if this is obvious in docs that I should have seen.)
```
claude mcp add skilldocs -e SKILLDOCS_TOKEN=<paste-token> -- node <path-to-skilldocs-repo>/mcp/index.js
```
Product Hunt
@kwindla sorry yeah that’s confusing. Let me get back to you with a better way.
YourSitee
Skilldocs solves a surprisingly awkward collaboration gap! How are you thinking about source control once multiple people and agents are editing the same skill? Will comments and diffs eventually map cleanly back to Git branches/PRs?
Product Hunt
@andrasczeizel how would you want it to work?
YourSitee
@rajiv_ayyangar I'd probably want each skill to stay linked to its github source, then after a collaborative session Skilldocs could turn the edits into a clean commit/pr while preserving comments as review context. Ideally I could see exactly what changed, approve what gets written back, and let my coding agent pick up the pr + discussion from there without manually copying anything :)
Product Hunt
@andrasczeizel so a “Save version and generate PR” button? then it programmatically creates a PR?
YourSitee
@rajiv_ayyangar yes!
on the source control question - since everyone's already live in the same doc like Figma, I'm not sure you actually want git branches, branching is for when people edit in isolation and need to reconcile later, which is the opposite of what you've built. what I'd actually want is lighter: the ability to name/tag a version before I hand the diff to my coding agent, so if the agent runs with a bad version of the skill I can point back to "the one from tuesday's meeting" instead of reconstructing it from memory. real branching only starts to matter once two agents are independently proposing edits to the same skill without a live human session tying them together, which sounds like a later problem, not a v1 one.
Product Hunt
@galdayan I love that story of just telling the agent which version to reference. Maybe one approach is to make really lightweight versioning in a way that's usable by, and apparent to, coding agents. In other words, having the version history and branching history in agents' context when it matters.
@rajiv_ayyangar "when it matters" is the whole design problem though - if it's always in context that's just noise for the agent to wade through, and if it's opt-in the agent has to know to ask for something it doesn't know exists. the trigger that'd actually work is probably conflict detection: the agent only needs version/branch history the moment its proposed diff touches a section that changed since its last read. everything before that point it can safely ignore. that's a much smaller thing to build than full context-awareness.
Product Hunt
@galdayan I'm not quite following your thinking here. Maybe a simpler question is: would you want to blindly subscribe to updates that anybody on your team makes to a skill?
@rajiv_ayyangar sorry, poor phrasing on my part - not a subscription/feed thing at all, the opposite actually. more like a stale-write check: right before the agent commits its diff, compare what it read when it started against what's actually there now, but only for the lines it's touching. if nothing moved, nothing changes, zero extra context. if something did move, that's the one moment worth surfacing what changed before the agent overwrites it. so no always-on feed of teammates' edits, just a single check at write-time scoped to the overlap.