Why I stopped hand-assembling content

I got tired of copy pasting my way through content.

Idea in Notion. Outline in Docs. Draft in ChatGPT. Formatting in Ghost. Images in Figma. Every post felt like a manual QA job instead of building something once and letting it run.

So I pushed the whole thing into Make.com.

Now a single row in Google Sheets turns into a drafted or published Ghost post. Titles, meta fields, tags, even a first-pass excerpt. All wired together with OpenAI in the middle.

This is the exact blueprint. Not theory. This is the scenario that runs my real content pipeline.

The high-level architecture

The stack is simple on purpose:

• Google Sheets as the content control panel.
• Make.com to orchestrate everything.
• OpenAI to generate and clean up text.
• Ghost (self-hosted) as the CMS.

One sheet row = one post. Status and flags in that row decide if Make should ignore it, draft it, or publish it.

I keep the Make scenario focused. One job. Turn structured data in Sheets into structured content in Ghost.

The Google Sheet schema

Here is the actual column setup from my sheet. No fluff.

• A: id – internal ID, just an incrementing number.
• B: status – idea, ready, generated, published.
• C: title – human-written title seed.
• D: slug – usually auto-generated in Make if empty.
• E: brief – 2–4 bullet outline or a short paragraph.
• F: target_keywords – comma separated SEO terms.
• G: tone – e.g. direct, informal, first-person.
• H: word_count_goal – rough length like 1200.
• I: tags – comma separated Ghost tags.
• J: generated_html – where I store the body HTML from OpenAI.
• K: meta_title
• L: meta_description
• M: excerpt
• N: publish_flag – draft or publish.
• O: ghost_post_id – for updates.

I do not trust LLMs to guess intent. So I give them a tight brief and flags.

The Make.com scenario: the main flow

I run a single Make scenario that does all of this:

• Polls Google Sheets for new ready rows.
• Generates content and meta fields via OpenAI.
• Writes the generated content back into the sheet.
• Creates or updates a Ghost post.
• Updates status and IDs.

I will walk through every module and what it actually does. No hand waving.

Module 1: Google Sheets “Search Rows”

Trigger: I run this scenario on a schedule. Every 15 minutes works for my pace.

First module is a Google Sheets > Search Rows module.

• Spreadsheet: my Content Pipeline sheet.
• Sheet: Posts.
• Filter: status = ready.
• Limit: I cap at 3 rows per run. I prefer small batches.

This returns an array of rows that are ready to be turned into drafts.

Each row carries all the columns I mentioned earlier.

Module 2: Iterator

I drop an Iterator right after Search Rows.

No magic here. It splits the list of rows into separate bundles so I can process each post independently.

The iterator just takes the array of rows from Sheets and iterates over values[].

Module 3: Data cleanup with Text & Tools

I do some pre-processing before I hit OpenAI.

• Trim whitespace from things like title and slug.
• Normalize commas in tags and target_keywords.
• Generate a fallback slug if the cell is empty.

In practice this is a couple of Tools > Text aggregator / Text parser modules and one Set variable module.

Example: to generate the slug I use a simple Make formula in a Set variable module:

lowercase(
  replace(
    replace(
      replace(
        stripDiacritics(title);
        " "; "-"
      );
      "--"; "-"
    );
    "[^a-z0-9-]"; ""
  )
)

If the slug column in Sheets is already filled, I keep it. Otherwise this kicks in.

Module 4: OpenAI “Create a chat completion” for the article body

Now the fun part.

I use the OpenAI > Create a chat completion module. Currently on gpt-4.1 but I keep this modular so I can swap models.

I feed it a structured prompt that merges sheet data and my own style instructions. Here is the actual system + user content simplified to fit here.

System message (in the module):

You are Richard Lemon, a creative web experience developer.
Write opinionated first-person blog posts.
No em dashes. Short paragraphs (max 2-3 lines).
Direct voice, practical, specific.
Use HTML with <h2>, <p>, <ul>, <li>, <pre>.
Do not add <html> or <body> tags.

User message template:

