Summary
The pr-processor sub-agent prompt in .github/workflows/pr-sous-chef.md instructs the agent to read PR review-thread node IDs (PRRT_...) "from reviewThreads" (see lines 427-428 and 499), but never specifies a valid way to fetch that data. In every observed failing run, the agent falls back to:
gh pr view <N> --repo github/gh-aw --json number,comments,reviews,reviewThreads,headRefName,headRefOid,mergeStateStatus,title
which fails immediately with:
Unknown JSON field: "reviewThreads"
Available fields:
... reviewDecision reviewRequests reviews ...
gh pr view --json has no reviewThreads field -- thread-level data with PRRT_... node IDs is only available via gh api graphql (e.g. querying pullRequest.reviewThreads.nodes { id isResolved comments { nodes { ... } } }).
Impact
This is a systemic, repeating bug: it was reproduced identically across at least 4 separate scheduled runs in the 2026-08-17 to 2026-08-18 window (run IDs 32182897882, 32173721105, 32181183908, 32175741590), and is the dominant contributor to "PR Sous Chef" agent_logic failure rate in that period (22 of 23 sampled agent_logic failures belonged to this workflow). Each failed run burns the sub-agent's tool-call budget (capped at 8 calls per step 4 of the prompt) on a command that can never succeed, then falls through to insufficient_context/skip_reason fallbacks instead of actually processing review threads.
Suggested fix
Update the pr-processor sub-agent instructions (and any prefilter step that assembles PR context) to fetch review threads via GraphQL instead of gh pr view --json, e.g.:
gh api graphql -f query='query($owner:String!,$repo:String!,$pr:Int!){repository(owner:$owner,name:$repo){pullRequest(number:$pr){reviewThreads(first:100){nodes{id isResolved comments(first:1){nodes{author{login} body}}}}}}}' -f owner=github -f repo=gh-aw -F pr=<N>
and explicitly document that field name and command in the prompt so the agent doesn't have to guess.
Scope note
This is a workflow-prompt issue, not a safe-output MCP tool schema/description issue -- filed separately per the Safe Output Tool Optimizer's routing rules. No changes to pkg/workflow/js/safe_outputs_tools.json or actions/setup/js/safe_output_validator.cjs are implicated by this finding.
Generated by ⚡ Daily Safe Output Tool Optimizer · agent · 227.5 AIC · ⌖ 11 AIC · ⊞ 9.8K · ◷
Summary
The
pr-processorsub-agent prompt in.github/workflows/pr-sous-chef.mdinstructs the agent to read PR review-thread node IDs (PRRT_...) "fromreviewThreads" (see lines 427-428 and 499), but never specifies a valid way to fetch that data. In every observed failing run, the agent falls back to:which fails immediately with:
gh pr view --jsonhas noreviewThreadsfield -- thread-level data withPRRT_...node IDs is only available viagh api graphql(e.g. queryingpullRequest.reviewThreads.nodes { id isResolved comments { nodes { ... } } }).Impact
This is a systemic, repeating bug: it was reproduced identically across at least 4 separate scheduled runs in the 2026-08-17 to 2026-08-18 window (run IDs 32182897882, 32173721105, 32181183908, 32175741590), and is the dominant contributor to "PR Sous Chef" agent_logic failure rate in that period (22 of 23 sampled agent_logic failures belonged to this workflow). Each failed run burns the sub-agent's tool-call budget (capped at 8 calls per step 4 of the prompt) on a command that can never succeed, then falls through to insufficient_context/skip_reason fallbacks instead of actually processing review threads.
Suggested fix
Update the
pr-processorsub-agent instructions (and any prefilter step that assembles PR context) to fetch review threads via GraphQL instead ofgh pr view --json, e.g.:and explicitly document that field name and command in the prompt so the agent doesn't have to guess.
Scope note
This is a workflow-prompt issue, not a safe-output MCP tool schema/description issue -- filed separately per the Safe Output Tool Optimizer's routing rules. No changes to
pkg/workflow/js/safe_outputs_tools.jsonoractions/setup/js/safe_output_validator.cjsare implicated by this finding.