Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン 初心者向け
#5,133 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
76/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
github, typescript
領域
devtools

調査の方向性

まず AGENTS.md から始め、issue 主導の作業と長期にわたる作業に関するガイダンスを見つけます。次に、docs/contribution-model.md の Close 手順と、一括 GitHub 書き込みのための issue-triage および board-ops スキルの手順を読みます。提示されたルールを AGENTS.md に追加し、数値を繰り返さずに、コントリビューションガイドと影響を受けるすべてのスキルからそのルールにリンクします。これらの参照先が単一のルールを指し、スキルを変更した場合は npm run verify:skills が成功すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
JavaScript
スター
91.2k
フォーク
11.8k
平均マージ
6時間 39分
マージ済み PR(30日)
111

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/servers のほかの issue

modelcontextprotocol/servers の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。