wehub-resource-sync
97e91a83f3
Ruff / Ruff (push) Waiting to run
Test / Core Tests (push) Waiting to run
Test / Offline Coverage Tests (Python 3.10) (push) Waiting to run
Test / Offline Coverage Tests (Python 3.11) (push) Waiting to run
Test / Offline Coverage Tests (Python 3.12) (push) Waiting to run
Test / Offline Coverage Tests (Python 3.13) (push) Waiting to run
Test / Offline Coverage Tests (Python 3.9) (push) Waiting to run
Test / Full Coverage (Python 3.11) (push) Waiting to run
Test / Core Provider Tests (OpenAI) (push) Blocked by required conditions
Test / Core Provider Tests (Anthropic) (push) Blocked by required conditions
Test / Core Provider Tests (Google) (push) Blocked by required conditions
Test / Core Provider Tests (Other) (push) Blocked by required conditions
Test / Anthropic Tests (push) Blocked by required conditions
Test / Gemini Tests (push) Blocked by required conditions
Test / Google GenAI Tests (push) Blocked by required conditions
Test / Vertex AI Tests (push) Blocked by required conditions
Test / OpenAI Tests (push) Blocked by required conditions
Test / Writer Tests (push) Blocked by required conditions
Test / Auto Client Tests (push) Blocked by required conditions
ty / type-check (push) Waiting to run
46 lines
1.8 KiB
Plaintext
46 lines
1.8 KiB
Plaintext
---
|
|
description: when asked to implement new features or clients
|
|
globs: *.py
|
|
alwaysApply: true
|
|
---
|
|
|
|
- When being asked to make new features, make sure that you check out from main a new branch and make incremental commits
|
|
- Use conventional commit format: `<type>(<scope>): <description>`
|
|
- Types: feat, fix, docs, style, refactor, perf, test, chore
|
|
- Example: `feat(validation): add email validation function`
|
|
- Keep commits focused on a single change
|
|
- Write descriptive commit messages in imperative mood
|
|
- Use `git commit -m "type(scope): subject" -m "body" -m "footer"` for multiline commits
|
|
- If the feature is very large, create a temporary `todo.md`
|
|
- And start a pull request using `gh`
|
|
- Create PRs with multiline bodies using:
|
|
```bash
|
|
gh pr create --title "feat(component): add new feature" --body "$(cat <<EOF
|
|
## Description
|
|
Detailed explanation of the changes
|
|
|
|
## Changes
|
|
- List important changes
|
|
- Another change
|
|
|
|
## Testing
|
|
How this was tested
|
|
|
|
This PR was written by [Cursor](cursor.com)
|
|
EOF
|
|
)" -r jxnl,ivanleomk
|
|
```
|
|
- Or use the `-F` flag with a file: `gh pr create -F pr_body.md`
|
|
- Make sure to include `This PR was written by [Cursor](mdc:cursor.com)`
|
|
- Add default reviewers:
|
|
- Use `gh pr edit <id> --add-reviewer jxnl,ivanleomk`
|
|
- Or include `-r jxnl,ivanleomk` when creating the PR
|
|
- use `gh pr view <id> --comments | cat` to view all the comments
|
|
- For PR updates:
|
|
- Do not directly commit to an existing PR branch
|
|
- Instead, create a new PR that builds on top of the original PR's branch
|
|
- This creates a "stacked PR" pattern where:
|
|
1. The original PR (base) contains the initial changes
|
|
2. The new PR (stack) contains only the review-related updates
|
|
3. Once the base PR is merged, the stack can be rebased onto main
|