Write a blog post with the following constraints:

Title: {{title}}
Brief: {{brief}}
Target keywords: {{target_keywords}}
Tone: {{tone}}
Word count target: {{word_count_goal}}

Rules:
- Write in first person as if I actually did the thing.
- Be concrete and technical where useful.
- Use only HTML tags for structure (<h2>, <p>, <ul>, <li>, <pre>, <code>).
- No introduction fluff, start with context or action.
- No conclusion heading.

Return only the HTML body.

The output is pure HTML. I do not want Markdown here because Ghost accepts HTML just fine and I like having precise control.

Module 5: OpenAI for SEO meta + excerpt

I split generation into two calls instead of asking one model response to do everything.

Second OpenAI > Create a chat completion module takes the title, target keywords, and a short summary of the generated HTML and creates meta fields plus an excerpt.

System message:

You create SEO metadata for blog posts.
Always stay under the specified character limits.
Return JSON only.

User message:

Post title: {{title}}
Target keywords: {{target_keywords}}
Body HTML (truncated): {{body_preview}}

Generate:
- meta_title: max 60 chars, must include at least one keyword.
- meta_description: 120-155 chars, natural and specific.
- excerpt: 1-2 sentences, no clickbait.

Return JSON like this:
{
  "meta_title": "...",
  "meta_description": "...",
  "excerpt": "..."
}

I then parse that JSON with a JSON > Parse JSON module.

Could I compress this into one call? Sure. I tried that. The meta fields got worse and harder to constrain. So I split it.

Module 6: Write everything back to Google Sheets

At this point I have:

• Cleaned title and slug.
• Generated HTML body.
• Meta title, description, and excerpt.

Before touching Ghost I push this back into the sheet.

I use Google Sheets > Update a Row with:

• Column J → generated_html from OpenAI.
• Column K → meta_title from JSON.
• Column L → meta_description.
• Column M → excerpt.
• Column D → final slug.
• Column B → set to generated.

Why write back before publishing?

Because I like a manual checkpoint. I can read the generated HTML in Sheets, tweak the brief or title, flip status back to ready if I want a regen.

This effectively makes Sheets my content staging area while Ghost stays clean.

Module 7: Filter on publish_flag

Not every generated post should go live.

I add a filter between the Sheets update and the Ghost modules:

• publish_flag = "draft" OR publish_flag = "publish"

If publish_flag is empty or something else, the scenario stops for that row. It will still update the generated fields, but nothing touches Ghost.

When I want a post to move to Ghost I set publish_flag to draft or publish in the sheet.

Module 8: Router for create vs update in Ghost

I use Ghost both for new posts and edits triggered from Sheets.

So I drop a Router with two branches:

• Branch 1: Create when ghost_post_id is empty.
• Branch 2: Update when ghost_post_id is not empty.

This lets me tweak a title or tags in Sheets, set publish_flag again, and push an update to the existing Ghost post.

Module 9: Ghost “Create a post” (branch 1)

On the create branch I use the Ghost > Create a post module.

Here is how I map things:

• Title → Sheet title.
• Slug → final slug from Module 3.
• HTML → generated_html.
• Excerpt → AI generated excerpt.
• Meta title → meta_title.
• Meta description → meta_description.
• Tags → split tags column on comma, trim each value.

For status I map directly from publish_flag:

• draft → Ghost draft.
• publish → Ghost published.

Ghost returns a post object with an id. I capture that and write it back to the sheet.

Module 10: Google Sheets “Update a Row” with ghost_post_id

Immediately after the create call I drop another Google Sheets > Update a Row module.

It takes the id from Ghost and stores it in column O: ghost_post_id. I also set:

• status = published if publish_flag was publish.
• status = generated if publish_flag was draft.

This keeps my spreadsheet the single source of truth. I can filter ideas, generated drafts, and published content without logging into Ghost.

Module 11: Ghost “Update a post” (branch 2)

On the update branch, I use Ghost > Update a post with the stored ghost_post_id.

I do not blindly overwrite everything. Here is my mapping logic:

