17th-deep-discussion

name: 17th-deep-discussion description: | Enable structured Claude-GPT debate for deep problem analysis. Both models bring unique perspectives to synthesize optimal solutions. GPT can read code (sandbox=read-only), Claude handles web search on request. Appropriate for: complex architectural decisions, trade-off analysis, design reviews. Not appropriate for: simple questions, implementation tasks, quick lookups.

Deep Discussion

Structured Claude-GPT debate for deep problem analysis and solution synthesis.

Usage

/17th-deep-discussion                    → gpt-5.3-codex, high (default)
/17th-deep-discussion high               → gpt-5.3-codex, high
/17th-deep-discussion xhigh              → gpt-5.3-codex, xhigh
/17th-deep-discussion high CODEX         → gpt-5.3-codex, high
/17th-deep-discussion xhigh CODEX        → gpt-5.3-codex, xhigh

Argument Parsing

Format: /17th-deep-discussion {effort} {model}

Model mapping:

• CODEX → gpt-5.3-codex (optimized for code analysis)

When to Use

• Complex architectural decisions with multiple valid approaches
• Trade-off analysis where context matters
• Design reviews needing multiple perspectives
• Problems where "it depends" is the initial answer
• Situations requiring deep exploration before commitment

When NOT to Use

• Simple questions with clear answers
• Implementation tasks (use task-architect instead)
• Quick lookups or searches (use vanguard instead)
• Time-critical decisions

Discussion Phases

Phase 0: Problem Framing (Claude)

Before invoking GPT, Claude:

1. Clarifies the problem with user if needed
2. Identifies key constraints and context
3. Frames the discussion topic clearly
4. Determines what code/docs GPT should examine

Output: Problem Statement + Context Files

Phase 1: Initial GPT Analysis

Start Codex session with problem framing:

response = codex(
    model="{model}",  # gpt-5.3-codex
    config={"model_reasoning_effort": "{effort}"},  # high or xhigh
    cwd="{project_root}",
    sandbox="read-only",
    approval-policy="never",
    prompt="""
You are participating in a structured discussion with Claude (Opus 4.5).
Maximum {max_rounds} rounds. End early if consensus is reached.

## Discussion Topic
{problem_statement}

## Your Role
- Provide your initial analysis and position
- Read relevant code files to ground your analysis
- Be specific with file:line references
- Acknowledge uncertainties and trade-offs
- End with 2-3 key points for Claude to respond to

## Web Search
If you need external information, include:
[SEARCH_REQUEST: "your search query"]
Claude will perform the search and provide results in the next round.

## Context Files to Examine
{context_files}

## Consensus Signal
When you believe consensus is reached, include:
[CONSENSUS_REACHED]

Provide your initial analysis now.
"""
)

threadId = response.threadId  # CRITICAL: Save for multi-turn

Phase 2: Debate Rounds (Max 10, Early Exit on Consensus)

Claude and GPT alternate perspectives:

max_rounds = 10
round_num = 1
consensus_reached = False

while round_num <= max_rounds and not consensus_reached:
    # Check for search requests in GPT's response
    search_requests = extract_search_requests(gpt_response)
    search_results = ""
    for query in search_requests:
        result = WebSearch(query=query)
        search_results += f"\n## Search: {query}\n{result}\n"

    # Check for consensus signal
    if "[CONSENSUS_REACHED]" in gpt_response:
        consensus_reached = True
        break

    # Claude's turn: formulate response
    claude_response = """
    (Claude analyzes GPT's points, provides counterpoints or extensions)
    (Claude may challenge assumptions, offer alternative perspectives)
    (Claude identifies areas of agreement and remaining differences)
    """

    # GPT's turn: continue thread
    gpt_response = codex_reply(
        threadId=threadId,
        prompt=f"""
Round {round_num + 1} of {max_rounds}.

{search_results if search_results else ""}

Claude (Opus 4.5) responds:

{claude_response}

## Your Task
1. Address Claude's points directly
2. Refine or defend your position
3. Identify areas of agreement
4. Propose synthesis where possible
5. If consensus reached, include [CONSENSUS_REACHED]
6. If you need web search, include [SEARCH_REQUEST: "query"]

Continue the discussion.
"""
    )

    round_num += 1

