[Phase 5] Recursive Decomposition as PRD Stress Test and Technical Spec Generator

[frankbria]

Summary

Use recursive classify/decompose (inspired by tinyagi/fractals) as a requirements discovery tool — not just for generating tasks, but for stress-testing a PRD and generating a technical specification that surfaces ambiguities before any code gets written.

The Insight

When the LLM recursively decomposes a high-level goal, it will inevitably hit nodes where it can't classify (atomic vs composite) without more information. These ambiguity points are exactly the requirements gaps the PRD should have addressed:

• "Auth system" → Is this email/password? OAuth? SSO? The PRD doesn't say.
• "Payment integration" → One provider or multiple? Subscriptions or one-time? The PRD is vague.
• "Notification system" → Email only? Push? SMS? Real-time? Nobody specified.

These gaps, caught at decomposition time, become questions fed back to the human — turning the recursive decompose into a Socratic refinement loop.

Proposed Workflow

cf prd generate          ← Socratic PRD creation (exists today)
        │
cf prd stress-test       ← NEW: recursive decompose, surface gaps
        │                   Returns: ambiguity questions + draft tech spec
        │
cf prd refine            ← Human answers questions, PRD updated
        │
cf tasks generate        ← Now produces high-quality tasks from refined PRD

The stress-test step is the new primitive. It produces two outputs:

Output 1: Ambiguity Report

Questions the PRD doesn't answer, discovered by trying to decompose:

PRD Stress Test — 7 ambiguities found:

1. AUTH SCOPE (from decomposing "User Authentication")
   The PRD mentions "user accounts" but doesn't specify:
   - Authentication method (email/password? OAuth providers? Both?)
   - Session management approach (JWT? server sessions?)
   → Recommendation: Add "Authentication Requirements" section to PRD

2. DATA PERSISTENCE (from decomposing "Invoice Management")
   The PRD says "store invoices" but doesn't specify:
   - Database choice (relational? document store?)
   - Retention policy (how long? archival?)
   → Recommendation: Add "Data Architecture" section to PRD

3. PAYMENT SCOPE (from classifying "Payment Integration")
   Cannot determine atomicity — depends on:
   - One payment provider or multiple?
   - Subscription billing or one-time payments?
   → Recommendation: Narrow scope in PRD or mark as future phase

Output 2: Draft Technical Specification

The decomposition tree, formatted as a technical spec:

# Technical Specification: Invoice SaaS

