Socratic Philosophy Clarification

Guide users through Socratic questioning to establish clear project philosophy. The output is a philosophy document that serves as the design criterion for all future decisions.

This skill produces a philosophy document (manifesto), NOT an implementation plan. Do NOT invoke writing-plans or any implementation skill. The terminal state is a committed philosophy document.

The Four-Layer Framework

Every project philosophy document covers four layers, in order:

1. Ontology — What is it?

The deepest layer. Clarify the essence of the thing being built.

Key questions:

• What is the core definition of this thing?
• What makes it different from similar things?
• Who are the stakeholders/users?
• What are the key concepts and their relationships?

2. Teleology — What is success?

The goal layer. Clarify what "done" and "good" look like.

Key questions:

• What problem does this solve?
• What does success look like?
• How do we measure it?
• What are the success criteria / metrics?

3. Methodology — How to achieve it?

The approach layer. Clarify the principles that guide decisions.

Key questions:

• What are the core design principles?
• What patterns/approaches are preferred?
• How do we handle trade-offs?
• What is the decision-making framework?

4. Boundaries — What is it NOT?

The exclusion layer. Clarify what's out of scope.

Key questions:

• What is this explicitly NOT?
• What problems does it NOT solve?
• What approaches are explicitly rejected?
• Where does it stop being useful?

Process

Phase 1: Understand Context

First, explore the current state:

• Check existing docs (CLAUDE.md, README.md, design specs)
• Look at recent commits and current implementation
• Identify any stated or implied principles

Phase 2: Socratic Dialogue

Ask questions one at a time through the four layers:

1. Start with Ontology — the essence
2. Move to Teleology — the goals
3. Then Methodology — the approach
4. Finally Boundaries — the exclusions

Question style:

• Prefer multiple choice (A/B/C/D) when possible
• Each question should clarify one specific aspect
• Build on previous answers
• Go deeper when answers reveal ambiguity

Example question format:

[Layer] Question about specific aspect

| Option | Meaning |
|--------|---------|
| **A. ...** | ... |
| **B. ...** | ... |

Phase 3: Synthesize

When all four layers are clarified:

1. Summarize the core principles
2. Present to user for approval
3. Write the philosophy document

Phase 4: Document

Write the philosophy document with this structure:

# [Project Name] Philosophy

> This document defines core principles and design criteria, serving as the judgment basis for all architectural decisions.

## I. Ontology: [What is it]
...

## II. Teleology: [What is success]
...

## III. Methodology: [How to achieve it]
...

## IV. Boundaries: [What it is NOT]
...

## V. Decision Criteria
When facing design choices, test with these questions:
1. ...
2. ...

---

*This document was clarified through Socratic dialogue, established on YYYY-MM-DD.*

Phase 5: Commit

Save to docs/metaphysics/YYYY-MM-DD--philosophy.md and commit to git.

Key Principles

• One question at a time — Don't overwhelm
• Multiple choice preferred — Easier to answer, forces clarity
• Build incrementally — Each question builds on previous answers
• Go deep before broad — Understand essence before expanding
• Be flexible — If a layer is already clear, move on
• Respect user's vision — You're clarifying, not imposing

Output

The final output is a philosophy document that:

1. Defines the core essence (Ontology)
2. Clarifies success criteria (Teleology)
3. Establishes design principles (Methodology)
4. Sets clear boundaries (Boundaries)

This document becomes the design criterion — the reference for all future architectural decisions.

Terminal State

Commit the philosophy document to git. Do NOT proceed to implementation planning. The philosophy stands alone as a foundational document.