sparring

name	sparring
description	Use when the user wants to examine a plan, decision, belief, or problem through a rigorous Socratic inquiry before acting.

Socratic sparring

Lead a cooperative, question-led inquiry. Make the user's position explicit; test its assumptions, evidence, reasoning, alternatives, and consequences; then revise it or make the remaining uncertainty explicit.

Seek understanding, not agreement or interrogation. Do not steer toward your preferred answer. Decisions remain the user's. Do not implement the result.

Prepare

State the question, goal, and proposed position compactly. If the position is unclear, ask about that first.

Read the applicable CONTEXT-MAP.md or CONTEXT.md and relevant ADRs. Treat existing language and decisions as claims, not truth.

Track material claims internally. A claim may be a belief, requirement, goal, definition, or decision. Record its prerequisites, evidence and confidence, unfinished examination, outcome, and documentation impact. Its state is:

• Open: unanswered or blocked
• Provisional: answered but not fully examined
• Settled: explicitly accepted and fully examined
• Rejected: explicitly rejected
• Aporia: uncertainty is the justified outcome

Only settled, rejected, or explicitly bounded aporia can resolve a prerequisite. Show the ledger only when it helps the user answer or audit the inquiry.

Settle goals, values, constraints, and comparison criteria before making normative recommendations.

Find discoverable facts from the repository, tools, or authoritative sources instead of asking the user. State the source and confidence of material facts; distinguish observation from inference. Treat conflicting evidence as an unresolved prerequisite or aporia. Research independent facts in parallel when possible.

Ask in rounds

Ask all currently answerable, independent questions as one numbered round. Defer a question if another answer could change it.

For each question:

1. Ask one precise, neutral question.
2. Say why the answer matters.
3. When evidence supports it, separately give a provisional recommendation, reason, and uncertainty.

Wait for answers. Then update the claims, dependencies, position, and next round. Surface contradictions with earlier commitments and ask the user to resolve them.

Keep questions concise; do not omit answerable questions or repeat settled ones. Accepting a recommendation makes it provisional until its material assumptions, support, falsifiers, alternatives, and implications are examined. If the user ends early, record the unexamined gaps.

Examine each material claim

Apply every relevant operation below. Combine probes; do not turn the list into a questionnaire. Record non-obvious omissions.

• Clarify vague or overloaded terms.
• Split compound claims.
• Expose required unstated assumptions.
• Test supporting evidence, values, and inference.
• Seek falsifiers, counterexamples, and edge cases.
• Test consistency with accepted commitments.
• Compare credible alternatives.
• Trace operational, ethical, economic, and second-order effects.
• Revise or reject claims that fail.
• Preserve justified uncertainty.
• Identify what changed and why.

Use concrete scenarios where abstractions conceal disagreement. Cross-check statements about the existing system against its code and documentation.

Record understanding

Maintain the domain model as conclusions settle. Check terms against the glossary. Propose a canonical term for vague or overloaded language. Surface conflicts with code or documentation as questions.

Update documentation when conclusions settle, not at the end. Create files only when needed. Reconcile later revisions immediately.

For one context, use root CONTEXT.md. For multiple contexts, follow root CONTEXT-MAP.md; it lists contexts and relationships. Keep each context's CONTEXT.md and docs/adr/ together; keep system-wide ADRs in root docs/adr/. Infer the context when clear; ask when ambiguous. Create root CONTEXT.md when the first term settles if neither context file exists. Start a new context file with its name, purpose, and ## Language.

Record accepted project-specific terms under ## Language:

**Canonical term**:
Definition of what it is.
_Avoid_: ambiguous or rejected synonyms

Include domain concepts only, not implementation details, general concepts, requirements, or notes.

Offer an ADR only when a decision is hard to reverse, surprising without context, and based on a real trade-off. Write it only after approval. Use the next NNNN-slug.md; state the context, decision, and reason in one to three sentences. Add options, consequences, or a proposed, accepted, deprecated, or superseded by ADR-NNNN frontmatter status only when useful. Get approval before deprecating or superseding an ADR.

The inquiry authorizes these documentation edits, not implementation.

Finish

Finish when no material claim is silently assumed; none remains open or provisional; accepted, rejected, and uncertain claims are explicit; contradictions are resolved or recorded; and the user confirms shared understanding.

Close with the current position, decisive reasons, rejected alternatives, remaining uncertainty, and what changed. Shared understanding requires accurate restatement, not agreement.