## 1. User Authentication
**Scope**: [NEEDS CLARIFICATION — see ambiguity #1]

### 1.1 Email/Password Registration
- User model with email, password_hash, created_at
- Registration endpoint with email verification
- Estimated complexity: Low

### 1.2 Session Management  
- [NEEDS CLARIFICATION: JWT vs server sessions]
- Login/logout endpoints
- Estimated complexity: Low-Medium

## 2. Invoice Management

### 2.1 Invoice CRUD
- Create, read, update, delete invoices
- Line items with quantity, rate, tax
- Draft/Sent/Paid status machine
- Files: models/invoice.py, routes/invoices.py
- Estimated complexity: Medium

### 2.2 PDF Export
- Generate PDF from invoice data
- Template system for invoice layout
- Estimated complexity: Medium
...

Implementation Design

New module: core/stress_test.py

async def stress_test_prd(prd_content: str, max_depth: int = 3) -> StressTestResult:
    """Recursively decompose PRD goals, surface ambiguities."""
    
    goals = extract_high_level_goals(prd_content)  # LLM: what are the major deliverables?
    
    tree = []
    ambiguities = []
    
    for goal in goals:
        node = await recursive_decompose(
            description=goal,
            lineage=[],
            prd_context=prd_content,
            depth=0,
            max_depth=max_depth,
            ambiguities=ambiguities,  # collect gaps as we go
        )
        tree.append(node)
    
    return StressTestResult(
        tree=tree,
        ambiguities=ambiguities,
        tech_spec=render_tech_spec(tree),
    )

Modified classify step

Unlike Fractals' simple binary classify, this version has THREE outcomes:

class Classification(Enum):
    ATOMIC = "atomic"        # Small enough to execute directly
    COMPOSITE = "composite"  # Clearly needs breakdown
    AMBIGUOUS = "ambiguous"  # Can't classify — PRD doesn't specify enough

When the LLM returns AMBIGUOUS, it also returns the question(s) it needs answered. These accumulate into the ambiguity report.

CLI commands

cf prd stress-test                    # Run decomposition against current PRD
cf prd stress-test --max-depth 4      # Deeper analysis
cf prd stress-test --output spec.md   # Write tech spec to file
cf prd stress-test --interactive      # Ask human to resolve ambiguities inline

The --interactive mode is the killer feature: it decomposes, hits an ambiguity, asks the human, records the answer, updates the PRD, and continues decomposing. Essentially a second-pass Socratic session focused on technical feasibility rather than product requirements.

What This Is NOT

• Not a replacement for cf tasks generate — stress-test produces a spec, not executable tasks
• Not a replacement for cf prd generate — stress-test refines an existing PRD, doesn't create one
• Not a planning tool for agents — this is a human-facing discovery tool

Acceptance Criteria

• cf prd stress-test recursively decomposes PRD goals
• Ambiguities surfaced with actionable questions
• Tech spec generated from decomposition tree
• --interactive mode allows inline ambiguity resolution
• Resolved ambiguities update the PRD
• --output writes tech spec to file
• Max depth prevents runaway recursion (default: 3)
• Works with PRDs generated by cf prd generate

Dependencies

• Benefits from existing cf prd generate (Socratic discovery)
• The decomposition tree feeds into [Phase 5] Richer Task Generation: Dependencies, Complexity, and File Scope #420 (richer task generation) — tasks can be generated from the tech spec leaves
• Benefits from [Phase 4] Task Context Packager for External Agents #410 (context packager) — lineage context informs agent prompts

Relationship to Other Issues

• [Phase 5] Richer Task Generation: Dependencies, Complexity, and File Scope #420 (Richer Task Generation): The stress-test tech spec becomes the input for task generation. cf tasks generate could accept a tech spec instead of (or in addition to) a raw PRD.
• [Phase 4] Task Context Packager for External Agents #410 (Context Packager): Lineage context from the decomposition tree is exactly what the packager should include in agent prompts.
• This is the PRD → Tech Spec bridge that doesn't exist in CodeFrame, Symphony, Gastown, or Fractals.

Priority

Phase 5 — this is a refinement that builds on the existing PRD system. Not day-one, but it's a unique differentiator: no other tool in this space helps humans think through what they're building before agents start coding.

[traycerai]

Plan

Observations

The codebase is well-structured: codeframe/core/prd_discovery.py houses PrdDiscoverySession with a clean Socratic loop pattern (generate question → validate answer → update coverage → repeat). LLM calls go through AnthropicProvider via _llm_provider.complete(messages, purpose, system, max_tokens, temperature). CLI commands are Typer-based and registered in file:codeframe/cli/app.py under prd_app. PRD versioning via prd.create_new_version() already exists. The TaskDecomposer in file:codeframe/planning/task_decomposer.py shows the prompting and parsing pattern for recursive breakdown.

Approach

Create a new file:codeframe/core/prd_stress_test.py module mirroring the patterns from PrdDiscoverySession (LLM provider, session persistence, prompt constants) and TaskDecomposer (prompt-parse loop). Add a @prd_app.command("stress-test") in file:codeframe/cli/app.py following the exact same Typer/Rich patterns as prd_generate. No new dependencies needed — typer, rich, anthropic, pydantic, and sqlite are all already present.

---

Implementation Steps

1. Define Data Models in file:codeframe/core/prd_stress_test.py

Create the module with these dataclasses (following the @dataclass pattern from file:codeframe/core/models.py):

• Classification — str enum with three values: ATOMIC, COMPOSITE, AMBIGUOUS
• DecompositionNode — dataclass holding: id (str), title (str), description (str), classification (Classification), children (list of DecompositionNode), lineage (list[str]), depth (int), complexity_hint (Optional[str])
• Ambiguity — dataclass holding: id (str), label (str), source_node_title (str), questions (list[str]), recommendation (str), resolved_answer (Optional[str])
• StressTestResult — dataclass holding: prd_title (str), tree (list[DecompositionNode]), ambiguities (list[Ambiguity]), tech_spec_markdown (str)

---

2. Define Prompt Constants in file:codeframe/core/prd_stress_test.py

Following the same pattern as the string constants in file:codeframe/core/prd_discovery.py (e.g., DISCOVERY_SYSTEM_PROMPT, COVERAGE_ASSESSMENT_PROMPT):

• GOAL_EXTRACTION_PROMPT — instructs the LLM to return a JSON list of high-level deliverable goals given PRD content
• CLASSIFY_AND_DECOMPOSE_PROMPT — the core prompt. Given a node's title, description, lineage, depth, and PRD context, the LLM returns a JSON object with:
  • classification: "atomic" | "composite" | "ambiguous"
  • children: list of {title, description} (only when composite)
  • ambiguity_label: short label (only when ambiguous)
  • questions: list of clarifying questions (only when ambiguous)
  • recommendation: what to add to the PRD (only when ambiguous)
  • complexity_hint: "Low" | "Low-Medium" | "Medium" | "High" (always)
• AMBIGUITY_RESOLUTION_PROMPT — given a resolved answer, returns updated PRD content (used by --interactive mode)

---

3. Implement Core Functions in file:codeframe/core/prd_stress_test.py

extract_goals(prd_content: str, provider: AnthropicProvider) -> list[str]
Call provider.complete() with GOAL_EXTRACTION_PROMPT, parse JSON list of goal strings.

classify_and_decompose(title: str, description: str, lineage: list[str], prd_content: str, depth: int, provider: AnthropicProvider) -> tuple[Classification, list[dict], Optional[Ambiguity], str]

• Call provider.complete() with CLASSIFY_AND_DECOMPOSE_PROMPT
• Parse JSON response
• Return (classification, children_dicts, ambiguity_or_None, complexity_hint)

recursive_decompose(title: str, description: str, lineage: list[str], prd_content: str, depth: int, max_depth: int, ambiguities: list[Ambiguity], provider: AnthropicProvider) -> DecompositionNode

flowchart TD
    A[Call classify_and_decompose] --> B{Classification?}
    B -->|ATOMIC| C[Return leaf node]
    B -->|AMBIGUOUS| D[Append to ambiguities list\nReturn node with AMBIGUOUS]
    B -->|COMPOSITE| E{depth < max_depth?}
    E -->|No| F[Treat as ATOMIC leaf]
    E -->|Yes| G[Recurse for each child]
    G --> H[Return node with children]

render_tech_spec(tree: list[DecompositionNode], ambiguities: list[Ambiguity]) -> str

• Walk the decomposition tree recursively
• Render markdown with H2 for root nodes, H3 for depth-1, H4 for depth-2, etc.
• Insert [NEEDS CLARIFICATION — see ambiguity #{n}] markers at AMBIGUOUS nodes
• Append Estimated complexity: {complexity_hint} on atomic leaves

render_ambiguity_report(ambiguities: list[Ambiguity]) -> str

• Format the numbered ambiguity list matching the ticket's output format

stress_test_prd(prd_content: str, provider: AnthropicProvider, max_depth: int = 3) -> StressTestResult

1. Call extract_goals()
2. For each goal, call recursive_decompose() collecting into tree and ambiguities
3. Call render_tech_spec() and render_ambiguity_report()
4. Return StressTestResult

---

4. Add prd stress-test CLI Command in file:codeframe/cli/app.py

Add @prd_app.command("stress-test") immediately after the existing prd_generate command (around line 1500), following the exact same typer/rich/console style:

Parameters:

Parameter	Flag	Default	Description
repo_path	--workspace/-w	None	Workspace path
prd_id	--prd-id	None	Specific PRD ID (defaults to latest)
max_depth	--max-depth	3	Max recursion depth
output	--output/-o	None	Write tech spec to this file path
interactive	--interactive/-i	False	Inline ambiguity resolution

Command body logic:

1. Resolve workspace via get_workspace()
2. Load PRD via prd.get_latest() or prd.get_by_id()
3. Build AnthropicProvider from os.getenv("ANTHROPIC_API_KEY"), raise typer.Exit(1) with helpful message if missing
4. Call stress_test_prd(record.content, provider, max_depth=max_depth)
5. Print ambiguity report using console.print() with Rich markup (yellow for ambiguity labels, cyan for questions)
6. If --interactive: loop over unresolved ambiguities, use typer.prompt() to collect answers, store answer in ambiguity.resolved_answer, then at the end call prd.create_new_version() with updated PRD content (generated via a final LLM call using AMBIGUITY_RESOLUTION_PROMPT)
7. Print tech spec to console using console.print()
8. If --output is set, write result.tech_spec_markdown to the file path using Path.write_text()
9. Emit EventType.PRD_UPDATED event via emit_for_workspace() only if interactive mode resolved ambiguities and created a new PRD version

---

5. Register No New Sub-App (Already Part of prd_app)

The stress-test command attaches directly to the existing prd_app Typer instance — no changes needed to the app.add_typer(prd_app, ...) registration at line 4780 of file:codeframe/cli/app.py.

---

End-to-End Flow

    participant User
    participant CLI (prd_app)
    participant stress_test module
    participant AnthropicProvider
    participant prd module

    User->>CLI (prd_app): cf prd stress-test [--interactive] [--output spec.md]
    CLI (prd_app)->>prd module: get_latest() → PrdRecord
    CLI (prd_app)->>stress_test module: stress_test_prd(content, provider, max_depth)
    stress_test module->>AnthropicProvider: extract_goals(prd_content)
    loop for each goal
        stress_test module->>AnthropicProvider: classify_and_decompose(node, lineage, depth)
        AnthropicProvider-->>stress_test module: classification + children OR ambiguity
        alt COMPOSITE and depth < max_depth
            stress_test module->>stress_test module: recurse children
        else AMBIGUOUS
            stress_test module->>stress_test module: append Ambiguity
        end
    end
    stress_test module-->>CLI (prd_app): StressTestResult (tree, ambiguities, tech_spec)
    CLI (prd_app)->>User: Print ambiguity report + tech spec
    opt --interactive
        loop for each Ambiguity
            CLI (prd_app)->>User: typer.prompt() for answer
            User-->>CLI (prd_app): answer text
        end
        CLI (prd_app)->>AnthropicProvider: AMBIGUITY_RESOLUTION_PROMPT → updated PRD
        CLI (prd_app)->>prd module: create_new_version(prd_id, updated_content, change_summary)
        CLI (prd_app)->>User: "PRD updated to version N"
    end
    opt --output
        CLI (prd_app)->>CLI (prd_app): Path(output).write_text(tech_spec_markdown)
        CLI (prd_app)->>User: "Tech spec written to <path>"
    end

Import In IDE

🤖 Prompt for AI Agents

## Observations

The codebase is well-structured: `codeframe/core/prd_discovery.py` houses `PrdDiscoverySession` with a clean Socratic loop pattern (generate question → validate answer → update coverage → repeat). LLM calls go through `AnthropicProvider` via `_llm_provider.complete(messages, purpose, system, max_tokens, temperature)`. CLI commands are Typer-based and registered in `file:codeframe/cli/app.py` under `prd_app`. PRD versioning via `prd.create_new_version()` already exists. The `TaskDecomposer` in `file:codeframe/planning/task_decomposer.py` shows the prompting and parsing pattern for recursive breakdown.

## Approach

Create a new `file:codeframe/core/prd_stress_test.py` module mirroring the patterns from `PrdDiscoverySession` (LLM provider, session persistence, prompt constants) and `TaskDecomposer` (prompt-parse loop). Add a `@prd_app.command("stress-test")` in `file:codeframe/cli/app.py` following the exact same Typer/Rich patterns as `prd_generate`. No new dependencies needed — `typer`, `rich`, `anthropic`, `pydantic`, and `sqlite` are all already present.

---

## Implementation Steps

### 1. Define Data Models in `file:codeframe/core/prd_stress_test.py`

Create the module with these dataclasses (following the `@dataclass` pattern from `file:codeframe/core/models.py`):

- **`Classification`** — `str` enum with three values: `ATOMIC`, `COMPOSITE`, `AMBIGUOUS`
- **`DecompositionNode`** — dataclass holding: `id` (str), `title` (str), `description` (str), `classification` (`Classification`), `children` (list of `DecompositionNode`), `lineage` (list[str]), `depth` (int), `complexity_hint` (Optional[str])
- **`Ambiguity`** — dataclass holding: `id` (str), `label` (str), `source_node_title` (str), `questions` (list[str]), `recommendation` (str), `resolved_answer` (Optional[str])
- **`StressTestResult`** — dataclass holding: `prd_title` (str), `tree` (list[`DecompositionNode`]), `ambiguities` (list[`Ambiguity`]), `tech_spec_markdown` (str)

---

### 2. Define Prompt Constants in `file:codeframe/core/prd_stress_test.py`

Following the same pattern as the string constants in `file:codeframe/core/prd_discovery.py` (e.g., `DISCOVERY_SYSTEM_PROMPT`, `COVERAGE_ASSESSMENT_PROMPT`):

- **`GOAL_EXTRACTION_PROMPT`** — instructs the LLM to return a JSON list of high-level deliverable goals given PRD content
- **`CLASSIFY_AND_DECOMPOSE_PROMPT`** — the core prompt. Given a node's title, description, lineage, depth, and PRD context, the LLM returns a JSON object with:
  - `classification`: `"atomic"` | `"composite"` | `"ambiguous"`
  - `children`: list of `{title, description}` (only when composite)
  - `ambiguity_label`: short label (only when ambiguous)
  - `questions`: list of clarifying questions (only when ambiguous)
  - `recommendation`: what to add to the PRD (only when ambiguous)
  - `complexity_hint`: `"Low"` | `"Low-Medium"` | `"Medium"` | `"High"` (always)
- **`AMBIGUITY_RESOLUTION_PROMPT`** — given a resolved answer, returns updated PRD content (used by `--interactive` mode)

---

### 3. Implement Core Functions in `file:codeframe/core/prd_stress_test.py`

**`extract_goals(prd_content: str, provider: AnthropicProvider) -> list[str]`**
Call `provider.complete()` with `GOAL_EXTRACTION_PROMPT`, parse JSON list of goal strings.

**`classify_and_decompose(title: str, description: str, lineage: list[str], prd_content: str, depth: int, provider: AnthropicProvider) -> tuple[Classification, list[dict], Optional[Ambiguity], str]`**
- Call `provider.complete()` with `CLASSIFY_AND_DECOMPOSE_PROMPT`
- Parse JSON response
- Return `(classification, children_dicts, ambiguity_or_None, complexity_hint)`

**`recursive_decompose(title: str, description: str, lineage: list[str], prd_content: str, depth: int, max_depth: int, ambiguities: list[Ambiguity], provider: AnthropicProvider) -> DecompositionNode`**

```
flowchart TD
    A[Call classify_and_decompose] --> B{Classification?}
    B -->|ATOMIC| C[Return leaf node]
    B -->|AMBIGUOUS| D[Append to ambiguities list\nReturn node with AMBIGUOUS]
    B -->|COMPOSITE| E{depth < max_depth?}
    E -->|No| F[Treat as ATOMIC leaf]
    E -->|Yes| G[Recurse for each child]
    G --> H[Return node with children]
```

**`render_tech_spec(tree: list[DecompositionNode], ambiguities: list[Ambiguity]) -> str`**
- Walk the decomposition tree recursively
- Render markdown with H2 for root nodes, H3 for depth-1, H4 for depth-2, etc.
- Insert `[NEEDS CLARIFICATION — see ambiguity #{n}]` markers at `AMBIGUOUS` nodes
- Append `Estimated complexity: {complexity_hint}` on atomic leaves

**`render_ambiguity_report(ambiguities: list[Ambiguity]) -> str`**
- Format the numbered ambiguity list matching the ticket's output format

**`stress_test_prd(prd_content: str, provider: AnthropicProvider, max_depth: int = 3) -> StressTestResult`**
1. Call `extract_goals()`
2. For each goal, call `recursive_decompose()` collecting into `tree` and `ambiguities`
3. Call `render_tech_spec()` and `render_ambiguity_report()`
4. Return `StressTestResult`

---

### 4. Add `prd stress-test` CLI Command in `file:codeframe/cli/app.py`

Add `@prd_app.command("stress-test")` immediately after the existing `prd_generate` command (around line 1500), following the exact same `typer`/`rich`/`console` style:

**Parameters:**
| Parameter | Flag | Default | Description |
|---|---|---|---|
| `repo_path` | `--workspace/-w` | `None` | Workspace path |
| `prd_id` | `--prd-id` | `None` | Specific PRD ID (defaults to latest) |
| `max_depth` | `--max-depth` | `3` | Max recursion depth |
| `output` | `--output/-o` | `None` | Write tech spec to this file path |
| `interactive` | `--interactive/-i` | `False` | Inline ambiguity resolution |

**Command body logic:**
1. Resolve workspace via `get_workspace()`
2. Load PRD via `prd.get_latest()` or `prd.get_by_id()`
3. Build `AnthropicProvider` from `os.getenv("ANTHROPIC_API_KEY")`, raise `typer.Exit(1)` with helpful message if missing
4. Call `stress_test_prd(record.content, provider, max_depth=max_depth)`
5. Print ambiguity report using `console.print()` with Rich markup (yellow for ambiguity labels, cyan for questions)
6. If `--interactive`: loop over unresolved ambiguities, use `typer.prompt()` to collect answers, store answer in `ambiguity.resolved_answer`, then at the end call `prd.create_new_version()` with updated PRD content (generated via a final LLM call using `AMBIGUITY_RESOLUTION_PROMPT`)
7. Print tech spec to console using `console.print()`
8. If `--output` is set, write `result.tech_spec_markdown` to the file path using `Path.write_text()`
9. Emit `EventType.PRD_UPDATED` event via `emit_for_workspace()` only if interactive mode resolved ambiguities and created a new PRD version

---

### 5. Register No New Sub-App (Already Part of `prd_app`)

The `stress-test` command attaches directly to the existing `prd_app` Typer instance — no changes needed to the `app.add_typer(prd_app, ...)` registration at line 4780 of `file:codeframe/cli/app.py`.

---

### End-to-End Flow

```sequenceDiagram
    participant User
    participant CLI (prd_app)
    participant stress_test module
    participant AnthropicProvider
    participant prd module

    User->>CLI (prd_app): cf prd stress-test [--interactive] [--output spec.md]
    CLI (prd_app)->>prd module: get_latest() → PrdRecord
    CLI (prd_app)->>stress_test module: stress_test_prd(content, provider, max_depth)
    stress_test module->>AnthropicProvider: extract_goals(prd_content)
    loop for each goal
        stress_test module->>AnthropicProvider: classify_and_decompose(node, lineage, depth)
        AnthropicProvider-->>stress_test module: classification + children OR ambiguity
        alt COMPOSITE and depth < max_depth
            stress_test module->>stress_test module: recurse children
        else AMBIGUOUS
            stress_test module->>stress_test module: append Ambiguity
        end
    end
    stress_test module-->>CLI (prd_app): StressTestResult (tree, ambiguities, tech_spec)
    CLI (prd_app)->>User: Print ambiguity report + tech spec
    opt --interactive
        loop for each Ambiguity
            CLI (prd_app)->>User: typer.prompt() for answer
            User-->>CLI (prd_app): answer text
        end
        CLI (prd_app)->>AnthropicProvider: AMBIGUITY_RESOLUTION_PROMPT → updated PRD
        CLI (prd_app)->>prd module: create_new_version(prd_id, updated_content, change_summary)
        CLI (prd_app)->>User: "PRD updated to version N"
    end
    opt --output
        CLI (prd_app)->>CLI (prd_app): Path(output).write_text(tech_spec_markdown)
        CLI (prd_app)->>User: "Tech spec written to <path>"
    end
```

---

Execution Information

Branch: main
Commit: 705b160

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

🔗 Related PRs

#205 - feat(planning): Add planning phase automation and task approval [merged]
#213 - feat(planning): Add Generate Task Breakdown button to DiscoveryProgress [merged]
#317 - feat(cli): add interactive PRD generation via Socratic discovery [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!