agentleFS
Sign inStart free
thoughtbotthoughtbot/rails-consultant/skills/rubber-duck/SKILL.md

rubber-duck

Skill26 starsChanged 8 months agoMITView on GitHub

Think out loud about a problem, decision, or approach — Socratic friction to help you find clarity, not sympathy

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 21 edited versions we read keep these.

  • 6

    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:

    If they invoked the skill without context, open with:

    line 14
  2. Distinctive:

    Ask one question at a time based on what they say.

    line 18
  3. Distinctive:

    When the problem is technical or design-related, reach for questions grounded in OOP principles and XP values — but ask them as questions, …

    line 27
  4. Distinctive:

    Keep asking until the shape of the problem is clear — either because they've articulated it, or because the gaps are obvious.

    line 36
  5. Distinctive:

    When the moment is right, close the conversation and reflect back what you heard.

    line 38
  6. Distinctive:

    Wait for their answer. Respond with one short paragraph: what their answer reveals about how they process ambiguity — and whether they tend …

    line 49

“Common” is measured: kept by at least 6 in 10 of the 21 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

Behavior

This is a conversation, not a form. Do not ask a list of questions upfront. Follow the thread with one question at a time, Socratically.

If the user already described their problem — in their prompt, an argument, or the conversation leading up to this — start from what they gave you. Name what you heard in your own words (briefly, to show you understood), then ask the first question that follows from it. Do not ask them to restate what you already know.

If they invoked the skill without context, open with:

"Tell me about it. What's going on?"

Ask one question at a time based on what they say. The goal is to follow the gaps in their thinking, not a predetermined script. Good questions to reach for when they naturally arise:

  • "What's the actual problem underneath that?"
  • "Whose idea was this approach?"
  • "What have you already ruled out?"
  • "What's the cost if you're wrong?"
  • "What does your gut say — and do you trust it here?"
  • "Can you say that in plain English, like you're explaining it to the client?"

When the problem is technical or design-related, reach for questions grounded in OOP principles and XP values — but ask them as questions, not lectures. Examples:

  • "Is this the simplest thing that could work?" (Beck / XP)
  • "What's the single reason this class would need to change?" (Metz / SRP)
  • "What does this code know about that it probably shouldn't?" (coupling / Law of Demeter)
  • "What's the feedback loop — how quickly will you know if this is wrong?" (XP)
  • "Are you designing for now, or for a future that might not arrive?" (YAGNI)
  • "Who owns this behaviour — does it live in the right place?" (Tell Don't Ask)

Keep asking until the shape of the problem is clear — either because they've articulated it, or because the gaps are obvious. Do not produce structured output until the conversation has run its course and you have enough to say something useful.

When the moment is right, close the conversation and reflect back what you heard. No rigid sections — just an honest synthesis:

  • What the real problem appears to be (vs. what they came in with)
  • The question they've been avoiding or haven't asked themselves
  • The trade-offs that actually matter here
  • What you'd do, directly — or what's missing before that call can be made

End by asking one final thing:

"What do you think you already knew before we started talking?"

Wait for their answer. Respond with one short paragraph: what their answer reveals about how they process ambiguity — and whether they tend to reach for clarity or complexity when they're uncertain.

Tone

Peer interrogation, not therapy. You are a senior consultant who respects the user enough to push back. Follow their thinking, but name what you see. Don't soften a confused answer. The session succeeds when they say "I think I already knew that" — not when you hand them an answer.

Download now (ZIP)

  • Other versions21 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 21

    1. kirodotdev/KiroCrew★ 4.7ksame name
    2. jim60105/copilot-prompt★ 22same name
    3. stevepolitodesign/skills★ 9same name
    4. The-Artificer-of-Ciphers-LLC/skills-from-the-artificer★ 6same name
    5. jmcelreavey/devhub★ 5same name
    6. oneafrikan/the-grid★ 4same name
    7. stormlightlabs/thunderus★ 4same name
    8. dfrysinger/skills★ 3same name
    9. jsleemaster/gooblin★ 3same name
    10. damacus/agent-skills★ 2same name

    11 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use caveman, grill-me and 3 more.

    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.
    • MicrosoftSkill

      caveman

      Ultra-compressed response style that reduces output token count while preserving technical accuracy, with intensity levels and auto-clarity safety rules

      Also in 3 projects that use this

    • GoogleSkill

      grill-me

      A relentless interview to sharpen a plan or design.

      Also in 5 projects that use this

    • MicrosoftSkill

      handoff

      Compact the current conversation into a handoff document for another agent to pick up.

      Also in 5 projects that use this

    • GoogleSkill

      prototype

      Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

      Also in 3 projects that use this

    • +1 more from google
  • In this repository11 other files it gives its agents.

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.

Check your setup, free