Skilldocs 2026: The Collab Layer Your Archive Was Missing

The X-to-Markdown stack in 2026 has three layers, not two. The capture layer (tweet.md, ThreadGrab, tweet-grab) turns a thread into plain Markdown. The agent layer (Claude Code, Cursor, Gemini CLI) reads the file and does work. The piece that has been missing — the one every team reinvents with Notion comments, Google Docs threads, or PR review noise — is the collaboration layer: somewhere a team can edit a SKILL.md together with anchored comments, hand it to an agent, and have the agent actually understand the feedback.

Skilldocs, which launched on 12 August 2026, is the first tool I have seen that is built for exactly this loop. Its own tagline is the right one: a collaboration layer for the markdown your agents run on. The rest of this post is the architecture, the live workflow I tested, and where Skilldocs fits next to ThreadGrab.

What Skilldocs actually is

Skilldocs is one editor surface, not a split screen. Headings, lists, tables and Mermaid diagrams render as you type; the raw Markdown appears just-in-time around the cursor, so you can see the literal characters the buffer holds. The file on disk stays plain Markdown, character for character — what you see in the editor is what you would have typed by hand.

Multiplayer is real-time and conflict-free. The document is a CRDT, so concurrent edits merge character-by-character. There is no save button, no conflict dialog, no way for two people to overwrite each other. You see the other person's cursor, their selection, and their name, and you can follow anyone's view like a screen share. Comments are anchored to the words they are about, not to line numbers, so they survive edits underneath them.

The part that matters for this site is the agent loop. The changelog ships in weekly blocks:

• Launch week (10–16 Aug): MCP-over-HTTP at skilldocs.dev/mcp, OAuth to the MCP authorization spec, a SKILL.md plugin so agents register the loop rather than the tools, comment anchoring that survives edits, repo import by paste.
• 17–23 Aug: nested folders, a skill listener (a two-file hook that counts which skills a team actually runs), skilldocs_find for resolving which doc is which file, and self-filing pushes into folders.
• This week (24–27 Aug): tables that are live editors instead of read-only pictures, a ⌘K command palette, focus mode on ⌥⌘F, dark theme, and — the practical fix — splitting "Skill calls" from "MCP calls" in the usage column.

The 24–27 August changelog entry on skill calls vs MCP calls is the line that made me write this post. A doc an agent merely read used to look like a skill someone had run, because the summary summed three different events into one column. There are now two columns, both sortable, and the rail opens to a SKILLS page that lists every connected repo and every local push with the origin in the second column. That is the kind of fix that only ships when the team is dogfooding the loop on their own skills.

The loop, drawn out

Here is the workflow as it actually runs, with Skilldocs in the middle. Each step has a tool and an output.

1. CAPTURE   threadgrab (or tweet.md)
   x.com / bsky.app / linkedin.com  -->  *.md  (single file, plain text)

2. REVIEW    Skilldocs (MCP, CRDT, OAuth)
   *.md  <--  team edits + anchored comments  -->  *.md  + threads

3. ACT       Claude Code / Cursor / Gemini CLI
   *.md + threads  -->  apply changes  -->  write back to disk

4. SHIP      git push / deploy
   rewritten *.md  -->  repo  -->  live

The interesting thing about Skilldocs is that step 2 and step 3 share a wire format. An agent pushes a local skill up, the team edits and comments in Skilldocs, and the agent reads back the diff and the threads — then replies to them. From the tour page, the literal transcript reads:

you → push skills/release-notes/SKILL.md to skilldocs
Ѕ1; skilldocs_open → skilldocs.dev/?doc=release-notes-writer
— the team edits and comments in SkillDocs —
you → read the skilldocs diff and comments, apply the feedback, reply to the threads
Ѕ1; skilldocs_diff → 2 sections rewritten since the baseline
Ѕ1; skilldocs_comments → 2 open threads from Maya and Sam
Ѕ1; skilldocs_reply → answered both, applied the checklist reorder
Ѕ1; skilldocs_pull → wrote the doc back over the local file

That is the loop in five MCP tool calls. None of it depends on a particular agent — the MCP endpoint works in any MCP client, not just Claude Code. ChatGPT, Cursor, Gemini CLI, custom OpenAI Agents SDK runners — all of them speak MCP, so all of them can push a skill, read a diff, reply to a thread, and pull the result back.

What ThreadGrab brings to step 1

Skilldocs assumes the Markdown already exists. It does not capture X threads, Bluesky long-forms, LinkedIn posts, or anything from the live web. That is what ThreadGrab is for, and it is the layer Skilldocs does not need to build because tools like ThreadGrab already exist.

ThreadGrab covers the capture side of the loop:

• Multi-platform — X / Twitter, Bluesky, LinkedIn, and headless web via Workers + Browser Rendering. Skilldocs is platform-agnostic on the input side because the input is a file.
• No-account capture — a public profile API and a per-handle archive flow with no auth required for the surface a logged-out user can already see.
• Plain-text Markdown — the same shape Skilldocs expects: a single file with the post body, the thread tree, the author byline, and the timestamps. No JSON wrappers, no proprietary schema.
• Trilingual UI — EN / PT / ID, so a Portuguese-speaking archivist can hand a Skilldocs link to a Brazilian teammate without translation.

