loosen commit granularity rule in prompts
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.
This commit is contained in:
parent
bb6bd7cbb3
commit
40726c3984
2 changed files with 28 additions and 16 deletions
|
|
@ -32,18 +32,24 @@ Code patterns to follow:
|
||||||
- Variable names: use explicit, descriptive names — never single-letter or abbreviated variables (e.g., use $sponsorship not $s, $event not $e)
|
- Variable names: use explicit, descriptive names — never single-letter or abbreviated variables (e.g., use $sponsorship not $s, $event not $e)
|
||||||
|
|
||||||
Git commit style:
|
Git commit style:
|
||||||
- Present tense, imperative mood (add, create, test, fix)
|
- Subject: present tense, imperative mood (add, create, test, fix)
|
||||||
- Lowercase
|
- Subject: lowercase, short (3-6 words)
|
||||||
- Short (3-6 words)
|
- Match subject patterns found in git history
|
||||||
- Match 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:
|
Git commits:
|
||||||
- Tests should be committed first, before implementation
|
- Tests should be committed first, before implementation
|
||||||
- One commit per file - each new file gets its own commit
|
- Group related changes together in a single commit (e.g., a new class
|
||||||
- Make commits SMALL and FREQUENT - every meaningful change should be a commit
|
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
|
- 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
|
||||||
- Don't wait to commit - commit as you go
|
|
||||||
- Run `php-cs-fixer fix` on worked on directories before committing
|
- Run `php-cs-fixer fix` on worked on directories before committing
|
||||||
|
|
||||||
Branch naming:
|
Branch naming:
|
||||||
|
|
|
||||||
|
|
@ -22,18 +22,24 @@ Code patterns to follow:
|
||||||
- Variable names: use explicit, descriptive names — never single-letter or abbreviated variables (e.g., use sponsorship not s, event not e)
|
- Variable names: use explicit, descriptive names — never single-letter or abbreviated variables (e.g., use sponsorship not s, event not e)
|
||||||
|
|
||||||
Git commit style:
|
Git commit style:
|
||||||
- Present tense, imperative mood (add, create, test, fix)
|
- Subject: present tense, imperative mood (add, create, test, fix)
|
||||||
- Lowercase
|
- Subject: lowercase, short (3-6 words)
|
||||||
- Short (3-6 words)
|
- Match subject patterns found in git history
|
||||||
- Match 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:
|
Git commits:
|
||||||
- Tests should be committed first, before implementation
|
- Tests should be committed first, before implementation
|
||||||
- One commit per file - each new file gets its own commit
|
- Group related changes together in a single commit (e.g., a new class
|
||||||
- Make commits SMALL and FREQUENT - every meaningful change should be a commit
|
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
|
- 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
|
||||||
- Don't wait to commit - commit as you go
|
|
||||||
|
|
||||||
Branch naming:
|
Branch naming:
|
||||||
- Use kebab-case (e.g., node-page text-page)
|
- Use kebab-case (e.g., node-page text-page)
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue