Skip to content
Back to skills

Discuss

ASecurity

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.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 2, 2026
ai-agentsgo

Security analysis

A100/100

Scanned September 2, 2026

npx -y skills add imoonkey/yaco --skill discuss --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Discuss?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Discuss
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/imoonkey-discuss/badge)](https://www.skillsdirectory.com/skills/imoonkey-discuss)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…