explain-this

Name: explain-this
Author: tobihagemann

3installs29forks

How to install explain-this?

tobihagemann/turbo/explain-this

$npx -y skills add tobihagemann/turbo --skill explain-this

Installs into the current project.

Summary

Explain whatever the user is pointing at right now in plain language: a pending question, a piece of code, an error, a command output, or an artifact like a plan or findings report. Use when the user asks to \"explain this\", \"what am I being asked\", \"what's happening right no

Files · 1

View on GitHub

SKILL.md

1	# Explain This
2
3	Take whatever the user is pointing at and translate it into plain language. "This" is usually the most recent assistant output or something pasted as an argument: a multi-option prompt, a free-form question, a code block, an error, a command output, or an artifact like a plan, findings report, or diff.
4
5	## Step 1: Identify the Subject
6
7	Pick the subject in priority order:
8
9	1. Text passed as an argument — use that
10	2. A quoted or selected region from the user's most recent message — use that
11	3. The most recent non-trivial assistant output — use that
12	4. If the guess is not obvious, lead the explanation by naming what was picked so the user can redirect
13
14	## Step 2: Ground in State
15
16	Read whatever makes the explanation concrete, no more:
17
18	- Files the subject references
19	- The active skill's `SKILL.md` when a skill-specific question is being asked
20	- `git status` and `git diff --stat` when the subject involves staged or unstaged changes
21	- Any artifact cited (plan, spec, findings, test plan, audit, PR, commit)
22
23	## Step 3: Produce the Explanation
24
25	The reader is an experienced developer who may not be fluent in every tech stack or acronym but doesn't need concepts from first principles. Skip ELI5. Use plain language; strip skill-internal jargon, or define it inline when the jargon is what the user needs explained (for example, "P1 peer" becomes "priority 1 finding from the peer reviewer").
26
27	Go beyond "what this does" and surface the trade-offs: pros and cons per choice, benefits and costs, whether the thing reads as clean and elegant or redundant and overcomplicated. Be honest about red flags; be honest about solid work.
28
29	Shape the output to match the subject. Use the branch that applies; drop the rest.
30
31	Question with discrete options — restate the question plainly, then enumerate options using this template:
32
33	```
34	What you're being asked: <plain-language restatement>
35
36	### Your Options
37	1. <label as shown> — <concrete effect: files changed, next step, what is lost>
38	- Pros: <what you gain>
39	- Cons: <what it costs>
40	2. <label> — <concrete effect>
41	- Pros: <...>
42	- Cons: <...>
43
44	### When Each Fits
45	- Pick <option> if your goal is <goal>.
46	- Pick <option> if your goal is <other goal>.
47	```
48
49	Apply these option-specific rules:
50
51	- Describe each option's real-world effect. Example:
52	- Concrete: "Renames the module to `auth-v2` and updates the 3 import sites in `src/`."
53	- Too abstract: "Cleans up the auth code."
54	- If an option was labelled "(Recommended)" in the original, repeat that label verbatim. Do not add a fresh recommendation.
55	- If an option would skip a safety step (tests, review, a gate), call that out.
56	- If the pending question was posed via `AskUserQuestion`, re-invoke `AskUserQuestion` after the explanation with the same question, header, and options so the user can answer inline without losing the dialog. Preserve any "(Recommended)" label verbatim. Otherwise (plain-text prompt from the assistant), end by noting the question is still pending and the user should reply to the original prompt directly.
57
58	Free-form question — restate the question plainly, say what the answer will be used for (which file gets written, which step consumes it), and call out what makes a good answer versus a problematic one. End by noting the question is still pending.
59
60	Code, error, or command output — say what it does or means, likely cause or purpose, and what action is typically expected. Judge the design: is it clean and idiomatic, or are there smells like redundant guards, tangled control flow, or unnecessary abstraction?
61
62	Artifact (plan, findings, diff, PR) — summarize its contents, the decisions it represents, and what step comes next. Flag strengths and weaknesses: over-engineering, missing cases, clear wins.
63
64	## Rules
65
66	- Read-only. Do not modify files, stage changes, or answer a pending question on the user's behalf.
67	- If an active skill's SKILL.md contradicts what the conversation shows, trust the conversation and note the discrepancy briefly.
68	- If the subject cannot be identified at all, say so and stop.

