> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blitzy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Close

> When to discard pull requests and create new code generation requests

Close a pull request when the generated code has fundamental issues that make refinement inefficient. This protects code quality and allows you to iterate on your prompt before creating a new generation request.

<Note>
  **Post-Code-Generation Options:** [Merge](/pull-request-review/merge) | [Close](#close-criteria) (this page) | [Refine PR](/pull-request-review/refine)

  **Choose Close when:** Critical gaps exist that block merge, the architectural approach is fundamentally flawed, or regeneration is more efficient than refinement.
</Note>

## Close Criteria

Choose Close when any of these conditions exist:

| Condition                         | Reason                                                                        |
| --------------------------------- | ----------------------------------------------------------------------------- |
| **Critical gaps >0**              | Security vulnerabilities, broken core functionality, architectural violations |
| **Architectural approach flawed** | Fundamental design requires complete rework                                   |
| **Scope misalignment**            | Implementation doesn't match original requirements                            |
| **Refinement inefficient**        | Would require 3+ iterations or exceeds effort to regenerate                   |

**Critical Gap Examples:**

* Security vulnerabilities or credential exposure
* Broken core functionality preventing deployment
* Data corruption or loss potential
* Architectural violations requiring structural changes
* Breaking changes without migration path

## Decision Matrix

| Condition                               | Decision   |
| --------------------------------------- | ---------- |
| Critical gaps >0 OR fundamental issues  | **CLOSE**  |
| Major gaps 3 or fewer, no critical gaps | **REFINE** |
| Zero critical gaps, minor gaps only     | **MERGE**  |

## When to Close vs. Refine

| Scenario                          | Close | Refine |
| --------------------------------- | ----- | ------ |
| Architectural approach wrong      | Yes   |        |
| Critical gaps present             | Yes   |        |
| Would require 3+ iterations       | Yes   |        |
| Faster to regenerate              | Yes   |        |
| Minor implementation fixes needed |       | Yes    |
| Architecture sound                |       | Yes    |

## Closing Process

<Steps>
  <Step title="Document critical gaps">
    For each critical gap, document:

    * **Location** - File path and line numbers
    * **Issue** - What is fundamentally wrong
    * **Impact** - Why it blocks merge
    * **Root cause** - Why the generation failed
  </Step>

  <Step title="Identify root cause">
    Determine why the generation failed:

    * **Unclear prompt** - Requirements not specific enough
    * **Missing context** - Insufficient codebase information
    * **Wrong approach** - AAP needed different strategy
    * **Specification issues** - Project guide incomplete or ambiguous
  </Step>

  <Step title="Close PR with explanation">
    Post a clear explanation in the PR:

    * State the Close decision
    * List critical gaps
    * Explain why regeneration is preferred
    * Provide next steps
  </Step>

  <Step title="Refine your prompt">
    Before creating a new request:

    * Update prompt with clearer requirements
    * Add missing context or constraints
    * Reference specific patterns to follow
    * Address root causes identified in review
  </Step>
</Steps>

## After Closing

1. **PR closed** - Generated code discarded
2. **Refine prompt** - Improve specifications based on learnings
3. **Create new request** - Submit refined prompt to Blitzy
4. **New AAP generated** - Fresh plan based on improved prompt
5. **New PR created** - Better code generated from improved specifications

Closing preserves momentum by preventing technical debt from flawed implementations, creating a cleaner starting point, applying lessons learned, and avoiding inefficient incremental patching.

## Related Guides

<CardGroup cols={2}>
  <Card title="Merge Pull Request" icon="code-merge" href="/pull-request-review/merge">
    Criteria for accepting generated code
  </Card>

  <Card title="Refine Pull Request" icon="pen-to-square" href="/pull-request-review/refine">
    When to iterate on the current PR
  </Card>

  <Card title="Prompt Engineering" icon="wand-magic-sparkles" href="/prompt-engineering/golden-rules">
    Improve prompts to reduce failures
  </Card>
</CardGroup>