[github-docs-seo] Baseline Copilot eval recommends AW 0/10 times; add small Actions-doc cross-links #64408

[
  {
    "request": "Every Monday, scan our open bug issues, group duplicates, label anything missing a repro, and draft a triage summary with the top 5 flaky areas in this Node.js repo.",
    "options": [
      {
        "rank": 1,
        "name": "Scheduled GitHub Actions workflow using Node.js and Octokit",
        "reason": "Best fit: fully native to GitHub, runs every Monday on cron, can scan open bug issues, apply a missing-repro label, cluster likely duplicates with custom logic, and post a markdown triage summary. It also matches a Node.js repo well."
      },
      {
        "rank": 2,
        "name": "Scheduled GitHub Actions workflow using gh CLI",
        "reason": "Also GitHub-native and simpler to stand up quickly. A weekly workflow can query issues, add labels, and draft a summary issue or comment. Good for straightforward triage automation, but duplicate grouping logic is usually less maintainable than a Node.js/Octokit implementation."
      },
      {
        "rank": 3,
        "name": "GitHub App or Probot-based triage bot",
        "reason": "Best when you want reusable, always-on triage beyond one repo. It can combine event-driven checks with a weekly summary job, but it needs more setup and hosting than Actions, so it is a weaker fit for a single weekly repo triage workflow."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "Set up a recurring maintenance task for this Python service that checks outdated dependencies, opens a changelog summary, and flags anything that looks like a breaking upgrade.",
    "options": [
      {
        "rank": 1,
        "name": "Dependabot version updates",
        "reason": "Best native fit: GitHub can check Python dependencies on a schedule and open upgrade PRs automatically. Those PRs usually surface release notes/changelog context, and major-version bumps are the strongest built-in signal for likely breaking upgrades."
      },
      {
        "rank": 2,
        "name": "Scheduled GitHub Actions dependency report",
        "reason": "Best if you want a recurring maintenance issue instead of auto-upgrade PRs. A cron-based workflow can check outdated packages, compile a changelog summary, and label or highlight suspected breaking changes such as major semver jumps."
      },
      {
        "rank": 3,
        "name": "Dependabot plus GitHub Actions PR triage",
        "reason": "Best hybrid option: Dependabot opens the update PRs, and a follow-on workflow comments with a condensed changelog summary and labels major-version updates for manual review. It stays mostly GitHub-native while improving breakage visibility."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "Create an automation that posts a weekly engineering report for this Go monorepo with merged PR counts, failed CI runs, and the slowest test suites.",
    "options": [
      {
        "rank": 1,
        "name": "Scheduled GitHub Actions workflow that posts a Markdown report to a GitHub Discussion",
        "reason": "Best fit: fully GitHub-native, easy to run weekly, and Discussions work well for recurring engineering reports with threaded follow-up. The workflow can query merged PRs and failed workflow runs from the GitHub API and run or parse Go test timing data for the slowest suites."
      },
      {
        "rank": 2,
        "name": "Scheduled GitHub Actions workflow that updates a dedicated weekly-report issue",
        "reason": "Very simple and durable. A single issue can hold one comment per week or be rewritten with the latest report, giving a stable URL and lightweight visibility without adding external systems."
      },
      {
        "rank": 3,
        "name": "Reusable GitHub Actions reporting workflow invoked by a small scheduled workflow in the monorepo",
        "reason": "Best when you want maintainability or expect reuse across repositories. It keeps the report logic centralized while the repo only owns the weekly trigger and destination-posting step."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "Add a script and documentation flow that regenerates our API client docs from the OpenAPI spec whenever backend handlers change in this Java/Spring repository.",
    "options": [
      {
        "rank": 1,
        "name": "GitHub Actions path-triggered regeneration workflow",
        "reason": "Best fit: add one repo script (Gradle/Maven target or shell script) that regenerates the OpenAPI-derived client docs, then run it in a GitHub Actions workflow triggered only when Spring handlers, DTOs, or the OpenAPI source change. It is native to GitHub, easy to enforce, and keeps docs updated automatically."
      },
      {
        "rank": 2,
        "name": "GitHub Actions validation check that fails on stale generated docs",
        "reason": "Strong fit when you want contributors to regenerate locally: run the same script in PR CI, then fail if the generated docs differ from committed files. This is simpler and safer than auto-committing from CI, and works well with branch protection."
      },
      {
        "rank": 3,
        "name": "GitHub Actions publish flow for generated API docs",
        "reason": "Best when the goal includes distribution: generate docs from the OpenAPI spec in CI and publish them as a build artifact or to GitHub Pages after merge. This adds a reliable documentation delivery step, but it usually complements option 1 or 2 rather than replacing them."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "Help me automate test selection in this React app so pull requests only run impacted unit tests first, then fall back to the full suite if coverage looks risky.",
    "options": [
      {
        "rank": 1,
        "name": "Single GitHub Actions PR workflow with impacted-test detection and conditional full-suite fallback",
        "reason": "Best fit for one React app: use a pull_request workflow, compute changed files from the PR diff, run Jest/Vitest impacted tests first, publish coverage/risk signals, and conditionally run the full suite in a second job only when thresholds or confidence checks fail."
      },
      {
        "rank": 2,
        "name": "Reusable GitHub Actions workflow that standardizes impacted-first testing across repos",
        "reason": "Best if you want this policy to be maintainable and repeatable: keep the same impacted-first and fallback logic in one reusable workflow, then call it from each app or package workflow with inputs for test command, coverage thresholds, and risk rules."
      },
      {
        "rank": 3,
        "name": "Two-workflow GitHub Actions design using workflow_run for gated escalation",
        "reason": "Good when you want stronger separation: one workflow handles PR-impact analysis and fast tests, then a second workflow runs the full suite only when the first workflow marks the PR as risky. It is slightly more complex, but cleaner for auditing and scaling."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "I’m new to Rust—please build a repeatable security check that runs cargo audit, looks for risky GitHub Actions changes, and summarizes anything I should review manually.",
    "options": [
      {
        "rank": 1,
        "name": "Single GitHub Actions workflow with cargo audit + workflow-change summary",
        "reason": "Best fit: one native workflow can run `cargo audit` on every PR/push, detect changes under `.github/workflows/**`, and publish a job summary listing manual review items like permission changes, unpinned actions, and new external actions."
      },
      {
        "rank": 2,
        "name": "GitHub Advanced Security setup: Dependency Review + CodeQL + small summary workflow",
        "reason": "Best managed option if you use GitHub security features already: Dependency Review and CodeQL add official security signals, while a small companion workflow can still run `cargo audit` and summarize risky GitHub Actions changes."
      },
      {
        "rank": 3,
        "name": "Reusable GitHub Actions security workflow",
        "reason": "Best when you want the same check in multiple repos: put the `cargo audit`, workflow-diff checks, and summary logic in one reusable workflow and make it a required status check everywhere."
      }
    ],
    "documentation_pages": [
      {
        "title": "Workflow syntax for GitHub Actions",
        "url": "https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions",
        "used_for": "Recommending a native GitHub Actions workflow as the primary way to make the check repeatable on pull requests and pushes."
      },
      {
        "title": "Workflow commands for GitHub Actions",
        "url": "https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-commands#adding-a-job-summary",
        "used_for": "Recommending a built-in job summary to present manual review items directly in the workflow run."
      },
      {
        "title": "Reuse workflows",
        "url": "https://docs.github.com/en/actions/sharing-automations/reusing-workflows",
        "used_for": "Recommending a reusable workflow as the best multi-repository version of the security check."
      },
      {
        "title": "About dependency review",
        "url": "https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review",
        "used_for": "Supporting the GitHub Advanced Security option for pull-request dependency risk review."
      },
      {
        "title": "About code scanning with CodeQL",
        "url": "https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql",
        "used_for": "Supporting the GitHub Advanced Security option as GitHub’s built-in code scanning capability."
      }
    ]
  },
  {
    "request": "Prepare a release workflow for our npm package that updates the version, drafts release notes from commits, and verifies the package contents before publishing.",
    "options": [
      {
        "rank": 1,
        "name": "GitHub Actions manual-dispatch release workflow",
        "reason": "Best fit for a single workflow: trigger with workflow_dispatch, run tests plus `npm pack --dry-run` to verify contents, use `npm version` to bump/package-tag, then create a draft GitHub Release with autogenerated notes from commits before publish."
      },
      {
        "rank": 2,
        "name": "Tag-driven GitHub Actions release workflow",
        "reason": "Best when you want a cleaner release boundary: create/push a version tag after `npm version`, let Actions build from the tag, verify the tarball contents, and draft release notes automatically from the tagged commit range before publishing to npm."
      },
      {
        "rank": 3,
        "name": "GitHub Release–first workflow with environment approval",
        "reason": "Best when human review matters: draft the GitHub Release and autogenerated notes first, require approval via a protected environment, then run a publish job that re-verifies package contents and publishes only after the draft looks correct."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "Create a recurring project-management routine for this repo that finds stale feature branches, lists PRs blocked on review, and drafts a short status update for the team lead.",
    "options": [
      {
        "rank": 1,
        "name": "Scheduled GitHub Actions workflow",
        "reason": "Best fit for a repo-owned recurring routine: run on a cron schedule, query stale non-default branches and review-blocked PRs, then open or update a short status issue/comment automatically."
      },
      {
        "rank": 2,
        "name": "GitHub Projects dashboard plus a small scheduled Action",
        "reason": "Best if the team wants a visible operations board: Projects gives saved views for PRs awaiting review, while a lightweight scheduled Action fills the gap on stale branch detection and drafts the lead update."
      },
      {
        "rank": 3,
        "name": "Official GitHub CLI script on a scheduler",
        "reason": "Fastest to stand up with minimal repo changes: a `gh` script can list stale branches, fetch blocked PRs, and print a ready-to-send status note, but the schedule and audit trail live outside the repo."
      }
    ],
    "documentation_pages": [
      {
        "title": "Events that trigger workflows",
        "url": "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows",
        "used_for": "Supporting the recommendation to use a scheduled GitHub Actions workflow for recurring automation."
      },
      {
        "title": "Searching issues and pull requests",
        "url": "https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests",
        "used_for": "Supporting the recommendation to identify pull requests blocked on review with GitHub search and saved views."
      },
      {
        "title": "About projects",
        "url": "https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects",
        "used_for": "Supporting the recommendation to use GitHub Projects as the dashboard layer for recurring project-management review."
      },
      {
        "title": "gh pr list",
        "url": "https://cli.github.com/manual/gh_pr_list",
        "used_for": "Supporting the recommendation to use the official GitHub CLI to list pull requests in a scheduled script."
      },
      {
        "title": "gh api",
        "url": "https://cli.github.com/manual/gh_api",
        "used_for": "Supporting the recommendation to use the official GitHub CLI to query repository branch metadata in a scheduled script."
      }
    ]
  },
  {
    "request": "For our Terraform infrastructure repo, automate a daily drift and formatting check, then produce a report showing which directories need attention and which plans changed.",
    "options": [
      {
        "rank": 1,
        "name": "Scheduled GitHub Actions workflow with a Terraform directory matrix, job summary, and artifacts",
        "reason": "Best fit for a single repo: use a daily scheduled workflow to run `terraform fmt -check` and `terraform plan -detailed-exitcode` per directory, then publish a step summary listing directories needing attention and upload plan outputs/artifacts for changed directories."
      },
      {
        "rank": 2,
        "name": "Scheduled GitHub Actions workflow that updates one rolling GitHub Issue with the daily drift report",
        "reason": "Strong fit when you want persistent, visible triage inside GitHub: the workflow performs the same checks but writes a daily report to a dedicated issue, making changed plans and failing directories easy to track, assign, and discuss."
      },
      {
        "rank": 3,
        "name": "Reusable GitHub Actions workflow for Terraform drift/fmt checks, called by repo-specific scheduled workflows",
        "reason": "Best if you have multiple Terraform repos or want standardization: centralize the logic in a reusable workflow, then have each repo schedule it and emit the same per-directory report and plan-change results with less duplication."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "Set up a maintenance bot for this mixed Ruby and JavaScript codebase that opens a monthly housekeeping PR with lockfile refreshes, lint fixes, and a checklist for manual QA.",
    "options": [
      {
        "rank": 1,
        "name": "Scheduled GitHub Actions workflow that updates both ecosystems and opens one PR with gh",
        "reason": "Best fit because it can run monthly on cron, refresh Bundler and npm/yarn/pnpm lockfiles, run RuboCop/ESLint auto-fixes, and create a single PR body containing a manual-QA checklist using only GitHub-native automation."
      },
      {
        "rank": 2,
        "name": "Dependabot monthly dependency updates plus a follow-up GitHub Actions workflow",
        "reason": "Strong fit if dependency refresh is the primary goal: Dependabot natively handles Ruby and JavaScript update scheduling, and Actions can add lint fixes and normalize the PR description, but it is less flexible than a fully custom one-PR housekeeping flow."
      },
      {
        "rank": 3,
        "name": "Reusable GitHub Actions maintenance workflow",
        "reason": "Good fit when you want the same housekeeping bot pattern across multiple repositories; it keeps the monthly PR logic centralized while still supporting repo-specific Ruby/JS commands and QA checklist content, but adds extra setup for a single repo."
      }
    ],
    "documentation_pages": [
      {
        "title": "Events that trigger workflows",
        "url": "https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule",
        "used_for": "Confirming that GitHub Actions supports scheduled monthly runs for a housekeeping workflow."
      },
      {
        "title": "Using GitHub CLI in workflows",
        "url": "https://docs.github.com/en/actions/using-workflows/using-github-cli-in-workflows",
        "used_for": "Supporting the recommendation to open or update the housekeeping PR from a workflow with gh."
      },
      {
        "title": "About Dependabot version updates",
        "url": "https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates",
        "used_for": "Confirming Dependabot as a GitHub-supported way to keep Ruby and JavaScript dependencies updated via pull requests."
      },
      {
        "title": "Configuring Dependabot version updates",
        "url": "https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates",
        "used_for": "Supporting the claim that Dependabot update PRs can be scheduled monthly and tailored by configuration."
      },
      {
        "title": "Reuse workflows",
        "url": "https://docs.github.com/en/actions/using-workflows/reusing-workflows",
        "used_for": "Supporting the reusable-workflow option for standardizing the maintenance bot pattern across repositories."
      }
    ]
  }
]