People who liked this also viewed

6 picks

Type

explain-this

3installs29forks

View on GitHub

How to install explain-this?

tobihagemann/turbo/explain-this

$npx -y skills add tobihagemann/turbo --skill explain-this

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Explain This
2
3	Take whatever the user is pointing at and translate it into plain language. "This" is usually the most recent assistant output or something pasted as an argument: a multi-option prompt, a free-form question, a code block, an error, a command output, or an artifact like a plan, findings report, or diff.
4
5	## Step 1: Identify the Subject
6
7	Pick the subject in priority order:
8
9	1. Text passed as an argument — use that
10	2. A quoted or selected region from the user's most recent message — use that
11	3. The most recent non-trivial assistant output — use that
12	4. If the guess is not obvious, lead the explanation by naming what was picked so the user can redirect
13
14	## Step 2: Ground in State
15
16	Read whatever makes the explanation concrete, no more:
17
18	- Files the subject references
19	- The active skill's `SKILL.md` when a skill-specific question is being asked
20	- `git status` and `git diff --stat` when the subject involves staged or unstaged changes
21	- Any artifact cited (plan, spec, findings, test plan, audit, PR, commit)
22
23	## Step 3: Produce the Explanation
24
25	The reader is an experienced developer who may not be fluent in every tech stack or acronym but doesn't need concepts from first principles. Skip ELI5. Use plain language; strip skill-internal jargon, or define it inline when the jargon is what the user needs explained (for example, "P1 peer" becomes "priority 1 finding from the peer reviewer").
26
27	Go beyond "what this does" and surface the trade-offs: pros and cons per choice, benefits and costs, whether the thing reads as clean and elegant or redundant and overcomplicated. Be honest about red flags; be honest about solid work.
28
29	Shape the output to match the subject. Use the branch that applies; drop the rest.
30
31	Question with discrete options — restate the question plainly, then enumerate options using this template:
32
33	```
34	What you're being asked: <plain-language restatement>
35
36	### Your Options
37	1. <label as shown> — <concrete effect: files changed, next step, what is lost>
38	- Pros: <what you gain>
39	- Cons: <what it costs>
40	2. <label> — <concrete effect>
41	- Pros: <...>
42	- Cons: <...>
43
44	### When Each Fits
45	- Pick <option> if your goal is <goal>.
46	- Pick <option> if your goal is <other goal>.
47	```
48
49	Apply these option-specific rules:
50
51	- Describe each option's real-world effect. Example:
52	- Concrete: "Renames the module to `auth-v2` and updates the 3 import sites in `src/`."
53	- Too abstract: "Cleans up the auth code."
54	- If an option was labelled "(Recommended)" in the original, repeat that label verbatim. Do not add a fresh recommendation.
55	- If an option would skip a safety step (tests, review, a gate), call that out.
56	- If the pending question was posed via `AskUserQuestion`, re-invoke `AskUserQuestion` after the explanation with the same question, header, and options so the user can answer inline without losing the dialog. Preserve any "(Recommended)" label verbatim. Otherwise (plain-text prompt from the assistant), end by noting the question is still pending and the user should reply to the original prompt directly.
57
58	Free-form question — restate the question plainly, say what the answer will be used for (which file gets written, which step consumes it), and call out what makes a good answer versus a problematic one. End by noting the question is still pending.
59
60	Code, error, or command output — say what it does or means, likely cause or purpose, and what action is typically expected. Judge the design: is it clean and idiomatic, or are there smells like redundant guards, tangled control flow, or unnecessary abstraction?
61
62	Artifact (plan, findings, diff, PR) — summarize its contents, the decisions it represents, and what step comes next. Flag strengths and weaknesses: over-engineering, missing cases, clear wins.
63
64	## Rules
65
66	- Read-only. Do not modify files, stage changes, or answer a pending question on the user's behalf.
67	- If an active skill's SKILL.md contradicts what the conversation shows, trust the conversation and note the discrepancy briefly.
68	- If the subject cannot be identified at all, say so and stop.

People who liked this also viewed

6 picks

Type