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

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.

The task: one skill, four target formats

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.

Round 1: the Jinja2 script I already had

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:

# 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.

Round 2: just asking Claude to convert it

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.

Round 3: SkillSpec Converter

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.

The scores, and which one I keep open

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 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.

FAQ

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.