Fix docs-review noop on issue_comment triggers (fork and non-fork PRs) - #250
Merged
Conversation
When the lock file is called via uses: from docs-pr-ai-menu, the
$GITHUB_EVENT_PATH on disk contains the workflow_call payload (just inputs),
not the original issue_comment event. The jq that extracts the PR number
from GITHUB_EVENT_PATH returns empty, causing the pre-step to write
"not a pull request context" and the agent to noop.
GitHub Actions expressions (${{ github.event.* }}) DO propagate the
original event context to called workflows, so injecting the PR number via
env: before the jq fallback fixes the extraction without requiring a new input.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When
gh-aw-docs-review.lock.ymlis triggered via the AI PR menu (issue_commentedit event), the agent noops with "pull-request-number is false". This affects all PRs (fork and non-fork).Root cause: the gh-aw framework exposes
pull-request-numberto the agent asgithub.event.pull_request.number, which is always null forissue_commentevents — the PR number lives atgithub.event.issue.numberinstead. The pre-step jq extraction is fine (eligible_count=1in logs for fork runs), but the agent checkspull-request-numberand noops before reading the pre-fetched data. Whether the agent self-recovers viagithub-issue_readis non-deterministic (it did for one non-fork run, did not for the fork run).Fix
Two changes to
gh-aw-docs-review.md:Shell (pre-step): The "Run Vale on changed markdown" step now injects
PR_NUMBER_FROM_CONTEXTviaenv:using the expression${{ github.event.pull_request.number || github.event.issue.number }}(expressions propagate the original event context even throughworkflow_call). It writes atrigger-context.jsonfile with{"pr_number": N, "is_pr_context": true/false}.Prompt: Replaces the ambiguous "Confirm that the triggering item is a pull request or PR comment context" instruction with an explicit directive to read
trigger-context.jsonfirst and useis_pr_contextas the gate — explicitly warning thatpull-request-numberis unreliable forissue_commenttriggers.Test plan
trigger-context.json, seesis_pr_context: true, and proceeds with the review instead of noopingis_pr_context: falsecauses a correct noop🤖 Generated with Claude Code