add prompt template

ai/PROMPT_TEMPLATE.md

@@ -0,0 +1,54 @@
+# Entity Creation Prompt Template
+
+Follow the existing patterns in this codebase to create a new entity called [EntityName].
+
+Requirements:
+- The entity encapsulates [one or more Entities]
+- Include [any other fields]
+
+Process (TDD - Test Driven Development):
+1. Write a test first
+2. Run the test to confirm it fails
+3. Implement the code to make the test pass
+4. Run the test to confirm it passes
+5. Repeat for each new behavior
+
+Code patterns to follow:
+- First, explore the codebase to understand existing entity patterns
+- Look at similar entities (e.g., AgendaSlot, Event, etc.) for reference
+- Entities: constructor with properties, getters
+- DTOs: simple data containers for creation
+- Repositories: interfaces that define data access
+- Use cases: business logic with Request objects
+  - When throwing exceptions, add @throws docblock
+- Fakes: in-memory implementations for testing
+  - Look at tests/Fakes/ for examples
+  - Find/lookup methods must return a new instance of the entity, not the stored reference
+- Tests: follow existing patterns in tests/Unit/[Entity]/UseCases/
+- Lines should not exceed 80 columns
+- Imports: always put use statements at the top of the file, never use inline imports (e.g., \App\Foo\Bar::class)
+- Variable names: use explicit, descriptive names — never single-letter or abbreviated variables (e.g., use $sponsorship not $s, $event not $e)
+
+Git commit style:
+- Present tense, imperative mood (add, create, test, fix)
+- Lowercase
+- Short (3-6 words)
+- Match patterns found in git history
+
+Git commits:
+- Tests should be committed first, before implementation
+- One commit per file - each new file gets its own commit
+- Make commits SMALL and FREQUENT - every meaningful change should be a commit
+- Commits are for reviewing and documenting the development of code
+- A commit can be as simple as adding one import, one getter, one property, etc.
+- Don't wait to commit - commit as you go
+- Run `php-cs-fixer fix` on worked on directories before committing
+
+Branch naming:
+- Use kebab-case (e.g., presenting-track, agenda-slots)
+- Use descriptive feature names
+- Examples: "presenting-track", "agenda-slots", "confirm-application"
+- Or use type/description: "feature/presenting-track", "fix/bug-name"
+- NEVER work directly on master/main - always create and work on a branch
+
+Do not push anything. Make commits as you go.