MCP.Market

thinking-out-loud skill

by Shubhamsaboo·Shubhamsaboo/awesome-llm-apps·145k stars·Apache-2.0

A contract for what the agent does when a long, messy, stream-of-consciousness ramble arrives (usually voice dictation): act on nothing until the echo brief is approved. The echo audits the entire transfer, mission, locked decisions and constraints, open questions, flips and parked tangents, with the model's inferences and guesses quarantined away from the user's own phrasing, so the user verifies what the model believes, not just what it doubts. Use when the user says "let me think out loud" or wants to ramble a bit before building anything, when a message opens with a speech-to-text preamble like "switching to voice, sorry for typos", when input is a long weakly punctuated stream with restarts and mid-message reversals ("actually no, wait, scrap that idea entirely"), or when the user asks to be interviewed about a fuzzy half-formed idea. Includes an optional capture mode for rambles spread across several messages and an optional targeted interview.

A100/100content scan

Is the thinking-out-loud skill safe?

Clean: nothing in its files matched our rules. We read 3 files in the folder on 2026-10-25.

No findings.

Install the thinking-out-loud skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/Shubhamsaboo/awesome-llm-apps.git /tmp/awesome-llm-apps
mkdir -p ~/.claude/skills
cp -r /tmp/awesome-llm-apps/agent_skills/thinking-out-loud ~/.claude/skills/thinking-out-loud
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

Thinking Out Loud

A ten minute voice ramble transfers more context than any prompt a person would type, and models reconstruct rambles well. The failure is downstream and invisible: the model fills every gap in the ramble confidently. "The usual model" silently becomes a specific model. "The standard size" becomes a specific viewport. A position the user reversed mid-ramble survives as fact. None of this registers as uncertainty from the inside, so none of it ever becomes a clarifying question. The model then acts on a misreading it fully believes, and the user discovers it an hour of generated work later.

This skill is the fix: before acting on any ramble, produce an echo, a short structured audit of everything absorbed, with the model's own additions quarantined from the user's words. The user corrects three lines instead of debugging a built artifact.

Why an echo instead of follow-up questions

Asking clarifying questions is good, and the interview below does it. But questions alone cannot secure a ramble, for two structural reasons:

model believes.** A clarifying question requires felt uncertainty, and confident misreadings feel like knowledge. The echo forces every inference and gap-fill into the open whether or not it felt uncertain.

  • **Questions verify what the model doubts. The echo verifies what the

facts and half-decisions. Even good questions probe three or four; the rest of the model's understanding goes unverified into action. The echo inventories the entire transfer, and it works by recognition, not recall: the user reads and spots what is wrong, which is far cheaper than producing answers, and ramblers often do not know their answer until they see the wrong guess written down.

  • Questions sample; the echo audits. A long ramble carries dozens of

The contract

fragments, until the echo is approved. Reconstruct first.

  1. Act on nothing. No file edits, no code, no plans, no solutions to

section, apart from the user's own content. Never present a guess in the user's voice.

  1. Label every addition. Inferences and guesses live in their own

flip. Never silently average or pick.

  1. Surface every reversal. Adopt the later position, but flag the

and restarts are resolved silently from context. Keep the user's own vocabulary and project names.

  1. Lose nothing. Tangents get parked, not dropped.
  2. Never remark on dictation artifacts. Typos, homophones, filler,

saved unprompted.

  1. Ask before persisting. The approved brief is offered a home, never

When to use

restarts, filler, and mid-message reversals ("actually no, scrap that")

  • A message is a long, weakly punctuated stream of consciousness with

