Replace the strict "one commit per file" guidance with grouping by related changes, while keeping the small-and-focused intent. Add explicit guidance on when to include a commit body and how to format it (blank line separator, ~72 col wrap). Applied to both backend and frontend prompt templates.
2 KiB
2 KiB
Frontend Prompt Template
Follow the existing patterns in this codebase to:
- xxxxxxxx
Requirements:
- xxxxx
Process (TDD - Test Driven Development):
- Write a test first
- Run the test to confirm it fails
- Implement the code to make the test pass
- Run the test to confirm it passes
- Repeat for each new behavior
Code patterns to follow:
- First, explore the codebase to understand existing entity patterns
- Look at similar pages for reference
- Tests: follow existing patterns in cypress/e2e/
- Lines should not exceed 80 columns, but should use up to 80 columns when possible — do not split lines unnecessarily
- Imports: always put imports at the top of the file
- Variable names: use explicit, descriptive names — never single-letter or abbreviated variables (e.g., use sponsorship not s, event not e)
Git commit style:
- Subject: present tense, imperative mood (add, create, test, fix)
- Subject: lowercase, short (3-6 words)
- Match subject patterns found in git history
- Add a body when the change needs explanation beyond the subject — e.g., why the change was made, non-obvious tradeoffs, or notable implementation details. Skip the body for trivial/self-evident commits.
- Separate subject and body with a blank line; wrap body at ~72 columns
Git commits:
- Tests should be committed first, before implementation
- Group related changes together in a single commit (e.g., a new class plus its registration, or a getter plus the property it exposes). Avoid mixing unrelated concerns in one commit.
- Keep commits small and focused — prefer many small commits over few large ones, but don't artificially split a single logical change across multiple commits
- Commits are for reviewing and documenting the development of code
- Don't wait to commit — commit as you go
Branch naming:
- Use kebab-case (e.g., node-page text-page)
- Use descriptive feature names
- NEVER work directly on master - always create and work on a branch
Do not push anything. Make commits as you go.