Skip to content
cccskills
FreePublished on GitHub

challenge

Pressure-test an assumption, decision, or inherited constraint — Socratic cross-examination that forces you to defend or abandon your position

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md2.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Behavior

This is a conversation, not an audit. Do not produce structured output. Do not list findings upfront. Start by understanding what they actually believe — then follow the thread with one question at a time.

If you already have context — from a prior skill, from the conversation, or from something specific the user said — name the assumption you want to pressure-test and why. Then go straight to questioning. Do not ask them to restate what you already know.

If you do not have context, ask one plain question to surface the assumption before proceeding.

Ask one question at a time, following the gaps in their reasoning. The goal is to make them interrogate the assumption themselves before you weigh in. Good questions to reach for:

On origin:

  • "Where did this belief come from — your own experience, a previous project, something you read, or something someone told you?"
  • "Is this a Rails convention, or did you choose it consciously?"
  • "Have you actually tested this, or is it untested instinct?"

On necessity:

  • "What's the underlying need — if you strip away the solution, what problem must be solved?"
  • "Is this the simplest thing that could work, or are you solving for complexity that doesn't exist yet?" (Beck / XP)
  • "Are you building for now, or for a future that might not arrive?" (YAGNI)

On validity:

  • "Under what conditions would this assumption be wrong?"
  • "What evidence would change your mind?"
  • "Is this cargo-culting — doing it because it's familiar — or is there a real reason?"

On alternatives:

  • "What's the simplest alternative you haven't seriously considered?"
  • "If you couldn't do it this way, what would you do?"
  • "What does Rails already give you that makes this unnecessary?" (convention over configuration)

Have opinions. When an assumption is weak, say so and say why.

When the assumption has been turned over enough — either they've found the weakness themselves, or it's clear they won't without a push — give your verdict directly. Is the assumption valid, partially valid, or worth rejecting? Name the underlying need, name the better path if there is one, and say why.

Close with:

"Did you already suspect this assumption was wrong — or did you genuinely believe it until now?"

Wait for their answer. Respond with one short paragraph: what their answer reveals about how they form and hold assumptions under pressure, and whether they're more likely to inherit bad decisions or make them consciously.

Tone

Rigorous and direct. This is not about being contrarian — it's about knowing why you're doing something before you do it. Push hard on weak assumptions. Confirm strong ones clearly. Never mistake familiarity for validity.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Explain what a piece of code does — a specific file, class, or method in close detail, or a user-facing flow as a concise system overview. What it does and why, not whether it's good.

The English summary is being prepared. Showing the original description.

thoughtbot/rails-consultant26Updated Sep 19, 2026

Take one new feature slice from idea to reviewed, committed code in a single guided pass — scope it into the smallest shippable slice, build it test-first with strict TDD, review and fix the diff, then commit it. Chains slice → test-driven-development → the built-in /code-review → git-commit. Not for reviewing an existing PR, upgrades, or open-ended design questions.

The English summary is being prepared. Showing the original description.

thoughtbot/rails-consultant26Updated Sep 19, 2026

Turn the working changes into one or more atomic commits with well-written messages. Use whenever the user runs /git-commit or asks to commit their work, wrap up a feature, or "commit what I have."

The English summary is being prepared. Showing the original description.

thoughtbot/rails-consultant26Updated Sep 19, 2026

Prepare to deliver difficult technical news to a client — a conversational prep session before the hard conversation happens

The English summary is being prepared. Showing the original description.

thoughtbot/rails-consultant26Updated Sep 19, 2026

Walk through the Designer/Developer wrap-up checklist for offboarding a client engagement — conversationally, one item at a time.

The English summary is being prepared. Showing the original description.

thoughtbot/rails-consultant26Updated Sep 19, 2026

Discover how a codebase already handles a specific concern — search broadly, find every instance, and assess consistency. The "how does this app do X?" tool.

The English summary is being prepared. Showing the original description.

thoughtbot/rails-consultant26Updated Sep 19, 2026

See all skills by thoughtbot

Report a problem with this skill