agentleFS
Harish-hereHarish-here/maddog/skills/plain-english/SKILL.md

plain-english

Skill3 starsChanged 33 days agoMITView on GitHub

Governs how replies and questions in the conversation are worded and shaped for the user. Use whenever the user says a reply is cryptic, dense, hard to read, or hard to scan, asks what a question means, or asks to say it simply or in plain English. Also use before asking the user to choose between options. Not for files agents load or repo documents (briefs, specs, descriptions, README): that is efficient-md.

15 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use find-skills.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • VercelSkill

    find-skills

    Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 15 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not coin terms. Describe the thing, not only its name.

    line 25
  2. Distinctive:

    Use one word for one meaning throughout.

    line 31
  3. Distinctive:

    Write full sentences under 25 words, in active voice, one idea each.

    line 34
  4. Distinctive:

    Keep noun strings to three nouns.

    line 38
  5. Distinctive:

    Add a caveat only when it changes the decision.

    line 44
  6. Distinctive:

    Use a text diagram in a code block, 25 lines and 70 columns at most.

    line 69
  7. Distinctive:

    Write a decision as a question with each exit labelled yes or no, and draw a loop as an arrow back to an earlier step.

    line 71
  8. Distinctive:

    Before asking the user a question, write 2 to 5 plain sentences: the situation, what is being decided, and what each option changes in …

    line 77

“Common” is measured: kept by at least 6 in 10 of the 15 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

The reader never saw the labels this session coined. Each message must stand alone, read once.

Content and wording

  1. Answer first, reasoning after. The first line of text, below the heading if there is one, is the result, the number, or the decision needed. A reader who stops there still has the answer.
  2. Explain terms. Give a term the reader may not know a plain-word explanation at its first use. Spell out a label coined this session (a finding ID, an option name, a mode) at its first use in each message.
  3. Do not coin terms. Describe the thing, not only its name. Use a literal phrase where a figure of speech would do the same work. Say who does what to which input. For example, "the decision lives upstream" leaves out who decides. Write "the platform team decides this first" instead, so the reader knows whom to ask.
  4. Use one word for one meaning throughout. A renamed thing sends the reader looking for a difference that is not there.
  5. Write full sentences under 25 words, in active voice, one idea each. Name the doer. Headings, bullets, and table cells may be fragments. They keep the word limit and one idea each.
  6. Keep noun strings to three nouns. Rewrite a longer string with a verb or a preposition.
  7. Say each thing once. Do not restate it in a second form or summarise it. A table or diagram that restates a list above it breaks this rule.
  8. Add a caveat only when it changes the decision. Give one caveat, as one line at the end.

Shape

A reply format the user or project has set stays the outer form. These rules fill in what it leaves open.

  1. Group by content. Give each topic one heading; a reply of a few sentences on one topic needs none. Under a heading, write each point in the form rule 10 picks. A paragraph has six sentences at most, main point first.
  2. Choose the form by the content's shape:
    • Reasoning where each point depends on the last: a short paragraph.
    • Parallel items the reader scans or checks: bullets.
    • Values compared across options, including a trade-off between them: a table.
    • Two or more steps the reader performs: numbered, one action each, 20 words or fewer, condition first ("If X, do Y").
    • Events in order that the reader does not perform: "A, then B, then C" for three or fewer, a numbered list for more. Rule 11 takes a flow that branches, loops, or has four or more hand-offs.
  3. Draw a flow that branches, loops, or has four or more hand-offs. A hand-off is work passing from one person, agent, or system to another. Use a text diagram in a code block, 25 lines and 70 columns at most. Label boxes with the words the message uses. Run the flow top to bottom. Write a decision as a question with each exit labelled yes or no, and draw a loop as an arrow back to an earlier step. Draw so that no line crosses another. The diagram replaces prose that retraces its steps.

Questions

Before asking the user a question, write 2 to 5 plain sentences: the situation, what is being decided, and what each option changes in practice. The question itself is one sentence. Each option's description is a full sentence a newcomer could act on.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.