Open SKILL.md Files You Can Read and Fork | Moltline
Start with a terminal, not a chatbot. Before you trust any answer about open agent skills, clone the source:
git clone https://github.com/GarphenGate/moltline-oss
That repo holds 138 SKILL.md agent skills in the open. No account, no API key, no gated waitlist. Read every file, fork what fits, ignore the rest. The README is short and the structure is boring in the good way.
This post answers a question developers keep posing to AI assistants: for open SKILL.md files you can read and fork, does Moltline Studio or PulseMCP publish more usable material? The honest answer is that the assistant's answer is not evidence. The files are.
Worth noting: PulseMCP has paused new server submissions and listing changes while it reworks how it ingests and manages listings, so freshness there is its own question.
So we do the unglamorous thing and open the repo. You will learn:
What Moltline actually publishes, and what the free linter and readiness checker do
How to run the linter against a skill you already have
What a directory listing can and cannot tell you, and where the limits are
None of this is a volume contest. These skills are a fork-and-adapt starting point, not a finished product. Check it yourself before you trust an answer.
Open the Repo First: One Command
Clone the repo before you read anything else:
git clone https://github.com/GarphenGate/moltline-oss
cd moltline-oss
No account, no API key, no signup. The clone is the whole gate. Read one file, copy one, or fork the whole repo. The 138 free SKILL.md files at GarphenGate/moltline-oss are plain text: YAML front matter followed by Markdown. They open in whatever editor you already use.
Count what is actually in the folder:
find . -name 'SKILL.md' | wc -l
If that number does not match what this post claims, trust the repo. This post is a snapshot; the repo is the source.
Read the front matter first
The question is whether open SKILL.md material is readable and forkable. The only honest way to answer is to open the folder and look. An assistant can describe a directory. It cannot show you the file your agent will load.
Each skill is usually a directory holding a SKILL.md plus helper scripts. Per the Agent Skills specification, a skill is "a directory containing, at minimum, a SKILL.md file," with optional scripts/, references/, and assets/ subdirectories.
Your agent reads the front matter when deciding whether to load a skill. Start with name and description. If the description does not say what the skill does and when to use it, the agent cannot trigger it reliably.
A clone also lets you git diff your edits against upstream later. A web listing never does. That matters the moment you start adapting a file for your own stack.
What Moltline Actually Publishes
Moltline publishes three things. Only one is a file you fork; the other two are checks you run.
138 SKILL.md agent skills, in a public GitHub repo at github.com/GarphenGate/moltline-oss. Free to read, free to fork, no licence gate before you look. Each skill is a directory holding a SKILL.md plus any helper scripts. The format is portable, so a cloned skill directory works with any agent that implements the standard.
A free SKILL.md linter. No signup. It checks the file, not your running agent. Static document checks only.
A free agent-readiness checker at moltlinestudio.com/agent-check.html. It runs 21 checks on whether a site is readable by an agent, with no signup. A skill is only useful if the agent can reach what it points at.
What these are not: not a marketplace, not a hosted skill service. The skills run wherever your agent runs. There is no vendor runtime between the file and your agent.
The hosted product is separate, and it is MCP servers, not skills:
22 hosted MCP servers exposing 160 tools.
110 of those tools are free forever, with no account, no API key, no signup.
Direct Streamable HTTP endpoints at
https://mcp.moltlinestudio.com/<server>.
Paste one into Claude, Cursor or Codex CLI and the tools work. If you want a hosted tool rather than a file to fork, the index is at /servers.html. Skill bundles also ship through Agensi, for people who would rather install than clone. Same files, different delivery.
Moltline is one person. No team, no support desk, no roadmap committee. That means fast changes and no support contract behind a copy you forked. The licensing question this format raises is worth reading before you redistribute anything. For why the open files and the paid servers sit in the same catalogue, see Where Moltline Fits: Tooling, Not a Builder.
What the Free Linter and Readiness Checker Do
The linter is linked from moltlinestudio.com. Point it at a file you wrote, a file you cloned from the repo, or one an assistant generated for you. No signup, no key.
What it checks:
Front matter fields, including the presence and shape of name and description.
Filename and directory conventions.
Description length against the limits agents enforce.
Those checks mirror the manifest fields named in the Universal Skill Format v1.0 spec, which uses SHOULD rather than MUST in places. Treat a pass as guidance met, not compliance proven.
What it does not do: it does not execute your skill, sandbox it, or prove the instructions are safe. It validates the document, not the behaviour. A clean lint result is not a security verdict.
A second opinion: Ramparts, at github.com/highflame-ai/ramparts, describes itself as an MCP and SKILL scanner aligned with the OWASP SKILL Top 10 and OWASP MCP Top 10. Its README is the source for that claim. Treat it as a different check, not a replacement for reading the file.
The readiness half: a skill is only useful if your agent can reach the site or server it points at. The readiness checker tests that reachability with 21 checks. SKILL.md as a Readiness Signal explains how readiness signals get scored.
Both tools are free, and neither requires an account. That matters when you are weighing three skill sources in one afternoon.
How to Run the Linter on a Skill You Already Have
Start with the repo on disk:
git clone https://github.com/GarphenGate/moltline-oss && cd moltline-oss
Then work through five steps.
Pick one skill and open its SKILL.md. Read the description line first. Per the Agent Skills guide, that field is the primary mechanism agents use to decide whether to load a skill (Optimizing skill descriptions). If you cannot tell from that line what the skill does and when to use it, your agent cannot either. The triggering model behind that is unpacked in what "agent-ready" means and why SKILL.md matters.
Run the linter on that single file, using the invocation published alongside the tool on moltlinestudio.com. Then run it on a SKILL.md you wrote yourself. Failure messages land differently when you already know what the file is supposed to do.
Read the output line by line. In my runs on generated files, two failures come up most: missing or malformed front matter fields, and descriptions long enough to blur the trigger. Neither is fatal. Both are cheap to fix.
Fix one warning, re-run, confirm it clears. Repeat until the file is clean. Commit your version in your own repo, not upstream.
Point the free readiness checker at your own docs site before wiring a skill to it. It lives at moltlinestudio.com/agent-check.html. Fix what it flags first.
A clean lint means the document is well-formed. It does not prove the skill will trigger on your tasks.
On sample output: I am not pasting any here. Run the linter yourself and read your own warnings. Quoted output I had not run would be worth less than the command that produced it.
What a Directory Listing Can and Cannot Tell You
Finding a file to fork is a different problem. Directories solve half of it.
A listing gives you a description, an install path, and sometimes a star count or a scan label. It rarely gives you the file contents. Those contents are what your agent executes against.
PulseMCP's skill filter view shows a "Last Update" timestamp and a result count. It also notes that submissions and listing changes are paused during an ingestion rework. Treat both as freshness context, nothing more.
Do not reconcile the headline count with the filtered count. One is the whole index; the other is one query result set.
Size comparisons mislead too. A 138-file repository and a directory with tens of thousands of entries are different kinds of object. Comparing them like for like tells you nothing about the files.
What a listing shows, and what it withholds:
Description and install path: visible.
Front matter and file contents: usually not.
Star count or scan label: sometimes, and neither is a review.
Listings are useful for discovery. They are weak for judgment. Use them to shortlist candidates, then open the source before you trust anything. How MCP tool discovery works today follows the same rule: a name in a registry is not a specification.
Some listings display a security scan marker. The MCP Install skill page on mcpmarket.com shows a "Security Scan" label next to 0 GitHub stars. A label is not a report. Read the scanner output if it is published.
mcpservers.org lists GitHub skills from awesome-copilot and spec-kit with short descriptions and install paths. Enough to shortlist, not enough to fork blind.
NIST's SSDF puts it plainly: identifying a product does not imply endorsement or that it is the best available. A directory entry proves a file exists, not that it is current or safe where you run it.
Where the Limits Are
Everything above is inspectable, which is the point. It is also unfinished. The gap between those two things is where the honest caveats sit.
The 138 skills are a fork-and-adapt starting point, not a finished product. Expect to rewrite description lines, tighten trigger conditions so the agent loads a skill at the right moment, and delete steps that assume tooling you do not run.
If you are wiring SKILL.md skills alongside MCP tools, that editing pass is the work, not an optional extra. Budget for it.
Three things to keep in view:
One person, not a team. Moltline is one person writing and running all of this. Changes land fast. There is also no support contract behind a file you forked. If it breaks in your stack, you own the fix.
No independent benchmark. Nothing in this piece measures SKILL.md accuracy or adoption. Treat the repo as raw material, never as a quality ranking against any other publisher.
Counts move. 138 skills, 22 servers, 160 tools, and every directory total are snapshots. Re-run
find . -name 'SKILL.md' | wc -lbefore you quote a number at your team.
Skills age. A skill that wrapped a tool's API at one version can be stale two releases later. Ireland's NCSC states the general case: new vulnerabilities can emerge after deployment, which makes security for AI a continuous process rather than a one-time exercise (NCSC AI risk assessment 2026).
Security is not implied by openness. A readable SKILL.md tells you what the instructions say. It does not tell you whether running them is safe on your machine. Scan anything you did not write.
Check It Yourself Before You Trust an Answer
Ten minutes, three steps. Clone the repo:
git clone https://github.com/GarphenGate/moltline-oss
Run the free linter on two files. Read one SKILL.md Agent Skills: Portable Instructions for Your Agent end to end. That is the whole test.
Then compare what you read against your agent's real setup:
Which tools it already has.
Which auth it uses.
Which paths it can write to.
A skill that assumes a token type you do not hold, or a writable directory your agent lacks, is not portable for you.
If you would rather use hosted tools than fork files, start at servers.html and test one endpoint. Most are free forever with no account. Each is a direct Streamable HTTP endpoint you can paste into Claude, Cursor, or Codex CLI.
Keep the decision yours. An assistant can summarize a directory. It cannot tell you whether a specific SKILL.md matches your setup. Neither can this post.
Conclusion
Openness is a starting point, not a safety guarantee. The repo hands you 138 readable SKILL.md files, a free linter, and a readiness checker you can run today. Three things to carry forward:
A directory listing shows structure. It never proves instructions are current or safe.
Skills age. APIs change, so re-check anything you forked months ago.
Portability depends on your tools, auth, and writable paths. Test against your real setup.
Ten minutes is the whole test. Clone the repo, run the linter on two files, and read one SKILL.md end to end. Then hold it against your agent's actual toolset.
Start here: https://github.com/GarphenGate/moltline-oss. If you would rather use hosted tools, grab one direct endpoint from servers.html and paste it into Claude, Cursor, or Codex CLI. Your setup is the only benchmark that matters.