Persistent discussion
SkillDocs & knowledgeSilently persist and recover visible multi-turn clarification, interviews, design Q/A and brainstorming, regardless of which Skill or prompt starts them. Use for ongoing discussion, not ordinary single-answer chat.
Use Persistent discussion in Claude, ChatGPT or Ahel Desktop
Free. Sign in, add Persistent discussion and connect your AI. About a minute.
Also: Claude Code · Cursor · Codex
Then ask your AI: use the Persistent discussion skill
Details
Instructions available. Your AI can read the instructions. Execution depends on the setup they require.
Account requirements not reviewed. Check the skill instructions before use; Ahel provides instructions and does not run this skill.
No other account needed.
Add Ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.
What this skill tells your AI
The instructions your AI receives, as published by janyork/llm-wiki-cli in skills/using-discussion/SKILL.md and read by Ahel’s review.
When a user requests or enters iterative clarification/brainstorming, use this protocol alongside the active domain Skill (including grill-me, grilling or superpowers). No name allowlist. Do not initiate questions merely to use it. Reuse the authorized project SQLite and current Hook's opaque agent context. Never manufacture another context, initialize a missing Wiki, or install tooling solely to record. An unavailable store is a capture limitation, not permission to pretend the conversation is saved. Without a resolved context, disclose the gap.
Use lwc contract discussion once for the exact schema and example. CLI
lwc discussion apply --json - and MCP lwc_discussion action apply share it.
MCP always requires the current absolute projectPath. Never pass shell-interpolated
user text: serialize JSON to stdin or structured MCP arguments.
- Recover
discussion current --context CONTEXTbefore starting or after a compact/restart. No binding means start a discussion with a unique ID, title, description and stable request ID. The firststartbinds only this context. - Save each question and options with stable IDs before displaying identical text. Question preparation is not proof of display. Only report delivery with a host message reference; it remains reported evidence.
- On each user reply, persist exact visible text before analysis or another
question. An
answerreferences its parent question; multiple messages have separate IDs. If association is ambiguous usereplyand latermoveit to a question. Preserve multi-question original responses; never invent a split. - Read unassigned host replies first to avoid duplicate recording. Message IDs deduplicate supplied host events; unsupported/missing IDs fall back to this Agent protocol, never a guarantee of complete host capture. Do not reread full transcripts or store expanded prompts, tools, system text or reasoning.
- Batch the preceding answer and next question when possible. Use the last receipt's revision and one stable request ID. On uncertain result retry the identical input; on conflict reload and reconcile. Never blindly replay with a new ID. Successful receipts are silent: no logging commentary is necessary.
- On persistent failure, notify the user once that capture is incomplete and
keep retrying only within the task's scope. Do not continue claiming durable
capture. For excluded secrets submit a
gapwith a nonsensitive description; never store the secret in the reason, ID or retry log. This is an explicit exception for visible Discussion records, not general prompt logging.
Local adjustment and completion
revise changes one item's current text, retaining original text and history;
require a reason. Represent answer fragments/options/summary conclusions as
separate stable items to edit at that granularity. move updates parent/ordinal;
combine moves and new questions to split or merge groups without deleting IDs.
withdraw/restore retain history. metadata changes title/description.
confirm is only for a user's explicit confirmation, with the visible basis in
reason. Never mark an Agent proposal confirmed. Summary refs must form a DAG.
Write the detailed summary as separately addressable summary items: background,
requirements/constraints, alternatives and tradeoffs, decisions and rationale,
user corrections, unresolved questions, risks and next actions. Every item cites
question/answer IDs. revise a stale summary with current refs after rechecking
its evidence; unrelated conclusions stay intact. Newly introduced topics may
require additional summary items. Do not equate a generated summary with user
approval or implementation authorization.
close requires current summaries and all active questions answered; explicitly
withdraw waived questions with the user's reason. pause preserves pending work
and releases binding. resume requires a reason; cross-context resume supplies
from_context explicitly (empty for an imported unbound discussion). Never guess
or silently take over another task. After closing, deliver the saved summary.
Use list --context CONTEXT to discover owned/imported discussions and item ID ITEM --context CONTEXT for one item. Read show and history using limit/offset; use export only for an explicitly
needed full JSON artifact. SQLite alone owns the records. Do not mirror raw Q/A
into Wiki or filesystem memory. Promote confirmed reusable knowledge separately
with Discussion item references when requested or justified by project policy.
Signals
- GitHub stars
- 64
- Forks
- 7
- Last commit
- Oct 2026
Advanced
- Item type
- skill
- Key
using-discussion- Source
- github.com/janyork/llm-wiki-cli
github.com/janyork/llm-wiki-cli
More in Docs & knowledge
Skill · mattpocock
More in Docs & knowledgecanvas-design
Skill · anthropics
More in Docs & knowledgedoc-coauthoring
Skill · anthropics
More in Docs & knowledgepopups
Skill · coreyhaines31
More in Docs & knowledgewriting-for-agents
Skill · mattpocock
More in Docs & knowledgespec-driven-development
Skill · addyosmani
More in Docs & knowledge