• Always update HTML from generated_html.
• Update title and slug only if the sheet values changed.
• Update meta fields if they exist in Sheets. Otherwise keep Ghost values.
• Tags are rebuilt from the tags column every time.

In Make that means I use if expressions in the field mapping. For example:

if(
  empty(sheet_meta_title);
  ghost.meta_title;
  sheet_meta_title
)

I apply a similar pattern for slug and description.

Module 12: Error handling and logging

I do not like silent failures.

So I added a simple error path using Make’s built-in error handlers:

• If Ghost or OpenAI throws an error, I catch it in a separate route.
• Then I write the error message into a errors column in Sheets.
• I also ping myself with a Gmail > Send an email module when something breaks.

Nothing fancy. Enough to see when the pipeline has issues without watching Make all day.

Why I structured it this way

I tried a few alternative versions before landing on this flow.

What I did not like:

• Single gigantic OpenAI prompt that tried to output HTML, meta, title variants, tag suggestions, everything. It was brittle.
• Direct Sheets to Ghost without writing generated content back first. Harder to see what the model produced.
• No publish_flag, so everything went straight to draft in Ghost. That got noisy fast.

What works better for me now:

• Sheets is the control tower. All fields visible. Easy to override.
• Make is the transport layer. No business logic hidden in Ghost.
• OpenAI is a dumb transformer that takes structured inputs and outputs structured HTML and metadata.

The end result is that I spend time on outlines and ideas, not formatting posts or fighting CMS UI.

How this feels in daily use

Here is my actual workflow on a random Tuesday.

• I open the Posts sheet and dump three new ideas as rows with rough titles and briefs.
• I set status = ready and leave publish_flag empty.
• Make picks them up, runs OpenAI, writes back generated HTML and meta, sets status = generated.
• I skim the HTML in Sheets. If a post feels off, I tweak the brief or title, flip status back to ready and let it regenerate.
• Once I like a post, I set publish_flag = draft or publish.
• Next run, Make pushes it into Ghost accordingly.

I still edit inside Ghost sometimes. Especially for code-heavy posts or things where I want to insert images manually.

But 80 percent of the grunt work is automated. Which is the point.

If you want to copy this

If you are already using Make, you can rebuild this in an afternoon.

The three non-negotiables in my experience:

• Use Sheets as a real schema, not a random dumping ground.
• Keep OpenAI prompts tight and specific. One job per call.
• Always round trip data back into Sheets so you can see what the system did.

From there you can layer on extras. Social post generation, image generation, cross-posting to other platforms. I keep those in separate scenarios so this core pipeline stays boring and reliable.

That is the full blueprint I run right now. It will probably change again in a month. But the core idea stays the same. Treat your content as structured data, not as a CMS typing session.

I Built a “Production-Ready” AI Agent Framework. It Was a Lie. So I Fixed It.

A story about AI-generated repos, fake READMEs, and what I did about it.

Two weeks ago, I built an automation pipeline that generates open-source projects on GitHub. The idea: market-research trending tech, scaffold a repo, fill it with code, add docs, and push — fully automated. 14 agents working together. 65 seconds end-to-end. I was proud of it.

Then I actually looked at the generated code.

The Ugly Truth

The pipeline had generated three repos:

• ai-agent-starter: “Production-ready AI agent framework with multi-provider support”
• dev-cli-kit: “Modern CLI toolkit with scaffolding, code generation, and git automation”
• nextjs-saas-starter: “Next.js SaaS starter with auth, payments, and AI integration”

Sounds great, right? Here’s what was actually inside:

The nextjs-saas-starter didn’t even have a src/ directory. Just a package.json, a tsconfig.json, and a README claiming it had “authentication, Stripe payments, and an AI chat interface.” None of those existed. Not even a single component.

The READMEs were AI-generated marketing fluff. Every claim was false. And somehow, each one had donation links (PayPal, Buy Me a Coffee, GitHub Sponsors) — asking for money before delivering a single working line of code.

I had built a lying machine.

What I Did