Phase 3: Synthesis

synthesis = codex_reply(
    threadId=threadId,
    prompt="""
The discussion is concluding.

## Synthesis Task
Based on our multi-turn debate, create a structured synthesis:

1. **Agreed Points**: What we both support
2. **Key Trade-offs**: Trade-offs identified with analysis
3. **Recommended Approach**: Specific recommendation with rationale
4. **Open Questions**: Remaining uncertainties requiring user input
5. **Implementation Hints**: If applicable, concrete next steps

## Output Format
Use clear headers and bullet points.
Reference specific code locations where relevant.
Be decisive but acknowledge trade-offs.
"""
)

Phase 4: Report Generation

Save discussion to .kkachi/{branch}/completed/deep-discussion-{timestamp}.md

report = f"""
# Deep Discussion Report

**Timestamp**: {iso_timestamp}
**Topic**: {problem_statement}
**Model**: {model} ({effort})
**Rounds**: {actual_rounds}
**Consensus**: {"Reached" if consensus_reached else "Max rounds"}

## Discussion Transcript

{transcript}

## Synthesis

{synthesis}

## Claude's Final Observations

{claude_observations}
"""

save_report(report, output_path)

Web Search Delegation

GPT cannot directly search the web. When GPT needs external information:

1. GPT includes [SEARCH_REQUEST: "query"] in its response
2. Claude extracts the query and performs WebSearch
3. Results are included in the next codex-reply prompt
4. Multiple search requests per round are supported

Example:

GPT: "I'm not sure about the latest React Server Components API.
[SEARCH_REQUEST: "React Server Components API 2024"]"

Claude: *performs WebSearch, includes results in next round*

GPT: "Based on the search results, RSC now supports..."

Early Termination

Discussion ends before 10 rounds when:

• GPT includes [CONSENSUS_REACHED] in response
• Claude determines sufficient agreement exists
• No new substantive points are being raised

Configuration

MCP Tools Used

Thread Management

CRITICAL: Maintain same threadId throughout entire discussion.

codex() → acquire threadId
    ↓
codex-reply(threadId) → Round 2
    ↓
codex-reply(threadId) → Round 3
    ↓
... (up to Round 10 or consensus)
    ↓
codex-reply(threadId) → Synthesis

Output Location

Reports saved to: .kkachi/{branch_name}/completed/deep-discussion-{epoch_timestamp}.md

Report Format

# Deep Discussion Report

**Timestamp**: 2024-01-15T10:30:00Z
**Topic**: Should we use event sourcing for the order domain?
**Model**: gpt-5.3-codex (high)
**Rounds**: 6
**Consensus**: Reached

## Discussion Transcript

### Round 1: GPT Initial Analysis
After examining `internal/order/`, I recommend CQRS with event sourcing
for the write side because...

### Round 2: Claude Response
I agree on CQRS but question full event sourcing given the team's
experience. The operational complexity at `internal/order/repository.go:78`...

### Round 3: GPT Response
Valid concern. Perhaps event sourcing only for critical state transitions...

### Round 4: Claude Response
That's a reasonable middle ground. What about the migration path?

### Round 5: GPT Response
[SEARCH_REQUEST: "event sourcing migration strategies"]
Based on the patterns in the codebase...

### Round 6: GPT Response
Incorporating the search results, here's a migration approach...
[CONSENSUS_REACHED]

## Synthesis

### Agreed Points
- CQRS pattern for command/query separation
- Event sourcing for order state transitions only
- Traditional persistence for read models

