# Section 5: Prompt Updates (godot_development_prompt_v2.md)

## Overview

This section adds five targeted changes to the MCP development prompt at `/Users/salvatorefarruggio/Desktop/godotiq/src/godotiq/prompts/godot_development_prompt_v2.md`. The goal is to close three behavioral gaps: the agent does not check for script errors before running, it does not perform real gameplay testing, and it writes too much text between tool calls. These are all markdown-only changes with no code dependencies on other sections.

## File to Modify

`/Users/salvatorefarruggio/Desktop/godotiq/src/godotiq/prompts/godot_development_prompt_v2.md`

No other files are created or modified in this section.

## Verification Checklist

Since this section is a markdown file, there are no automated tests. Verify each change manually:

- "Test-Driven Completion" section exists and appears **before** the "MANDATORY: Final QA" heading
- QA Step 5 has been expanded from a single step into sub-steps 5.1 through 5.6
- "Act immediately" rule is added to the Efficiency Rules section
- "Maximum 2 paragraphs between tool calls" rule is added
- `SCRIPT_ERRORS` entry is added to the Error Recovery section
- `godotiq_check_errors` is listed in the Tool Reference UNDERSTAND section

---

## Change 1: Add "Test-Driven Completion" Section

**Location:** Insert immediately **before** the `### MANDATORY: Final QA` heading.

**Content:**

```markdown
### Test-Driven Completion

You are NOT done when code compiles or the game starts without crashing. Done means every player-facing feature works during actual gameplay.

Examples of "broken but compiles":
- Towers that don't shoot at enemies
- Buttons that don't respond to clicks
- Score labels that never update
- Enemies that spawn but don't follow the path
- Resources that never change when they should

After building any feature, ask yourself: "If a player tried every feature right now, would it all work?" If you are unsure, test it with runtime tools (`godotiq_run`, `godotiq_state_inspect`, `godotiq_input`). Compiling is the floor, not the finish line.
```

---

## Change 2: Expand QA Step 5 (Real Gameplay Testing)

**Location:** Replace the existing QA step 5 block (currently a compact code-block version).

**Replace with:**

```markdown
5. **Gameplay test** — Run a thorough play-test with real interaction:

   **5.1** Check for script errors first:
   - Call `godotiq_check_errors(scope="scene")` before starting
   - If errors found, fix them before attempting to run

   **5.2** Start and verify initial state:
   - `godotiq_run(action="play")`, wait for confirmation
   - `godotiq_state_inspect` to verify starting values (gold, lives, wave, etc.)

   **5.3** Test every interactive feature:
   - Use `godotiq_ui_map(detail="brief")` to find clickable elements
   - Use `godotiq_input` to click/tap each interactive element
   - Use `godotiq_state_inspect` to verify expected changes after each interaction
   - If something didn't change when it should have, that's a bug — fix it

   **5.4** Wait for a complete cycle:
   - If the game has waves/rounds/turns, start one
   - Wait with `godotiq_input(commands=[{"wait_ms": 10000}])`
   - Verify enemies were processed, resources changed, scores updated

   **5.5** Check for runtime errors:
   - Read `_editor_state.recent_errors` from any bridge tool response
   - If errors appeared during gameplay, stop the game and fix them

   **5.6** Stop and report results:
   - `godotiq_run(action="stop")`
   - Summarize what was tested and what passed
```

---

## Change 3: Add Efficiency Rules

**Location:** In the existing `## Efficiency Rules` section, append two new items at the end of the list.

**Content:**

```markdown
6. **Act immediately.** When you know the next step, execute it. Don't write multi-paragraph plans. The tool will tell you if something is wrong — act on the response, don't pre-plan for every contingency.

7. **Maximum 2 paragraphs between tool calls.** After a tool call, explain what happened in 1-2 sentences, then make the next call. Don't write essay-length analysis between actions. If you find yourself writing more than 2 short paragraphs without a tool call, stop and act instead.
```

---

## Change 4: Add SCRIPT_ERRORS to Error Recovery

**Location:** In the `## Error Recovery` section, add a new entry after the existing `TIMEOUT` entry.

**Content:**

```markdown
- `SCRIPT_ERRORS` → `godotiq_check_errors(scope="scene")` to see details, then fix the broken scripts before running again
```

---

## Change 5: Add godotiq_check_errors to Tool Reference

**Location:** In the `### UNDERSTAND` section of the Tool Reference, add a new entry.

**Content:**

```markdown
**`godotiq_check_errors`** — Check GDScript files for compilation/parse errors. Call before `godotiq_run` or after writing scripts. Use `scope="scene"` for current scene scripts + autoloads, `scope="project"` for all scripts in the project.
```

---

## Implementation Notes

- All five changes are edits to a single markdown file. No Python code, no GDScript, no tests.
- Independent of other sections at code level. References `godotiq_check_errors` (Section 4) as documentation only.
- Preserve existing markdown formatting style: `##` for sections, `###` for subsections, backtick code blocks, bold for emphasis.

## Implementation Notes (Post-Implementation)

- All 5 changes applied exactly as specified in plan
- No deviations from plan content
- Code review skipped (markdown-only, no logic to review)
