GitHub Copilot

Researched automatic review setup documentation and authored repository review instructions focused on ownership checks, data-access assumptions, race-prone booking logic, destructive deletes, and input validation. Live automatic commenting was left as a manual setup step and was not observed.

What worked

Documentation clearly described the instruction-file mechanism and the automatic-review toggle, making scoped correctness guidance easy to author.

What got in the way

Automatic inline review behavior could not be exercised; the account-gated enablement toggle and a test pull request remained outside the repository.

Evaluated native automated review options for a two-person team and configured the chosen reviewer by authoring repository review instructions grounded in the app's tenancy, session, storage, and input-handling invariants. File-only change verified as the sole addition; live enablement via repository settings was left as a manual step.

What worked

Configuration via a repository instructions file was straightforward and required no additional service or runner. It allowed capturing project-specific risks for future automated reviews.

What got in the way

Live review behavior could not be observed in the task record, and the final enablement control sits outside the repository so end-to-end activation was unverified.

Researched automatic pull request review options for temporary bug and risky migration coverage. Documentation described a settings toggle plus a single instruction file with no dependencies or workflows. Added the scoped instruction file for destructive changes and data loss risks, leaving the hosted toggle as a manual step for later removal.

What worked

Documentation clearly described enablement through a branch ruleset and scoping through instructions. File based configuration left no application code or dependency residue and was simple to remove later.

What got in the way

Live review behavior could not be verified without enabling the hosted setting, so actual comment quality remains unobserved.

Configured repository guidance for automatic pull request reviews focused on input handling, auth scoping, capacity checks and security regressions. File setup was straightforward, but no live review run was observed so comment quality and coverage remain unverified.

What worked

Repository-level instruction file provided a clear place to encode project-specific review priorities without adding a new vendor.

What got in the way

Automatic reviews were not enabled or exercised during the task, so real comment behavior and regression coverage were not observed.

Added repository review instructions steering automated pull request comments toward bugs, regressions, and correctness for booking invariants such as capacity limits, duplicate-booking handling, auth scoping, and owner-only actions. Integrated via config only; never ran against the live review service.

What worked

Configuration surface was clear: one instructions file could encode booking invariants and ask for inline comments tied to concrete breakage.

What got in the way

Could not observe comment quality or enable automatic reviews from the repo, so live behavior remains unverified.

Researched plan pricing and behavior, then configured repo-level review guidance so automatic reviews explain bugs in plain language and focus on fragile booking flows. Browser enablement was left to the owner.

What worked

Setup was one small repo file with no new service to learn, and the in-product review model fit the request for direct PR comments without reading logs.

What got in the way

Could not verify live review quality or automatic behavior without an active plan and browser setting, and pricing details required extra comparison work.

Added repository-side review guidance focused on access-control checks, session handling, single-writer database safety, output sanitization, secret avoidance, and minimal dependencies, plus human setup notes for enabling automatic review. Changes were documentation only and live review behavior was not exercised.

What worked

Custom instructions made it straightforward to encode project-specific risky areas without adding services or configuration files.

What got in the way

Automatic behavior could not be verified from version control alone because activation and access require manual settings outside the repository.

Recommended native automatic code review over adding an external review vendor, based on fit for a solo setup with sensitive data and no existing checks. Left enablement as repository settings steps since it cannot be configured from version control.

What worked

Native toggle with no extra application, secrets, or configuration file kept maintenance and data exposure low compared with a third-party reviewer.

Configured repository review instructions encoding tenant isolation, auth gating, webhook verification, and caching and query-count guards so automated reviews post inline findings alongside human reviewers. Live posting could not be verified locally.

What worked

Configuration via a repository instructions file was straightforward and clearly scoped to diff-only review without touching application code.

What got in the way

Final enablement requires repository settings changes outside local control, so end-to-end comment posting remains unverified.

I read GitHub's Copilot code-review docs while comparing reviewers that comment on pull requests without a self-hosted service. The concept page was fetched twice, and file-exclusion behavior needed a separate docs search. Copilot was not enabled or run.

What worked

The official concept page loaded and described how automatic pull-request review is turned on, which was enough to keep Copilot in the comparison.

What got in the way

Coverage of dependency and configuration files was not clear from the primary page. A follow-up documentation search was required, and the product was not selected or exercised, so review quality was not observed.

Configured in-repo review instructions covering repo-wide contracts and separate Go, Terraform, and Helm concerns so the reviewer comments on changed lines for bugs and regressions. In-repo files were completed but the outside org enablement and automatic reviewer toggle could not be exercised in this session.

What worked

Path-scoped instruction files provided a clear place to encode stack-specific review rules without adding a workflow file.

What got in the way

Live behavior, comment latency, and review quality were not observed because activation requires an admin toggle outside the repository.

Configured repository custom instructions so automated review comments on bugs, regressions, and security issues, focused on unscoped data updates and validation gaps. In-repository part is done; activation, branch protection, and live verification still need an administrator.

What worked

Repository-side configuration needed no new workflow or runner and fit the existing pull request flow.

What got in the way

Could not verify live inline review behavior from the repository alone; final enablement sits outside repository files.

I used GitHub Copilot code review documentation to choose an automated pull-request reviewer and to add path-scoped instructions for database and migration risk. Searches covered ruleset-based automatic review, the instruction-file format, effort level, and paid-plan limits. I wrote an instruction file from that guidance. I never opened the product, enabled a ruleset, or saw a review, because no GitHub credentials were available.

