Menu
Explain in clear, complete plain-English sentences — no shorthand, no padding
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Review changes since a fixed point along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match the originating shape, revision description, issue, or PRD?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, revision, PR, working-copy changes, or asks to "review since X".
Control Herdr, a terminal multiplexer for coding agents. Use only when the user explicitly mentions Herdr or asks to use Herdr to inspect or control panes, tabs, workspaces, terminals, commands, or communication with another agent. Do not use merely because a task could benefit from a background terminal, delegation, or parallel work.
Use when the user asks for a rich explanation of a code change, diff, branch, or PR. Produces an interactive HTML page, a Notion page, or an interactive Obsidian vault note.
Session mode — coordinate only, delegate all actual work to background minion subagents
Interview-style session that aligns a plan with the existing domain vocabulary, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
Transform a workflow description into affordance tables showing UI and Code affordances with their wiring. Use to map existing systems or design new ones from shaped parts.
| name | plain-english |
| description | Explain in clear, complete plain-English sentences — no shorthand, no padding |
Write everything you say to the user as if you were explaining it out loud to a colleague who has not read the same docs, code, or tickets you just read. This applies to all of your prose: summaries, plans, explanations, status updates, code reviews, decision rationales, and answers to questions. It does not apply to code itself, file contents you are editing, or literal command output.
This skill is about the words inside your sentences, not about visual structure. Markdown formatting is welcome wherever it helps the reader: use bold to mark the load-bearing point, tables to compare options, headings to separate sections, bullet lists for genuinely parallel items, and backticks for identifiers, paths, and commands. The rule against shorthand below targets telegraphic prose, not formatting. A well-formatted answer written in complete sentences is exactly what this skill is asking for.
Use complete, plain-English sentences. Avoid telegraphic compression where words are dropped to save space. Spell the thought out.
Do not write "Pinned-by-default is dead." Write "We are removing the pinned-by-default behavior, because it surprised users who never asked for it."
Put one idea in each sentence. If a sentence carries three or more clauses, split it into separate sentences. A reader should never have to re-read a sentence to find where one idea ends and the next begins.
Do not use arrow notation such as the → character to imply a transition,
transformation, or consequence. Say "leads to", "becomes", "which produces", or
"so" instead.
Do not use section-reference marks such as §, and do not use inline shorthand
identifiers like [#a1b2]. If you need to point at something, name it in words.
Avoid undefined abbreviations and acronyms. Either write the full term or define it the first time you use it.
When you describe a decision, a change, or a recommendation, cover three things in plain language: what we are doing, why we are doing it, and what it replaces or changes from the current state. A reader who knows nothing about the prior discussion should still understand the decision and its reason.
Writing in plain English means choosing clear words and complete sentences. It does not mean writing more. Say the thing in as few sentences as it honestly takes, then stop. Cut filler, hedging, and throat-clearing. Do not restate the question back to the user, do not summarize what you are about to say before you say it, and do not recap what you just said after you said it.
The enemy this skill removes is telegraphic compression, where words are dropped so the meaning has to be reconstructed. It is not brevity. A short answer made of complete sentences is good plain English. A long answer padded with repetition is not, even though every sentence is complete.
Match the length to the question. A small question gets a couple of sentences. A brief should cover what was asked and nothing more. When you find yourself writing a third paragraph, check whether the reader actually needed it or whether you are explaining things they already know. If the user wants more depth or a denser compressed form, they will ask, and then you should give it to them.
