Reply in place to `>`-marked comments inside a markdown doc, keeping multi-round Q&A navigable. Use when the user runs `/discuss` or left notes/questions in a doc to answer inline rather than in chat.
Scanned 9/2/2026
Install to Claude Code
npx -y skills add imoonkey/yaco --skill discuss --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Discuss?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/imoonkey-discuss)More formats (shields.io, HTML) on the badges page.
---
name: discuss
description: Reply in place to `>`-marked comments inside a markdown doc, keeping multi-round Q&A navigable. Use when the user runs `/discuss` or left notes/questions in a doc to answer inline rather than in chat.
---
# Discuss
The user thinks by leaving comments in a doc — each marked with a `>` blockquote
so it stands out in the markdown preview — and wants you to answer them *in
place*, right under each comment. Two jobs: answer well, and keep the thread
navigable as it grows across rounds.
They invoke this with `/discuss` after writing a new comment, so you won't get a
restatement of the question — go find it. Lifecycle: each `/discuss` is one
round (find new comments → reply in place); when the discussion converges,
`/discuss wrap up` folds the decisions into the doc and archives the thread (see
**Wrap-up** below).
## Find what to answer
A comment awaiting reply is a `>` blockquote with **no `>>` reply nested under
it**. Answer every such comment — a single `/discuss` may have several. They're
usually at the bottom, but scan the whole doc: a follow-up often lands
mid-thread, right under an earlier exchange.
The doc is normally the file in context (open or just-edited). If it's unclear
which file or which comment, ask rather than guess.
## Format
Keep the user's question in `>`; nest your reply one level deeper in `>>`. The
nesting renders as an inset quote, so Q and A separate at a glance with no extra
labels. Number turns so the newest round and the thread structure are obvious:
```markdown
> **Q2** an earlier topic — next integer
>
>> **A2** reply keeps full markdown: `code`, lists, [links] all work
> **Q2.1** a follow-up to Q2 — decimal, stays attached to its thread
>
>> <mark>**A2.1**</mark> your reply — the A marker is highlighted
> **Q3** the comment you're answering now
>
>> <mark>**A3**</mark> your reply
```
- **Number** — new topic → next integer (`Q3`); follow-up to the latest thread →
decimal (`Q2.1`). Judge from content: does the comment continue the previous
exchange or open a new subject? Placement is a hint — a comment sitting right
under the last reply is usually a follow-up.
- **Highlight what's new this pass** — first strip the `<mark>` off the previous
pass's replies, then wrap the `**A{n}**` marker of *every* reply you write this
pass in `<mark>…</mark>`. The marks then point at exactly what you just added —
one reply or several — and fade next time. Mark only the **A** marker: not the
question (the user's own text), not the whole reply block (a wall of yellow is
hard to scan).
- **You keep the books** — the user writes a bare `> their comment`. You add the
`**Q{n}**` marker, the number, and the `<mark>` on your `**A{n}**`.
Don't reformat earlier turns — leave the discussion's history as-is and apply
this format to the round you're adding. If the doc already uses its own marker
words (e.g. `Comment N` / `→ Reply`), continue those for consistency, but still
add the number and move the `<mark>` so navigation works.
## Reply well
The format only makes answers findable; the answer is the point. Two steers
against failure modes specific to replying to comments:
- **Don't rubber-stamp.** Being asked to "reply to a comment" pulls toward
agreement. If you disagree, push back with evidence — these comments are left
to be challenged.
- **Verify, don't guess.** When the question is about the system, read the code
or run it before you answer. A doc answer carries `file:line` weight, not
chat-quick-take weight.
## Wrap-up
When the discussion has run its course and the user says `/discuss wrap up …`,
fold the outcome into the deliverable and clear the scaffolding — the Q/A was a
means to decisions, not part of the product.
- **Land the decisions in the main body.** Update the design (or code / skill) to
reflect what the discussion settled, and make it self-contained: someone who
never read the thread should get the full picture, rationale included.
- **Archive the thread, don't strip it silently.** Move the `>` / `>>` blocks
verbatim to a `## Discussion Archive` under a `# Appendix`, creating both if
they don't exist. If the discussion lives in a skill, code, or other
deliverable rather than a design doc — where an appendix doesn't belong — ask
the user whether to delete the blocks or move them to a separate file.Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!