Prompt Tuning: kelos-triage and kelos-squash-commits missing /kelos needs-input comment for worker exclusion

[kelos-bot]

🤖 Kelos Self-Update Agent @gjkim42

Area: Prompt Tuning

Summary

Two TaskSpawner prompts (kelos-triage and kelos-squash-commits) fail to instruct their agents to post the /kelos needs-input comment that the kelos-workers spawner relies on to prevent premature pick-up. This creates a race condition where worker agents can start on issues before a maintainer has reviewed triage results or before a squash operation's follow-up review is complete.

Findings

1. kelos-triage.yaml prompt missing /kelos needs-input comment and kelos/needs-input label

README expectation (self-development/README.md, line 132):

Posts a single triage comment with its findings, adds the kelos/needs-input label (to prevent re-triage), and posts a /kelos needs-input comment (to prevent workers from picking up the issue before maintainer review).

Actual prompt (kelos-triage.yaml, lines 142-150): The prompt only instructs the agent to add triage-accepted and optionally actor/kelos, then remove needs-triage and needs-actor:

If recommending `actor/kelos`:
  `gh issue edit {{.Number}} --add-label triage-accepted --add-label actor/kelos --remove-label needs-triage --remove-label needs-actor`

If leaving `needs-actor`:
  `gh issue edit {{.Number}} --add-label triage-accepted --remove-label needs-triage`

What's missing from the prompt:

• No instruction to add the kelos/needs-input label
• No instruction to post a /kelos needs-input comment

Impact: When triage recommends actor/kelos, it adds the actor/kelos label (which is the kelos-workers trigger label) but does NOT post /kelos needs-input. The kelos-workers spawner uses excludeComments: ["/kelos needs-input"] to defer issues that need human review. Without this comment, the workers spawner could immediately pick up a triaged issue before the maintainer has reviewed the triage result or posted /kelos pick-up.

In practice, the triggerComment: "/kelos pick-up" requirement on kelos-workers currently prevents this — the worker won't start until a maintainer comments /kelos pick-up. However, this is a defense-in-depth gap: if triggerComment were ever removed or loosened, the missing /kelos needs-input comment would become a live race condition.

More concretely, the README documents this as existing behavior, which means the intention was always to have this gate. The prompt should match the documented design.

Proposed fix: Add to the triage prompt's label-update section (after the gh issue edit commands):

After updating labels, post a comment to signal that triage is complete and the issue needs maintainer review:
  `gh issue comment {{.Number}} --body "/kelos needs-input\n\nTriage complete. Please review the triage report above and `/kelos pick-up` if you want a worker agent to implement this."`

And when recommending actor/kelos, include kelos/needs-input in the label update:

  `gh issue edit {{.Number}} --add-label triage-accepted --add-label actor/kelos --add-label kelos/needs-input --remove-label needs-triage --remove-label needs-actor`

2. kelos-squash-commits.yaml uses label instead of comment for needs-input signaling

Current prompt (kelos-squash-commits.yaml, lines 87-89):

7. Add `kelos/needs-input` label to the linked issue:
   - Extract the linked issue number from the PR body (look for `Closes #N`, `Fixes #N`, etc.)
   - Run: `gh issue edit <issue-number> --add-label kelos/needs-input`

Problem: The kelos-workers spawner filters on excludeComments: ["/kelos needs-input"], not excludeLabels: ["kelos/needs-input"]. Adding the kelos/needs-input label does not trigger the workers' comment-based exclusion filter.

The label and the comment serve different roles in the system:

• Label (kelos/needs-input): visual indicator on the GitHub UI that the issue needs human attention
• Comment (/kelos needs-input): programmatic signal that the kelos-workers spawner reads via excludeComments to prevent premature pick-up

The squash agent should do both — add the label AND post the comment — to fully signal that the issue needs maintainer review after the squash.

Evidence of the dual-signal pattern: The kelos-workers.yaml prompt itself (line 119) instructs the worker to:

Post a `/kelos needs-input` comment on the issue (gh issue comment {{.Number}} --body "/kelos needs-input")

This posts a comment, not a label. The squash agent should follow the same pattern.

Proposed fix: Replace step 7 with:

7. Signal that the linked issue needs maintainer review:
   - Extract the linked issue number from the PR body (look for `Closes #N`, `Fixes #N`, etc.)
   - Add the label: `gh issue edit <issue-number> --add-label kelos/needs-input`
   - Post the exclusion comment: `gh issue comment <issue-number> --body "/kelos needs-input\n\nCommits squashed. Please review the PR."`

Summary of changes needed

File	Issue	Fix
kelos-triage.yaml	No /kelos needs-input comment or kelos/needs-input label after triage	Add comment and label instructions to both actor/kelos and needs-actor code paths
kelos-squash-commits.yaml	Step 7 adds label but not comment	Add /kelos needs-input comment alongside the label

Relationship to existing issues/PRs

• Issue Workflow: Triage-to-worker handoff loses structured context — add WorkItem metadata enrichment #455 (triage-to-worker metadata enrichment) — different concern; Workflow: Triage-to-worker handoff loses structured context — add WorkItem metadata enrichment #455 is about passing structured triage data to workers, not about the /kelos needs-input exclusion gate
• Issue Prompt Tuning: kelos-workers step 7a uses issue number in gh pr edit and lacks CI monitoring guidance #592 (workers step 7a template variable misuse) — different concern; covers {{.Number}} in gh pr edit
• PR Sync task templates with TaskSpawners and document tasks/ directory #551 (task template sync) — covers task template drift, not the spawner prompts themselves
• Issue Configuration Alignment: AgentConfig co-location incomplete after PR #555, README stale, and agentsMD still drifted #601 (AgentConfig co-location and drift) — covers agentsMD drift, not prompt logic

[kelos-bot]

🤖 Kelos Agent @gjkim42

Kelos Triage Report

Kind: kind/bug
Priority: priority/important-longterm — The triggerComment: "/kelos pick-up" on kelos-workers prevents the race condition in practice, but the prompts diverge from the documented design in self-development/README.md (line 132), creating a defense-in-depth gap
Actor: actor/kelos — Well-scoped YAML prompt edits in two files with clear proposed fixes and objectively verifiable results

Status: STILL VALID

Evidence:

• kelos-triage.yaml lines 142-148: after triage, the prompt only updates labels (triage-accepted, actor/kelos) but never instructs the agent to post a /kelos needs-input comment or add the kelos/needs-input label. The README (self-development/README.md, line 132) explicitly documents both as expected behavior.
• kelos-squash-commits.yaml lines 87-89: step 7 adds the kelos/needs-input label but does not post the /kelos needs-input comment. The kelos-workers spawner (line 43-44) filters on excludeComments: ["/kelos needs-input"], not labels. The label alone does not prevent premature worker pick-up.
• kelos-workers.yaml line 119 confirms the comment-based pattern: the worker agent itself posts /kelos needs-input as a comment, not a label, validating the dual-signal expectation.
• No merged PRs or recent commits address this issue.

Duplicates found: None found

• Prompt Tuning: kelos-workers step 7a uses issue number in gh pr edit and lacks CI monitoring guidance #592 — different concern (step 7a template variable misuse in kelos-workers)
• Workflow: Triage-to-worker handoff loses structured context — add WorkItem metadata enrichment #455 — different concern (structured metadata enrichment in triage-to-worker handoff)
• Configuration Alignment: AgentConfig co-location incomplete after PR #555, README stale, and agentsMD still drifted #601 — different concern (AgentConfig co-location and drift)

Recommendation: KEEP OPEN