QBP: Clearness Committee

Overview

When a question needs more than one perspective can provide in one context, convene a clearness committee - spawn specialized agents to do parallel deep work, then synthesize toward unity.

Core principle: Some questions deserve distributed depth, not single-context breadth. Recognize when to convene.

When to Convene

digraph when_clearness {
    "Question received" [shape=box];
    "Needs deep analysis?" [shape=diamond];
    "Multiple specialized perspectives needed?" [shape=diamond];
    "Would benefit from parallel work?" [shape=diamond];
    "Internal discernment sufficient" [shape=box];
    "Convene clearness committee" [shape=box];

    "Question received" -> "Needs deep analysis?";
    "Needs deep analysis?" -> "Multiple specialized perspectives needed?" [label="yes"];
    "Needs deep analysis?" -> "Internal discernment sufficient" [label="no"];
    "Multiple specialized perspectives needed?" -> "Would benefit from parallel work?" [label="yes"];
    "Multiple specialized perspectives needed?" -> "Internal discernment sufficient" [label="no"];
    "Would benefit from parallel work?" -> "Convene clearness committee" [label="yes"];
    "Would benefit from parallel work?" -> "Internal discernment sufficient" [label="no"];
}

Convene for:

• •Code reviews touching multiple concerns (security, performance, architecture, maintainability)
• •Architecture decisions with many dimensions
• •Research requiring deep exploration of multiple options
• •Design decisions where each option deserves full consideration
• •Trade-off analysis where each perspective requires significant context

Don't convene for:

• •Quick questions with clear answers
• •Questions where internal discernment (simulated voices) suffices
• •Tasks that don't benefit from parallel work

Red Flags - STOP and Consider Convening

If you catch yourself:

• •Writing a very long single response covering many angles shallowly
• •Saying "from a security perspective... from a performance perspective..." in one breath
• •Doing research that could be parallelized
• •Giving "my analysis" of something that has multiple legitimate deep perspectives

These may mean: This deserves a clearness committee, not a single-context response.

The Process

1. Propose the Committee

Before spawning, confirm with user:

"This seems like a clearness committee question - it would benefit from parallel deep analysis. I'd suggest these perspectives:

• •Security analyst: Deep dive on auth, data handling, vulnerabilities
• •Performance specialist: Profiling, scalability, resource usage
• •Architecture reviewer: Patterns, maintainability, coupling

Anyone you'd add or remove?"

Always ask. Don't assume.

2. Spawn Agents with Context

Each agent receives:

Full context:

• •The question being considered
• •Relevant background from conversation
• •Pointers to relevant files/code/docs
• •Constraints or requirements

Perspective assignment:

• •What lens they're bringing
• •What specifically to focus on

Quaker process instructions:

"You are participating in a clearness committee. Do your analysis thoroughly from the [X] perspective. Take the time you need. When ready, share what you're led to share - your genuine observations, concerns, and insights.

If after your analysis you find you have nothing significant to add, say so explicitly - that silence is meaningful. Don't pad your response."

3. Agents Work in Parallel

Use the Task tool to spawn agents. They work independently:

• •Each does real analysis (reads files, researches, reasons deeply)
• •Each produces free-form reflection (not templates)
• •Each may say "nothing significant to add" (meaningful silence)

4. Receive and Sit with Results

As clerk, receive all outputs. Don't rush to synthesis.

Listen for:

• •Where do perspectives align?
• •Where is there genuine tension?
• •Where is one perspective surfacing something others missed?
• •Are tensions real conflicts or different facets of same truth?

5. Synthesize Toward Unity

If unity emerges:

"The committee reached unity. Here's the synthesis: [Unified recommendation]

Key insights from each perspective:

• •Security noted [X]
• •Performance raised [Y]
• •Architecture suggested [Z]

These perspectives reinforced each other around [core insight]."

If stand-asides:

"The committee recommends [X]. The security perspective notes concern about [Y] but doesn't block - this should be monitored."

If no unity:

"The committee couldn't reach unity. The tension is:

• •[Perspective A] believes [X] because...
• •[Perspective B] believes [Y] because...

What might help resolve this: [specific question, constraint, or information]"

Agent Silence vs. Failure

Important distinction:

Require explicit acknowledgment so silence is intentional.

When to Use Clearness vs. Discernment

Rule of thumb: If each perspective would benefit from its own context and time, convene a committee.

Common Rationalizations

Example: Before and After

Without clearness (baseline):

User: "Review my auth system rewrite - 40 files, OAuth, session handling, schema changes" Claude: "I'd look for: [list of 7 security concerns], [list of 5 performance concerns], [list of 4 architecture concerns]... Which files should I start with?"

With clearness:

User: "Review my auth system rewrite - 40 files, OAuth, session handling, schema changes" Claude: "This deserves a clearness committee - parallel deep analysis from multiple perspectives. I'd suggest:

• •Security specialist: OAuth implementation, token handling, session security
• •Performance analyst: Connection pooling, caching, query patterns
• •Architecture reviewer: Separation of concerns, migration safety, API design

Want me to convene this committee? Anyone to add or remove?"

[After spawning and synthesis]

"The committee found unity on most points with one stand-aside:

• •All agree the OAuth flow is well-implemented
• •Architecture notes clean separation but flags the session-schema coupling
• •Security stands aside on the token refresh window - not a blocker but worth monitoring

[Specific recommendations from synthesis]"

The difference: Distributed depth, not single-context breadth.

Shared Resources

For underlying principles, see: skills/shared/principles.md For vocabulary, see: skills/shared/vocabulary.md For clerk synthesis patterns, see: skills/shared/clerk-patterns.md