Skip to content

Weekly data page update from a wiki

A scheduled task runs every Thursday, finds the newest weekly page on a community wiki, and rewrites one data file in the repo from it. It stops without writing if the week is already covered or the page is incomplete, and opens a pull request a person merges by hand.

EngineeringWorks with Claude Code · Cursor+1Community example
Build your promptSee requirements

What it does

  • Finds the newest weekly page on the source wiki
  • Stops if that week is already in the data file or has an open pull request
  • Stops without writing if required sections are still missing from the page
  • Replaces the data file following a written update guide and runs the project's verify step
  • Opens a pull request on its own branch named for the week

Your approval boundaries

Creates drafts

These actions always wait for your yes:

  • Reviewing and merging the pull request
  • Rerunning by hand when a page was incomplete

You decide what happens next.

More about this workflow

This setup is for developers and small engineering teams who want fewer chores. It takes a repeat chore off your plate and hands back something you can check quickly.

First, it finds the newest weekly page on the source wiki. Next, it stops if that week is already in the data file or has an open pull request. Then it stops without writing if required sections are still missing from the page. After that, it replaces the data file following a written update guide and runs the project's verify step. Finally, it opens a pull request on its own branch named for the week. It works with your git host, web fetch and CI, each on its own login with limited access.

You get the prep work done and waiting for you. The agent stops and asks for your yes before reviewing and merging the pull request and rerunning by hand when a page was incomplete, and says plainly if a step cannot be undone.

“every weekly PR is reviewed and merged by hand (no auto-merge)”
ToothyDev ToothyDev on GitHub · Oct 22, 2026
Before you startGit host · Web fetch accessScoped permissionsClaude Code or Cursor
Explore required tools and model recommendations

Tools and access

  • GitHub

    Handles the git host and ci part of this job. Grant a fine-grained token, read code and write comments.

    API required: Yes. Needs a GitHub App or a fine-grained personal access token scoped to the repos it needs.

    Sign up: Create a GitHub account

  • Web fetch

    Handles the web fetch part of this job. Grant public pages, no logged-in sessions.

    API required: No. Built into most agent harnesses. It reads public pages with no login.

    No sign-up needed

Official links only. Not sponsored, no affiliate links.

Model recommendations

Best pick

Claude Opus 5.5

Its maker points to it for long running coding work.

$4 per million input tokens, $20 per million output tokens.

Anthropic docs as of October 11, 2026

Cheaper backup

Claude Sonnet 5.5

Half the price per token and still strong for reviews and docs.

$2 per million input tokens, $10 per million output tokens.

Anthropic docs as of October 11, 2026

Our own picks. Not sponsored, no affiliate links.

Build your prompt

Add your details, then copy the prompt into your tool.

1Your details

Fill these in and the prompt updates as you type.

the wiki or page that changes weekly

the file in the repo to replace

what must be present before writing

2Your prompt

4 of 4 still empty
Fill these in before you run it: [SOURCE PAGE: the wiki or page that changes weekly] [DATA FILE: the file in the repo to replace] [REQUIRED SECTIONS: what must be present before writing] [RUN DAY AND TIME] You are the Weekly data page update from a wiki agent. A scheduled task runs every Thursday, finds the newest weekly page on a community wiki, and rewrites one data file in the repo from it. It stops without writing if the week is already covered or the page is incomplete, and opens a pull request a person merges by hand. Use only the details filled in above. If any [BRACKETED] item is still blank or unclear, stop and ask for it first. Do not guess. What you do on your own: - Finds the newest weekly page on the source wiki - Stops if that week is already in the data file or has an open pull request - Stops without writing if required sections are still missing from the page - Replaces the data file following a written update guide and runs the project's verify step - Opens a pull request on its own branch named for the week What you must never do without a yes from a person: - Reviewing and merging the pull request - Rerunning by hand when a page was incomplete Rules: - Before any step on the list above, stop and ask. Say in plain words what you want to do, who it affects, and whether it can be undone. - If something cannot be undone, say so first, in one short line. - Write drafts, not final actions. A person sends, pays, posts, or deletes. - Keep a short log of every action you took and every source you read. - If you are unsure, ask instead of guessing.
View run instructionsPaste into: Claude Code, Cursor, n8n

Your answers stay in this browser only.

Run your workflow

Connect your tools with only the access this setup needs, then follow these steps.

Steps

Do these in order. Test on old data before it touches live work.

  1. 1Connect GitHub with its own login, not yours. Grant a fine-grained token, read code and write comments.
  2. 2Set up Web fetch. Keep it to public pages, no logged-in sessions.
  3. 3Paste the prompt where your harness takes instructions. See the note under the Copy button.
  4. 4Do a dry run on old or test data first. Check every draft and every stop point by hand before you let it near live work.
  5. 5Read its log after the first real run. Only widen access once a week of runs looks clean.

Safeguards and trust score

The score describes this example setup’s access, approval boundaries, ability to undo changes, and scope.

Access24 / 30

Writes drafts and notes inside your tools, nothing leaves on its own.

Human approval30 / 30

Waits for a yes on: reviewing and merging the pull request, rerunning by hand when a page was incomplete.

Undo and logs14 / 20

Proposes changes to live records, so the setup needs a change log and a way back.

Scope16 / 20

Runs on its own login across 3 tools. Fewer connections means a smaller blast radius.

How to raise it

  • Undo and logs: Stop it from editing live records. Have it write the change as a proposal you apply, and keep a log of every change with a way to roll it back +3
  • Scope: Cut it down from 3 connected tools to the 2 it needs most, each with its own limited login instead of your full account +2

Do all of these to reach 89, up from 84.

Want help getting there? Get an AI Trust Audit from Pixeldesigns

Reviewed by Trustcase (example setup). How scoring works

Embed badge

Show this trust score on your site or README. It links back here.

Trustcase trust score badge
Markdown
[![Trustcase trust score for Weekly data page update from a wiki](https://trustcase.dev/badge/weekly-data-page-update-from-a-wiki.svg)](https://trustcase.dev/use-cases/weekly-data-page-update-from-a-wiki)
HTML
<a href="https://trustcase.dev/use-cases/weekly-data-page-update-from-a-wiki"><img src="https://trustcase.dev/badge/weekly-data-page-update-from-a-wiki.svg" alt="Trustcase trust score for Weekly data page update from a wiki" height="20"></a>

More engineering workflows

  • Weekly agent setup review from session logs

    Every Monday a local job condenses the past week's coding agent transcripts into a digest, then a read only session suggests setup changes such as hooks, skills, permission entries and instruction rules. It writes a report and changes nothing.

  • Weekly open source contribution scout

    Once a week it checks the status of your open issues and pull requests in other people's repos, finds unclaimed help wanted issues in the projects you care about, and writes one issue in your own repo with what needs you. It posts nothing anywhere else.

  • Pull request reviewer

    Gives every PR a first pass before a person looks.

  • Flaky test hunter

    Finds tests that fail at random and why.

Other workflows that use the same tools

  • New page internal link suggester

    Marketing. Once a week it finds the pages you published and suggests where your older pages should link to them. You approve the links before they go live.

  • Weekly local events draft with fact checks

    Marketing. Every Wednesday it drafts next week's events roundup for a local guide site using only listings already on the guide, and notes every URL it read. A second mode fact checks a stale place page against primary sources.

  • Competitor watch

    Marketing. Keeps an eye on what competitors change on their sites.