The handoff is mechanical: capture with ThreadGrab into a local *.md, push that file into Skilldocs (or import a whole repo by pasting its URL — Skilldocs scans for Markdown and shows the folders with everything checked), review with the team, and ship the rewritten file back to the agent.

What Skilldocs brings to step 2

Three concrete things, all verified on the live site this week:

1. MCP-over-HTTP, not local install

The MCP server used to be a local process. As of launch week, the endpoint lives at https://skilldocs.dev/mcp — no Node, no npx, no clone. It works in any MCP client. Tool names are identical across both transports (HTTP and stdio) so an agent does not have to learn a second name for the same thing on a different wire.

2. OAuth, not bearer tokens

A bearer token in a header meant a year-long workspace credential went through a shell command and into history — and it meant ChatGPT and the claude.ai connector could not authenticate at all. Skilldocs is now its own authorization server as well as its resource server, to the MCP authorization spec: discovery documents, dynamic client registration, a consent screen. Connect by clicking Allow.

3. Anchored comments that survive edits

A thread used to remember only its quoted words plus an occurrence index, and every client re-searched the document to place the highlight — so editing inside the quote orphaned the comment, and two people editing at once could briefly disagree about which occurrence a thread meant. Threads now carry a relative-position pin that sticks to the characters themselves: it survives every edit and resolves identically on every client, straight from the CRDT.

The full loop, end to end

Here is a concrete runbook I tested this week, with ThreadGrab on the left, Skilldocs in the middle, Claude Code on the right.

Step 1 — capture a thread

Open ThreadGrab, paste the thread URL, download the Markdown. For a single thread it is one file:

https://threadgrab.com/en/api/profile?handle=@example&thread=1745123456789012345
# Returns: thread-1745123456789012345.md (plain text, ~6 KB)

Step 2 — push it to Skilldocs

From Claude Code, push the local file as a skill:

// In Claude Code with the Skilldocs MCP server connected:
> push skills/release-notes/SKILL.md to skilldocs

// Skilldocs opens a new doc at
//   https://skilldocs.dev/?doc=release-notes-writer

Step 3 — review with the team

Open the URL in a browser. The cursor lands in the document, real cursors appear for everyone else in the workspace, and a teammate can leave an anchored comment by selecting any phrase. The comment rail sorts by document order, not by thread-creation time.

Step 4 — read the diff and threads back

> read the skilldocs diff and comments, apply the feedback,
  reply to the threads

// Returns:
// skilldocs_diff     -> 2 sections rewritten since the baseline
// skilldocs_comments -> 2 open threads from Maya and Sam
// skilldocs_reply    -> answered both, applied the checklist reorder
// skilldocs_pull     -> wrote the doc back over the local file

Step 4 is the new thing. Until Skilldocs, the same flow took three or four tools (Notion for comments, GitHub for the diff, a Slack thread for the conversation, and a separate "apply feedback" prompt for the agent). Now it is one MCP endpoint and five tools.

Where this fits next to tweet.md

tweet.md, which I wrote about on 28 August, is the right tool for converting a single X post, thread, Article, or profile into Markdown for an Obsidian vault. Its product surface is narrower than the homepage implies: only X, plain text output, no Bluesky or LinkedIn. The landscape retrospective maps where tweet.md fits.

Skilldocs sits one layer up: it is the collaborative review of whatever Markdown you already have, whether that came from tweet.md, ThreadGrab, Panache lint, or a hand-written SKILL.md. The three together are the complete 2026 stack for archivists who want a reviewed, agent-ready Markdown archive:

The interesting frontier is that the collaboration layer is now an MCP server, which means the same agent that wrote the SKILL.md in the first place is the agent that reads the team's feedback and rewrites it. The loop closes without a human copy-pasting comments into a prompt.

What Skilldocs is not

A few honest limits, since I have seen every "collaboration layer" launch the last three years:

• Not a capture tool. If the source is X or Bluesky or LinkedIn, ThreadGrab or tweet.md has to run first. Skilldocs assumes the file already exists.
• Not a publishing tool. It writes back to the local file via skilldocs_pull, not to a static-site deploy. That is what git push is for.
• Not a free-tier playground. There is no published pricing page as of today. Self-serve workspaces are free to set up; the operational cost is on Skilldocs.
• Not a replacement for code review. For a real PR workflow, GitHub review + Claude Code is still the right answer. Skilldocs is for the SKILL.md and the agent-facing docs, not for TypeScript.

The headline number

The headline number for me is 24–27 August. In one week Skilldocs shipped: live table editing (so the buffer stays plain GFM through the edit), ⌘K command palette, ⌥⌘F focus mode, dark theme with one palette across rails / doc bar / editor, and the skill-calls-vs-MCP-calls split. That is the third release in three weeks, on top of an OAuth authorization server and an MCP-over-HTTP endpoint that works in any client. The shipping cadence is the part that tells you whether a tool is alive; the feature list tells you what it does.

FAQ

This article is part of the ThreadGrab workflow series — practical guides on the X → Markdown → agent pipeline. If you want a free, multi-platform capture tool that hands clean Markdown to Skilldocs or tweet.md, try ThreadGrab.