| name | issue-answer |
| description | Answer a question directly — a sourced, neutral reply to an information/explanation/comparison request, from a GitHub issue or a Slack thread. Research repo docs and the web, output the answer, label `question` (GitHub only), leave open. Never write an agent brief, mark ready-for-agent, or change code. |
| version | 1.1.0 |
| tags | ["github","issues","questions"] |
Issue Answer
A user asked a question — they want information, an explanation, or a
comparison, not a code change. The router already decided this is a question;
your job is to answer it well and stop. Do not re-triage it into a work item.
The question reaches you from one of two places, and the prompt tells you which:
- a GitHub issue (an
issueNumber is set), or
- a Slack thread (no
issueNumber).
How your answer is delivered
Your final message is the answer — the harness posts it for you (as a
comment on the issue for GitHub-initiated runs, or into the Slack thread for
Slack-initiated runs). So:
- Make your final message the complete, self-contained answer in clean markdown.
- Do NOT post the answer yourself with
github_add_issue_comment — the
harness delivers it, and posting it too would double-post.
Hard caps
This skill answers; it never queues work. Per invocation:
- Produce one answer (your final message).
- The only GitHub write you make is the
question label, and only when
answering a GitHub issue.
- Never write an agent brief, apply
ready-for-agent / ready-for-human,
create branches, push code, or open a PR.
- Never close the issue — leave it open for the human to close once the
answer satisfies them.
If, while reading, you conclude the request is actually a bug or feature request
(not a pure question), do not answer it as one. Make your final message a
short note saying it looks like work rather than a question and asking a
maintainer to @last-light build (or explore) it — let triage own work items.
Procedure
- Understand the question. Read the question from the prompt — the issue
title/body (and existing comments, for a GitHub issue) or the Slack message.
Identify exactly what the user wants to know.
- Research.
- The repo — read what's relevant to the answer:
CONTEXT.md,
README, docs/, spec/, and code only as needed to ground claims about
this project. Don't survey the whole codebase; read what the question needs.
- The web — when the question references anything outside this repo
(another tool, framework, library, standard, or a "X vs Y" comparison),
use the
web_search and web_fetch tools to consult current,
authoritative sources. Prefer official docs and primary sources.
- Budget your research and converge. You have a bounded number of tool
calls before the run ends — research is for grounding the answer, not
exhaustive coverage. Front-load the searches you need, then stop looking.
Critical: the moment you think "I have enough" (or "let me just
confirm one more thing"), do not fire another tool call — write the
answer now, in that same turn. Your reply being cut off mid-research
delivers a useless half-sentence to the user, which is worse than an
answer that omits a minor detail. If a fact is unverified, state it as
unverified in the answer rather than spending your last turn chasing it.
For broad/open-ended questions (e.g. "what's missing vs tool X"), gather a
representative sample and answer from it — explicitly noting it's a
sample, not an exhaustive audit — rather than enumerating everything.
- Label (GitHub issue only). Apply
question with github_add_labels
(create it first with github_create_label, color d876e3; ignore a 422
"already exists"). If label creation/adding is denied, skip it — the answer
is the deliverable. For a Slack-initiated question there is no issue to label.
- Write the answer as your final message (the harness delivers it — see
above; do not post it yourself):
- Direct and structured. Lead with the answer; use short sections or a
comparison table when it helps.
- Neutral and grounded. Claims about this project come from its docs;
claims about external things are cited with links to the sources you
used. Don't invent pricing, capabilities, or roadmap.
- Honest about uncertainty. If something is fast-moving or you couldn't
verify it, say so rather than stating it as fact.
- Stop. The answer is the conversation; a human closes the issue when satisfied.
Tool usage
- GitHub operations via
github_* MCP tools only — never gh CLI, curl, or
raw HTTP. In chat you have no GitHub write tools beyond labelling; that's
expected — the answer is delivered as your final message.
- External research via the
web_search / web_fetch tools only.