### Key Trade-offs
| Approach | Pros | Cons |
|----------|------|------|
| Full ES | Complete audit trail | High complexity |
| Hybrid | Balanced | More design decisions |
| CRUD | Simple | Limited auditability |

### Recommended Approach
Hybrid: Event sourcing for order lifecycle events, CRUD for ancillary data.

### Open Questions
1. Event store technology choice (PostgreSQL vs dedicated)?
2. Replay strategy for projections?

### Implementation Hints
1. Start with `internal/order/events/` directory
2. Define `OrderCreated`, `OrderConfirmed`, `OrderShipped` events
3. Implement `EventStore` interface in `internal/infrastructure/`

## Claude's Final Observations

The hybrid approach balances the team's current capabilities with future
auditability needs. Consider starting with a spike on the event store
abstraction before full commitment.

Example Session

User: "Should we use GraphQL or REST for our new API?"

Claude: "Let me start a deep discussion on this API design decision."

[Phase 0: Claude frames the problem]
- Context: New customer-facing API, mobile + web clients
- Constraints: Team has REST experience, 3-month timeline
- Files: internal/api/*, proto/*, docs/api-design.md

[Phase 1: GPT Initial Analysis]
GPT: "After examining the existing API patterns at internal/api/rest/,
I lean toward GraphQL for the following reasons..."

[Phase 2: Debate]
Claude: "I see the benefits, but given the team's REST experience
and timeline, what about the learning curve impact?"

GPT: "That's a valid concern. However, looking at internal/api/rest/handlers.go,
there's already significant over-fetching happening..."

[Continues for several rounds]

[Phase 3: Synthesis]
GPT: "Based on our discussion, I recommend REST with
carefully designed resource endpoints, plus GraphQL evaluation
for v2. Here's why... [CONSENSUS_REACHED]"

[Phase 4: Report]
Claude: "Discussion complete. Here's our recommendation..."
Report saved to: .kkachi/main/completed/deep-discussion-1705312200.md

User: "What about the migration path from current API?"

[Can continue discussion or start new topic]

Implementation

Parse arguments and start the discussion:

# Parse arguments
effort = "high"  # or "xhigh"
model = "gpt-5.3-codex"

# Get user's problem statement
problem = user_input

# Phase 0: Frame the problem
context_files = identify_relevant_files(problem)
problem_statement = frame_problem(problem, context_files)

# Phase 1: Start GPT session
response = codex(
    model=model,
    config={"model_reasoning_effort": effort},
    cwd=project_root,
    sandbox="read-only",
    approval-policy="never",
    prompt=initial_prompt.format(
        problem_statement=problem_statement,
        context_files=context_files,
        max_rounds=10
    )
)
threadId = response.threadId

# Phase 2: Debate loop
transcript = [("GPT", response.output)]
for round in range(2, 11):
    # Handle search requests
    searches = extract_searches(response.output)
    search_results = perform_searches(searches)

    # Check consensus
    if "[CONSENSUS_REACHED]" in response.output:
        break

    # Claude's response
    claude_resp = generate_claude_response(response.output, context)
    transcript.append(("Claude", claude_resp))

    # GPT's response
    response = codex_reply(
        threadId=threadId,
        prompt=round_prompt.format(
            round=round,
            search_results=search_results,
            claude_response=claude_resp
        )
    )
    transcript.append(("GPT", response.output))

# Phase 3: Synthesis
synthesis = codex_reply(threadId=threadId, prompt=synthesis_prompt)

# Phase 4: Generate and save report
report = generate_report(transcript, synthesis)
save_to_kkachi(report)

Notes

• Claude and GPT bring genuinely different analytical approaches
• GPT reads code directly; Claude handles web searches
• Keep debate focused (avoid circular arguments)
• User can redirect discussion at any point
• Report captures full transcript for future reference
• For purely abstract problems (no code), consider NONE model variant
• Maximum 10 rounds prevents runaway discussions
• Consensus detection allows efficient early termination