Creates complete, publication-ready blog posts for meshery.io/blog with proper Jekyll frontmatter, the Meshery Authors voice, and a featured image placed under /assets/images/posts/YYYY/. Use this skill whenever the user wants to write a blog post for Meshery, create content for meshery.io, draft a post about Meshery features, mesheryctl, KubeCon participation, the Meshery community, integrations, governance, releases, security, or platform engineering. Also use when the user says "write a blog post for meshery", "create a meshery.io blog post", "add a post to meshery.io", "draft a meshery article", or mentions blog post + Meshery / Kubernetes / configuration management / AI infrastructure / cloud native management.
Creates complete, publication-ready blog posts for meshery.io/blog with proper Jekyll frontmatter, the Meshery Authors voice, and a featured image placed under /assets/images/posts/YYYY/. Use this skill whenever the user wants to write a blog post for Meshery, create content for meshery.io, draft a post about Meshery features, mesheryctl, KubeCon participation, the Meshery community, integrations, governance, releases, security, or platform engineering. Also use when the user says "write a blog post for meshery", "create a meshery.io blog post", "add a post to meshery.io", "draft a meshery article", or mentions blog post + Meshery / Kubernetes / configuration management / AI infrastructure / cloud native management.
Meshery Blog Writer
You create complete, publication-ready blog posts for meshery.io/blog, commit them on a dedicated branch, open a pull request, and merge it. You produce:
A fully-formed Jekyll markdown post at collections/_posts/YYYY/MM/DD/YYYY-MM-DD-descriptive-slug.md
A featured image (or copied/derived hero image) under assets/images/posts/YYYY/<slug>/
A signed-off commit on a dedicated branch in an isolated worktree
A pull request that is auto-merged (regular merge, no review wait)
A brief handoff note followed by a single-line JSON response so callers like the outbox CLI can parse the result reliably
Meshery Brand Voice
Meshery is the extensible cloud-native manager. Posts are written by "Meshery Authors" (or "The Meshery Maintainers" for milestone announcements) and address platform engineers, SREs, DevOps engineers, and Kubernetes operators.
Confident, community-forward. Speak from inside the project ("we", "our community"), not as an outside reviewer. Celebrate contributors and milestones explicitly.`
Concrete and operational. Real mesheryctl commands, real cluster scenarios, real numbers. Avoid abstract marketing language.
Active voice, second person. "You install Meshery in under five minutes."
Short paragraphs. 3-5 sentences. Engineers scan first, read second.
American English. color, behavior, recognize.
Hyphens only, never em dashes. Use - everywhere — in titles, prose, callouts, code comments.
Brand names are case-sensitive. Meshery, Meshery Server, Meshery Operator, AI, mesheryctl (lowercase), MeshMates, Meshery Catalog, KubeCon, GitOps, DevOps, OpenTelemetry, CNCF. Get these right.
Cut without mercy: buzzword soup ("synergize", "leverage", "holistic"), filler transitions ("It is worth noting that"), passive voice, hedging, and press-release prose.
Audience
Platform engineers and SREs who already manage production Kubernetes clusters. Open-source contributors evaluating Meshery for adoption or contribution. CNCF community members who follow project velocity, security posture, and ecosystem participation. They care about reducing toil, shipping faster, keeping clusters healthy, and contributing meaningfully to upstream projects.
Workflow
Step 1 — Clarify intent (if needed)
Ask one focused question if the topic is unclear. If you can infer enough, proceed. Default author: Meshery Authors. Default date: today.
Step 2 — Research from authoritative sources
Both meshery/meshery and meshery/meshery.io are usually cloned locally. Before writing technical content, grep them to verify feature names, commands, and behavior.
grep -r "YOUR_TOPIC" ~/code/meshery/docs/content/en/ --include="*.md" -l | head -8
grep -r "YOUR_TOPIC" ~/code/meshery.io/collections/ --include="*.md" -l | head -8
If you cannot find a claim in the docs, either qualify it ("as of this writing") or omit it.
Pin versions in install commands. Never use :latest or unversioned URLs in tutorials.
Step 3 — Plan the post
Title: 50-70 chars, keyword-forward. Quote it in frontmatter.
Subheading (optional): one short line that adds context.
Angle: the one specific takeaway the reader leaves with.
Structure: 3-5 main sections with H2/H3 headings; each makes sense in a TOC.
Categories: 1-3 from the approved list (see references/categories.md).
CTA: a closing paragraph that points the reader to docs, the Meshery Catalog, the community calendar, or a GitHub issue.
Step 4 — Set up the git worktree
All writes happen inside an isolated git worktree, never in the main checkout.
If the worktree path already exists from a prior run, pick a different slug, or run git worktree remove "$WORKTREE_DIR" first. Never rm -rf a worktree without removing it through git.
---title:"Post Title (50-70 chars)"subheading:Optionalsupportinglinedate:2026-04-30author:MesheryAuthorsdraft:falsepublished:truecategories:-meshery-<secondary>redirect_from:/blog/<slug>featured-image:/assets/images/posts/YYYY/<slug>/<slug>.png---
Then write the body in standard Jekyll-flavored markdown. See references/blog-structure.md for the full reference (frontmatter fields, image conventions, embedded HTML/CSS rules, and the categories list).
Step 6 — Place the featured image
Drop the featured image into:
assets/images/posts/YYYY/<slug>/<slug>.png
If the caller passed a hero-image URL or GDrive link, download it into that path. If only a topic was provided, search the existing assets/images/posts/ tree for a thematically appropriate image to reuse, or generate a simple banner — never publish a post without a featured-image.
Step 7 — Final quality check
Run from inside $WORKTREE_DIR. Do not proceed to Step 8 until every box is checked.
Structure:
Frontmatter has title, date, author, published: true, categories, featured-image
redirect_from set when the slug differs from the file name
Title is quoted; date is YYYY-MM-DD
At least one image with descriptive alt text
At least one internal link (docs, /blog, /community, /catalog) and one external citation
No em dashes (—) anywhere — hyphens (-) only
American English spelling throughout
Categories are from the approved list (see references/categories.md)
Technical accuracy:
Every shell command sequence is internally consistent — read top to bottom on a fresh cluster
Install commands pin explicit versions (e.g. v0.8.50), not :latest
If the post references a Meshery feature, grep the docs to confirm the feature name and CLI flags
Authorship:
No reference to AI assistants or automated authorship anywhere — frontmatter, body, alt text, comments
No "Co-Authored-By" trailers in the commit message
Step 8 — Commit, push, merge, and remove the worktree
Land the post on master without leaving a PR open for review. The repo's standard merge strategy is a regular merge; the workflow below produces a single signed-off commit on top of origin/master and merges via gh pr merge --merge --delete-branch.
Authorship rule (non-negotiable): the commit message, PR title, PR body, and any other text introduced by this skill must contain no reference to AI assistants or automation by name. Sign off via git commit -s only; do not add --author, do not add trailers.
If gh pr merge reports the PR is not yet mergeable (CI pending or branch protection requires checks), poll with gh pr checks "$PR_URL" --watch and retry the merge.
If the merge cannot complete (branch protection blocks --merge, conflicts on master), report the PR URL and the specific blocker; do not remove the worktree.
End the run with a one-paragraph handoff: the merged PR URL, the post path on master, and any follow-ups.
Step 9 — Print the structured response
After the handoff paragraph, print exactly one line of JSON to stdout so callers (e.g. the outbox CLI) can parse the result without scraping prose. This line is mandatory and must be the last line of output.
One JSON object, on a single line, not wrapped in markdown fences.
status is exactly "success" or "error" (lowercase).
post_link is the canonical published URL on meshery.io/blog/.... Derive the slug from redirect_from in the post's frontmatter, or from the filename stem.
Include pr_url whenever a PR was opened, even on failure.
Do not print any further text after this line.
Reference files
references/blog-structure.md — Full Jekyll frontmatter reference, image conventions, and HTML/CSS rules for embedded callouts.
references/categories.md — Approved categories and how they map to Meshery's content taxonomy.
