Dreaming: up to 3 atomic PRs + per-PR core-team reviewer requests

[jankratochvilcz]

What

Two enhancements to the Dreaming learning-atoms workflow (.github/workflows/dreaming.agent.md), requested to make its output more actionable:

1. Up to 3 atomic PRs per run. create-pull-request.max raised 1 → 3. Distinct, unrelated recurring patterns now each land as their own atomic, independently-reviewable PR (one theme per PR, each on its own git branch). A quiet week or a single-theme week still produces just one PR — the workflow is told not to split for the sake of it.

2. Per-PR reviewer requests, scoped to the core MSBuild team, max 2. For each PR, the agent identifies the people who were actually involved in the discussions behind that pattern, keeps only core-team members, caps at 2, and requests their review.

Prompt-body changes support this: Step 1 now records each participant's authorAssociation, Step 2 keeps the per-theme participant list, Step 4 branches per pattern for atomicity, and a new Step 5b does reviewer selection.

How "core MSBuild team" is determined

The agent classifies a participant as core team only when their GitHub authorAssociation on the PR is OWNER or MEMBER (org members) — COLLABORATOR/CONTRIBUTOR/NONE are dropped, along with bots and the PR authors. When no individual qualifies, it falls back to the @dotnet/kitten CODEOWNERS team (the MSBuild owners team). This keeps the "only core team" guarantee without hardcoding a username list that would churn.

Platform constraint (why reviewers are recorded in the PR body)

I dug through gh-aw v0.82.9's safe-outputs internals to find the right mechanism, and there is a real limitation worth calling out:

• create_pull_request has no per-item reviewers field — the agent can't attach reviewers to an individual PR it emits.
• create-pull-request.reviewers / team-reviewers config does issue a real requestReviewers call, but it is static and uniform — the same reviewers on every PR in the run — so it can't be the specific per-discussion people.
• The add-reviewer safe output resolves its target PR only from a literal integer pull_request_number or a pull_request-event context. Dreaming runs on schedule/workflow_dispatch and creates its PRs in the same run, so add-reviewer has no PR number to target and would error every time. (I verified this in pr_helpers.cjs getPullRequestNumber and confirmed add_reviewer is never deferred for temp-ID resolution.)

So a formal, dynamic, per-PR, ≤2-specific-people review request isn't achievable through gh-aw safe-outputs today. The faithful, reliable path — which is dynamic per pattern and restricted to the right people — is to record the request in each PR body as a dedicated ## Reviewers (core MSBuild team) section with real @-mentions. This notifies the chosen reviewers and lets a maintainer assign them with one click. If we later want formal auto-assignment, the supported route is a small companion workflow triggered on the Dreaming PR's pull_request opened event (which does have PR context) — happy to add that as a follow-up if desired.

Guardrail preserved

The existing "no contributor call-outs / no individual names" rule still governs the learning-atom content (the edited instruction files). Naming reviewers in the PR body is explicitly carved out as review metadata, not atom content.

Scope

Only the Dreaming workflow's .md + regenerated .lock.yml. Lock diff is limited to max 1→3, the removal of the (non-functional) add-reviewer tooling, and the embedded prompt text. Compiles clean (0 errors, 0 warnings). A human still approves and merges every Dreaming PR.

[Copilot]

Pull request overview

Updates the Dreaming agentic workflow to produce more actionable learning-atom updates by splitting distinct recurring themes into separate PRs and capturing per-theme core-team reviewer intent in PR metadata.

Changes:

• Increase create-pull-request.max from 1 to 3 so the workflow can open up to three atomic PRs per run (one per distinct recurring pattern).
• Extend the prompt to preserve per-theme participant metadata (login + authorAssociation) and add a reviewer-selection step for core-team participants (max 2, with @dotnet/kitten fallback) recorded in the PR body.

Reviewed changes

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

File	Description
.github/workflows/dreaming.agent.md	Raises PR limit to 3 and updates the Dreaming prompt to branch per pattern and record per-theme core-team reviewer mentions in the PR body.
.github/workflows/dreaming.agent.lock.yml	Regenerates the compiled workflow to reflect the updated prompt text and create_pull_request(max:3) safe-output configuration.

[github-actions]

24-Dimension Review Summary

Dimensions 2-3, 5-9, 11-17, 19, 21, 23-24 (ChangeWave, binary log, performance, allocations, API surface, evaluation model, concurrency, etc.) — LGTM. Not applicable to this workflow-only PR.

Dimension 1 (Backwards Compatibility) — LGTM. No existing callers depend on the single-PR behavior; the workflow is internal automation.

Dimension 4 (Test Coverage) — LGTM. Workflow agent prompts have no unit tests; the lock file recompilation serves as validation.

Dimension 10 (Design) — The multi-PR design is sound and well-motivated. Splitting unrelated patterns into atomic PRs improves reviewability. The reviewer-request feature is a nice touch for routing reviews to knowledgeable people.

Dimension 18 (Documentation) — Generally clear and self-consistent. One clarification needed on rule 8 (see inline comment about same-theme vs same-file).

Dimension 20 (Scope & PR Discipline) — LGTM. Well-scoped: two related features (multi-PR + reviewer requests) that naturally go together.

Dimension 22 (Correctness) — Two minor edge cases flagged inline:

1. Branch creation should ensure main is fresh (fetch before checkout).
2. @-mentions in PR body are notifications, not formal review requests — the instructions should set expectations accordingly.

Overall this is a well-structured improvement. The inline comments are suggestions/questions, not blockers.

Warning

Firewall blocked 2 domains

The following domains were blocked by the firewall during workflow execution:

• awmgmcpg
• patchdiff.githubusercontent.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"
    - "patchdiff.githubusercontent.com"

See Network Configuration for more information.

Generated by Expert Code Review (on open) for #14373 · 117.4 AIC · ⌖ 5.21 AIC · ⊞ 4.8K