Triage action can result in a github comment 😆

[williambdean]

Triage analysis

This issue is a post-release cleanup task involving reverting CI/workflow configuration files and removing v1.0.0 references. This is clearly a maintenance/refactoring task rather than a bug or new feature.

• It's about cleaning up config files → maintenance
• No actual bug, no user-facing feature, just housekeeping → low priority → priority: low

gh issue edit --add-label "maintenance,priority: low"

Originally posted by @github-actions in #2612

[github-actions]

Triage analysis

This issue is about post-release cleanup — reverting CI/workflow configuration files and removing v1.0.0 references. This is housekeeping/maintenance with no user-facing impact.

gh issue edit --add-label "maintenance,priority: low"

[williambdean]

Or maybe this was the most recent design? Maybe better to update the issue body?

[anevolbap]

Or maybe this was the most recent design? Maybe better to update the issue body?

🙋 It came from #2474 and landed in #2560: before that, the triage analysis was only visible in a workflow artifact, so the workflow now posts it as a collapsed comment.

Moving the analysis into the issue body has two costs. It edits text the reporter wrote, and the edit fires an edited event, which triggers the duplicate-issues workflow on every triage run. That workflow sleeps 5 minutes and then runs an agent, so each triage would add a wasted run unless we also teach it to skip bot edits.

[williambdean]

Make sense. So this is intended behavior, then?

[anevolbap]

Make sense. So this is intended behavior, then?

Yes, intended. But no strong opinion on my side, if you prefer the issue body or no comment at all I can open a PR.