Turning Weekly GitHub Activity Into Blog Posts on Notion + DEV.to

No more Monday amnesia. The blog writes itself.

What it actually does

1. 
   Harvests my GitHub activity via GraphQL — commits, PRs, issues, code reviews, discussions, language stats, contribution streak


2. 
   Narrates the raw data into a casual, first-person blog post using Gemini (with a deterministic fallback if the LLM is unavailable)


3. 
   Publishes to two platforms simultaneously:
   
   
   
   
   • 
     Notion — a planner-style page with stats tables, repo breakdowns, PR/issue/review tables, language breakdown, and the full blog post
   
   
   • 
     DEV.to — a draft article ready for review
   
   
   
   

Key features

• 
  3 specialized agents — each does one thing well (harvest, narrate, publish)


• 
  LLM only where it adds value — harvest and publish are deterministic, zero token overhead


• 
  4 blog tone profiles — casual (default), professional, technical, storytelling


• 
  Planner-style Notion pages — not just a wall of text, but structured tables with stats, repos, PRs, issues, reviews, and languages


• 
  Notion MCP integration — full Notion API surface via Model Context Protocol


• 
  Notion Markdown Content API — write rich markdown directly to pages (the real game changer)


• 
  DEV.to draft publishing — articles created as drafts, ready to review and publish


• 
  GitHub Actions CI — weekly cron (Sundays 08:00 UTC) + manual dispatch


• 
  Blog log in README — CI auto-commits a metrics table after each run


• 
  Fallback chain — always produces a blog post, even if Gemini is down


• 
  Rate limiting everywhere — p-queue + p-retry for both Notion and DEV.to APIs

Architecture

through Mastra's MCP client. This gives the agent access to the full Notion API surface via Model Context Protocol:

import { MCPClient } from '@mastra/mcp';



export const notionMcp = new MCPClient({

  servers: {

    notion: {

      command: 'npx',

      args: ['-y', '@notionhq/notion-mcp-server'],

      env: {

        OPENAPI_MCP_HEADERS: JSON.stringify({

          Authorization: `Bearer ${env.NOTION_TOKEN}`,

          'Notion-Version': '2022-06-28',

        }),

      },

    },

  },

  timeout: 30000,

});

The MCP tools are loaded lazily with a graceful fallback — if the MCP server fails to start, the direct tools still work independently:

export async function getNotionMcpTools(): Promise<Record<string, any>> {

  try {

    return await notionMcp.listTools();

  } catch (err) {

    console.warn('MCP: Notion MCP server unavailable, using direct tools only');

    return {};

  }

}

2. Direct tools + MCP tools merged

The publisher agent merges both tool sets — MCP tools for the full Notion API surface, and direct tools for capabilities MCP doesn't cover:

// Direct tools (Markdown Content API + DEV.to — not available via MCP)

const directTools = {

  createNotionPage: createNotionPageTool,

  writeMarkdown: writeMarkdownTool,

  searchNotion: searchNotionTool,

  updateNotionPage: updateNotionPageTool,

};



// Merge: Notion MCP tools + direct tools

const mcpTools = await getNotionMcpTools();

const tools = { ...mcpTools, ...directTools };

This dual approach means the publisher agent gets the best of both worlds — MCP's broad API surface for interactive use in the Mastra playground, plus direct tools for the automated workflow.

3. The Markdown Content API (the game changer)

This is the Notion feature that made the planner-style pages possible. Instead of constructing Notion blocks one by one (which is painful and rate-limit-heavy), I write the entire page as markdown in one API call:

const response = await fetch(

  `https://api.notion.com/v1/pages/${pageId}/markdown`,

  {

    method: 'PATCH',

    headers: {

      Authorization: `Bearer ${env.NOTION_TOKEN}`,

      'Content-Type': 'application/json',

      'Notion-Version': '2026-03-11',

    },

    body: JSON.stringify({

      type: 'replace_content',

      replace_content: { new_str: markdown },

    }),

  },

);

One PATCH request replaces the entire page content with rich markdown — including tables, headings, blockquotes, links, code blocks, everything. This is what powers the planner-style layout with structured stats tables + the full blog post, all in a single API call.

4. Rate limiting

Notion's API allows roughly 3 requests per second. Every Notion call (MCP and direct) goes through a shared rate limiter:

const queue = new PQueue({ concurrency: 1, interval: 334, intervalCap: 1 });



async function rateLimited<T>(fn: () => Promise<T>): Promise<T> {

  return queue.add(() => pRetry(fn, { retries: 3 })) as Promise<T>;

}

p-queue throttles concurrency, p-retry handles transient failures. I learned this the hard way — without rate limiting, the Notion API will 429 you into oblivion when you're creating a page, writing markdown, and updating the icon in quick succession.

Lessons Learned

Rate limits are the real boss

Notion (3 req/s), DEV.to (30 req/30s), GitHub GraphQL (5000 points/hr) — every API has its own throttle. I ended up with p-queue + p-retry wrappers around everything. The rate limiter code is almost identical across all three services, and honestly, it should probably be a shared utility. But three similar lines of code is better than a premature abstraction.

Structured output is slower than you'd think

I originally used Gemini's native JSON schema for structured output (agent.generate(prompt, { structuredOutput: { schema } })). It worked, but added 20-40 seconds per call. Switching to plain text generation with YAML frontmatter parsing was 3-4x faster and just as reliable. The deterministic fallback catches the rare parsing failure.

Gemini model musical chairs

I've been through three Gemini models on this project: gemini-2.5-flash-preview-04-17 (retired), gemini-2.5-flash (stable but slow for structured output), and now gemini-3-flash-preview (current). The lesson: always make the model configurable via env vars. Hardcoding model IDs is a recipe for broken deploys.

The Zod conflict that broke everything

Mastra and my code both depend on Zod, but different versions. Having two Zod instances means z.string() from one isn't recognized by the other — schema validation just silently fails. The fix: a single line in package.json:

{

  "pnpm": {

    "overrides": {

      "zod": "$zod"

    }

  }

}

Forces pnpm to deduplicate to one Zod version. Took me way too long to figure that out.

Direct API calls beat agent reasoning for deterministic work

The harvest and publish steps started as full agent calls. But an LLM doesn't add anything when the task is "call this GraphQL endpoint and return the result." Switching to direct function calls made the pipeline faster, cheaper, and more predictable. Only use an LLM where you need creativity or reasoning — everywhere else, just write a function.

Built with , Notion API, and a lot of coffee. If you've ever forgotten what you worked on last week, give DevNotion a try.