LLMs.txt generation on every PR

[evantahler]

Rather than wait until the end of the week, we can run the generation of LLMs.txt on every PR, looking only for what has changed. Changes will be auto-commited back to your PR

---

Note

Runs LLMs.txt generation on pull requests with auto-commit and updates the generator to perform incremental, git-aware regeneration with embedded metadata; refreshes llms.txt.

• CI/CD (GitHub Actions)
  • Trigger workflow on pull_request (opened/synchronize/reopened).
  • Checkout PR head ref with custom token.
  • Detect file changes; if changes in PR runs, auto-commit public/llms.txt back to the PR branch.
  • For manual/scheduled runs, create a PR and enable automerge.
• Generator Script (scripts/generate-llmstxt.ts)
  • Add incremental regeneration using previous llms.txt metadata and git diff to only summarize changed/new pages; remove deleted pages implicitly.
  • Embed metadata comment (git-sha, generation-date) in output; preserve if no changes.
  • Reuse existing summaries; batch summarize changed pages; refactor into helper functions.
  • Minor: add constants/regexes, structured logging, and sectioned output generation.
• Artifact (public/llms.txt)
  • Regenerated with new metadata header and refreshed link summaries/sections.

^{Written by Cursor Bugbot for commit 04fbfae. This will update automatically on new commits. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
docs	Ready	Preview, Comment	Dec 19, 2025 4:55pm

[evantahler]

@sdserranog and @torresmateo what do you think about this pattern?

[torresmateo]

I like this pattern! I like opened and reopened for sure, but I'm not so sure about synchronize, as it may become too verbose when there's a lot of back and forth in a PR. But I'm willing to try!

[evantahler]

I like this pattern! I like opened and reopened for sure, but I'm not so sure about synchronize, as it may become too verbose when there's a lot of back and forth in a PR. But I'm willing to try!

Yeah, but what I was worried about was the page content changing, and the summary being inaccurate.

[torresmateo]

[cursor]

Bug: Error handler claims to process all files but doesn't

When getChangedFilesSince() fails (e.g., the previous SHA was rebased away), it logs "processing all files" but returns an empty Set. This causes changedFiles.has(page.path) in determinePagesToSummarize() to return false for all pages. Combined with the condition if (isChanged || !existingSummary), pages with existing summaries will be kept unchanged rather than re-processed. The actual behavior is the opposite of what the log message states - modified files silently retain stale summaries instead of being re-summarized.

 

[cursor]

Bug: Duplicate entries when source files share same URL

The incremental update logic iterates over discovered pages by file path but looks up existing summaries by URL. When two source files map to the same URL (e.g., how-arcade-helps.mdx and how-arcade-helps/page.mdx), both pages pass through the loop independently. If one file is changed and another isn't, one ends up in pagesToSummarize and the other in pagesToKeep, resulting in duplicate entries in the final output. The generated llms.txt shows this happening with the "How Arcade helps with Agent Authorization" page appearing twice.