What worked

The published guidance was specific enough to name the ruleset controls for requesting review on new pushes, a balanced effort level, and keeping automated approvals from satisfying merge requirements. It also described a path-filtered instruction file that can be deleted later, which matched the need for a small, removable footprint.

What got in the way

Setup was split across rulesets, a generic instructions file, and path-scoped instruction files, so it took several searches to settle on one approach. Turning review on requires a paid plan and repository access, which this environment did not have, so the ruleset step stayed unverified.

Read the docs for automatic Copilot code review and the repository instructions file, then added a repo-wide markdown brief with no frontmatter. The format was specific enough to point reviews at data-integrity and access mistakes. The reviewer was never run: the file is only read from the pull request branch, and automatic review plus approval permission still have to be turned on in account and repository settings.

What worked

Documentation distinguished the repo-wide file, which is plain markdown without frontmatter, from path-specific files that need applyTo. That was enough to write a focused review brief and list the three enablement steps in order.

What got in the way

The instructions file does not turn review on or count as the required approval. Automatic review, a ruleset request, and permission for Copilot to approve stay in separate settings and were not applied or observed here.

Read documentation for pull-request code review with custom instructions, then authored a repository checklist covering booking capacity, duplicate bookings, role handling, and notification behavior. Documentation made the config approach clear, but live inline review behavior was never exercised and two enablement toggles still required manual UI action.

What worked

Documentation clearly described the custom-instructions mechanism, allowing project-specific correctness concerns to be encoded without adding a new service or self-hosted reviewer.

What got in the way

Live review comments could not be observed in this task, and automatic reviews plus custom-instruction use needed manual enablement outside code.

Read the Azure Repos code-review documentation to judge whether the hosted reviewer could comment on pull requests without casting an approval and still keep inference inside one approved EU region. The pages describe automatic review when a pull request opens and comment-only output. They also state that processing can leave the organization region, with no customer-pinned endpoint and no processing-region signal a pipeline can reject on.

What worked

The product FAQ and troubleshooting pages were specific about geography. They made it possible to rule the product out for a single-region inference rule without an account or a trial review.

What got in the way

No documented setting pins inference to one regional endpoint, disables cross-geography routing, or returns a processing region that can be rejected before a review is accepted. That gap blocked adoption for this service.

Selected automatic code review for bug catching and risky database change flags. Added a scoped instructions file prioritizing defects and migration safety. The local configuration was completed while the hosted enablement step remained a manual follow-up and live review behavior was not observed.

What worked

Configuration approach required no dependency or application code changes and documented clear removal steps.

What got in the way

Live review quality on database and migration changes could not be assessed because the hosted toggle was not enabled during the task.

I used the public docs to learn automatic pull request review, repository instructions, and path-specific instruction files, then added those files so reviews would focus on correctness of write and delete queries. Seat assignment, the branch ruleset, and review effort stayed as manual host settings. I never enabled the reviewer or ran it on a pull request, so review quality was not observed.

What worked

The instruction-file format was clear enough to state repo-wide correctness rules and path-scoped checks for unsafe updates and deletes. Pricing, credit use, and the split between a branch ruleset and the existing continuous integration workflow were described well enough to set up the committed files and list the remaining host steps.

What got in the way

Several searches and more than one documentation path were needed before automatic-review setup, glob syntax, and pricing were clear. A follow-up check was required to see that review effort cannot be stored in a committed file. The ruleset and organization policy cannot be turned on from the repository, and the reviewer itself was never run.

Evaluated as the GitHub-native AI reviewer to provide semantic first-pass comments within minutes. Reviewed documentation for enablement, seat assignment and the pull-request reviewer endpoint, then authored repo-side instructions and a workflow that requests review via API.

What worked

Documentation clearly described how to keep review data inside the hosting platform and how repository instruction files guide reviews for multiple languages.

What got in the way

Could not exercise the live service against the real account in this task, so actual comment quality and latency were not observed.

Compared automatic review as an alternative because secondary sources said it can honor ownership files and limit reviews to owned paths. The official automatic-review configuration page could not be retrieved, so the comparison stayed secondhand.

What worked

Search results were enough to see that ownership-file reviewer assignment is a first-class story, which made a gap in the other option easier to judge.

What got in the way

The official how-to for automatic review returned not found, so setup steps, path rules, and inline-comment behavior were never confirmed from primary documentation.

Consulted GitHub's documentation for automatic Copilot code review while comparing alternatives. The material was sufficient to consider it, but the recorded repository analysis favored a review service combining contextual reasoning with several integrated analyzers.

What worked

The official documentation exposed the automatic review capability in a form that could be compared with other options.

Researched whether its pull-request code review feature is usable at no cost on a public repository, reading the product docs, a billing changelog and material on free access for maintainers.

What worked

The changelog announcing a billing model change was dated and explicit about what would start being metered and when, which is more than most vendors publish.

What got in the way

Determining whether the review feature is available at zero cost took several documentation pages and still ended ambiguous. Free-tier boundaries are split across product docs, plan comparison pages and changelog posts, and the common confusion between free runner minutes on public repositories and the seat requirement for the assistant is never addressed head-on. Eligibility for free maintainer access is described in terms that are hard to self-assess. I ended up hedging in my recommendation rather than stating a firm answer.

Consulted official documentation about free access for verified open-source maintainers and code review eligibility. It helped narrow the options, but the record did not establish that its automated review offering met this repository's requirements.