Instead of deleting the repos (GitHub URLs and star history have value), I decided to make every claim true.

I rewrote all three from scratch, and built a fourth:

1. ai-agent-starter (v0.2.0)

What it claimed → What it now is:

• “Multi-provider support (OpenAI, Anthropic, Ollama)” → Actually implemented all three, with streaming
• “Built-in tool execution engine” → Real function calling via OpenAI/Anthropic native tool APIs, not regex string matching
• “Conversation memory” → Token-aware memory manager with auto-pruning
• “CLI and programmatic API” → npx ai-agent-starter chat, npx ai-agent-starter run "prompt", and importable package

650+ lines of TypeScript, 24 tests, zero build errors.

2. dev-cli-kit (v0.2.0)

The old version’s only source file was cli.ts.hbs — a Handlebars template with // TODO: Implement init logic as its core functionality.

Now: real project scaffolding from 3 built-in templates (Node/TS, React/Vite, CLI tool), code generation (component/hook/util/api), and git workflow helpers. 480+ lines, 8 tests.

3. nextjs-saas-starter (v0.2.0)

From zero lines to a complete Next.js 14 app: landing page (hero, features grid, pricing), dashboard with sidebar + stats, login/register pages, billing page, settings page, API route, Tailwind CSS with dark mode. 520+ lines across 14 files.

4. ai-chat-saas (NEW)

Built on top of the first three — a complete AI chat application. Multi-provider streaming chat with server-side API key protection. 763 lines. Ready to deploy on Vercel in 60 seconds.

What I Learned

1. AI-generated code isn’t the problem — unverified AI-generated code is. My pipeline agents were generating template stubs and calling them “production-ready.” The fix was embedding real, tested code as the generation template.

2. READMEs should describe what EXISTS, not what you WISH existed. Every line in the new READMEs corresponds to actual code you can run.

3. Donation links on empty repos are a red flag. If a project has zero working code and asks for money, it damages trust in the entire open-source ecosystem. I removed all donation links and added them back only where appropriate.

4. “Production-ready” means something. It means tests pass, builds succeed, and someone can clone your repo, run npm install && npm run dev, and see a working product. Not a TODO comment.

What’s Next

The pipeline is fixed. The code agents now generate real, working code instead of stubs. Cron runs daily at 16:00 Beijing time.

I’m also launching a paid template — ai-chat-saas — on Gumroad for $19. It’s the chat application with all three providers, streaming, dark mode, and server-side API protection. Clone, set your API keys, deploy.

The moral: if you’re using AI to generate code, verify it. Actually run npm install. Actually run npm test. Actually try to use it. Otherwise you’re just building a very fast bullshit machine.

All repos: github.com/GrahamduesCN

Most RAG tutorials start the same way: “First, install a vector database…” Then come the embedding models, the chunking strategies, the similarity thresholds. By the time you can ask a question about a PDF, you’ve deployed three services and written 200 lines of boilerplate.

Garudust Agent takes a different path. RAG is built in — backed by SQLite FTS5 with a trigram tokenizer. No vector database. No embedding API calls. Drop a PDF (or TXT, CSV, Markdown, JSON) into the conversation and start asking questions in seconds.

How It Works

When you ingest a document, Garudust:

1. Extracts text (native PDF parser, no external tools)
2. Splits it into chunks (≤ 800 chars, paragraph-aware)
3. Indexes chunks into an FTS5 virtual table with tokenize = 'trigram'

When you ask a question, doc_search runs a full-text query against the index and feeds the top matching chunks to the LLM as context. That’s the whole pipeline — one SQLite file at ~/.garudust/state.db.

The trigram tokenizer means it works on any language, including Thai, Chinese, and Japanese, without any tokenizer configuration.

Setup

RAG is enabled by default. The only thing you need to configure is which directories the agent is allowed to read from:

# ~/.garudust/config.yaml
security:
  allowed_read_paths:
    - /home/you/documents
    - /data/company-docs

That’s it. If you want to turn RAG off entirely:

disabled_toolsets: [rag]

Your First Ingestion

