Copilot instructions

1# Commit Message Guidelines
2 
3Follow these rules for all commit messages to ensure clarity and consistency.
4 
5## Commit Message Format
6 
7```
8<type>[optional scope]: <subject>
9<BLANK LINE>
10[optional body]
11```
12 
13- **type**: One of `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `perf`, `build`, `ci`, `chore`, `revert`
14- **scope**: (Optional) A noun describing the section affected (e.g., `api`, `ui`, `auth`)
15- **subject**: Short, imperative summary (max 50 characters, no period)
16- **body**: (Optional) Detailed explanation, reasoning, or context
17 
18## Examples
19 
20```
21feat(api): Add user login endpoint
22fix(ui): Correct button alignment
23docs(README): update usage section for clarity
24style: format codebase using Prettier
25refactor(auth): simplify token handling logic and improve error handling
26 
27# Explanations:
28# - Used lowercase for commit types/scopes for Conventional Commits consistency.
29# - Made descriptions more specific and actionable.
30# - Added "improve error handling" to encourage robust refactoring.
31# - Used imperative mood for clarity and best practices.
32test(api): Add tests for login
33perf: Optimize query performance
34build: Update dependencies
35ci: Add GitHub Actions workflow
36chore: Remove unused files
37revert: Revert "feat(api): Add user login endpoint"
38```
39 
40## Best Practices
41- Use imperative mood in the subject (e.g., "Add", not "Added" or "Adds")
42- Start subject with a capital letter
43- Do not end subject with a period
44- Limit subject to 50 characters for readability
45- Leave a blank line between subject and body
46- Use the body for:
47  - Explaining the motivation and context
48  - Listing multiple changes as bullet points
49  - Referencing related issues or PRs (e.g., "Closes #123")
50- Ensure messages are descriptive and actionable
51- For breaking changes, start the body with `BREAKING CHANGE:`
52- Only mention files that are directly affected by the change
53 
54## Error Handling & Edge Cases
55 
56- If reverting a commit, use the `revert:` type and reference the original commit
57- For multi-part changes, consider splitting into focused commits
58- Avoid ambiguous types or scopes; be specific
59 
60## Atomic Commits
61- Each commit should represent a single logical change
62- Avoid large commits that mix multiple changes
63