recognition, sorry for any typos", "dictating this")

  • A message opens with a voice preamble ("switching to speech
  • The user says they want to ramble or think out loud
  • The user asks to be interviewed to untangle a fuzzy idea

When not to use

while keeping their exact words

  • Short requests that are already clear
  • The user wants a verbatim transcript, minutes, or cleanup of dictation
  • Long but already structured text, such as a pasted spec or document
  • The user asked a direct question and wants a direct answer

The echo

One structured reply. Dense, scannable, and short: the user should find and fix an error in seconds. Full template with a worked example in references/echo-format.md.

achieve. Often this differs from what they said first; that is fine.

  1. Mission: one sentence stating what the user is actually trying to

list. Mark anything they called a top priority.

  1. Locked: the user's decisions and constraints, merged into one

parked tangents (one line each).

  1. Open: questions the ramble raised but did not answer.
  2. Ledger: flips (both positions in one line, later one adopted) and

(strongly implied but never stated) and "Guessed" (gaps you filled). Tell the user to correct these first.

  1. My additions: the only interpretation callouts. "Inferred"

Compression rules, non-negotiable:

own content by definition; only the model's additions get called out.

  • Nothing appears twice. Every fact lives in exactly one section.
  • No "you said" recap. Everything outside My additions is the user's

or it is bloat.

  • One line per bullet. If a bullet needs two lines, it is two bullets

"standard size", "soon": each lands in Open or Guessed, never absorbed into a locked item as if it were specified.

  • Vague quantifiers are never silently resolved. "The usual model",

Close by inviting corrections and offering the interview.

The interview (optional)

Follow-up questions have their place: after the audit, not instead of it. Only if the user accepts the offer, or asked to be interviewed up front.

  • Ask only about items flagged in Open or Guessed
  • One question per message, highest information gain first
  • Each question states in one clause why it matters
  • Cap at five questions; stop early once answers stop changing the brief
  • After the interview, restate only the sections of the echo that changed

Capture mode (multi-message rambles)

Not needed for dictation tools, where the whole ramble arrives as one message. Use it when the user invokes the skill before rambling and then adds thoughts across several messages, possibly over a long stretch.

'done' when you want the echo.")

  • Acknowledge once, in one short line ("Go ahead, I'm listening. Say

("Listening."). Vary it slightly so it does not feel robotic.

  • For every following message, reply with a single minimal line

sentences, then return to listening.

  • Do NOT solve, praise, summarize, analyze, or ask questions mid-stream.
  • If the user asks a direct question mid-ramble, answer it in at most two

any clear equivalent, then deliver the echo.

More skills from Shubhamsaboo/awesome-llm-apps

  • Aadvisor-orchestrator-workerUse when a task is too large for one model pass, needs parallel research or generation across many subtasks (like researching a dozen competitors at once), or the user asks to orchestrate multiple models, split work across a model team, run an advisor-worker loop, have a stronger model review the plan while cheap workers execute, or says "too big for one model" or "fan this out". Not for single-file edits or tasks one model handles in one pass.
  • Achatgpt-app-builderDEPRECATED: This skill has been replaced by `mcp-app-builder`. Check if `mcp-app-builder` is available in the skills folder. If not, install it: `npx skills install mcp-use/mcp-use --skill mcp-app-builder` Use `mcp-app-builder` instead of this skill.
  • Acommit-archaeologistReconstructs why code exists from local git history, including the introducing commit, later changes, current authors, repeated companion files, and likely intent. Use when the user asks "why does this code exist", "who wrote this function and why", or to "explain the history of this function" before a rewrite, refactor, or risky edit. Runs entirely locally.
  • Adependency-doctorChecks requirements.txt, pyproject.toml, and package.json dependency manifests for surface-level direct-dependency footguns: standard-library shadowing pins, abandoned backports, unpinned dependencies, and obvious intra-manifest conflicts, plus opt-in PyPI yanked releases. Use when the user asks to check a manifest for dependency problems, asks why dependencies won't install or whether anything is wrong with their dependencies, wants a dependency autopsy, or suspects dependency manifest rot. Runs offline by default as a local tool for the user's own project, not repository CI.
  • Afirst-readerBeta readers for any draft, run by simulating how a real reader experiences it, moment by moment. A skim gate, a no-lookahead timed read producing an attention transcript with quit points, a recall test of what a reader remembers the next day, and a trust ledger of the implied author. Use when the user asks for a beta read, beta readers, test readers, human review, reader review, to read something like a human, to be a first reader, whether a piece holds attention or will actually get read, for a quick read of whether a busy skimmer would even open a post, what readers will remember or take away tomorrow, where readers stop reading or bounce, or why a draft still feels off or hollow after anti-slop or humanizer edits. Final gate before publishing; reports where the reading broke; never rewrites.
  • Amcp-apps-builder**MANDATORY for ALL MCP server work** - mcp-use framework best practices and patterns.
  • Amcp-builderDEPRECATED: This skill has been replaced by `mcp-app-builder`. Check if `mcp-app-builder` is available in the skills folder. If not, install it: `npx skills install mcp-use/mcp-use --skill mcp-app-builder` Use `mcp-app-builder` instead of this skill.
  • Aproject-graveyardScans the developer's machine for dead side projects, autopsies each one from its git history (died at the payments wall, killed by a newer project, finished but never shipped), surfaces their personal death patterns, and picks the corpse most worth resurrecting — then helps ship it. Use when the user mentions abandoned, unfinished, or old side projects, asks "what should I finish", wants to revive or resurrect a project, says "run the graveyard", wonders why they never finish anything, or is about to start a new project that sounds like one they already built. Runs entirely locally.
  • Ascope-creep-detectorAnalyzes git diffs against a stated intent to detect scope creep, unrelated files, broad pull requests, changes that grew beyond a fix, dependency additions, public API renames, config or CI edits, oversized hunks, and formatting-only files. Use when the user asks whether a change grew beyond the fix, a PR is too broad, or what unrelated stuff they touched, and wants keep, split, or justify guidance. Operates locally and offline.

All agent skills → · MCP servers