Skip to content

Is your blog Lyra-ready?

Lyra writes into a git-based blog. She commits a Markdown file to a branch and opens a pull request, the same way a human contributor would. So before you connect, your blog needs to be a folder of Markdown files with frontmatter, in a GitHub repository. If it is, you are ready to connect your repository. If it is not, this page shows you what to change first.

The readiness checklist

Your blog is ready for Lyra when all four of these are true:

  1. Your posts are Markdown files. Each post is a .md or .mdx file, not a row in a hosted CMS.
  2. Each post has frontmatter. A block at the top of each file holds the title, description, date, and other fields. See Blog frontmatter.
  3. The blog lives in a GitHub repository. Your posts are versioned in a repo you can install a GitHub App on.
  4. A static site generator builds it. Something like Next.js, Astro, Hugo, or Jekyll turns your Markdown into your live site. A merged pull request is what publishes a post.

If all four are true, skip ahead to Connect your repository.

Why Lyra needs a git-based blog

Lyra's whole model is the pull request. She reads your repo to learn your structure and voice, writes a new post as a Markdown file that matches your existing posts, fact-checks it, and opens a PR you merge. That only works when your posts are files in a repo, because the diff is the review surface and the merge is the publish event.

This is also why nothing auto-publishes. Your live site is built from your default branch by your own pipeline, so a draft on a branch cannot reach production until you merge it.

What Lyra needs from the repo

When your blog is code, Lyra expects five things, and she learns most of them by scoping your repo:

  • Markdown with your frontmatter. She writes a .md file shaped like the ones already there: the same frontmatter keys, the same date format, the same slug rule.
  • Work on a branch, never your live site. She commits to a feature branch through a GitHub App, and stops there.
  • A pull request you review as a diff. You see the exact file added, the body, and the frontmatter, rendered like any other change.
  • Your CI checks respected. Because the post arrives as a real PR, your existing build, linter, and link checks run against it.
  • No lock-in. Posts are plain files you own, and Lyra runs on your own Anthropic key. See Add your Claude key.

If your blog is not ready

If your blog lives in a hosted CMS with no repo behind it, Lyra cannot write to it yet. The common cases:

Who a git-based blog is not for

A git-based workflow assumes someone reviews the diff and merges it. If your blog lives in a hosted CMS with no repo and no review step, and you want to keep it that way, Lyra is not the right fit. Her value is the review gate, so she assumes a person who reads the pull request before it ships.

What's next