Reading the code, I noticed that when a label matches labelPrompts (e.g. Feature → builder), the prompt goes through buildLabelBasedPrompt(), which does not fetch or include Linear comments — while the fallback path (buildIssueContextPrompt()) does.
PR #105 introduced this and described it as "No Linear comments for focused processing." I'd like to understand the reasoning better:
- What does "focused processing" gain by hiding comments? Was the concern token cost? Distraction / off-topic noise? Something else?
- Was the assumption that the description is always the source of truth, and comments are sidebar discussion?
- builder / debugger / scoper system prompts also don't tell Claude to call
list_comments itself — so on the label path, Claude has no signal that comments even exist. Is that intentional too?
Asking because in practice we often discuss in comments and then assign (e.g. a blocker gets resolved in a comment, then we hand off to Cyrus). On the label path Cyrus acts on the stale description and misses the resolution. Curious whether this is a use case the maintainers consider in scope, or whether the expectation is "put final scope in the description before assigning."
If the original rationale still holds, no change needed — just want to understand it before working around it. If it's open to revisiting, happy to PR.
Reading the code, I noticed that when a label matches
labelPrompts(e.g.Feature→ builder), the prompt goes throughbuildLabelBasedPrompt(), which does not fetch or include Linear comments — while the fallback path (buildIssueContextPrompt()) does.PR #105 introduced this and described it as "No Linear comments for focused processing." I'd like to understand the reasoning better:
list_commentsitself — so on the label path, Claude has no signal that comments even exist. Is that intentional too?Asking because in practice we often discuss in comments and then assign (e.g. a blocker gets resolved in a comment, then we hand off to Cyrus). On the label path Cyrus acts on the stale description and misses the resolution. Curious whether this is a use case the maintainers consider in scope, or whether the expectation is "put final scope in the description before assigning."
If the original rationale still holds, no change needed — just want to understand it before working around it. If it's open to revisiting, happy to PR.