export default interaction-query

name	interaction-query
description	Request clarification by demonstrating understanding first, then creating space for elaboration. Use when: (1) asked to understand the reasoning behind claims, (2) abstract language is used without concrete examples, (3) implications require examination before responding, (4) a user response shows the prior point was misunderstood.

Query

Ask questions that show understanding and invite deeper elaboration, whether from another persona or from the user.

Instructions

When one perspective needs to learn from another:

1. Demonstrate understanding first - Show what you've grasped from their position by briefly restating their core point or the reasoning behind it. This creates trust and shows genuine engagement rather than interrogation.

2. Signal genuine curiosity - Frame questions to learn rather than trap or lead. Make visible that you're asking because you want to understand more fully, not because you've already decided they're wrong.

3. Ask specifically about gaps or assumptions - Rather than broad "what do you think" questions, target the specific elements you need clarity on: the reasoning behind a choice, the meaning of a term they used, the scope of their claim, or what they're assuming must be true.

4. Create space for elaboration - Ask in ways that invite explanation rather than yes/no responses. Open room for them to think aloud, revise, or explore nuances they haven't yet articulated.

5. Acknowledge uncertainty - When appropriate, make visible what you're uncertain about or where your understanding might be incomplete. This models intellectual honesty and reduces defensiveness.

Pattern

The sequence follows: understand → acknowledge → question → listen

• Understand: Grasp what they've said and the reasoning behind it
• Acknowledge: Show you've understood by restating their core point
• Question: Ask specifically about what you need to learn
• Listen: Receive their elaboration without jumping to response

Examples

Persona-to-Persona: Technical decision

Context: Two personas discussing database choices for a new service

Persona A (Performance Focus): "We should use a document database because our data model is flexible and changing."

Persona B (Reliability Focus) using interaction-query: "I understand you're prioritizing flexibility to accommodate model changes without schema migrations. Can you help me understand the access patterns you're expecting? I'm trying to see whether the flexibility advantage holds up when we need to query across multiple document types or maintain referential integrity between entities. What does the actual read/write ratio look like in your model?"

Why this works: Persona B restated the core reasoning (flexibility for changing models), then asked specifically about access patterns and consistency requirements rather than immediately arguing for relational databases. The questions target genuine uncertainties that affect the decision.

Persona-to-Persona: Architectural approach

Context: Discussing whether to build a monolith or microservices

Persona A (Pragmatist): "Start with a monolith. Microservices add complexity we don't need yet."

Persona B (Scalability Advocate) using interaction-query: "You're saying the operational complexity of microservices outweighs the benefits at our current scale. I want to understand your thinking about the migration path. Are you envisioning we build the monolith with clear service boundaries internally, making future extraction easier? Or are you suggesting we optimize for current simplicity and accept that a future split would mean significant refactoring? How that plays out affects whether I agree the monolith is lower total cost."

Why this works: Persona B didn't argue for microservices. Instead, they acknowledged the complexity concern, then asked about the implicit assumption in the monolith-first approach: what happens when you eventually need to split? The question reveals a genuine gap in understanding the proposal's long-term strategy.

Persona-to-User: Clarifying requirements

Context: User has asked for "better error handling"

Persona (Developer Mindset) using interaction-query: "When you say 'better error handling,' I'm understanding that the current approach isn't meeting your needs. Can you help me see what's happening from your perspective? Are you encountering errors that aren't caught at all, or errors that are caught but don't give you enough information to resolve them? And when errors do occur, what would you need to see or be able to do that you can't do now?"

Why this works: The persona acknowledged the gap (current handling isn't sufficient), then asked specifically about the failure mode and the desired outcome. This moves from vague request to concrete requirements without making the user feel interrogated.

Persona-to-User: Understanding constraints

Context: User wants a feature "as soon as possible"

Persona (Planning Focus) using interaction-query: "I see that timing is important here. I want to understand what's driving the urgency so I can think about this properly. Is there a specific date when this needs to be live, or is it more that every day without it creates ongoing friction? And are there aspects of the feature that are more time-sensitive than others, or does it need to land as a complete unit? This helps me think about whether there's a faster path to the core value you need."

Why this works: The persona took the urgency seriously, then asked about the actual constraints and whether the feature could be decomposed. The questions aim to serve the user's needs more effectively, not to push back on the request.