2026-09-04 11:06:57 -07:00
1 changed files with 14 additions and 19 deletions
@@ -34,16 +34,16 @@ This document provides a reference for AI assistants working with YeetGeese. It

 ---

-### `make-pr` — Pull Request Creation
+### `make-pr` — Pull Request Creation (Gitea Web UI)

-**Purpose:** Create comprehensive pull requests from the current branch to a target branch (default: `develop`) with human-readable change overviews and testing strategies.
+**Purpose:** On Gitea, pull requests are created directly via the web interface at:  
+`https://gitea.letteka.com/letteka/YeetGeese/pulls/new/move_docs`

-**Capabilities:**
- Generating human-readable PR descriptions summarizing all changes
- Listing testing strategies for each major change area
- Validating changes before PR submission
- Formatting PR descriptions with clear, organized sections
- Identifying breaking changes and migration notes
+**How to use on Gitea:**
+1. Push changes to a branch (e.g., `move_docs`)
+2. Visit the URL above or navigate via Gitea web UI
+3. Create PR with descriptive title and body
+4. Include testing strategies and validation status in description

 **When to use:**
 - When ready to submit a pull request from your current branch
@@ -51,16 +51,12 @@ This document provides a reference for AI assistants working with YeetGeese. It
 - To ensure all changes are properly documented and validated
 - When creating PRs for features, fixes, or refactoring

-**Input required:**
- Target branch (default: `develop`)
- Optional custom PR title override
- Optional specific testing requirements
-
-**Example prompt:**
-```
-"Create a pull request from move_docs to develop. The changes include moving 
-all AI documentation files into an 'AI Docs' folder with organized structure."
-```
+**Best practices for Gitea PRs:**
+- Use descriptive titles following conventional commits format
+- Include file-by-file change summary in PR body
+- List testing strategies: unit tests, integration tests, manual QA
+- Mention any validation already performed locally
+- Flag known issues or limitations clearly

 ---

@@ -515,7 +511,6 @@ When requesting implementations:
 - `refactor-assistant`: Before code grows unmanageable
 - `test-generator`: After implementing critical logic
 - `design-patterns`: When architecture becomes unclear
- `make-pr`: When ready to submit a pull request from current branch

 **Always provide:**
 - File paths, node names, and Godot version context