Move Bot Comment Text and Documentation Links into Template/Config Layer

[darshit2308]

👾 Description of the Task

Many bot comments currently combine reusable automation logic with C++ SDK-specific wording, documentation links, support team mentions, and contributor guidance.

This makes the bot harder to reuse across SDK repositories because another repository would need to copy and edit JavaScript files just to change text, links, or support contacts.

Relevant Files

• .github/scripts/helpers/comments.js
• .github/scripts/commands/assign-comments.js
• .github/scripts/commands/finalize-comments.js
• .github/scripts/bot/bot-recommend-issues.js
• .github/scripts/tests/test-comments.js
• .github/scripts/tests/test-assign-bot.js
• .github/scripts/tests/test-finalize-bot.js
• .github/scripts/tests/test-recommend-issues-bot.js

💡 Proposed Approach

Introduce a template/config layer for bot messages and repository-specific links.

The initial goal should be to extract C++ SDK-specific content, not to build a complex templating system. Simple functions backed by config values are sufficient.

Examples of Content to Extract

• Signing guide URL
• Workflow guide URL
• README setup URL
• Merge conflict guide URL
• Discord/community URL
• Support team mention
• Maintainer team mention
• Welcome message repository name
• PR helper bot wording
• Skill-level boilerplate text

👩‍💻 Implementation Steps

• Identify user-facing bot comments that contain C++ SDK-specific text or links
• Add a message/template helper that receives config values
• Move documentation URLs and team mentions into config
• Refactor comment builders to use the message/template helper
• Keep generated comments unchanged where possible
• Update snapshot/string assertion tests as needed
• Add tests for template rendering with custom repository values

✔️ Acceptance Criteria

• C++ SDK-specific links and team mentions are no longer hardcoded throughout comment logic
• Existing bot comments remain unchanged for the C++ SDK configuration
• Tests cover rendering with configured values
• The comment layer can support another repository without copying and editing bot logic
• Existing bot script tests continue to pass

🤔 Additional Information

This directly supports reusable automation across SDK repositories while keeping contributor-facing messages clear and repository-specific.

[rwalworth]

Thanks for putting this together @darshit2308. I just finished going through #1634 in detail, and the upshot is that this issue needs a re-scope before I can triage it - most of what's in the "Examples of Content to Extract" list is actually done (or going to be done) by #1634, and what's left is a narrower and more design-ambiguous slice. Let me lay out where I'm landing.

What #1634 already covers from this issue's list:

• Signing guide URL: documentation.signingGuide
• Workflow guide URL: documentation.workflowGuide
• README setup URL: documentation.readme
• Merge conflict guide URL: documentation.mergeConflictsGuide
• Discord/community URL: community.discordChannel
• Support team mention: goodFirstIssueSupportTeam
• Maintainer team mention: already extracted previously as MAINTAINER_TEAM

So roughly seven of the ten items in the original list are no longer this issue's responsibility - they're #1625's, via #1634. That matches the boundary I drew on the #1625 thread: structural policy values (URLs themselves, team mentions, labels, limits, hierarchies) belong to #1625; user-facing bot comment prose and any URLs that get built from templates inside that prose belong here.

What's legitimately left for this issue:

1. SDK display strings embedded in comment bodies: "Hiero C++ SDK", "Hiero C++ SDK community", "Hiero-SDK-C++ Discord". Different from the Discord URL (already in config); this is the name shown in the link text.
2. Command-name literals in prose: the `/unassign` mention in buildWelcomeComment etc.
3. Browse-issues URL templates: the inline https://github.com/${owner}/${repo}/issues?q=... builders in assign-comments.js that hardcode "status: ready for dev" and similar label names into the query string.
4. The full English prose bodies of every buildXComment function: welcome, already-assigned, not-ready, prerequisite-not-met, no-skill-level, limit-exceeded, GFI-limit-exceeded, the dashboard greeting in helpers/comments.js, and the recommendation/error comments in bot-recommend-issues.js.

Items 1–3 are mechanical extensions of the #1634 pattern: add config keys, swap inline string for config read, update string-equality test assertions. Item 4 is the design-ambiguous one - and I think it's worth being explicit about that ambiguity before you start.

The design question on item 4: "Move comment text into a template/config layer" can mean very different things:

• Narrow: Keep the prose in-code, just extract the variables it interpolates (SDK name, command names, URLs, label names). Comment functions stay where they are; their string literals get fewer hardcoded substrings.
• Wide: Move the entire English prose body of each comment into config - every paragraph becomes a configurable message string. Possibly with a small ${var} interpolation helper.
• Wider still: Adopt a real templating engine (Mustache, Handlebars, etc.) for prose.

Your own framing in the issue ("the initial goal should be to extract C++ SDK-specific content, not to build a complex templating system") points at the narrow end, which is what I'd want too. But the issue description doesn't pick a boundary, and the test impact (string-equality assertions in test-comments.js, test-assign-bot.js, test-finalize-bot.js, test-recommend-issues-bot.js) gets very different at each end. For the narrow option the test surface is small; for the wide options the entire snapshot/assertion layer changes.

The cluster-direction question still applies here. This is the same concern I raised on #1627: the value of any of these refactors depends on what consumer SDK is on the other end of the abstraction. For #1625 (structured values) and #1626 (internal control flow split) that argument is weak - the refactors pay off locally too. For #1629, especially at the wide end of item 4, the payoff is only "another SDK can adopt this bot without editing JS." Which means the right templating boundary depends on what the consumer side looks like. I don't want to commit to a prose-template shape against a still-unsettled target.

Where I'm landing:

I'm going to move this from status: awaiting triage to status: needs info rather than triage it onto the ready-for-dev queue. Two reasons:

1. The issue description needs to be re-scoped after Refactor: Extract repository-specific automation policy into centralized configuration #1634 lands. The current list is mostly stale, and a contributor picking it up off the description alone would do work that's already done.
2. The residual scope's design boundary (narrow vs wide on item 4) is genuinely open and benefits from knowing the cluster consumer direction before we lock it in.

To unblock this:

When #1634 merges, please update this issue's description to reflect what's actually left - roughly items 1–4 above (or whatever subset of 4 you want to commit to). Pin the narrow/wide question one way: my strong recommendation is the narrow end (extract variables, keep prose in-code) unless the cluster direction calls for something bigger. At that point I'll re-triage with skill/priority and we can move forward.

On sequencing with #1626 (since both touch assign-comments.js): #1626 restructures assign.js, which calls into assign-comments.js builders. If you end up doing both, do #1626 first so the decision/effect split is in place before the builders' prose gets extracted, rather than rebasing prose-extraction work over a moving caller.

Appreciate the patience and the careful work on this series.

[darshit2308]

yes, once the #1634 is merged, I will update the issue description too. Thanks for detailed review !