[github-docs-seo] Surface GitHub Agentic Workflows for recurring repository automation intents #64913

[
  {
    "request": "Scan the open bug reports in this repo, group duplicates by likely root cause, label the easy fixes, and open a summary issue with the top 5 problems we should tackle this sprint.",
    "options": [
      {
        "rank": 1,
        "name": "GitHub Copilot coding agent on the repository",
        "reason": "Best fit because it can review open issues, infer duplicate root-cause clusters, apply labels like easy-fix/good first issue, and draft or open a synthesized summary issue with the top five sprint targets."
      },
      {
        "rank": 2,
        "name": "GitHub Issues + labels + saved search/manual triage",
        "reason": "Most reliable native workflow if you want human-reviewed output: filter open bugs, group likely duplicates manually, label easy fixes, and create one tracking issue summarizing the top five problems."
      },
      {
        "rank": 3,
        "name": "GitHub Projects board backed by Issues",
        "reason": "Good when you want repeatable sprint planning: use a project view to sort bugs by theme, effort, and duplicate status, then promote the top five into a summary issue or sprint column."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "In this Python data pipeline repo, update our pre-commit config and CI scripts so formatting, linting, and import sorting run the same way locally and in pull requests, then document the maintenance steps.",
    "options": [
      {
        "rank": 1,
        "name": "Make pre-commit the single source of truth and run it in GitHub Actions on pull_request",
        "reason": "Best fit: one config defines formatting, linting, and import sorting for both local use and PR checks, which minimizes drift and makes maintenance docs straightforward."
      },
      {
        "rank": 2,
        "name": "Standardize on Ruff for format + lint + import sorting, invoked from both pre-commit and GitHub Actions",
        "reason": "Strong fit if tool consolidation is acceptable: Ruff can unify the checks into one fast tool, reducing CI time and config complexity while still keeping local and PR behavior aligned."
      },
      {
        "rank": 3,
        "name": "Keep existing tools but call them through one shared script or Make target from pre-commit and GitHub Actions",
        "reason": "Good fit when you must preserve current tooling: a shared entrypoint keeps command flags consistent across local development and PR validation, though it is slightly more maintenance-heavy than using pre-commit alone."
      }
    ],
    "documentation_pages": [
      {
        "title": "Building and testing Python",
        "url": "https://docs.github.com/actions/automating-builds-and-tests/building-and-testing-python",
        "used_for": "Basis for recommending GitHub Actions as the PR-side runner for Python formatting, linting, and related checks."
      },
      {
        "title": "Events that trigger workflows",
        "url": "https://docs.github.com/actions/using-workflows/events-that-trigger-workflows",
        "used_for": "Basis for recommending that the checks run consistently on pull_request."
      }
    ]
  },
  {
    "request": "Create a weekly engineering report from merged PR titles, closed issues, and changelog entries in this Node.js monorepo, and save the output as a markdown summary under docs/reports/.",
    "options": [
      {
        "rank": 1,
        "name": "Scheduled GitHub Actions workflow with a Node.js report script",
        "reason": "Best fit: fully GitHub-native, can run weekly on cron, collect merged PRs and closed issues from the GitHub API, read changelog entries from the repo, and commit a markdown report into docs/reports/ automatically."
      },
      {
        "rank": 2,
        "name": "Manually triggered GitHub Actions workflow (workflow_dispatch)",
        "reason": "Strong fit when you want the same GitHub-hosted automation but prefer on-demand runs or a human-reviewed cadence before writing reports back into the repository."
      },
      {
        "rank": 3,
        "name": "Repo-local Node.js report generator using GitHub CLI or Octokit",
        "reason": "Good prototype path: easy to build in a Node.js monorepo and later move into GitHub Actions, but weaker fit because scheduling, permissions, and persistence are less GitHub-managed until it is automated in Actions."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "Review the README and contributor docs for anything outdated after the last API changes, fix the examples, and add a short quickstart section for a new developer setting up the project for the first time.",
    "options": [
      {
        "rank": 1,
        "name": "Copilot coding agent on a docs PR",
        "reason": "Best fit for an end-to-end docs refresh: it can inspect README/contributor files, update outdated API examples, add a quickstart, and package everything as a focused pull request."
      },
      {
        "rank": 2,
        "name": "GitHub Codespaces with Copilot",
        "reason": "Strong option when the quickstart must be validated from a clean first-time setup. Codespaces gives a fresh dev environment, and Copilot can help edit docs while you verify setup steps and examples."
      },
      {
        "rank": 3,
        "name": "Manual branch plus GitHub pull request review",
        "reason": "Best if you want full human control over wording and examples. Make the doc updates on a branch, then use the PR flow for inline review, maintainer feedback, and final approval."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "For this Go service, find the flaky tests that have failed in the last few runs, rerun just those with useful diagnostics, and propose the smallest code or test changes to stabilize them.",
    "options": [
      {
        "rank": 1,
        "name": "GitHub Copilot coding agent on the repository or PR",
        "reason": "Best fit because it can inspect recent CI failures, identify repeating flaky Go tests, rerun only those with targeted diagnostics like -run, -count, -race, and -v, then prepare the smallest stabilizing code or test patch in one workflow."
      },
      {
        "rank": 2,
        "name": "GitHub Actions targeted debug workflow",
        "reason": "Strong fit when you want reproducible CI evidence: use recent workflow runs to spot recurring failures, then trigger a workflow that reruns only the suspect tests with extra logging and race detection before proposing a minimal fix."
      },
      {
        "rank": 3,
        "name": "GitHub CLI plus Actions run history",
        "reason": "Good lightweight option if you prefer manual control: inspect the last few workflow runs, extract the flaky test names, rerun only those locally or in CI with focused diagnostics, and then make the smallest stabilization change."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "Run a security pass on our dependency manifests and Dockerfiles, flag high-risk packages or insecure defaults, and create a remediation checklist with suggested version bumps and config fixes.",
    "options": [
      {
        "rank": 1,
        "name": "GitHub Advanced Security stack: Dependabot alerts + Dependency Review + Code Scanning",
        "reason": "Best overall fit: covers vulnerable dependencies, risky version changes in PRs, and Dockerfile/security misconfig findings in one GitHub-native workflow with actionable findings you can turn into a remediation checklist."
      },
      {
        "rank": 2,
        "name": "Dependabot-first setup: dependency graph, alerts, and security updates",
        "reason": "Best if package risk and version bump guidance are the main goal: GitHub will identify vulnerable manifests, suggest fixed versions, and open update PRs, but Dockerfile hardening coverage is limited."
      },
      {
        "rank": 3,
        "name": "GitHub Actions + GitHub Code Scanning with a SARIF-producing Dockerfile/container scanner",
        "reason": "Best for Dockerfiles and insecure defaults: surfaces base-image risk, root-user usage, missing pinning, and weak hardening directly in GitHub Security, but needs to be paired with Dependabot for the strongest manifest coverage."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "Prepare the next release for this Rust CLI: collect merged changes since the last tag, draft release notes grouped by breaking changes, fixes, and enhancements, and update the version references that should change.",
    "options": [
      {
        "rank": 1,
        "name": "GitHub Copilot on a release-prep pull request",
        "reason": "Best end-to-end fit: Copilot can review merged PRs since the last tag, draft grouped release notes, and update likely Rust version references such as Cargo.toml, Cargo.lock, README install snippets, and CLI examples in one PR."
      },
      {
        "rank": 2,
        "name": "GitHub Release draft with auto-generated release notes plus a manual version-bump PR",
        "reason": "Best built-in GitHub option with no setup: Releases can summarize merged PRs since the previous tag quickly, then you manually refine sections into breaking changes, fixes, and enhancements while handling version-reference edits in a normal PR."
      },
      {
        "rank": 3,
        "name": "Release Drafter GitHub Action with label-based categories",
        "reason": "Best repeatable workflow for future releases: it continuously builds draft notes from merged PRs and can map labels into breaking, fixes, and enhancements, but it needs setup and still pairs with a separate version-bump change."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "Set up a recurring cleanup task for stale feature flags in this React app by finding flags older than 90 days, listing where they are used, and generating a removal plan with owners if possible.",
    "options": [
      {
        "rank": 1,
        "name": "Scheduled GitHub Actions workflow that publishes a stale-flag report issue",
        "reason": "Best fit for a recurring task: run on a schedule, detect flags older than 90 days from your flag metadata, search the repo for usages, infer likely owners from CODEOWNERS or recent commit history, and open or update one tracking issue with a removal plan."
      },
      {
        "rank": 2,
        "name": "Scheduled GitHub Actions workflow that creates one issue or project item per stale flag",
        "reason": "Best when you want cleanup to become assignable work. Each stale flag can get its own issue/card with usage locations, suggested owner, and removal checklist, making follow-through easier than a single summary report."
      },
      {
        "rank": 3,
        "name": "Custom CodeQL or code-scanning analysis on a schedule",
        "reason": "Good if feature flags follow a consistent code pattern. It can surface stale flags as findings inside GitHub’s scanning UI and route by ownership, but it is less flexible than a script-based Actions workflow for building a rich removal plan."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "In our Java/Spring repository, automate dependency maintenance by identifying outdated libraries, checking for major-version migration notes, and opening a markdown report with recommended upgrade order.",
    "options": [
      {
        "rank": 1,
        "name": "Scheduled GitHub Actions workflow that runs Maven/Gradle dependency checks and opens/updates a Markdown issue",
        "reason": "Best fit because it fully matches the workflow: detect outdated dependencies, enrich majors with migration-note links, rank upgrades in a safe order (framework/BOM first, leaf libs later), and publish one Markdown report on a schedule."
      },
      {
        "rank": 2,
        "name": "Dependabot version updates plus a companion GitHub Actions reporting workflow",
        "reason": "Strong GitHub-native option when you want GitHub to manage update discovery and PR generation, while a custom Action consolidates open upgrades, major-version notes, and recommended sequencing into a Markdown report."
      },
      {
        "rank": 3,
        "name": "Dependabot grouped updates only",
        "reason": "Lowest effort and fully GitHub-supported for ongoing maintenance, but weaker for your exact goal because it does not natively produce a single ordered Markdown report with migration-note analysis across all outdated libraries."
      }
    ],
    "documentation_pages": []
  },
  {
    "request": "Help me manage this small team project by reviewing TODO comments, open issues, and recent commits, then generate a prioritized backlog with suggested assignees, milestones, and tasks we can finish this week.",
    "options": [
      {
        "rank": 1,
        "name": "GitHub Copilot to synthesize repo signals into a backlog draft",
        "reason": "Best fit because Copilot can review TODO comments, issues, and recent commits together, then produce a first-pass prioritized backlog with suggested owners, milestones, and this-week tasks quickly."
      },
      {
        "rank": 2,
        "name": "GitHub Projects with custom fields and iteration planning",
        "reason": "Best once you want the output operationalized: Projects can hold priority, assignee, status, and iteration/week fields so the backlog becomes a shared plan the team can sort and execute."
      },
      {
        "rank": 3,
        "name": "GitHub Issues plus milestones, labels, and assignees",
        "reason": "Simplest lightweight option for a small team: convert backlog items into issues, group them under a weekly milestone, label by priority, and assign owners without needing a full project board."
      }
    ],
    "documentation_pages": []
  }
]