agent rules aktualisiert

2026-05-22 08:06:06 +02:00
parent ccf3b6f0bd
commit 3cdd73e260
2 changed files with 45 additions and 43 deletions
@@ -1,49 +1,7 @@
 ---
 trigger: always_on
 description: Project workflow rules, GitHub flow, and TODO.md tracking.
 alwaysOn: true
 always_on: true
 glob: "*"
 ---
 ## Git Feature Branch Workflow
 This project strictly follows the **Git Feature Branch Workflow** (as defined by [Atlassian](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)). 
 The core idea is that all feature development should take place in a dedicated branch instead of the `main` branch. 
 ### 1. Development Workflow
 1. **Never Commit to Main:** Direct commits to `main` are strictly prohibited. `main` must always be stable and deployable.
 2. **Branch Creation:** Create a descriptive branch from the latest `main` state (e.g., `feature/animated-menu-items` or `issue-#1061`):
   `git checkout main && git pull origin main && git checkout -b feature/your-feature-name`
 3. **Atomic Commits:** Make small, logical, and self-contained commits to your feature branch.
 4. **Push & Pull Request:** Push the feature branch to the remote repository and open a Pull Request (PR) against `main`. PRs act as a forum for discussing the feature and performing code reviews before it is merged.
   - **GitHub Actions Rule:** When setting up automated workflows (like Gemini AI PR review), **always pin actions to a specific version tag** (e.g., `@v1.0.4`) instead of `@latest` to prevent breaking changes. Ensure secrets are passed safely via repository secrets (`env:`), never hardcoded.
 5. **Merge & Close:** Once approved, the feature branch is merged into `main` and then deleted. (You can use the `close_feature` skill for this).
 ### 2. Merge Conflict Policy
 When multiple features are developed simultaneously, `main` might advance before your PR is merged, causing a merge conflict. **The author of the pending PR is solely responsible for resolving conflicts.**
 #### Resolution Procedure:
 Never force-push blindly or overwrite other developers' work without understanding it. Follow these exact steps to resolve a conflict:
 1. **Update Local Main:** Fetch the latest changes from the remote `main` branch.
   ```bash
   git checkout main
   git pull origin main
   ```
 2. **Merge Main into Feature Branch:** Switch back to your feature branch and merge `main` into it.
   ```bash
   git checkout feature/your-feature-name
   git merge main
   ```
 3. **Resolve Conflicts:** Git will pause the merge and mark the conflicted files. Open these files in your editor, look for the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`), and manually choose the correct code. Remove the markers once done.
 4. **Stage and Commit:** After resolving all conflicts, stage the files and finish the merge commit.
   ```bash
   git add .
   git commit -m "Merge main into feature and resolve conflicts"
   ```
 5. **Push Updates:** Push the resolved feature branch back to the remote repository to update the Pull Request.
   ```bash
   git push origin feature/your-feature-name
   ```
 ### 3. Documentation Update
@@ -0,0 +1,44 @@
 ---
 trigger: always_on
 ---
 ## Git Feature Branch Workflow
 This project strictly follows the **Git Feature Branch Workflow** (as defined by [Atlassian](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)). 
 The core idea is that all feature development should take place in a dedicated branch instead of the `main` branch. 
 ### 1. Development Workflow
 1. **Never Commit to Main:** Direct commits to `main` are strictly prohibited. `main` must always be stable and deployable.
 2. **Branch Creation:** Create a descriptive branch from the latest `main` state (e.g., `feature/animated-menu-items` or `issue-#1061`):
   `git checkout main && git pull origin main && git checkout -b feature/your-feature-name`
 3. **Atomic Commits:** Make small, logical, and self-contained commits to your feature branch.
 4. **Push & Pull Request:** Push the feature branch to the remote repository and open a Pull Request (PR) against `main`. PRs act as a forum for discussing the feature and performing code reviews before it is merged.
   - **GitHub Actions Rule:** When setting up automated workflows (like Gemini AI PR review), **always pin actions to a specific version tag** (e.g., `@v1.0.4`) instead of `@latest` to prevent breaking changes. Ensure secrets are passed safely via repository secrets (`env:`), never hardcoded.
 5. **Merge & Close:** Once approved, the feature branch is merged into `main` and then deleted. (You can use the `close_feature` skill for this).
 ### 2. Merge Conflict Policy
 When multiple features are developed simultaneously, `main` might advance before your PR is merged, causing a merge conflict. **The author of the pending PR is solely responsible for resolving conflicts.**
 #### Resolution Procedure:
 Never force-push blindly or overwrite other developers' work without understanding it. Follow these exact steps to resolve a conflict:
 1. **Update Local Main:** Fetch the latest changes from the remote `main` branch.
   ```bash
   git checkout main
   git pull origin main
   ```
 2. **Merge Main into Feature Branch:** Switch back to your feature branch and merge `main` into it.
   ```bash
   git checkout feature/your-feature-name
   git merge main
   ```
 3. **Resolve Conflicts:** Git will pause the merge and mark the conflicted files. Open these files in your editor, look for the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`), and manually choose the correct code. Remove the markers once done.
 4. **Stage and Commit:** After resolving all conflicts, stage the files and finish the merge commit.
   ```bash
   git add .
   git commit -m "Merge main into feature and resolve conflicts"
   ```
 5. **Push Updates:** Push the resolved feature branch back to the remote repository to update the Pull Request.
   ```bash
   git push origin feature/your-feature-name
   ```