[github-docs-seo] Improve GitHub Docs routing so Copilot recommends AW for repository automation intents
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 65/100
- Tipo de issue
- Documentación
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- github-actions, markdown
- Área
- devtools, documentation
Línea de trabajo
El issue propone actualizar la orientación en GitHub Docs sobre la creación de workflows de GitHub Actions, el uso de Copilot coding agent y la página de inicio y ejemplos de GitHub Agentic Workflows. Empieza por localizar esos puntos de entrada de la documentación y revisar las indicaciones existentes para elegir una opción de automatización. Añade las comparaciones, los enlaces cruzados y las intenciones de ejemplo propuestas. El trabajo estará terminado cuando las páginas dejen claro cuándo elegir Agentic Workflows y presenten los ejemplos de automatización recurrentes indicados.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
- AW recommendation rate: 0/10 (0%).
- Average AW rank when present: N/A — AW did not appear in any of the 30 ranked option slots.
- Strongest opportunity: recurring repo-native automation prompts (triage summaries, weekly reports, hotspot regression checks, stale issue cleanup) were consistently mapped to plain GitHub Actions workflows instead of GitHub Agentic Workflows.
- Conclusion: the smallest likely win is to add high-intent comparison/cross-link language where users choose between GitHub Actions, Copilot coding agent, and other GitHub-native automation approaches so AW is retrievable as the markdown-first path that compiles to Actions.
Baseline Results
All 10 requests and ranked options
| # | Request | Rank 1 | Rank 2 | Rank 3 | AW rank | Source-page count |
|---|---|---|---|---|---|---|
| 1 | Scan last 30 merged PRs; group by label/area; open triage summary issue | GitHub Actions workflow using GraphQL/REST (or gh api) to generate and open the triage issue | GitHub App or Probot automation backed by the GitHub API | Manual GitHub triage using pull request search/filter views, then opening a summary issue | Absent | 0 |
| 2 | Node.js monorepo dependency patch/minor upgrade with tests and one commit | GitHub Copilot coding agent on the repository | Custom GitHub Actions workflow for dependency maintenance | Dependabot version updates with grouped updates and CI | Absent | 0 |
| 3 | Weekly engineering report from git history since last Monday | Scheduled GitHub Actions report workflow | One-off GitHub CLI report script | GitHub PR metadata plus Insights/Pulse review | Absent | 0 |
| 4 | Fix Python README/onboarding docs and add uv + pytest quickstart | GitHub Copilot coding agent on the repository | GitHub Codespaces with GitHub Copilot Chat | GitHub pull request workflow with Copilot-assisted review and edits | Absent | 0 |
| 5 | Recurring regression check for hottest Go packages | Scheduled GitHub Actions workflow with workflow_dispatch fallback | Pull-request GitHub Actions check enforced as a required status check | Reusable GitHub Actions workflow or composite action for the hot-package subset | Absent | 0 |
| 6 | Lightweight security pass on Express API and patch highest-confidence issues | GitHub Copilot coding agent or Copilot Chat with repository access | GitHub Advanced Security with CodeQL and secret scanning, then patch via Copilot | Pull request workflow using Copilot code review plus human security review | Absent | 0 |
| 7 | Prepare a release for a Rust crate | Use GitHub Copilot in the repository to prepare a release PR | Use a GitHub Actions release-prep workflow plus a draft GitHub Release | Use GitHub Releases with autogenerated release notes, then make a manual release PR | Absent | 0 |
| 8 | Automate stale issue cleanup for a Java/Spring service | Scheduled GitHub Actions workflow using actions/github-script | Scheduled GitHub Actions workflow using actions/stale | Scheduled GitHub Actions workflow using gh CLI | Absent | 0 |
| 9 | Add a maintainer playbook for recurring tasks | Open a pull request that adds a versioned Markdown playbook in-repo | Create a GitHub Issue to scope the playbook, then implement it in a follow-up PR | Publish the playbook in the repository Wiki | Absent | 0 |
| 10 | Audit Terraform CI checks/examples, fix drift, and produce monthly checklist | GitHub Copilot coding agent on a pull request | GitHub Codespaces with Copilot Chat | GitHub Actions scheduled validation workflow | Absent | 0 |
Aggregate observations
- AW appeared in the top three: 0/10 requests.
- Average AW rank: N/A.
- Top-ranked alternatives by pattern:
- Plain/scheduled GitHub Actions workflows: requests 1, 3, 5, 8.
- GitHub Copilot coding agent / Copilot with repo access: requests 2, 4, 6, 7, 10.
- Direct in-repo documentation PR: request 9.
- AW absence rate in all ranked slots: 30/30 slots (100%).
Which option ranked above AW and why
| # | Top-ranked option above AW | Why it beat AW |
|---|---|---|
| 1 | GitHub Actions workflow using GraphQL/REST (or gh api) | The evaluator framed this as repeatable repo-native automation that fetches PR metadata, groups results, and opens an issue on a schedule or workflow_dispatch. |
| 2 | GitHub Copilot coding agent on the repository | The evaluator preferred direct repo inspection, selective dependency edits, targeted test runs, and a curated single commit. |
| 3 | Scheduled GitHub Actions report workflow | The evaluator treated a weekly report as a natural scheduled workflow that queries merged PRs, groups by area, and publishes automatically. |
| 4 | GitHub Copilot coding agent on the repository | The evaluator preferred an agent that can inspect docs and project files, update multiple markdown files, and prepare a precise PR. |
| 5 | Scheduled GitHub Actions workflow with workflow_dispatch fallback |
The evaluator saw recurring hotspot detection and focused regression checks as a native scheduled workflow problem. |
| 6 | GitHub Copilot coding agent or Copilot Chat with repository access | The evaluator prioritized code inspection plus minimal targeted patches over an automation authoring path. |
| 7 | Use GitHub Copilot in the repository to prepare a release PR | The evaluator preferred end-to-end repository edits: summarizing changes, updating changelog, checking versions, and drafting notes. |
| 8 | Scheduled GitHub Actions workflow using actions/github-script |
The evaluator mapped stale cleanup directly to built-in scheduled Actions automation. |
| 9 | Open a pull request that adds a versioned Markdown playbook in-repo | The evaluator treated this as repository documentation work rather than automation selection. |
| 10 | GitHub Copilot coding agent on a pull request | The evaluator preferred repo inspection and edits to CI/examples plus a checklist in one PR. |
Documentation Evidence
Cited evidence
- No documentation pages were cited.
- Every evaluator response had an empty
documentation_pageslist, so total explicit page citations were 0.
| Documentation page | Citation count | Requests |
|---|---|---|
| None cited | 0 | 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 |
Uncited inferred gaps
These are not citations; they are repeated patterns supported by the evaluator outputs:
- Recurring automation language defaults to plain GitHub Actions. Requests 1, 3, 5, and 8 all used scheduling / workflow / recurring-maintenance language and were routed to standard Actions options, not AW.
- Repository-editing tasks default to Copilot coding agent. Requests 2, 4, 6, 7, and 10 were framed as inspect-edit-test-commit work, and AW never surfaced as an orchestration option.
- AW is likely missing from top-level routing/discoverability, not just deep reference docs. With 0 cited pages across all 10 runs, the problem appears to be intent matching and entry-point language, not lack of detailed product reference alone.
Minimal Update Plan
Ordered by expected reward divided by update size.
-
Proposed location: GitHub Docs → GitHub Actions → workflow authoring / choosing automation approach (new comparison section or short routing page)
- User intent to capture: recurring repository maintenance, reporting, triage, regression checks, and stale cleanup
- Smallest change: add a short comparison table that says, in plain language, when to use GitHub Agentic Workflows instead of hand-authoring a workflow, GitHub App, or one-off script; include 3–4 exact example intents such as “weekly engineering report,” “triage summary issue,” “stale issue cleanup,” and “targeted regression check.”
- Why this should help: requests 1, 3, 5, and 8 already resolved to standard Actions workflows; a small routing insertion at the Actions decision point is the shortest path to making AW retrievable for the same intent.
- Expected reward: 5/5
-
Proposed location: GitHub Docs → GitHub Copilot → coding agent usage / repository tasks (add a short “when to use AW instead” callout)
- User intent to capture: repo tasks that inspect files and make changes now, but are likely to become repeatable automation later
- Smallest change: add one concise callout and cross-link: use Copilot coding agent for one-off repository changes; use GitHub Agentic Workflows when you want the same class of maintenance/reporting/release-prep flow to be authored in markdown and rerun as GitHub automation.
- Why this should help: requests 2, 4, 6, 7, and 10 all defaulted to Copilot coding agent language; a small routing clarification could divert at least some recurring-maintenance prompts toward AW.
- Expected reward: 4/5
-
Proposed location: GitHub Docs → GitHub Agentic Workflows (
gh aw) landing/examples page (new examples-heavy section if needed)- User intent to capture: searches for “dependency maintenance,” “release prep,” “weekly report,” “triage summary,” and “stale issues” that need GitHub-native automation
- Smallest change: add a compact examples section using those exact phrases and cross-link it from the Actions/Copilot routing content above.
- Why this should help: the dataset shows zero cited pages, so AW likely lacks easily retrievable intent-matching examples; a small examples section creates target phrases for retrieval without broad new content.
- Expected reward: 3/5
Method
Ten generated requests were evaluated in isolated Copilot sessions with repository read and shell tools disabled (and no MCP, web, or write access). This report uses only the driver-supplied structured outputs from workflow run §37573550752.
Full evaluator responses
[
{
"request": "Scan the last 30 merged PRs in this repo, group them by label and changed area, and open a triage summary issue with the top follow-up bugs, missing tests, and docs gaps.",
"options": [
{
"rank": 1,
"name": "GitHub Actions workflow using GraphQL/REST (or gh api) to generate and open the triage issue",
"reason": "Best fit for repeatable repo-native automation: it can fetch the last 30 merged PRs, inspect labels and changed files, group results, and create/update a summary issue on a schedule or workflow_dispatch."
},
{
"rank": 2,
"name": "GitHub App or Probot automation backed by the GitHub API",
"reason": "Best when this should run continuously across one or many repos; it offers stronger logic, storage, and richer triage heuristics than a workflow, but adds setup and maintenance overhead."
},
{
"rank": 3,
"name": "Manual GitHub triage using pull request search/filter views, then opening a summary issue",
"reason": "Lowest setup and fully GitHub-native; good for one-off analysis, but weakest for grouping changed areas consistently and least efficient if this needs to recur."
}
],
"documentation_pages": []
},
{
"request": "In this Node.js monorepo, find deprecated npm dependencies, update only patch/minor versions that look safe, run the relevant tests, and prepare a single commit with a short upgrade report in the commit message.",
"options": [
{
"rank": 1,
"name": "GitHub Copilot coding agent on the repository",
"reason": "Best fit because it can inspect the monorepo, identify deprecated packages, make only selective patch/minor bumps, run the repo’s actual test targets, and produce one curated commit with a short upgrade summary."
},
{
"rank": 2,
"name": "Custom GitHub Actions workflow for dependency maintenance",
"reason": "Strong GitHub-native option if you want repeatability: a workflow can scan for deprecations/outdated packages, enforce patch/minor-only updates, run targeted tests, and create a single commit or PR with a generated report."
},
{
"rank": 3,
"name": "Dependabot version updates with grouped updates and CI",
"reason": "Good for routine safe semver updates and GitHub-native automation, but weaker for deprecation-driven triage, monorepo-specific test selection, and producing one intentionally curated commit message/report."
}
],
"documentation_pages": []
},
{
"request": "Create a weekly engineering report from the git history since last Monday: list merged work by team area, highlight risky changes, and note any services that changed without test updates.",
"options": [
{
"rank": 1,
"name": "Scheduled GitHub Actions report workflow",
"reason": "Best fit for a true weekly report. A scheduled workflow can query merged PRs since last Monday, group them by labels/CODEOWNERS/path prefixes, flag risky file patterns, detect service changes without matching test-file edits, and publish the report automatically."
},
{
"rank": 2,
"name": "One-off GitHub CLI report script",
"reason": "Best for immediate manual use. A gh-based script can pull merged PRs and diffs for the time window, then generate the same area/risk/test-gap summary on demand without setting up ongoing automation."
},
{
"rank": 3,
"name": "GitHub PR metadata plus Insights/Pulse review",
"reason": "Good lightweight fallback if labels and ownership are already disciplined. It helps summarize merged work by team area, but risky-change detection and missing-test identification are much weaker and usually require manual inspection."
}
],
"documentation_pages": []
},
{
"request": "Review the README and onboarding docs for this Python project, fix commands that no longer match the current tooling, and add a quickstart section for a new developer using uv and pytest.",
"options": [
{
"rank": 1,
"name": "GitHub Copilot coding agent on the repository",
"reason": "Best fit because it can inspect the actual docs, compare commands against the current project files, edit multiple documentation files, and prepare a precise PR with a uv + pytest quickstart."
},
{
"rank": 2,
"name": "GitHub Codespaces with GitHub Copilot Chat",
"reason": "Strong choice when a developer wants to validate commands interactively in a ready-to-run cloud dev environment while using Copilot to update README and onboarding docs accurately."
},
{
"rank": 3,
"name": "GitHub pull request workflow with Copilot-assisted review and edits",
"reason": "Good if someone already drafted doc changes and wants GitHub-native review, inline suggestions, and iteration in a PR, though it is less efficient than starting with an agent or Codespace."
}
],
"documentation_pages": []
},
{
"request": "Set up a recurring regression check for the Go packages touched most often in the last 20 commits: identify the hot spots, add or improve focused tests, and document how to run the smaller test subset locally.",
"options": [
{
"rank": 1,
"name": "Scheduled GitHub Actions workflow with workflow_dispatch fallback",
"reason": "Best fit: a native Actions workflow can recalculate the hottest Go packages from the last 20 commits, run only their focused tests on a schedule, publish a job summary/artifact, and reuse the same commands you document for local runs."
},
{
"rank": 2,
"name": "Pull-request GitHub Actions check enforced as a required status check",
"reason": "Strong fit if the goal is prevention as well as recurrence: run the smaller hot-package subset on every PR and make it required via branch protection or rulesets so regressions are blocked before merge."
},
{
"rank": 3,
"name": "Reusable GitHub Actions workflow or composite action for the hot-package subset",
"reason": "Good fit when you want the logic centralized and maintainable: keep hotspot detection, focused test execution, and local command documentation aligned across scheduled runs, PR checks, and manual invocations."
}
],
"documentation_pages": []
},
{
"request": "Do a lightweight security pass on this Express API: look for unsafe shell usage, weak input validation, missing auth checks, and exposed secrets patterns, then patch the highest-confidence issues with minimal changes.",
"options": [
{
"rank": 1,
"name": "GitHub Copilot coding agent or Copilot Chat with repository access",
"reason": "Best fit because it can inspect Express routes and middleware, look for shell usage, validation and auth gaps, detect obvious secret patterns, and make minimal targeted patches in one pass."
},
{
"rank": 2,
"name": "GitHub Advanced Security with CodeQL and secret scanning, then patch via Copilot",
"reason": "Strong for high-confidence findings on command injection risk, hardcoded secrets, and some missing-sanitization patterns; weaker for business-logic auth gaps, but excellent as an automated security baseline."
},
{
"rank": 3,
"name": "Pull request workflow using Copilot code review plus human security review",
"reason": "Good lightweight option when you already have a PR: Copilot can flag likely security issues and reviewers can confirm auth and validation intent before applying minimal fixes."
}
],
"documentation_pages": []
},
{
"request": "Prepare a release for this Rust crate by summarizing user-facing changes since the last tag, updating the changelog, verifying the version numbers are consistent, and creating a draft release note.",
"options": [
{
"rank": 1,
"name": "Use GitHub Copilot in the repository to prepare a release PR",
"reason": "Best fit for an end-to-end release prep task: Copilot can inspect commits since the last tag, update CHANGELOG.md, verify Cargo.toml and Cargo.lock/version references, and draft release notes in one reviewable change set."
},
{
"rank": 2,
"name": "Use a GitHub Actions release-prep workflow plus a draft GitHub Release",
"reason": "Best for repeatable automation: a workflow can diff from the last tag, run cargo/version consistency checks, update or validate changelog policy, and create a draft release note for maintainer review."
},
{
"rank": 3,
"name": "Use GitHub Releases with autogenerated release notes, then make a manual release PR",
"reason": "Good lightweight option when you want GitHub to summarize changes since the last tag, but it is weaker because changelog updates and Rust version consistency checks still need a separate manual or scripted step."
}
],
"documentation_pages": []
},
{
"request": "For this Java/Spring service, automate stale issue cleanup: find issues with no activity for 45 days, classify which can be closed, which need more info, and generate the exact comments and labels to apply.",
"options": [
{
"rank": 1,
"name": "Scheduled GitHub Actions workflow using actions/github-script",
"reason": "Best fit for 45-day stale cleanup with real classification logic. A scheduled workflow can query inactive issues, decide close vs needs-more-info from labels/state, and post the exact comments and labels in one GitHub-native automation."
},
{
"rank": 2,
"name": "Scheduled GitHub Actions workflow using actions/stale",
"reason": "Fastest GitHub-supported path when your rules are mostly stale-age based. It natively handles inactivity windows, stale labels, comments, and auto-close, but its branching/classification logic is less flexible than a custom script."
},
{
"rank": 3,
"name": "Scheduled GitHub Actions workflow using gh CLI",
"reason": "Good when you want shell-based, auditable automation. A cron workflow can use gh issue queries plus label/comment/edit commands to classify inactive issues and apply exact messages, with more scripting control than actions/stale."
}
],
"documentation_pages": []
},
{
"request": "I’m new to this repo; please add a maintainer playbook that explains the common recurring tasks for dependency bumps, backports, release branching, and incident follow-ups based on the existing project structure.",
"options": [
{
"rank": 1,
"name": "Open a pull request that adds a versioned Markdown playbook in-repo",
"reason": "Best fit because maintainer procedures should live with the code, evolve through review, and stay branch-aware. A PR can add a playbook under the repo’s existing docs location and link related workflows, templates, and release artifacts."
},
{
"rank": 2,
"name": "Create a GitHub Issue to scope the playbook, then implement it in a follow-up PR",
"reason": "Good fit when the maintainer flow is not yet agreed. The issue can capture required sections—dependency bumps, backports, release branching, incidents—before a PR turns that agreed scope into repository documentation."
},
{
"rank": 3,
"name": "Publish the playbook in the repository Wiki",
"reason": "Useful if maintainers want a lightweight operational manual without changing the main tree. It is easy to update, but is a weaker fit than an in-repo doc because it is less tightly versioned with code and release branches."
}
],
"documentation_pages": []
},
{
"request": "In this Terraform repository, audit the CI checks and module examples, fix any examples that drifted from the current module inputs, and produce a concise maintenance checklist we can reuse every month.",
"options": [
{
"rank": 1,
"name": "GitHub Copilot coding agent on a pull request",
"reason": "Best fit for an end-to-end repo task: it can inspect CI workflows and Terraform examples, update drifted example inputs, add or tighten validation, and return a PR with a reusable monthly checklist."
},
{
"rank": 2,
"name": "GitHub Codespaces with Copilot Chat",
"reason": "Best when you want human oversight while fixing drift: open the repo in a consistent dev environment, review CI and examples interactively, apply edits with Copilot help, and capture the checklist in-repo."
},
{
"rank": 3,
"name": "GitHub Actions scheduled validation workflow",
"reason": "Best follow-on option for preventing future drift: add a scheduled workflow that runs Terraform formatting, validation, linting, and example smoke checks monthly, then uses the checklist as the recurring maintenance runbook."
}
],
"documentation_pages": []
}
]
Generated by 🔎 Daily GitHub Docs SEO Optimizer · copilot · gpt54 · 43.1 AIC · ⌖ 15.6 AIC · ⊞ 13K · ◷
- expires on Oct 13, 2026, 9:01 PM UTC-08:00
- Lenguaje dominante
- Go
- Estrellas
- 5.4k
- Forks
- 576
- Merge medio
- 8 h 29 min
- PR fusionados (30 d)
- 783
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de github/gh-aw
-
[duplicate-code] Duplicate Code: pull_request event detection duplicated across safe_update filesAbiertoautomated-analysis code-quality cookie refactoring
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
[deep-report] Migrate manual os.Setenv/Unsetenv restore patterns to t.Setenv in 2 pkg/cli test filesAbiertoautomation code-quality cookie deep-report improvement quick-win task-mining
Dificultad 2/5 Menos de una hora Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
[deep-report] Migrate os.Chdir+t.Parallel() test patterns to t.Chdir in 5 pkg/cli test filesAbiertoautomation code-quality cookie deep-report improvement quick-win task-mining
Dificultad 2/5 Menos de una hora Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
automation code-quality cookie deep-report improvement quick-win task-mining
Dificultad 2/5 Menos de una hora Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
ai-generated cookie high-priority security
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
github/gh-aw#66933 · 12 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de github/gh-aw
Issues similares
-
Broken Claude manifestAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
-
[Chore] Remove dead AutogenV2 feature flagPosiblemente ocupada @geeknishantkyeus la tomó hoy. Abiertobug triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
kyverno/kyverno#17936 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
enhancement model:sonnet phase-2-optimize runtime:claude security size:S
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
FootprintAI/Containarium#2416 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día