community

github now opens to your "home" view and actually shows you useful things!? I never thought this would happen! Seems like this feature went live: community#177902

When AI Co-Authors Skew Your Developer Reports: Restoring GitHub Contributor Accuracy Maintaining a clean and accurate repository history is not just about tidiness; it's fundamental to generating reliable developer reports and gaining true insights into team contributions. In today's AI-augmented development landscape, however, new challenges emerge. What happens when an overzealous AI assistant accidentally co-authors a commit, and even after meticulously rewriting history, that AI still stubbornly appears in your GitHub contributor list, skewing your metrics? This was the precise dilemma highlighted by clintolsen in GitHub Community Discussion #211348, a scenario that resonates with many dev teams and technical leaders. It underscores a critical, yet often overlooked, caching challenge that can directly impact the accuracy of your engineering KPIs and broader [software measurement metrics](/insights/optimizing-cloud-costs-at-scale-edge-computing-and-software-measurement-metrics-for-retail/). The core issue? GitHub's contributor list isn't updated instantly when you rewrite Git history. Instead, GitHub caches this data and recalculates it periodically, primarily based on the commits reachable from your default branch. A simple force-push, while removing the commit from your local history and remote default branch, might not be enough to immediately clear the cached contributor entry. !Developer identifies an unexpected AI entry in GitHub contributor list.Developer identifies an unexpected AI entry in GitHub contributor list. The Hidden Challenge: GitHub's Caching Mechanism For dev teams, product managers, and CTOs relying on GitHub's insights for resource allocation and performance reviews, this caching behavior can be a source of frustration. When an AI like Claude, or any unintended contributor, remains on the list, it dilutes the accuracy of your developer reports. It can misrepresent individual and team contributions, making it harder to assess productivity, identify key contributors, and make data-driven decisions. Understanding this mechanism is the first step to regaining control. Restoring Accuracy: A Step-by-Step Guide Thankfully, the community, particularly vectornguyen76, provided clear, actionable steps to resolve this. These steps are crucial for anyone looking to maintain data integrity in their [software measurement](/insights/boosting-dev-performance-how-ai-powered-prototyping-redefines-software-measurement/) metrics. 1. Comprehensive History Check: Root Out Lingering References Before attempting any refresh, you must be absolutely certain that the offending commit is truly gone from every corner of your repository. GitHub's caching is smart enough to pick up references from any reachable commit. If any branch, tag, or even an open pull request still references a commit with the Co-authored-by: trailer, that commit remains reachable and will continue to count towards contributor statistics. This is a common oversight that can prolong the issue. Use git log to perform a thorough sweep: git log --all --grep="Co-authored-by: Claude" --oneline This command is powerful: --all checks all branches and tags, and --grep specifically targets the problematic co-authorship line. If this command returns any output, you still have work to do. You'll need to identify which branches or tags still hold these references and either rebase, amend, or delete them until the commit is truly unreachable. !Using git log to thoroughly check repository history for unwanted co-authorship.Using git log to thoroughly check repository history for unwanted co-authorship. 2. Prompting a Recalculation: Push a New Commit Once you've confirmed that all problematic commits are unreachable from any branch or tag, the next step is to prompt GitHub to recalculate its contributor statistics. GitHub often triggers a recalculation when there's a new commit pushed to the default branch (e.g., main or master). This signals to GitHub that the repository's state has changed, necessitating an update to its cached metrics. A simple, non-disruptive way to do this is to push a minor, innocuous commit. For example, updating a README.md file with a tiny fix or adding an empty line to a documentation file, then pushing that change, can often do the trick. Remember, patience is key here; the sidebar list can lag behind by several hours as GitHub processes the update across its systems. 3. When All Else Fails: Engage GitHub Support If, after a day or so, the unwanted entry persists despite your best efforts, it's time to escalate. Contact GitHub Support directly. They have the tools and access to clear cached contributor data for your repository. This step is particularly important if you've had to remove sensitive data (beyond just an AI co-author) from your history, as old commit views in pull requests can also retain cached information. GitHub's documentation on "Removing sensitive data from a repository" explicitly mentions that Support intervention might be necessary for a complete purge. Proactive Measures: Preventing Future Skews While the steps above address the immediate problem, preventing recurrence is crucial for maintaining consistent and accurate developer reports. As AI tools become more integrated into our workflows, managing their output effectively is a new facet of technical leadership. - Configure AI Tools: Most AI coding assistants, like Claude Code, offer settings to control their attribution behavior. Look for attribution or co-author options in their settings documentation. Disabling automatic co-authorship or setting it to prompt for confirmation can save significant cleanup time. - Implement Pre-Commit Hooks: For teams requiring strict control over commit messages, consider implementing Git pre-commit hooks. These client-side hooks can automatically check commit messages for specific patterns (e.g., "Co-authored-by: Claude") and block the commit until the message is corrected. This adds an automated layer of defense against unwanted entries. - Educate Your Team: Ensure all team members are aware of these potential issues and the importance of reviewing commit messages, especially when using AI-assisted tools. A brief team guideline on commit message hygiene can go a long way. !Configuring AI tools and implementing pre-commit hooks to prevent future contributor list inaccuracies.Configuring AI tools and implementing pre-commit hooks to prevent future contributor list inaccuracies. Beyond the List: The Impact on Engineering KPIs and Software Measurement Metrics This seemingly minor issue of an AI in a contributor list actually touches upon a much larger theme: the integrity of your data. For CTOs, product managers, and delivery managers, accurate developer reports are the bedrock of strategic decision-making. Skewed data directly impacts your ability to: - Assess Team Productivity: Misattributed contributions can inflate or deflate perceived team output, making it difficult to identify bottlenecks or celebrate genuine successes. - Track Project Progress: If contributor metrics are off, your understanding of who is driving progress on specific features or modules becomes cloudy. - Allocate Resources Effectively: Data from software measurement metrics informs hiring decisions, team structuring, and budget allocation. Inaccurate data leads to suboptimal resource deployment. - Evaluate Tooling ROI: If AI tools are inadvertently skewing your metrics, it becomes harder to genuinely evaluate their return on investment and impact on [developer efficiency](/posts/apps-tools/boosting-developer-efficiency-rethinking-feedback-systems-with-ai/). Maintaining clean contributor data is therefore not just a technical chore; it's a strategic imperative for reliable engineering KPIs and effective technical leadership. It ensures that your metrics truly reflect human effort and allows for meaningful analysis of your development velocity and team health. Conclusion The accidental co-authorship by an AI assistant is a modern twist on an old problem: maintaining data accuracy in a dynamic development environment. While GitHub's caching behavior can introduce a delay, a systematic approach—from comprehensive history checks to proactive prevention and, if necessary, GitHub Support—ensures your developer reports remain precise and trustworthy. By taking these steps, you safeguard the integrity of your engineering KPIs and empower your leadership with the accurate insights needed to drive productivity and successful delivery.

