You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
gh-aw workflows ignoring the triggering comment #226 — documents established needs.activation.outputs.* usage for passing workflow outputs into prompts, which could guide how to expose and consume additional outputs for this issue.
Do not repeat previous findings #405 — discusses surfacing issue numbers/titles from prior agent-generated issues, which is adjacent to this issue’s request to expose created issue numbers in outputs.
TL;DR: gh-aw already emits machine-readable issue creation data, but not as a dedicated created_issue_numbers output; today the reliable signal is process_safe_outputs_temporary_id_map (plus the safe-output-items artifact), so I recommend consuming that instead of adding a new output unless we want an explicit convenience field.
Recommendation
Use needs.(job).outputs.process_safe_outputs_temporary_id_map as the job output contract for created issue IDs, and parse issue numbers from that map in downstream jobs. If we want a simpler contract, open a scoped enhancement to gh-aw to add a first-class created_issue_numbers output derived from the same map.
Findings
Verified code and runtime evidence
Workflow output wiring includes process_safe_outputs_temporary_id_map, not a dedicated created-issue output:
Runtime logs from prior runs confirm created issues are registered and exported through temp-ID map, then exposed as job outputs:
Job 65123354810 (run 22481977490): logs include Created issue ...#449, Exported temporary ID map with 1 mapping(s), and Set output 'process_safe_outputs_temporary_id_map'.
Job 65238090480 (run 22517704877): logs include Registered temporary ID ... -> ...#475, Exported temporary ID map with 1 mapping(s), and Set output 'process_safe_outputs_temporary_id_map'.
Verification
What I checked
Searched compiled workflows for output keys and create_issue wiring.
Inspected previous job logs for safe-outputs execution and output publication.
Result: behavior is consistent with issue creation metadata being available via temporary-ID map, not a dedicated created-issue-number output.
Detailed Action Plan
If you want to act on this now
In the consuming workflow, read needs.(safe_outputs_job).outputs.process_safe_outputs_temporary_id_map.
Parse the map values to extract issue numbers (e.g., owner/repo#123 → 123).
Use those parsed IDs for any follow-up automation (comments, linking, dedupe checks).
Optional enhancement: add a compiler/runtime feature that also emits created_issue_numbers for easier downstream use, while keeping temporary_id_map for backward compatibility.
/ai maybe we should publish an action which extracts the value out of the job output and puts it in a normal spot that you can then use for triggering a fix workflow?
I agree we should put this in a simpler contract, but we likely don’t need a new trigger path to run fixes: issue creation is already the “normal spot.”
Evidence:
Safe output map is already published as a job output: .github/workflows/gh-aw-product-manager-impersonator.lock.yml:1516 (process_safe_outputs_temporary_id_map).
Scheduled audit is already designed to stamp created issues with a stable title prefix/optional label: .github/workflows/gh-aw-scheduled-audit.md:30-37, :117.
Scheduled fix already selects targets from open issues via that prefix/label (no job-output parsing required): .github/workflows/gh-aw-scheduled-fix.md:30-38, :117-127.
If you want immediate fix execution, issue-fixer already triggers on issue creation (issues.opened): gh-agent-workflows/issue-fixer/example.yml:2-5.
Practical recommendation:
Use labels/title-prefix as the cross-workflow contract (already in place).
For immediate chaining, run issue-fixer on issues.opened with an if: filter for your audit label/prefix.
Optional enhancement: add a tiny helper action that converts process_safe_outputs_temporary_id_map into created_issue_numbers JSON/CSV outputs for convenience, but treat that as ergonomics rather than required for triggering fixes.
/ai process_safe_outputs_temporary_id_map into created_issue_numbers is nice, the problem is that github-actions making an issue and labeling it won't trigger another workflow so unless it do funny business you need to trigger the fix in the same workflow and the easy way to do that I think is to encourage users to extract out the created issue and invoke a fix workflow as part of the same action run. Let's make a pr
Activity
github-actions commentedon Feb 28, 2026
2 related issues
needs.activation.outputs.*usage for passing workflow outputs into prompts, which could guide how to expose and consume additional outputs for this issue.What is this? | From workflow: Duplicate Issue Detector
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
github-actions commentedon Feb 28, 2026
TL;DR: gh-aw already emits machine-readable issue creation data, but not as a dedicated
created_issue_numbersoutput; today the reliable signal isprocess_safe_outputs_temporary_id_map(plus thesafe-output-itemsartifact), so I recommend consuming that instead of adding a new output unless we want an explicit convenience field.Recommendation
Use
needs.(job).outputs.process_safe_outputs_temporary_id_mapas the job output contract for created issue IDs, and parse issue numbers from that map in downstream jobs. If we want a simpler contract, open a scoped enhancement to gh-aw to add a first-classcreated_issue_numbersoutput derived from the same map.Findings
Verified code and runtime evidence
process_safe_outputs_temporary_id_map, not a dedicated created-issue output:.github/workflows/gh-aw-product-manager-impersonator.lock.yml:1511.github/workflows/gh-aw-product-manager-impersonator.lock.yml:1513.github/workflows/gh-aw-product-manager-impersonator.lock.yml:1515.github/workflows/gh-aw-product-manager-impersonator.lock.yml:1516create_issuehandler (so issue creation is expected):.github/workflows/gh-aw-product-manager-impersonator.lock.yml:154165123354810(run22481977490): logs includeCreated issue ...#449,Exported temporary ID map with 1 mapping(s), andSet output 'process_safe_outputs_temporary_id_map'.65238090480(run22517704877): logs includeRegistered temporary ID ... -> ...#475,Exported temporary ID map with 1 mapping(s), andSet output 'process_safe_outputs_temporary_id_map'.Verification
What I checked
create_issuewiring.Detailed Action Plan
If you want to act on this now
needs.(safe_outputs_job).outputs.process_safe_outputs_temporary_id_map.owner/repo#123→123).created_issue_numbersfor easier downstream use, while keepingtemporary_id_mapfor backward compatibility.Related Items
Relevant history and artifacts
product-manager-impersonator,refactor-opportunist).github/workflows/gh-aw-product-manager-impersonator.lock.yml:1511-1516What is this? | From workflow: Issue Triage
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
strawgate commentedon Feb 28, 2026
/ai maybe we should publish an action which extracts the value out of the job output and puts it in a normal spot that you can then use for triggering a fix workflow?
github-actions commentedon Feb 28, 2026
I agree we should put this in a simpler contract, but we likely don’t need a new trigger path to run fixes: issue creation is already the “normal spot.”
Evidence:
.github/workflows/gh-aw-product-manager-impersonator.lock.yml:1516(process_safe_outputs_temporary_id_map)..github/workflows/gh-aw-scheduled-audit.md:30-37,:117..github/workflows/gh-aw-scheduled-fix.md:30-38,:117-127.issue-fixeralready triggers on issue creation (issues.opened):gh-agent-workflows/issue-fixer/example.yml:2-5.Practical recommendation:
issue-fixeronissues.openedwith anif:filter for your audit label/prefix.process_safe_outputs_temporary_id_mapintocreated_issue_numbersJSON/CSV outputs for convenience, but treat that as ergonomics rather than required for triggering fixes.What is this? | From workflow: Mention in Issue
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
strawgate commentedon Feb 28, 2026
/ai process_safe_outputs_temporary_id_map into created_issue_numbers is nice, the problem is that github-actions making an issue and labeling it won't trigger another workflow so unless it do funny business you need to trigger the fix in the same workflow and the easy way to do that I think is to encourage users to extract out the created issue and invoke a fix workflow as part of the same action run. Let's make a pr