Writing · 3 min read

Socrates: Before I Say ‘Go Build It’

I want the agent to help me think through the work, not just get on with it.

A better question now is worth less rework later.

Socrates is a Claude skill I use before planning a piece of work. It researches the problem, challenges my assumptions, and writes down what we decide. Once we have something coherent enough to execute, it produces a plan.

This isn’t just a tool for AI. It’s a way of thinking: slow down at the beginning, examine the problem, make the reasoning explicit, and only then commit to a direction.

Illustrated bust of Socrates
Examine the claim before acting on it.

Why Socrates

The part of the Socratic method I’m borrowing is the examination of what someone thinks they already know. A claim gets tested against the rest of the person’s commitments until the contradiction—or the missing assumption—becomes visible.

That is different from requirements gathering. I may have stated my preferred solution confidently without having thought through the problem very far.

The useful outcome is often not more certainty. It is better uncertainty.

The Socratic method

Question assumptionsWhat are we treating as already decided?
Examine reasoningWhy does that conclusion follow?
Test tensionsWhich beliefs or constraints conflict?
Revise understandingWhat is the clearer problem now?
The point is not to win an argument. It is to expose what has not yet been thought through.

From request to clarity

Example: remove deployment approval

An agent can find the manual gate and remove it. Socrates asks a more useful question first: what is that gate protecting?

If the answer is destructive migrations, the task may become narrower: automate routine releases while preserving review for risky ones. If we cannot distinguish the two, that becomes the first problem to solve.

Without vs. with Socrates

Without Socrates

User request
Assume intent
Plan and implement

With Socrates

User request
Research + questions
Agree on actual problem
Plan and implement
The skill is valuable when the request contains a hidden product or policy decision.

Layered reasoning

A specification connects the dots

Socrates structures the outcome as seven linked layers. The point is not to fill seven headings. It is to make sure the work still follows from the problem.

A requirement without a reason is a suggestion. A success metric without a method is a hope.

The seven layers

  1. 1Problem
    what we’re solving
  2. 2Requirements
    what must be true
  3. 3Constraints
    what we must work within
  4. 4Risks
    what could go wrong
  5. 5Success
    measurable outcomes
  6. 6Validation
    how we’ll know
  7. 7Execution readiness
    handoff + authority
A weakness higher in the stack should send us back down, not get papered over in the plan.

Document, sequence, and preserve intent

Once the specification is validated, Socrates produces a plan. The important thing is the ordering: clarify the task, validate the reasoning, then sequence implementation around the dependencies.

The files carry those decisions forward so the executor does not have to reconstruct the conversation from memory.

The workflow

1Interrogate

Explore the problem

2Validate

Build the specification

3Plan

Create and review the plan

4Execute

Do the work

5Verify

Check the result

New evidence can reopen the specification. The difference is that the change to the agreement is explicit.