Add agentic workflow daily-doc-updater

[weikanglim]

Add agentic workflow daily-doc-updater

[Copilot]

Pull request overview

Adds a GitHub Agentic Workflow (“daily-doc-updater”) to automatically scan recent merged PRs/commits and open documentation update PRs, along with the generated lock workflow and git attributes to treat lock files as generated.

Changes:

• Added the agent prompt/spec for the daily documentation updater workflow (daily-doc-updater.md).
• Added the compiled GitHub Actions workflow generated by gh-aw (daily-doc-updater.lock.yml).
• Marked workflow lock files as generated and set merge strategy to prefer ours for conflicts.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
.github/workflows/daily-doc-updater.md	Defines the agent instructions, tool access, schedule, and safe-outputs PR creation policy.
.github/workflows/daily-doc-updater.lock.yml	Generated workflow that executes the agent, safe-outputs handling, and threat detection.
.gitattributes	Treats *.lock.yml workflow outputs as generated and resolves merge conflicts via merge=ours.

Comments suppressed due to low confidence (2)

.github/workflows/daily-doc-updater.lock.yml:46

• runs-on: ubuntu-slim is not a standard GitHub-hosted runner label (the repo’s other workflows use ubuntu-latest). If this repository doesn’t provide an ubuntu-slim runner label, the workflow will never start. Consider switching to ubuntu-latest or using an explicit self-hosted/custom label that’s known to exist here.

    runs-on: ubuntu-slim

.github/workflows/daily-doc-updater.lock.yml:977

• runs-on: ubuntu-slim is not a standard GitHub-hosted runner label (the repo’s other workflows use ubuntu-latest). If this repository doesn’t provide an ubuntu-slim runner label, the workflow will never start. Consider switching to ubuntu-latest or using an explicit self-hosted/custom label that’s known to exist here.

    runs-on: ubuntu-slim

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

The prompt uses GitHub Actions expression syntax (${{ github.repository }}) inside the agent instructions. This won’t be interpolated in the rendered prompt and may cause the agent to literally search for repo:${{ github.repository }}. Consider replacing it with a literal owner/repo placeholder (e.g., repo:OWNER/REPO) or referencing the provided workflow context value (e.g., __GH_AW_GITHUB_REPOSITORY__).

Suggested change

	- Search for pull requests merged in the last 24 hours using `search_pull_requests` with a query like: `repo:${{ github.repository }} is:pr is:merged merged:>=YYYY-MM-DD` (replace YYYY-MM-DD with yesterday's date)
	- Search for pull requests merged in the last 24 hours using `search_pull_requests` with a query like: `repo:__GH_AW_GITHUB_REPOSITORY__ is:pr is:merged merged:>=YYYY-MM-DD` (replace YYYY-MM-DD with yesterday's date)

[spboyer]

whose token is being used here? There are no global org tokens and this would be tied toa single user

[spboyer]

@weikanglim — cool to see the GitHubNext agentic workflows template in action! A few things worth discussing before this lands:

1. COPILOT_GITHUB_TOKEN requirement
The lock.yml validates this secret exists. Since there's no org-level token support, this will need to be a specific user's token. Who owns that, and what happens when it expires or the user leaves?

2. Doc targeting — this repo's docs aren't user-facing
End-user azd documentation lives on Microsoft Learn, not in a /docs folder here. The in-repo docs (cli/azd/docs/) are internal engineering design docs and style guides. If the intent is to update those internal/engineering docs or LLM-facing reference material, we should discuss how that scoping works — the workflow's agent instructions are completely generic (it just runs find . -name "*.md" at runtime and touches whatever it finds).

3. General observations

• The real review surface here is the 187-line .md file — the 1197-line .lock.yml is generated by gh aw compile and not hand-reviewable.
• This imports an off-the-shelf template from githubnext/agentics/workflows/daily-doc-updater.md at a pinned SHA — not a custom workflow.
• Daily cadence on a high-volume repo could be noisy. The agent instructions say "skip internal refactoring" but that's a soft AI guideline, not a hard filter.
• The PR description could use more context — rationale, expected behavior, which docs are in scope.
• The .gitattributes change (merge=ours for *.lock.yml) is a good pattern for generated files.

[weikanglim]

@spboyer

• PAT authentication requirement - it's only there for billing purposes -- Agentics Workflow team is working on a more permanent solution for org-wide billing soon. For now, we should just create fine-grained PATs that only have the "Copilot Requests" permission; there's no real security risk. This has been cleared with azure sdk engsys team (Wes) while we wait for the proper solution from the GitHub team. We're adopting this across Azure SDK teams.

• End-user azd documentation lives on Microsoft Learn -- In general, the principle that I'd like us to adopt is to have context closest to where the code lives. I'd like to see that we have high-level product/technical docs living in azure-dev, so that all agents can iterate faster and more accurately.

To close the loop on "Learn", We would have a separate Learn generation pipeline that reads azure-dev and generates more end-user facing, friendly docs for general audience.

• Generic doc -- Agreed on generic doc. I was curious about how this would perform today. I'm going to set up on my Fork to play around with it, but we will definitely want to continue iterating on this and fine-tune everything to work. Organization of docs is on my list.

[spboyer]

@weikanglim - End-user azd documentation lives on Microsoft Learn -- In general, the principle that I'd like us to adopt is to have context closest to where the code lives. I'd like to see that we have high-level product/technical docs living in azure-dev, so that all agents can iterate faster and more accurately.

That is not the model we have wtith Docs for end users. We do not write the docs, the docs team does. If there are techinal docs and requirements to how we shape code or LLMS understand it, that information should live in AGENTS.md / copilot-instructions.

[spboyer]

this is a generic template from gh next. Need to understand the benefit of creating a new docset that is out of line with the process of producing user end docs

[weikanglim]

@spboyer I understand the concern, but I think this is slightly different from creating a parallel end-user docset.

What I’m proposing is not a replacement for the existing docs process, and not an attempt to produce user-facing documentation outside that flow.

That is not the model we have wtith Docs for end users. We do not write the docs, the docs team does

What I’m suggesting is making space for technical and developer-focused documentation inside the azd repo. This would serve a different audience and purpose:

• Internal or contributor-facing guidance
• Architectural and implementation context
• AI/agent guidance for interacting with the repo

That kind of content serves a different purpose from polished end-user docs. It is closer to engineering context than product documentation.

If there are techinal docs and requirements to how we shape code or LLMS understand it, that information should live in AGENTS.md / copilot-instructions.

In practice, I’m not convinced a single AGENTS.md file will scale well. As the project grows, an organized repository of documents and supporting content tends to work much better than concentrating everything into one file.

OpenAI’s approach to harness engineering is a good example of this pattern:
https://openai.com/index/harness-engineering/

I'm happy to spend more time to organize our docs and refining the prompt to target these content ideas more specifically, but I do believe this is a step forward in the right direction.