52 lines
2.1 KiB
Markdown
52 lines
2.1 KiB
Markdown
# Frontend Prompt Template
|
|
|
|
Follow the existing patterns in this codebase to:
|
|
- xxxxxxxx
|
|
|
|
Requirements:
|
|
- xxxxx
|
|
|
|
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 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)
|
|
- Never use em-dashes (—) in code, comments, commit messages, or any
|
|
written output. Use a regular hyphen (-), a colon, or rephrase
|
|
with parentheses instead.
|
|
|
|
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.
|