Start the CLI:

garudust

Then tell the agent to ingest a file:

You: ingest /home/you/documents/employee-handbook.pdf

Agent: Indexed employee-handbook.pdf — 47 chunks ready for search.
       Preview: "This handbook outlines the policies and procedures for all employees…"

Now ask anything:

You: What is the remote work policy?

Agent: According to the employee handbook, remote work is permitted up to 3 days per week
       for roles that do not require on-site presence. Employees must notify their manager
       at least 24 hours in advance and maintain availability during core hours (10am–4pm).

The Four RAG Tools

You never call these directly — the agent decides when to use them based on your question. But knowing they exist helps you understand what’s happening.

Re-ingesting a file

If a document changes, just ingest it again. The old index for that path is replaced automatically.

Forgetting a document

You: Remove the Q1 report from the index.
Agent: Document removed from index.

Or clear everything:

You: Clear all indexed documents.
Agent: Removed 5 document(s) from index.

FTS5 Query Syntax

doc_search supports full FTS5 syntax, which the agent uses automatically when your question benefits from it:

You don’t need to write FTS5 queries yourself — the agent figures this out. But if you want to guide it:

You: Search for "termination clause" in the contract documents.

Real-World Use Cases

1. Company Knowledge Base

Ingest your onboarding docs, SOPs, and internal wikis. New team members can ask questions in plain language instead of searching through Confluence.

You: ingest /docs/sop-release-process.md
You: What approvals are needed before a hotfix can go to production?

2. Contract and Legal Review

You: ingest /legal/vendor-agreement-2025.pdf
You: Does this contract include a limitation of liability clause? What is the cap?

3. Log Analysis

Ingest a log file and ask questions without writing grep patterns:

You: ingest /var/log/app/error.log
You: Which service caused the most errors in the last hour?
You: Are there any database connection timeouts?

4. Codebase Documentation

You: ingest /project/docs/api-reference.md
You: What parameters does the /auth/refresh endpoint accept?

Ingesting Files Sent via Telegram or LINE

If you’re running garudust-server with a messaging platform, users can send files directly to the bot. Attachments are automatically saved to a temporary path and can be ingested on request:

User sends: quarterly-report.pdf (attached)

Agent: I received your file. Would you like me to index it for search?

User: yes

Agent: Indexed quarterly-report.pdf — 83 chunks ready.
       Preview: "Q1 2025 Financial Summary — Total Revenue: $4.2M…"

User: What was the gross margin for Q1?
Agent: According to the report, gross margin for Q1 2025 was 61.3%,
       up from 58.9% in Q4 2024.

Platform attachments (files from Telegram, LINE, Discord, etc.) are always allowed regardless of allowed_read_paths, since they’re written to /tmp/garudust_* by the platform adapter.

Multiple Documents at Once

You can ingest multiple files and search across all of them in the same session:

You: ingest /docs/policy-2024.pdf
You: ingest /docs/policy-2025.pdf
You: What changed in the travel expense policy between 2024 and 2025?

The agent searches both documents and synthesizes the differences.

Check what’s indexed at any time:

You: What documents have you indexed?

Agent: 2 documents indexed:
       - policy-2024.pdf | 34 chunks | ingested 2025-05-21 09:14
       - policy-2025.pdf | 38 chunks | ingested 2025-05-21 09:15

Limitations

• No semantic search — FTS5 is keyword/trigram matching, not embedding similarity. If the document says “annual leave” and you ask about “vacation days,” the agent bridges this with its language understanding, but results depend on the LLM’s reasoning.
• Session-scoped by default — The index persists in state.db, but searches are scoped to the current conversation key. Starting a new session means re-ingesting if you want to query the same files.
• Text-only — Images, tables, and charts inside PDFs are not extracted. Text content only.

Summary

Garudust’s RAG won’t replace a purpose-built vector search pipeline for large-scale production retrieval. But for a developer who wants to ask questions about their documents right now — without running a second service — it’s the fastest path from PDF to answer.

Garudust Agent — GitHub · Releases