Triage agent causes unnecessary notifications - should skip initial comment

[deboer-tim]

The triage agent adds a comment to every issue when it starts, which causes GitHub notification to trigger:

🤖 Triage · Started 12:08 PM UTC
Commit: c8a65f6 · [View workflow run →](https://github.com/some-org/some-repo/actions/runs/28941383103)

Then when it's done it adds the real comment, which causes another notification:

Triage Summary

Category: Feature request · Severity: Medium

Problem
...

This is causing unnecessary strain on my inbox, and I'm more likely to automatically file triage agent comments without looking at them because there's a 50% chance it's pointless.

If the system is working well I don't need the comment or the notification to know that triage is going to run. Humans don't post a comment to say 'hey, I'm going to look at this' 5 minutes before they post their analysis, they just do it. Plus, I can always look at the Actions tab if I want to confirm the run or look at details before it's complete.

We should skip posting the initial comment. If someone really wants some indication that triage is running it should use one of the other built-in mechanisms, e.g. add itself as an assignee, a participant, or react to the issue with an emoji.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 1:08 PM UTC · Completed 1:12 PM UTC
Commit: 7ada4e0 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Category: Feature request · Severity: High (bumped from medium)

Problem

The agent lifecycle posts a "Started" status comment on every issue, generating a notification. When the agent finishes seconds later and posts results, GitHub often suppresses that second notification as a duplicate — leaving users with only the useless "started" notification and no indication of results. This makes it impossible to scan notifications for issues needing attention.

Maintainer-Directed Solution

Per maintainer direction, this should be implemented as config.yaml-driven notification control with two independent, composable settings:

• notifications.comments — toggle start/stop comments (default: on, current behavior)
• notifications.emoji_reactions — toggle emoji reactions as status signals (default: off)

Emoji reactions should target the triggering entity: the issue/PR if triggered by an event, or the specific comment if triggered by a slash command.

Implementation Notes

• Reconcile-status (Reconcile-status step should not mark start comment as Terminated when agent already posted a success comment #4058) must handle missing initial status comments gracefully
• Related lifecycle issues: Add agent failure notifications to the post-run lifecycle #957 (failure notifications), Post failure status comment when agent fails before creating a status comment #3635 (failure status comment)
• Needs behavior tests covering all four setting combinations and slash-command targeting
• Needs user-facing documentation for the new config options

⚠ Workflow Changes Required

This fix likely requires modifications to workflow files (action.yml reconcile-status, post-run-link job) which the code agent cannot modify under current permissions. Manual intervention may be required for the workflow portions of this change.

Proposed Test Cases

Scenario: Comments disabled, reactions disabled (both off)
  Given config.yaml has notifications.comments=false and notifications.emoji_reactions=false
  When an issue triggers triage
  Then no status comments are posted during the run
  And no emoji reactions are added
  And the triage summary comment is still posted

Scenario: Comments disabled, reactions enabled
  Given notifications.comments=false and notifications.emoji_reactions=true
  When an issue triggers triage
  Then no status comments are posted
  And an emoji reaction is added to the issue at start

Scenario: Slash command targets the comment, not the issue
  Given notifications.emoji_reactions=true
  When a user posts /fs-triage as a comment
  Then the emoji reaction is added to that comment

Scenario: Reconcile-status handles missing initial comment
  Given notifications.comments=false
  When reconcile-status runs
  Then it completes without error

---

Labels: Maintainer bumped severity; upgrading from priority/medium to priority/high to reflect that this actively suppresses useful notifications and blocks dev adoption.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance

Previous run

Triage Summary

Category: Feature request · Severity: Medium

Problem

The triage agent posts an initial "Started" status comment on every issue it processes, triggering a GitHub notification. When triage completes, a second comment with the actual analysis triggers another notification. This doubles notification volume for triage runs, with 50% of notifications carrying no actionable information — training users to ignore triage output.

Root Cause Hypothesis

The agent lifecycle infrastructure posts a status comment at run start (using an agent-status marker comment) for visibility. While useful for long-running agents like code or review, this is counterproductive for triage, which typically completes quickly and whose value is entirely in the final analysis.

Recommended Fix

Skip the initial "Started" status comment for triage agent runs. Two approaches:

1. Skip entirely — remove the initial comment for triage. Users can check the Actions tab if they want to confirm a run is in progress.
2. Replace with non-notification mechanism — use a reaction emoji on the issue, add the bot as a participant, or self-assign. These provide visual indication without triggering notifications.

The reconcile-status post-step (see #4058) may need adjustment to handle the absence of an initial status comment gracefully. Consider whether this change should be triage-specific or apply to all agent types.

Proposed Test Case

Scenario: Triage agent posts only one comment per run
  Given an issue that triggers triage dispatch
  When the triage agent completes successfully
  Then exactly one comment is posted (the triage summary)
  And no "Started" status comment is present

Scenario: Triage agent failure is still surfaced
  Given an issue that triggers triage dispatch
  When the triage agent fails before completing
  Then a failure status comment is posted (or failure is visible in Actions)

Scenario: Reconcile-status handles missing initial comment
  Given a triage run with no initial status comment
  When the reconcile-status post-step runs
  Then it completes without error

---

Labels: This is a feature request for the triage agent, medium priority since it affects notification quality but has a workaround (filtering notifications).

[deboer-tim]

I'm bumping the severity of this. With the (non-)caching performance improvement the agents are now 'too quick' and GitHub notifications is deciding the second update is too soon after the first and not sending a notification. e.g. "Jim updated an issue at 9:17, a notification was sent out at 9:20. Jim updated the bug again at 9:21, but since it's the same person and we just told everyone, we won't send out a notification again."

The result is that you get notifications for triage or coder starting, but never for anything they actually do. Looking at your email there's no way to tell if triage ever finished or what state the issue/PR is in. Sometimes you get 'triage started', 'coding started' emails with no other content. You can assume triage must have finished for coder to begin, but no idea if coder succeeded.

Net: it's impossible to scan through notifications to see if there's anything that needs your attention. You have to open every issue to see what's going on.

Agents are quick enough now; nobody is sitting with a browser open waiting to see that first comment. We should remove it entirely (use reactions/assigning if people need to see if they're active) and the second comment can include a link, error, or other details if necessary.