feat: add support for /stdlib todo slash command

[anandkaranubc]

Resolves stdlib-js/metr-issue-tracker#185

Description

What is the purpose of this pull request?

This pull request:

• adds support for /stdlib todo slash command

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• [RFC]: add support for a stdlib-bot todo command metr-issue-tracker#185

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

Used Cursor+VS Code code-generation tools to help assist with the feature.

---

@stdlib-js/reviewers

[kgryte]

Left a few more comments.

[kgryte]

Looks to good to me.

Would be good for @Planeshifter to have a look, with particular regard for any potential security concerns.

[kgryte]

@Planeshifter In particular, we want to ensure that we don't need any additional guards to prevent secret exfiltration.

[Planeshifter]

Looks good to me overall, including from a security perspective.

For consistency, let's use the same condition as in 89f67e9,

&& contains(fromJSON('["OWNER","MEMBER"]'), github.event.comment.author_association)

in addition to the runtime check. One advantage is that write-scoped PAT is never provisioned onto a runner for a non-member and we save CI minutes, but there is no exploitable attack vector here.

One problem might be that for issue comments at least, the slash commands workflow is also triggered for edits. Since there are no checks for whether issue was already created for a comment, edits of a /todo comment might unexpectedly create additional issues. Not a blocker in my view but something that would better be addressed.

[kgryte]

One problem might be that for issue comments at least, the slash commands workflow is also triggered for edits. Since there are no checks for whether issue was already created for a comment, edits of a /todo comment might unexpectedly create additional issues. Not a blocker in my view but something that would better be addressed.

I suppose we could go two ways here:

1. Authors have to simply know that comments, once written, cannot be edited.
2. We somehow persist a comment ID and its associated issue ID. In this scenario, before opening an issue, we'd need to check the persistence store. If not present, create the issue. If already present, then we'd be left with a choice. We could either update the existing issue OP or we could do nothing. The former is slightly problematic as the issue OP could be independently edited after creation and overwriting would undo those changes. That doesn't seem desirable. For the latter, we could post a follow-up comment stating that the edit is purely local, but this just seems like additional complication.

As I don't see this being heavily used (abused) by maintainers, I think it is fine to punt the responsibility to authors to know that todo comments should not be edited.

I suppose a third possibility is to do (2), but instead of overwriting the OP, the bot could post a verbatim comment to the existing issue thread.

Again, not sure if it is worth the effort.

@anandkaranubc At a minimum, we can update the bot response comment after issue creation to state that any subsequent edits should be made to the issue itself rather than by updating the todo comment.