---
name: iflow-comments
description: >-
  Triage a GitHub issue's comment thread into the curated, bucketed summary
  section of issue<N>_original.md.
disable-model-invocation: true
issue-flow-version: 0.4.2a4
---

# issue-flow — issue comments triage

Follow this skill to turn a GitHub issue's comment thread into a short, decision-useful summary that lives next to the original issue body under `.issueflows/01-current-issues/issue<N>_original.md`.

It is the playbook that `/iflow-capture` (and the `iflow-capture` skill) delegate to for anything beyond fetching raw comments. It also covers re-triage of an already-captured issue when new comments arrive (the issue body text stays unchanged; only the curated section is rewritten).


### MODEL & EXECUTION DIRECTIVE


**Profile: economy** — Prioritize speed and token economy over deep reasoning.

In Cursor: use **Auto** or a fast model before invoking this step.



Keep scope tight to what this step requires.



## Inputs

A JSON array of comments as returned by:

```
gh issue view <N> --repo owner/repo --json comments -q .comments
```

Each element has at least:

- `author.login` — commenter handle
- `body` — markdown text
- `createdAt` — ISO timestamp

If you only have raw comment text, ask for the structured form (author + date matter for tie-breaking and for the footer).

## Triage rules

1. **Chronological precedence.** Walk the comments oldest → newest. If a later comment contradicts or walks back an earlier point, the earlier point moves to **Superseded / retracted** and the later one takes its place in the appropriate bucket.

2. **Three buckets, pick exactly one per surviving point.**
   - **Additional tasks** — new, concrete work that is not already in the issue body. Phrase as imperatives ("also update X", "add Y to Z"). If the point is vague ("maybe do something about caching"), either sharpen it into a task or drop it.
   - **Clarifications / constraints** — guidance on *how* to do the existing work: scope boundaries, non-goals, must-keep behaviors, stylistic or architectural preferences, acceptance criteria. Useful phrase: "when doing X, make sure Y".
   - **Superseded / retracted** — earlier tasks, preferences, or decisions that a later comment explicitly or implicitly walked back. Keep these visible (don't silently delete them) so the agent doesn't redo retracted work.

3. **Drop the noise.** Do not include:
   - Bot comments (CI, coverage bots, auto-assign bots, etc.).
   - Pure chit-chat, "LGTM", "+1", emoji-only reactions.
   - Status pings ("any update?") without new content.
   - Comments that only quote earlier ones without adding anything.

4. **Collapse duplicates.** If two commenters make the same point, record it once.

5. **Paraphrase; quote sparingly.** Short direct quotes are fine when exact wording matters (e.g. a feature name, an error message). Otherwise rewrite in your own words so the summary is scannable.

6. **Handle open disagreement honestly.** If two authors openly disagree and no later comment resolves it, record the disagreement under *Clarifications* (for example: "author A prefers option X, author B prefers option Y — no resolution in thread"). Do not guess a winner.

7. **Respect maintainer authority when obvious.** If the repo owner or a maintainer explicitly overrides an earlier suggestion, treat that as the winning position and move the overridden suggestion to *Superseded*.

## Output contract

Write exactly this block into `issue<N>_original.md`, immediately after the `## Original issue text` section:

```markdown
## Comments (curated summary)

- **Additional tasks**: <bullets distilled from comments that add real work>
- **Clarifications / constraints**: <bullets the agent should honour>
- **Superseded / retracted**: <earlier points later contradicted or walked back>

_Note: this section is an interpretive summary of the comment thread, not a verbatim dump. Source comments: <count>, last comment by @<login> on <date>._
```

Formatting rules:

- Each bucket's bullet is itself a list if there is more than one item — nest concrete bullets under the bold label.
- **Drop any bucket that is empty** — do not leave `- **Additional tasks**: ` with no content.
- **Always keep the `_Note: ..._` footer** when the section exists. Use the total `comments` length for `<count>` and the `author.login` + date of the most recent non-dropped comment for `@<login>` / `<date>`.

## Edge cases

- **Zero comments** — skip the whole section. Do not write an empty `## Comments (curated summary)` header.
- **All comments are noise** (bot-only, pure chit-chat, emoji) — skip the whole section. Note this in the command's final report ("N comments fetched, all filtered as noise — section omitted").
- **Every surviving point lands in a single bucket** — that's fine; just emit that one bucket.
- **Multi-author thread with heated disagreement** — log the disagreement under *Clarifications*, do not invent a resolution.
- **Comments reference external PRs, gists, or linked issues** — keep the reference (shortened URL or `owner/repo#N`) in the bullet, but do not fetch the linked content; it's out of scope for this skill.
- **Comments include code blocks the agent will need later** — summarize the intent in the bullet and mention that the full snippet is in the linked comment; do not paste large blocks into the summary.

## Constraints

- This skill only writes into the `## Comments (curated summary)` section of `issue<N>_original.md`. It never touches the issue body, the status file, or the plan file.
- It never calls `gh` or the network itself — it expects the caller (`/iflow-capture` or similar) to provide the comments JSON.