Docs

Answer

The answer workflow handles questions. When a newly-opened issue (or a Slack message) is classified as a question — someone wanting information, an explanation, or a comparison rather than a code change — this workflow researches the repo docs and the web, then posts a single sourced answer. It never opens a PR or hands off an agent brief.

Permission profile: issues-write — can read repo contents, post issue comments, and label issues.

Pipeline

Answer research + reply

What it does

  • Researches the repo's documentation plus the web for relevant context
  • Posts a single sourced answer comment
  • Labels the issue question and leaves it open
  • No agent brief, no PR — just the answer

Delivery

For GitHub-initiated runs, the answer is posted as an issue comment. For Slack-initiated runs, it's posted in the originating Slack thread.

Triggers

  • GitHub: a newly-opened issue classified as a question (route issue_answer)
  • Slack: a message classified as a question (route answer)

On Slack the bar is deliberately high, because this workflow provisions a sandbox while chat replies in-process in seconds — and chat is not toolless: it already reads repos, issues and their comments, pull requests and their diffs, file contents, commit history, and searches code. So a Slack question only reaches answer when it needs one of the two things chat can't do — the web (comparisons with other tools, upstream docs, current external facts) or real exploration of a checkout (tracing a behaviour across many files). "What does this workflow do?" or "what changed in PR #273?" are answered by chat, even though they name a repo. A newly-opened GitHub issue that asks a question always runs this workflow — an issue has no chat surface to fall back to.

Skill

This workflow uses the issue-answer skill.