Jinja2 vs Claude vs SkillSpec in 2026: same skill, 3 ways

A developer built SkillSpec Converter, a free browser-based tool that converts a single YAML skill definition into multiple output formats for OpenClaw, Claude, Codex, and MCP. The developer found that while a Jinja2 script was faster for a single format and Claude was fine for one-offs, the converter excelled when multiple formats were needed simultaneously. Claude quietly dropped required fields and produced casing errors in the MCP manifest.

SkillSpec Converter wins for anything I need in more than two output formats at once. The Jinja2 script is still faster for a single format I fully control, and asking Claude directly is fine for a one-off, though it quietly drops required fields. I timed the same skill through all three last week. Below are the actual outputs and the exact spot each one broke. The SkillSpec Converter I link to below is one I built. I got tired of hand-porting the same skill across OpenClaw, Claude, Codex, and MCP, and the four converters I tried each handled one target well and mangled the rest. It's free, runs entirely in your browser, needs no signup, and uploads nothing. If you know a better one, tell me and I'll switch to it happily. Last Tuesday I had a skill that worked in exactly one place and needed to run in four by the end of the week. The canonical definition is small. It's a PR summarizer that takes a pull request URL and returns five bullet points, gated behind a single read-only GitHub tool. That's the whole spec, and I keep it as one YAML file that acts as my source of truth. The four targets were OpenClaw's SKILL.md , a Claude system block, a Codex scaffold, and an MCP manifest snippet. My expected output was four files that all agree: same inputs, same tool allowlist, and the required: true on pr url , because a summarizer with no URL is just an apology generator. The test was drift. If any of the four copies disagreed with the YAML, I'd call the run a failure, because that's the bug you don't catch until it breaks in production three weeks later. I reached for the script first because it already existed. It's roughly 60 lines of Python that loads the YAML spec and renders one target through a Jinja2 template. Here's the trimmed version that produces the OpenClaw SKILL.md , and you can run it as-is after pip install pyyaml jinja2 : python pip install pyyaml jinja2 import yaml from jinja2 import Template CANONICAL = """ name: pr-summarizer description: Summarize a GitHub pull request into five bullet points inputs: - name: pr url type: string required: true - name: max bullets type: integer required: true - name: tone type: string required: true tools: - github read """ SKILL MD = Template """--- name: {{ name }} description: "{{ description }}" allowed-tools: {{ tools | join ", " }} --- {{ name }} {{ description }} Inputs {% for i in inputs -%} - {{ i.name }} {{ i.type }} {% if i.required %}, required{% endif %} {% endfor %}""" spec = yaml.safe load CANONICAL print SKILL MD.render spec It works, and the output was correct on the first pass. I trust it more than anything else here because I wrote every line of the template, so when something looks wrong I know where to look. The catch is the other three targets. Each one needs its own template, and the Codex scaffold and the MCP manifest have structural quirks that don't fall out of a flat YAML file cleanly. Building and debugging all four templates took me 43 minutes. I burned a chunk of that on a bug at line 41, where a tool with no parameters rendered an empty properties: {} block that the MCP validator flat-out rejected. Great for a format I'll render a hundred times. Rough for something I need once. Next I pasted the same YAML into a chat and asked for all four formats in one go. Six minutes, four clean-looking code blocks, done. Or so I thought. Two of the three inputs came back without their required flag. I don't fully know why. The description text came through fine and the tool allowlist was right, but the one boolean I actually cared about just wasn't there. I ran it twice more with a stricter prompt. It behaved once, then dropped the flag again on the third try. The MCP manifest it produced used input schema where the spec wants inputSchema , which is the kind of casing slip that reads fine to a human and dies in a parser. If I were shipping a throwaway skill I'd have taken it and moved on. For four files that have to stay in lockstep, I couldn't trust the output without diffing every field against the YAML by hand, and at that point six minutes isn't really six minutes. Then I ran it through my own tool, which is the honest reason this comparison exists. I pasted the same canonical YAML into the box, and it rendered all four targets into tabs in under a second. The required flags survived intact. The MCP manifest came out with the camelCase key. The Codex scaffold handled the empty-properties case, which is the precise bug I'd hit by hand at line 41 an hour earlier. I want to be fair about the limits. It only knows the four targets I taught it, so the moment you need a fifth output format you're back to a template or a model. There's no clever inference happening under the hood. But for the narrow job of keeping one skill definition consistent across OpenClaw, Claude, Codex, and MCP, it did in one paste what my script did in 43 minutes and what the chat couldn't do reliably at all. Here's how the three landed on the things I actually measured: | Criterion | Jinja2 script | Ask Claude | SkillSpec Converter | |---|---|---|---| | Time to get all four formats | 43 min | 6 min | under 1 min | | Required fields kept | all | 1 of 3 | all | | Valid MCP manifest out of the box | after a fix | no | yes | | Setup cost | high, four templates | none | none | | Customization ceiling | total | prompt-dependent | the four built-in targets | | Cost | free | API tokens | free | So which one do I reach for? It depends on the day, and I'll give you my honest split instead of pretending one tool won outright. If I need exactly one format and I'll be generating it over and over, the Jinja2 script takes it. Full control, and I can version the template right next to the code it belongs to. If I need a rough draft and I'm going to read every line anyway, asking Claude is the quickest way to a starting point, as long as I treat its output as a draft and diff it against the spec. For the case that actually stung one skill, four formats, zero drift allowed , I keep the SkillSpec Converter https://aidevhub.io/skill-spec-converter/ open in a tab. It's free, and it runs client-side. It also stopped me from shipping a manifest with the wrong casing twice this month. I'm biased here, plainly. I built it after the four alternatives I tried each nailed one target and butchered the rest. If yours does this better, I want to know. Q: Does converting a skill lose information between formats? A: It can. The formats don't have identical feature sets, so a field in one target may have no home in another. A good converter maps what it can and leaves a comment where a target can't represent something, which beats silently dropping it and finding out in prod. Q: Can I use the Jinja2 approach for MCP manifests too? A: Yes, and you should if MCP is your only target. Write one template, test it against the manifest validator, and you're set for good. The pain only shows up once you're maintaining three or four templates in parallel and they start disagreeing with each other. Q: Why did Claude drop the required flags? A: I don't have a clean answer. My guess is that boolean flags on nested objects are easy to lose across a long generation, especially when the surrounding prose is more salient to the model. A stricter prompt helped but didn't fix it every single time. Q: Which format is hardest to get right by hand? A: The MCP manifest, easily. The nesting runs deep and the key casing is unforgiving. An empty properties object trips the validator, which is the same trap I fell into at line 41. It's the one target where I stopped trusting my own templates first. Q: Is my skill definition uploaded anywhere? A: Not with SkillSpec Converter, since it runs in the browser and the spec never leaves your machine. For the Claude route, your spec does go to the API, which matters if the skill contains anything you'd rather keep off a server. Written with AI assistance and human review. Try the tool at aidevhub.io/skill-spec-converter.