Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add an AGENTS.md rule for pacing bulk GitHub writes (secondary rate limit)

Open Beginner friendly
#5,133 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
github, typescript
Domain
devtools

Research direction

Start with AGENTS.md and locate the issue-driven work and long-running work guidance, then read the Close step in docs/contribution-model.md and the issue-triage and board-ops skill recipes for bulk GitHub writes. Add the supplied rule to AGENTS.md and link to it from the contribution guide and any affected skills without repeating the numbers. Done when those references point to the single rule and, if a skill changed, npm run verify:skills passes.

Written by the indexing model from the issue text.

Description

documentation v2

Problem

Nothing in AGENTS.md governs how fast an agent may write to GitHub. The only pacing guidance is in docs/contribution-model.md (closing outside PRs: "a pause of a few seconds between them, in batches"). That is a design document, not loaded every session, and it gives no numbers.

Several flows in this repo make bulk writes, and agents run them:

  • the backlog triage (#4875, #4876, #4877): closing PRs with canned comments, boarding and labelling issues
  • board audits and recoveries (board-ops)
  • Copilot review loops (pr-flow): many thread replies per round

GitHub's secondary rate limit refuses those writes even while gh api rate_limit still shows primary quota. Most gh writes go through GraphQL, which has its own limits on top. A refused create is also not reliably a no-op: the object can still have been created, so a blind retry duplicates it.

Change

Add this rule to AGENTS.md, worded as given:

Pace bulk GitHub writes: 1 s between requests, never in parallel, under 80 a minute and 500 an hour. The secondary limit refuses while gh api rate_limit still shows quota, and most gh writes are GraphQL. After a refusal, wait out retry-after, or a minute without one; a refused create can still land, so look before retrying.

  • The rule belongs in AGENTS.md (where a rule that must not drop out of context lives), probably under Issue-driven work style or next to Waiting on long-running work, which already sets the 30 s polling floor for remote APIs.
  • docs/contribution-model.md's "Close" step should then link to the rule instead of stating its own pacing, so there is one copy.
  • Any skill recipe that loops over GitHub writes (issue-triage, board-ops) should follow it and point to it rather than restating the numbers.

Done when

  • AGENTS.md carries the rule as above.
  • docs/contribution-model.md and any skill that does bulk writes link to it, with no second copy of the numbers.
  • npm run verify:skills passes if a skill changed.
Dominant language
TypeScript
Stars
91k
Forks
11.8k
Avg merge
6h 52m
Merged PRs (30d)
107

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/servers

All issues in modelcontextprotocol/servers

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.