If your site builds from Markdown files in a repository, the cleanest place for an AI-written article is the same folder your other posts live in. Cituna commits `your-base-folder/slug.md` with YAML frontmatter, your existing build turns it into a page, and the article goes through whatever review your repo already has: a pull request, a preview deploy, a branch protection rule. Nothing new is introduced into your pipeline. This is the destination for Astro, Hugo, Jekyll, Eleventy, and for Next.js sites that read posts from a content directory. It is emphatically not the destination for a site that serves articles from a database, and the next section explains why that failure is silent.
What this assumes
1. Check where your posts actually live
Open any existing post in the repo and note its path. If your posts live at `src/content/blog/hello.md`, your base folder is `src/content/blog`. Get this from a real file rather than from memory: a plausible-but-wrong folder is the difference between a page and a file nobody reads.
Also check what frontmatter your build requires. Cituna writes title, description, date, slug and tags; if your theme demands a field none of those cover, add a default in your build config before connecting.
2. Create a fine-grained personal access token
On GitHub, go to Settings → Developer settings → Personal access tokens → Fine-grained tokens. Scope the token to the single repository you want, and give it Contents: Read and write. That is the only permission needed.
Classic tokens are refused. A classic token can reach every repository you own, and no publishing integration needs that.
3. Connect the repo in Cituna
Open Integrations → GitHub and paste the token and the repository as owner/name. Set the branch your site builds from, usually main, and the base folder you found in step one.
Publishing credentials are per brand, so switch to the right brand first if your workspace tracks more than one.
4. Let the write test prove the path
Cituna commits a test file and then deletes it, so you know the token, the branch and the folder are all correct before a single article is written. A path that collides with an existing folder is reported as a conflict rather than guessed at.
If the test fails, the message names which of the three is wrong.
5. Turn on the daily article
Open AutoSEO, choose GitHub under "Deliver articles to", and switch on Daily article. GitHub delivery has no draft-or-publish switch, and the interface says so: your own build decides when a committed file goes live.
If you want review before publication, use a branch your site does not build from, and merge when you are happy.
Troubleshooting
Cituna says committed but nothing appears on my site.
Two causes. Either your site does not build from files at all, in which case switch to the webhook destination, or the base folder is not the one your build reads. Open the commit on GitHub and compare its path against an existing post that does render.
What happens if I edit an article after it was committed?
Editing in Cituna and pressing Update on GitHub commits over the same file. The slug is fixed at the first commit and never re-derived from an edited title, precisely so a retitled article updates its file instead of orphaning it and committing a second one.
My token was rejected even though I just made it.
Fine-grained tokens on an organisation repository often need an admin to approve them before they work, and they carry an expiry date that is easy to set to seven days by accident. Check both on the token page.
Can Cituna open a pull request instead of committing directly?
Not today; it commits to the branch you configure. The equivalent is to point Cituna at a branch your site does not build from and open the PR yourself, which keeps your existing review process in charge.