VS Code Copilot Cloud Automations: Daily App Store Review Triage On October 28, 2026, GitHub added Copilot cloud automations to VS Code. You write a prompt and pick a time. Then a Copilot cloud agent runs that prompt on GitHub every day, even when your laptop is off. We used this for one common mobile job. Each morning, the agent sorts new bad App Store and Google Play reviews into crash, payment and login problems. We made 10 live calls to the EveryInfra app_store/reviews and google_play/reviews capabilities on November 11, 2026. The calls covered two public apps, Duolingo and Strava, in both stores. The API fee for a daily run over four store listings is $0.0056 a day, or $0.17 for 30 days. Two other facts decide if the job works. One call returns at most 200 English Google Play reviews for Duolingo, and they cover only 4.25 hours. So one daily run misses most new reviews of a large app. Also, VS Code lets a cloud automation run at most once a day. We did not create this automation in a GitHub repository. All Copilot steps in this article come from GitHub and VS Code documentation, and we label them "config example". All EveryInfra numbers come from live calls, with the Singapore time (SGT) of each call. > Key points > > - Copilot cloud automations shipped on October 28, 2026, with VS Code 1.144. They work on private and internal repositories, on the Pro, Pro+, Max, Business and Enterprise plans. > - In VS Code, a cloud automation runs manually, daily or weekly. Minutes are 00, 15, 30 or 45, and times are stored in UTC. Hourly and cron schedules are for local runs only. > - One call covers very different time spans: 4.25 hours for Duolingo on Google Play (English), 123.9 days for Strava on the US App Store. > - In both stores, the newest review is 24 to 44 hours old. Google Play holds new reviews for about 24 hours before it shows them. > - If the model reads the raw MCP output, it reads about 65,062 tokens a day. A script that keeps only new 1 to 3 star reviews cuts this to about 4,999 tokens. > - A keyword rule is only a first filter. In a random sample of 40 bad reviews, the rule was right 23 times, wrong 13 times and missed 4. !Isometric illustration on a dark background. On the left, two phone outlines without logos pour a line of small cards with stars into a wide metal sieve. Most cards fall through the holes into a large gray bin below. The few cards that stay on the sieve slide into four small trays on the right. The trays show only simple icons: a cracked gear, a coin, a key and a satellite dish. One tray is teal. Most reviews need no reading, and a few bad ones go into problem groups. The daily job is a sieve. Most reviews need no reading. A few bad reviews go into crash, payment, login and sync groups. The job: a bad-review report every morning A team ships one mobile app for iOS and Android. Each morning, the repository must contain a new report on the 1 to 3 star reviews since the last run. The report puts each review into one group: crashes and bugs, payment, login and account, sync and devices, ads, redesign, or other. If one group jumps, for example "the app crashes after the update" a dozen times in three days, the automation opens an issue. The issue holds the examples and the app version. The job fits Copilot cloud automations for three reasons. It runs on a schedule and must finish before people start work. It writes into the repository, and the cloud agent already has GitHub tools for files and issues. Its data is outside the repository, so the agent needs an MCP server or a fetch script. The EveryInfra data API fills that third gap. We picked one large app and one medium app. Duolingo (App Store ID 570060128, Android package com.duolingo) is a language app with a very large review volume. Strava (App Store ID 426826309, package com.strava) is a fitness tracker with a medium volume. We read only public reviews and signed in to no account. The main calls ran on November 11, 2026, from 00:22 to 00:42 SGT, which is about 08:30 PST on November 10. What are VS Code Copilot cloud automations? The October 28 release, checked line by line The GitHub changelog of October 28, 2026 announced Copilot Automations in Visual Studio Code. The entry says that you need VS Code 1.144 and the setting chat.automations.cloud.enabled. The feature is available on the Copilot Pro, Pro+, Max, Business and Enterprise plans. You find it in the Automations tab of the Agents window. The VS Code download page showed version 1.144.1 on that day. The VS Code automations page, dated November 11, 2026, now says something slightly different. It says that automations and cloud automation management are on by default. You check chat.automations.enabled and chat.automations.cloud.enabled only if the Run in the Cloud option is not in the form. Both pages agree on the version and the plans. We quote both because a team that follows the changelog may look for a setting that is already on. GitHub posted two related entries on the same day: cost controls for automations and shared team automations. The cost section and the limits section below use them. One Copilot cloud automation has three parts: a prompt, a trigger and a set of tools. The prompt says what to do, what to read and what to deliver. The trigger is a schedule, a manual run, or a GitHub event such as a new issue. The tools are the GitHub tools plus MCP tools from the repository settings. Each run starts one cloud agent session on GitHub, and its log stays there. The table below lists each fact with its source. | Fact | What the source says | Source | | --- | --- | --- | | Release date | October 28, 2026 | GitHub changelog | | VS Code version | 1.144 or later | GitHub changelog, VS Code 1.144 release notes | | Settings | chat.automations.cloud.enabled (changelog), on by default (docs page of November 11, 2026) | GitHub changelog, VS Code docs | | Plans | Copilot Pro, Pro+, Max, Business, Enterprise | GitHub changelog | | Repositories | Private and internal repositories only | VS Code docs | | Entry point | Automations tab in the Agents window | VS Code docs | | Cloud schedules | Manual, daily, weekly; minutes 00/15/30/45; stored in UTC | VS Code docs | | Tools | GitHub tools, plus MCP tools from the repository MCP settings | VS Code docs, GitHub docs | | Billing | One cloud agent session per run, paid in AI credits, plus Actions minutes | GitHub docs | | API | REST "agent automations", public preview, version 2026-03-10 | GitHub REST docs | One row is easy to miss. The VS Code page says that a cloud automation does not accept local mode, local approval settings, custom agents or local MCP configuration. So the cloud automation cannot see the EveryInfra MCP server in your own VS Code. You must add the server again in the GitHub repository settings, as the MCP section below shows. How often can it run? Cloud schedules are daily or weekly For a review job, the most important fact is the shortest interval. The text under the VS Code table "Set a recurring schedule" is direct. Cloud automations support Manual, Daily and Weekly triggers, and hourly and cron schedules are for local runs only. The minute must be 00, 15, 30 or 45, and cloud schedules are stored in UTC. We took a screenshot of that part of the page. !Screenshot of the Set a recurring schedule section of the VS Code automations documentation. At the top is a table with the schedule types Manual, Hourly, Daily, Weekdays, Weekly and Cron, and what each one does. Below it, a teal box marks one sentence: cloud automations support only Manual, Daily and Weekly, Hourly and Cron are for local automations, and times are stored in UTC. The schedule types that VS Code offers for cloud automations. The teal box marks the sentence that we quote. Screenshot taken on November 11, 2026, SGT. VS Code automations documentation, screenshot Two sources do not say exactly the same thing here. The GitHub page on creating automations lists hourly, daily and weekly schedules, event triggers for issues and pull requests, and an API trigger. A VS Code test issue from October 11 (number 340970) also lists Hourly and Weekdays as test items. Our reading is that an automation created on the GitHub website can run every hour. An automation created in VS Code offers only daily and weekly cloud schedules. The VS Code page is newer than the test issue, so this article follows the page. If your team needs an hourly run, create the automation on GitHub. You can also split the job into frequent fetches and one daily analysis, as we show later. UTC storage is easy in Singapore, where 01:00 UTC is 09:00 all year. In San Francisco, 15:00 UTC is 07:00 in winter (PST) and 08:00 in summer (PDT). The VS Code page tells you to check the saved time after a daylight saving change. The full flow: six steps per run !Flow animation with six boxes in two rows. A small dot travels around the boxes, one loop every nine seconds. Step 1, Trigger: daily at 01:00 UTC, scheduled on GitHub. Step 2, Session: Copilot cloud agent reads the repository instructions. Step 3, Fetch: app_store/reviews and google_play/reviews. Step 4, Dedupe and filter: drop review IDs already seen, keep 1 to 3 stars. Step 5, Classify: crash, payment, login, sync, other. Step 6, Report: write reports/date.md and open an issue on spikes. A note says the API fee is 4 calls a day, $0.0056 in total, and the model reads only filtered 1 to 3 star reviews. The figure above shows the flow that we recommend. Step 1 is the GitHub schedule, and in step 2 the agent reads the instruction files in the repository. Step 3 fetches new reviews, through MCP or a script. Step 4 removes reviews already seen, by ID, and keeps only 1 to 3 stars. Step 5 lets the model put each review into a fixed group and compare the counts with past days. Step 6 writes the report and, if necessary, opens an issue. The split between step 3 and step 4 is the main design choice. If the agent calls the API through MCP, each full review goes into the model context, with author, avatar link and helpful count. If a script fetches, dedupes and filters first, the model reads one small file. Both ways work, and the section "Filter with a script first" measures the tokens of each. How the Copilot cloud agent connects to MCP: the JSON in repository settings The Copilot cloud agent reads its MCP servers from the repository settings. Open the repository Settings, then Copilot, then MCP servers, and paste a JSON block there. The GitHub page on MCP servers describes the format. The top level is mcpServers. Each server has a type (local, stdio, http or sse), a url and headers for a remote server, and a tools allowlist. Only MCP tools work, not MCP resources or prompts. Remote servers that need OAuth are not supported yet, according to the same page. The EveryInfra remote MCP server uses an API key, not OAuth, so it fits. The block below is a config example. We did not save it in a GitHub repository. { "mcpServers": { "everyinfra": { "type": "http", "url": "https://api.everyinfra.com/mcp", "headers": { "Authorization": "Bearer $COPILOT_MCP_EVERYINFRA_KEY" }, "tools": ["everyinfra_list_capabilities", "everyinfra_call_api", "everyinfra_get_job"] } } } Do not put the key in this JSON. The GitHub page on secrets for the cloud agent explains the rules. Under Secrets and variables there is an Agents type. A secret whose name starts with COPILOT_MCP_ goes only to MCP servers and is not an environment variable for the agent. Other secrets become environment variables for the commands and scripts that the agent runs. Session logs mask secret values. So the MCP path stores the key as COPILOT_MCP_EVERYINFRA_KEY. The script path stores it under a name without the prefix, for example EVERYINFRA_API_KEY. The two paths need two different secrets. If you use the wrong name, the server or the script starts without a key and the first call fails with 401. Keep only three tools in the allowlist. At 00:22 SGT we sent one tools/list request to the EveryInfra MCP server, and it returned 12 tools. Review triage needs three of them: list capabilities, call the API and read an async job. The allowlist also has a second effect. The MCP specification gives each tool annotations, and readOnlyHint means that the tool changes nothing. In our tools/list response, everyinfra_list_capabilities and everyinfra_get_job are read-only. everyinfra_call_api costs money, so it is not marked read-only. The GitHub MCP overview says that Copilot code review uses only tools with readOnlyHint set to true. So the same config cannot call the data API during code review. It can call it in cloud agent sessions and automations. To test the setup, GitHub tells you to assign an issue to Copilot and open the session log. The step "Start MCP Servers" must list the server and its tools. There is also an open community report. GitHub community discussion 211107 was posted on October 27, 2026. A user says that custom MCP tools start in an automation session, but the agent cannot call them. The same setup works in a cloud session that the user starts by hand. When we read that thread, no GitHub staff member had posted an answer. So for the first launch, trigger the automation by hand. Check that the log shows a real everyinfra_call_api call and its result, and only then turn on the schedule. The firewall is the last difference. The GitHub firewall page says that it applies only to processes that the agent starts with its Bash tool, not to MCP servers. So the MCP path needs no change. On the script path, the request starts from Bash, and you must add api.everyinfra.com to the custom allowlist. The allowlist reference lists the default hosts, and our host is not on it. Two capabilities: app_store/reviews and google_play/reviews The free EveryInfra catalog (GET https://api.everyinfra.com/api/v1/social/catalog, no charge) listed 573 capabilities when we read it. Review triage uses two of them. Two more help during setup. app_store/search finds an App Store app and its numeric ID, and google_play/profile reads the store page of an Android app. You find all four on the App Store data API and Google Play data API pages. The capability pages are App Store reviews, Google Play reviews, App Store search and Google Play app profile. Each page shows the parameters, the response fields and the price from the same catalog. The table below compares the two review capabilities field by field. | Item | app_store/reviews | google_play/reviews | | --- | --- | --- | | App ID | app_id, numeric, for example 426826309 | app_id, package name, for example com.strava | | Region and language | country selects the store country | country does not change the reviews, language does | | Sort | newest or most_helpful | newest or top_rated | | Reviews per call | 30 by default, 500 at most | 40 by default, 200 at most | | Pages | No paging, one call returns all | page_token, valid 24 hours, 200 reviews at most | | Star field | rating (plus rating_scale) | score | | Other fields | id, title, text, author, app_version, helpful_count, posted_at | id, text, author_name, thumbs_up, reply_text, reply_at, app_version, language, url, posted_at | | Price | $0.001389 per call | $0.001389 per call | The price is per call, not per review. An App Store call for 500 reviews costs the same $0.001389 as a call for 30 reviews. So always set limit to the maximum. Google Play paging has a hard depth limit. At 00:23 SGT we asked for 100 Strava reviews and got a next-page token. The second page gave 100 more, and stop_reason was depth_limit, which means the 200-review limit. So the newest 200 reviews are all that this capability returns, in one call or in two pages. Paging only adds one more charge. The practical rule is one call with limit 200 per Google Play listing and one call with limit 500 per App Store listing. The two stores use different field names, so the script maps them first. Stars are rating in one store and score in the other, and only the App Store has a title. Both use posted_at, but the App Store value has a Pacific offset such as -07:00, and Google Play uses UTC. Convert all times to one zone before you count by day, or the boundary of "yesterday" moves by 7 or 8 hours. One real round trip: what the agent sends and what comes back In a Copilot cloud agent session, a call to an MCP tool is a standard MCP tools/call request. At 00:26:38 SGT we sent one in this format directly to the EveryInfra MCP server. The request asked for 20 newest Strava reviews from the US App Store. The reply was one JSON text block of 10,725 characters. It had count 20, and billing showed charged_usd 0.001389. The model in a session sees this full block, with no compression. {"jsonrpc":"2.0","id":2,"method":"tools/call", "params":{"name":"everyinfra_call_api", "arguments":{"platform":"app_store","action":"reviews", "params":{"app_id":"426826309","country":"us","sort":"newest","limit":20}}}} !Screenshot of real EveryInfra API responses in two parts. The top part is the MCP tools/call request and response at 00:26:38 SGT: everyinfra_call_api with platform app_store, action reviews, the Strava ID 426826309 and limit 20. The response shows two reviews with author names masked, and teal boxes mark count 20 and charged_usd 0.001389. The bottom part is a 429 response at 00:22:43. The message says that this key allows 10 calls per minute and to retry in 16 seconds. Teal boxes mark retry_after 16 and Nothing was charged. One MCP round trip and one 429 response, both real. Author names are masked, and balance fields are removed. Captured on November 11, 2026, SGT. Real EveryInfra API responses, 2026-11-11, 00:22 to 00:26 SGT The bottom half of the screenshot shows a rate-limited request. Our test key has its own limit of 10 calls per minute, and other jobs used the same key that night. At 00:22:43 SGT, the Duolingo Google Play request got a 429. The response gave the reason (this key's per-minute limit), retry_after 16 seconds and retryable true. It also said that nothing was charged. We waited 21 seconds and sent the request again. At 00:23:04 SGT it returned 200 reviews. At 00:23:44 SGT the Strava App Store request got another 429, and the retry at 00:24:11 SGT worked. Neither 429 was charged. For a daily automation, 429 handling is simple. Put one retry rule in the prompt: wait retry_after seconds after a 429, and try at most three times. The model can read the response, because the reason, the wait time and the charge status are all in it. The bigger risk is a changed parameter. While it waits, the model may call again with a different limit and pay twice for the same reviews. So the prompt also allows one call per app and store per run. Test 1: how much time does one call cover? To know if one run a day is enough, first look at the time span of one call. We took the posted_at of the newest and the oldest review in each response. The four sets are very different. For Duolingo, 200 Google Play reviews in English cover 4.25 hours, and 500 US App Store reviews cover 37.9 hours. For Strava, 200 Google Play reviews cover 7.6 days, from November 2, 2026, to November 9, 2026. The 450 US App Store reviews cover 123.9 days. The longest span is 700 times the shortest. !Horizontal bar chart on a log scale, ten times per grid line, titled How much time one call covers. Four bars: Duolingo Google Play English, 200 reviews, 4.3 hours. Duolingo App Store US, 500 reviews, 37.9 hours. Strava Google Play English, 200 reviews, 7.6 days. Strava App Store US, 450 reviews, 123.9 days. A teal vertical line marks 24 hours, one run a day. Only the Duolingo Google Play bar is shorter than this line. Source: our live calls, November 11, 2026, 00:22 to 00:29 SGT. | Data set | Call time (SGT) | Reviews | Time covered | New reviews per day | 1 to 3 stars | | --- | --- | --- | --- | --- | --- | | Duolingo · App Store US | 00:22:28 | 500 | 37.9 hours | 316.6 | 105 (21%) | | Duolingo · Google Play English | 00:23:04 | 200 | 4.25 hours | 1,130.6 | 27 (13.5%) | | Strava · Google Play English | 00:23:21 and 00:23:31, two pages | 200 | 7.6 days | 26.3 | 102 (51%) | | Strava · App Store US | 00:24:11 | 450 | 123.9 days | 3.6 | 236 (52.4%) | Two points need a comment. First, the 450 Strava App Store reviews cover four months, from July 7, 2026, to November 8, 2026. For an app with a low volume, one call shows a full quarter. Second, the share of bad reviews goes the other way from the volume. Duolingo, with many reviews, has 13.5% to 21% bad reviews. Strava, with fewer reviews, has more than half. This does not mean that one app is worse. A large app gets many quick five-star ratings, and they dilute the share. In a triage report, look at the count of bad reviews and its change, not at the share alone. Test 2: is one run a day enough? If you divide the limit of one call by the daily volume, you get the share that one daily run catches. The limit is 500 reviews for the App Store and 200 for Google Play, and the share stops at 100%. Three of the four sets reach 100%. Duolingo on the App Store gets about 317 a day, and Strava gets a few to a few dozen. Only Duolingo on Google Play in English gets about 1,131 a day, so one call catches 17.7%. !Horizontal bar chart titled One run a day: what share of new reviews it catches. Duolingo Google Play English 17.7 percent, about 1,130.6 reviews a day, in teal. Duolingo App Store US 100 percent, about 316.6 a day. Strava Google Play English 100 percent, about 26.3 a day. Strava App Store US 100 percent, about 3.6 a day. The subtitle says the limit per call is 500 for the App Store and 200 for Google Play, and new reviews per day equals reviews divided by time covered. The reviews that one run misses do not come back later. Google Play gives the newest 200 reviews and stops there, also with paging. So for an app like Duolingo, the daily report sees a slice of about 4 hours and loses the other 20. The group shares in that slice may still be fair. But a claim such as "this group grew" becomes weak, because the slice may follow a push notification by chance. !Isometric illustration on a dark background. A long conveyor belt carries many small cards with stars. At its end there is only one small basket with a teal rim. When the basket is full, most cards fall off the end of the belt and pile up on the floor. Above the belt hangs a round clock with marks but no numbers. Reviews arrive too fast, and a basket that runs once a day catches only a small part. For a high-volume app, one run a day catches a short slice. The rest falls off the end of the belt. To catch all reviews for Duolingo, you need 6 runs a day, one every 4 hours. A cloud automation made in VS Code runs at most once a day, so there are two paths. The first path is an automation made on the GitHub website with an hourly schedule. Every run starts an agent session, so every run uses AI credits and Actions minutes. The second path splits fetching from analysis. A plain GitHub Actions scheduled workflow runs the fetch script every 4 hours, with no model. It appends the new bad reviews to a file in the repository. The cloud automation runs once each morning and reads only that file. The API fee for this path is 9 calls a day: 6 for Duolingo on Android and 1 for each of the other three listings. That is about $0.375 for 30 days, and the model still starts only one session a day. For apps with medium or low volume, none of this matters. One run a day catches 100% with a large margin. The table below turns the four measured sets into a schedule rule. | Data set | Time covered by one call | Runs a day to catch all | API calls a day | API fee, 30 days | | --- | --- | --- | --- | --- | | Duolingo · Google Play English | 4.25 hours | 6 | 6 | $0.250 | | Duolingo · App Store US | 37.9 hours | 1 | 1 | $0.042 | | Strava · Google Play English | 7.6 days | 1 | 1 | $0.042 | | Strava · App Store US | 123.9 days | 1 | 1 | $0.042 | A simple test finds the right number for your own app. Make one manual call during setup and look at the span between the newest and the oldest review. If the span is more than 24 hours, one run a day is enough. If it is less, divide 24 by the span and round up. Put this test in the automation prompt, so the agent checks it on every run. One big release or one sale can multiply the review volume within a week. Test 3: the newest review is already a day old The second fact that affects a daily run is the delay. We took the call time minus the time of the newest review in each response. The table also shows the repeat calls that we made to check the delay. | Data set | Delay of the newest review | Repeat call (SGT) | Result of the repeat | | --- | --- | --- | --- | | Duolingo · App Store US | 36.9 hours | 00:40:33, 18 minutes later | 500 of 500 the same, 0 new | | Duolingo · Google Play English | 24.3 hours | 00:29:13, 6 minutes later | 177 the same, 23 new | | Strava · App Store US | 44.3 hours | (not compared) | — | | Strava · Google Play English | 24.4 hours | 00:41:50 to 00:42:10, about 19 minutes later | 200 of 200 the same | Both Google Play delays are just over 24 hours. This matches the Play Console help page, which says that new ratings and reviews appear publicly after a delay of about 24 hours. The App Store delay is longer, 36 to 44 hours, and the Apple pages on ratings and reviews give no exact number. The repeat calls show two patterns. On Google Play, 23 of 200 Duolingo reviews were new after six minutes, so the store releases reviews all the time, about one day late. On the App Store, all 500 Duolingo reviews were the same after 18 minutes, so that store updates in batches. Two calls a few minutes apart can give the same list, and this is normal. The delay has three effects on the automation design. First, the report must state the range of posting times that it covers. Do not call it "today's bad reviews", because it shows reviews from two days ago to yesterday. Second, decide "new" by review ID, not by posting time. A review posted 40 hours ago may appear for the first time today. Third, the exact start time does not matter much. A run 30 minutes earlier or later gets almost the same data. Test 4: what groups do the bad reviews fall into? We wrote the group rules as a fixed keyword table in the script. With fixed rules, anyone can run the numbers again, and we can compare the rules with the model later. The rules have an order. Crash and bugs come first (crash, freeze, bug, not working, stuck). Login and account come next (log in, sign in, password, account). Then come payment and subscription (subscription, charge, refund, premium, trial), and then sync and devices (sync, GPS, Garmin, watch, upload). Ads and redesign (update, redesign, changed) come last. When a review matches more than one rule, the first match wins. When it matches no rule, it goes to "other". We fixed these rules at 00:27 SGT, before we looked at the group counts. !Stacked percentage bar chart titled 1 to 3 star reviews by keyword rule. Four bars. Duolingo Google Play English, 27 reviews: other 70 percent, payment 15 percent. Duolingo App Store US, 105 reviews: other 52 percent, payment 26 percent, redesign 10 percent. Strava Google Play English, 102 reviews: other 37 percent, crash 19 percent, payment 14 percent, login 12 percent, sync 11 percent. Strava App Store US, 236 reviews: payment 27 percent, other 26 percent, crash 19 percent, sync 12 percent, login 11 percent. The legend lists crash and bugs, login and account, payment and subscription, sync GPS and devices, ads, redesign and updates, other. | Group | Duolingo · App Store | Duolingo · Google Play | Strava · App Store | Strava · Google Play | | --- | --- | --- | --- | --- | | Crash and bugs | 5 | 0 | 44 | 19 | | Login and account | 1 | 1 | 25 | 12 | | Payment and subscription | 27 | 4 | 63 | 14 | | Sync, GPS and devices | 2 | 0 | 28 | 11 | | Ads | 5 | 2 | 0 | 1 | | Redesign and updates | 10 | 1 | 14 | 7 | | Other | 55 | 19 | 62 | 38 | | Total, 1 to 3 stars | 105 | 27 | 236 | 102 | The two apps have very different bad reviews. For Duolingo, "other" and payment are the largest groups, and crash and login problems are rare. Most "other" reviews are about lesson design, the energy system and the learning method, and keywords do not catch them. For Strava, payment is still the largest group. But crash, sync and login together are larger than payment, which fits an app that connects to watches and records GPS tracks. A report that shows only shares would be nearly empty for Duolingo. Of 27 bad English Android reviews a day, 19 are "other". So the classification step cannot depend on keywords alone. The next test measures how far the keywords go. Test 5: how accurate is the keyword rule? To learn if the keyword rule can work alone, we drew 40 bad reviews from the four sets with a fixed random seed. We read the title and text of each review, gave it a group, and compared that group with the rule. The rule was right 23 times and wrong 13 times. It missed 4 reviews: the rule said "other" and we found a real group. With only 40 reviews, this ratio gives only the order of size. The rule is right a little more than half of the time. !Horizontal bar chart titled Is the keyword rule right? 40 random 1 to 3 star reviews checked by hand. Rule right: 23 reviews, 23 of 40, in teal. Rule wrong: 13 reviews. Rule missed and said other: 4 reviews. The subtitle says the author read each title and text, gave a group, and compared it with the first rule match. The sample is small and shows only the order of size. The 13 wrong reviews follow a pattern. The word "account" causes most errors. One user writes that they paid for a full year but cannot use it, and the text contains "account". The login rule comes first, so the rule says login, but the problem is payment. Complaints about support, or about a missing workout type, also go to login because of the word "account". The second pattern is "super". Duolingo calls its paid plan Super, so the rule treats "super" as a payment word, and "super annoying" goes to payment. The third pattern is the Strava Android data problem. A review such as "it used 4GB of mobile data in a few hours after the update" contains GB and a number. The payment rule catches it as a money amount, but the problem is a bug. The 4 missed reviews use no keyword at all. Examples are "heart rate does not show", "no full screen on iPad mini" and "auto-pause is terrible". A person sees the group at once. A keyword list does not. These errors show where the model belongs. Keyword rules are a good first filter: they are cheap, anyone can run them again, and they catch the obvious payment and crash reviews. The final group must come from a model that reads the text. Public research gives numbers to compare. A May 2025 paper used ChatGPT zero-shot on 1,880 labeled app reviews in four requirement groups and reports an F1 of 0.842. An October 2025 paper tested five lightweight open models on user feedback and reports F1 values from 0.47 to 0.68. A July 2025 paper on hybrid routing sends easy feedback to small fine-tuned models and hard feedback to a large model. It keeps 98.4% to 100.4% of the zero-shot accuracy of the large model alone. A value above 100% means that the mix was slightly better. It also cuts requests by 67.8% and token cost by 66.3%. These papers use other groups than ours, so do not copy their numbers. But the direction is the same: a cheap layer first, and a large model for the hard cases. Our keyword rule takes the place of the small model in that paper. Test 6: the Strava Android data bug, and how much earlier a daily run sees it The real value of a triage report is to show when one group suddenly grows. The Strava Google Play reviews gave us a real example. Of 200 reviews, 23 say that the app uses a lot of mobile data, for example 3GB for two hikes. Of those 23, 21 have one star. In the 450 Strava App Store reviews from the same period, no review mentions data use. The problem shows only on Android. !Line chart titled Strava Android reviews about mobile data use, falling day by day. The x-axis runs from November 2 to November 9. Two lines. Reviews per day: 33, 21, 21, 26, 26, 31, 22, 20. Reviews that mention mobile data: 10, 3, 3, 3, 0, 2, 1, 1. The subtitle says the data is 200 Google Play English reviews counted by posting day in UTC, and 0 of 450 App Store reviews from the same time mention it. By posting day, November 2, 2026 had 10 of these reviews. After that, each day had 0 to 3, and the count fell day by day. By app version, 17 of the 23 came from version 487.11 and 4 from version 488.11. Version 487.11 had 86 reviews in the set, so about 20% mention data. Version 488.11 had 68 reviews, and about 6% mention data. One review says that the problem started on October 22, 2026, and had no fix after two weeks. A Reddit thread in r/Strava describes the same jump in Android data use. In that thread, one user repeats advice from support to turn off mobile data first. We found no public statement from Strava about this problem. So we describe only what the reviews show, and we do not guess the cause. Now imagine a team that ran a daily triage from late October. The keyword rule would put the problem in "payment" or "other", as the last section showed. The model reads the text and puts it in the bug group. Ten reviews with the same complaint on one day mark it as a spike, and the automation opens an issue. A weekly report sees the problem several days later at best, and this is the main difference from our weekly Codex Cloud review report. Filter with a script first: why the agent should not read raw MCP output First, count the tokens. In the four raw responses, one review is 437 to 569 bytes on average. The OpenAI help page on tokens gives about 4 characters per token in English. So one review is about 109 to 142 tokens. The MCP round trip at 00:26:38 SGT fits this estimate, with about 536 characters per review. Now take one call a day for each of the four listings. For Duolingo on the App Store we count about 317 new reviews a day, and for the others we count the reviews of that day. If the model reads the raw MCP output, about 65,062 tokens a day enter the context. If a script removes seen IDs, keeps 1 to 3 stars and keeps only title and text, about 4,999 tokens a day remain. The difference is about 13 times. !Horizontal bar chart on a log scale titled Daily cost to let a model read the data, data part only. Five bars. MCP output into context with Sonnet 5.5: 0.1301 dollars a day. Script keeps 1 to 3 stars with Sonnet 5.5: 0.0100 dollars a day. MCP output into context with Haiku 5.5: 0.0065 dollars a day. Script keeps 1 to 3 stars with Haiku 5.5: 0.0005 dollars a day. EveryInfra API fee for 4 calls: 0.0056 dollars a day. The subtitle says about 4 characters per token, model prices from the GitHub Copilot price list, and session overhead is extra. The GitHub models and pricing page lists input prices per million tokens. Claude Sonnet 5.5 is $2, Claude Haiku 5.5 and GPT-6 Luna are $0.10, and Claude Opus 5.5 is $4. For the data part only, Sonnet 5.5 costs $0.1301 a day on raw output and $0.0100 a day on filtered output. Haiku 5.5 costs $0.0065 a day on raw output and $0.0005 a day on filtered output. These numbers include only the data that enters the context, not the prompt, the repository files, the report or the issue. We did not run a real session, so we have no measured number for that part. The data part already shows the direction. With filtering, even a strong model is cheap, and without it the same money buys only a small model. A script first has two more advantages. Code does the dedupe, not the memory of the model. Test 3 showed why: a review can appear for the first time long after its posting time. Also, author names and avatar links leave before the data enters the context. So the report and the issues cannot show the names of ordinary users by accident. Below is a minimal fetch script for the repository, and the agent runs it with Bash on each run. We ran it once with our test key at 00:41:50 SGT. It made one call per store, and the charge was $0.002778. It marked all 600 reviews as seen. It wrote 311 reviews with 1 to 3 stars to the file of the day. """Fetch new App Store / Google Play reviews, drop seen ones, keep 1-3 stars for the model.""" import json, os, pathlib, urllib.request, datetime API = "https://api.everyinfra.com/api/v1/social" KEY = os.environ["EVERYINFRA_API_KEY"] # Agents secret, no COPILOT_MCP_ prefix APPS = [ ("app_store", "426826309", {"country": "us", "sort": "newest", "limit": 500}), ("google_play", "com.strava", {"country": "us", "language": "en", "sort": "newest", "limit": 200}), ] STATE = pathlib.Path(".triage/seen.json") def call(platform, app_id, params): body = {"platform": platform, "action": "reviews", "params": {"app_id": app_id, **params}} req = urllib.request.Request(API, data=json.dumps(body).encode(), method="POST", headers={ "Authorization": f"Bearer {KEY}", "Content-Type": "application/json", "User-Agent": "review-triage/1.0"}) with urllib.request.urlopen(req, timeout=120) as r: return json.load(r) seen = set(json.loads(STATE.read_text())) if STATE.exists() else set() out, spent = [], 0.0 for platform, app_id, params in APPS: data = call(platform, app_id, params) spent += data.get("billing", {}).get("charged_usd", 0) for r in data.get("results", []): key = f"{platform}:{r['id']}" stars = r.get("rating", r.get("score")) if key in seen: continue seen.add(key) # mark as seen if stars is not None and stars <= 3: out.append({"key": key, "stars": stars, "version": r.get("app_version"), "posted_at": r["posted_at"], "text": ((r.get("title") or "") + " | " + (r.get("text") or ""))[:600]}) day = datetime.date.today().isoformat() pathlib.Path("reports").mkdir(exist_ok=True) pathlib.Path(f"reports/{day}.new-low-star.json").write_text(json.dumps(out, ensure_ascii=False, indent=1)) STATE.parent.mkdir(exist_ok=True) STATE.write_text(json.dumps(sorted(seen))) print(json.dumps({"new_low_star": len(out), "seen_total": len(seen), "charged_usd": round(spent, 6)})) The last line prints three numbers: the new bad reviews of this run, the total of seen reviews and the API fee of this run. The agent sees them in the session and can put them at the top of the report. Commit .triage/seen.json back to the repository. Each run starts in a new cloud environment, so without the file the script treats every review as new. The first run also treats all old reviews as new. Use the first report as a baseline only, with no spike alerts. How to write the automation prompt The automation prompt is text for the agent. You type it in the Automations tab in VS Code when you create the automation. A precise prompt gives more stable results and uses fewer credits, because the model does not have to plan the task again each day. The block below is a config example, and we did not save this automation on GitHub. We suggest that you put the group rules and the report format in a skill under .github/skills/review-triage/. The GitHub page on agent skills says that the cloud agent reads project skills from .github/skills, .claude/skills or .agents/skills. The VS Code video on agent skills shows the same layout. Each skill folder has one SKILL.md, with optional scripts beside it. Daily app store bad-review triage (config example) 1. Run `python3 scripts/triage.py`. It fetches new App Store and Google Play reviews, writes reports/<date>.new-low-star.json, and prints new_low_star, seen_total, charged_usd. Call each store listing once per run. On 429, wait retry_after seconds, at most 3 times. 2. Read the JSON. Put each bad review into one group from .github/skills/review-triage/SKILL.md: crash and bugs, payment and subscription, login and account, sync and devices, ads, redesign and updates, other. Decide from the full text, not from one keyword. 3. Write reports/<date>.md: the posting-time range covered, the count per group, the 7-report average per group, up to 3 review texts per group (remove names), and the API fee of this run. 4. If a group is more than 3 times its 7-day average and has at least 5 reviews, open an issue titled "[Review spike] group + app version" with the examples. If an open issue with that title exists, add a comment to it. 5. Commit reports/ and .triage/seen.json to the triage-reports branch and open a PR. Do not push to main. The threshold in item 4 (3 times the average, at least 5 reviews) is only a starting point, so tune it to your review volume. Item 5 is about safety. The GitHub page on cloud agent risks says that the agent works on copilot/ branches and delivers through pull requests. Review text comes from outside users and can contain text such as "ignore the instructions above". A pull request puts a human check between the agent and the main branch. What the report and the issue look like A person should read the first screen of the report in 10 seconds. The sample below uses the real Strava data from 00:22 to 00:24 SGT. We laid it out by hand, in the format of the prompt above. The group counts come from the keyword rule and had no model check, so the sample shows only the format. # Bad-review report 2026-11-11 (Strava) Covered: Google Play English 2026-11-02 to 11-09 (UTC), App Store US 2026-07-07 to 11-08 New 1-3 star reviews: Google Play 102, App Store 236 (first run, baseline only) API fee of this run: $0.002778 (2 calls) | Group | Google Play | App Store | |---|---|---| | Crash and bugs | 19 | 44 | | Payment and subscription | 14 | 63 | | Login and account | 12 | 25 | | Sync and devices | 11 | 28 | To check: 23 Google Play reviews say the app used a lot of mobile data after an update, mostly on 487.11. App Store: 0. The automation opens an issue only when a group clearly grows. The issue is shorter than the report. It has the group, the app version, the count and the past average, three review texts and a link to the report file. Both the GitHub issues REST API and the built-in GitHub tools of the cloud agent can open issues. In an automation, let the agent use its built-in tools. It does not need another GitHub token. The cost: API fee, AI credits and Actions minutes We used the GitHub billing pages as of November 11, 2026, for the Copilot side. Copilot usage is now counted in AI credits, and 1 credit is $0.01. The plans page and the usage-based billing page give the monthly credits below. | Plan | Price | AI credits included each month | | --- | --- | --- | | Pro | $10 a month | 1,500 | | Pro+ | $39 a month | 7,000 | | Max | $100 a month | 20,000 | | Business | $19 per user a month | 1,900 per user | | Enterprise | $39 per user a month | 3,900 per user | The cloud agent gets a 10% discount. Each session uses credits by model tokens and minutes under the GitHub Actions billing rules. The runner price list gives $0.006 a minute for a 2-core Linux runner. You can set credit limits per run, day, week and month, with 30 credits as the lowest limit per run. The daily count resets at 00:00 UTC. | One run a day, 30 days | Amount | How we got it | | --- | --- | --- | | EveryInfra API fee, two apps, 4 listings | $0.1667 | 4 calls a day × $0.001389 × 30 | | Same, Duolingo Android every 4 hours | $0.375 | 9 calls a day × $0.001389 × 30 | | Model reads data, Sonnet 5.5, script filter | $0.30 | about 4,999 tokens a day × $2 per million × 30 | | Model reads data, Sonnet 5.5, raw MCP output | $3.90 | about 65,062 tokens a day × $2 per million × 30 | | Actions minutes (10 minutes a run assumed, after included minutes) | $1.80 | 10 minutes × $0.006 × 30 | | Rest of the session (prompt, report, issue) | Not measured | We ran no real session, so we give no estimate | The API fee is the smallest part of the job, under $0.40 a month even with 9 calls a day. The script filter changes the model cost of reading data by about 13 times. The Actions cost depends on session length, and our 10 minutes is an assumption. Actions minutes are free until the account uses the minutes in its plan. Public pages cannot give the session overhead. So set a low credit limit per run for the first week, then read the GitHub usage page. Why not use the stores' own APIs? Both stores have APIs for developers, but each reads only your own apps. Apple's App Store Connect API has an endpoint that lists all customer reviews of an app. It needs an API key from your developer account, and it reads only apps of your own team. The Google Play Developer API has reviews.list. The Reply to reviews page says that it returns only reviews from the last week, only for production apps and only reviews with text. The read quota is 200 calls an hour, and a reply has a limit of 350 characters. The Python reference for the reviews resource shows the same methods. For a team that watches only its own app, these two APIs are the first choice. They

GitHub's new PR overview puts the merge answer first I merged three pull requests today. A data table post, a retitle, and another retitle, all on the portfolio repo. Every one of them followed the same little ritual. Open the PR, scroll past the description, scroll past the comments, keep scrolling, and somewhere near the bottom, find the merge box and check whether it is green. I do that over and over across four repos, and it always felt backwards, like checking whether the front door is locked by walking to the back of the house first. GitHub shipped a redesigned Overview page on November 5, as an opt-in public preview, and it moves the answer to the top. The merge box is now a compact readiness summary pinned near the top of the PR, showing merge status, checks, comments, approvals, and what to do next, all in under half the space the old merge box took. You can read the full announcement in the changelog. Rollout is continuing through the weekend, so some accounts may not see the option right away. !GitHub screenshot of the new pull request Overview page, with the merge readiness summary, checks, comments, approvals, and recent activity at the top !GitHub screenshot comparing the classic merge box with the compact readiness summary what else moved The summary is the headline, but the conversation got tools too. You can filter comments to All, Unresolved, or Mine, so you can jump straight to the open questions or your own feedback instead of re-reading the whole thread. You can sort newest first instead of only chronological, which is the order I actually want when I come back to a PR I already read. There is an activity summary in the upper right for review comments, review requests, and other updates. And marking a draft ready for review or closing a PR moved into the page header, with the same permissions as before. !GitHub screenshot of pull request comments with All, Unresolved, and Mine filters, newest-first sorting, and a summary of recent activity what did not change Nothing under the hood. Branch protection rules, required status checks, required reviewers, merge queues, and the PR API and webhooks all behave exactly as before. This is a layout change, not a merge-rules change, which is why I am comfortable turning it on. The worst case is I do not like the layout, and I switch back to classic from the same menu, because the preview lets you go back at any time. part of a longer redesign The Overview page is the next piece of a PR redesign GitHub has been working through all year. In March a new pulls dashboard entered public preview with an inbox and saved views, and by April it moved to opt-out. The Overview page is the same idea applied to the single PR view. GitHub calls this preview a starting point, not the finished experience, and they are collecting feedback in Community Discussion #212186. The test for me is simple. The next time I open a long PR, do I know whether it can merge before I scroll? If the answer is yes, the redesign did its job. If I still catch myself scrolling to double-check, I will switch back to classic and say so in the feedback thread, because GitHub asked for exactly that kind of answer. --- _Originally posted on nayemalam.com._

GitHub's PR overview page shows gate state, not coverage GitHub began rolling out an opt-in Overview page for pull requests on 5 November 2026, and the design decision behind it is worth reading closely. The page moves the merge box to the top and rebuilds it to carry the same information in less than half the space, so the first thing you see on a pull request is whether it can merge and what to do next. On a repository where agents open most of the pull requests, that summary is accurate about the gate and silent about whether anyone read the change. The changelog states the goal plainly: finding what is blocking progress and working out what to do next, because time spent scrolling adds up as people review more pull requests. That is a fair description of the problem. The question worth asking is what a compact readiness summary can assert, and which of its assertions change meaning once the author is a bot and the approver is one too. What the overview page compresses Three things move to the top of the page. A compact view of checks, comments and approvals keeps the supporting signals nearby. The actions available to move the pull request forward sit next to it, and updating your branch is the example GitHub gives. Merge readiness and the merge control come last, in the same panel. The second part of the preview is aimed at the conversation rather than the gate. Comments can be filtered to All, Unresolved or Mine, sorted newest first, and a summary in the upper right shows recent review comments and review requests, with controls to mark a draft ready for review or close the pull request. GitHub describes the preview as a starting point and collects feedback in the pinned community discussion, and the classic overview stays available from the same menu. Read the list of signals and notice what they have in common. Checks, approvals and merge conflicts are all machine-computed states. They are the right things to compress, because they are cheap to read and unambiguous when they are correct. The ambiguity sits one layer down, in how each state got there. A skipped job reports success GitHub's own status checks reference says it outright: a job that is skipped reports its status as success and will not prevent a pull request from merging, even if it is a required check. That is how required checks work rather than a quirk of one reviewer, and it means the readiness summary can show a green from a check whose work never happened. For a human-written pull request that rarely matters, because the human skipped it and knows why. On an agent-heavy repository it matters more. A review job skipped for a path filter, a size limit, a draft state or an author exemption reports the same green as a review job that read the diff. The summary at the top of the page does not distinguish them, and that summary is now the first thing a reviewer reads, above the diff and above the conversation where the reason is written down. This is the same failure mode I looked at across providers in what a merge gate sees when the AI review never ran, where CodeRabbit documents that its Skipped and Rate limited states both count as passing for a required check. GitHub's documentation says the equivalent thing about any skipped job. Putting the result at the top of the page makes it more legible without making it more informative. The action the summary offers can discard the approvals it counts There is a sharper interaction between two documented behaviours. The overview page lists updating your branch as an action to take when something is blocking. Separately, GitHub's branch protection documentation says that with stale approval dismissal enabled, an approving review is dismissed when the diff changes, and it names clicking Update branch as one of the ways the diff changes. So the readiness summary can present two true statements in sequence. The approval count is met, and here is the button to bring the branch up to date. Pressing it can reset the first one, and a follow-up push from an agent does the same thing without anyone pressing anything. GitHub documents a narrower alternative on the same page: requiring that the most recent reviewable push be approved by someone other than the person who pushed it. That setting avoids dismissing every stale approval on a long-running pull request, which is exactly the shape agents produce when a follow-up commit lands after the approval. None of this is a defect in the overview page. It is what happens when a summary of gate state is presented as the answer to whether a change can merge, because gate state is a snapshot and the actions in the same panel are what move it. What each reviewer's state looks like in that panel The summary reads whatever your checks and reviews report, so the useful question is what each tool posts and whether that artifact has a state which passes without work. | Tool | What it posts | Distinct state for "did not run" | Approval default | | - | - | - | - | | GitHub Copilot code review | A review with High, Medium or Low severity labels on each comment | Not documented as a separate check state | Comment review, which does not count toward required approvals until the repository enables approving reviews and counting them | | CodeRabbit | A check run on GitHub when review progress is on, a commit status otherwise | Yes on GitHub, Skipped and Neutral; GitLab, Azure DevOps and Bitbucket have no skipped or neutral state | Request-changes workflow off by default | | Kodus | Emoji reactions on the pull request, with the status posted as a comment where reactions are unavailable | No check to require, so nothing to pass; the skipped state is a reaction | Non-blocking by default, auto-approve optional | Copilot's usage documentation states that its reviews default to a Comment review and do not count toward required approvals, and that approving reviews are off until a repository enables them and lets them count. There is a second detail worth knowing on a bot-authored pull request: when Copilot re-reviews, it may repeat comments you already resolved or downvoted. The unresolved filter on the new page will surface those again, which is honest, and it also means an unresolved count is a count of open questions rather than a measure of what was read. Kodus goes the other way and gives up the check entirely. Its review flow documentation reports status as reactions, a rocket while working and a party emoji on completion, with eyes for a skipped run and a thumbs-down when the author has no license. Native reactions work on GitHub, GitLab and Forgejo, and on Azure DevOps and Bitbucket the status arrives as a comment instead. The consequence is that a Kodus review cannot be a required check, so it never contributes a green to the readiness summary, and it also cannot contribute a false one. Its review policy starts from non-blocking suggestions and recommends turning on blocking behaviour only after the team has agreed thresholds and has CI it trusts. Those are different trades rather than better and worse. If you want the reviewer inside the merge gate, Copilot and CodeRabbit can be there and Kodus cannot. If you want a review that cannot be mistaken for a gate, Kodus is the one of the three that is structurally unable to be one. The approval toggles and path globs that decide whether a bot approval clears branch protection are a separate setting from anything the summary shows. What to add to your gate The readiness summary is a gate-state view. Treating it as a coverage view is the mistake, and it is cheap to correct. List your required checks and, for each one, ask whether it has a passing state that requires no work to reach. If it does, the summary can be green over an unread change, and no amount of compactness at the top of the page will tell you. Any check that fits that description needs a companion assertion. Make coverage its own check. Instead of trusting the reviewer's check to mean the reviewer ran, add a check that fails when the review artifact is absent from the pull request. Presence is the thing to assert, because a skipped job reports success, so a pass or fail signal from the reviewer's own check cannot answer the question. A coverage check that reads the artifact directly can. Decide the stale approval question on purpose. The Update branch action sits next to the approval count, so whether updating the branch should clear the approvals is a decision you want made in the repository settings rather than discovered during a merge. The last-reviewable-push option is the narrower setting for long-running pull requests. Read the unresolved count as a question count. It tells you how much conversation is still open, which is useful, and it says nothing about how much of the diff a machine or a person actually examined. That distinction is the one the compact panel cannot carry, and on a repository where agents write most of the code, it is the one worth keeping in a separate check.

Scheduled actions on #GitHub simply do not fire at all it seems? Once it ran 8 hours after it was scheduled, and then the next 2 days not at all. It's a very old problem, but the comments stopped in February. Did it work between February and a few days ago? community#185081

We know Microsoft and Anthropic set up their AI in a way that it could access private GitHub repos in July (leaking their content through other, public repo Issues). GitHubs official statement is "All public code was used in training. We don't distinguish by license type"

Yes, but sites are super slow to enable it. * gitlab.com * community#138164

AIレビューが当たり前になってるこの時代において、未だにこの問題が残り続けてるの終わってる。 GitHubアカウントごとに有効なCopilotライセンスは1つのみなので、複数組織に所属している人がCopilotの請求を分けたい場合には複数アカウント作るしかないって話。 community#56234

They seem to be having an issue with release downloads (community#212407). Our CI is broken at the moment, unable to download tools used in various checks (gitleaks, etc).