docs: require frequent small commits and reduce Opus usage

AGENTS.md

@@ -135,6 +135,9 @@ async def execute_flux_node(inputs: dict, params: dict, context: ExecutionContex
 - **GitFlow**: Follow `BRANCHING_STRATEGY.md`. Feature, ordinary bug-fix, and documentation branches start from and target `dev`; release branches start from `dev` and target `main`, then synchronize back to `dev`; hotfix branches start from `main` and target `main`, then synchronize back to `dev`. Never commit directly to `main` or `dev`.
 - **Commit Messages**: Follow Conventional Commits (`feat:`, `fix:`, `docs:`, `refactor:`, `test:`, `chore:`).
 - **Clean Commits**: Keep changes atomic. Do not bundle formatting refactors with behavioral feature additions.
+- **Commit Frequency and Size**: Please commit frequently; large commits are prohibited. Commit each small, coherent, verified increment before moving to the next increment. Keep related implementation and tests together; never accumulate an entire task or milestone into one large commit.
+- **Preserve Small Commits**: Do not squash small commits into a large aggregate commit. Follow the merge guidance in `BRANCHING_STRATEGY.md`.
+- **Model Cost**: Prefer Gemini for routine implementation, UI, documentation, tests, and well-scoped fixes. Use Opus sparingly for complex architecture or difficult defects when needed. Assign one issue at a time unless the user requests otherwise.
 
 ---
 

BRANCHING_STRATEGY.md

@@ -27,10 +27,10 @@ Use lowercase, short, descriptive names. Include an issue ID when one exists. On
 
 1. Update local `dev` from `origin/dev` and create a short-lived branch from it.
 2. Implement a focused change with the relevant tests and English documentation.
-3. Write English Conventional Commits, for example `feat(launcher): add startup readiness check` or `fix(runtime): preserve engine data during update`.
+3. Please commit frequently; large commits are prohibited. Commit each small, coherent, verified increment using English Conventional Commits, for example `feat(launcher): add startup readiness check` or `fix(runtime): preserve engine data during update`. Keep related implementation and tests together, separate unrelated changes, and do not accumulate an entire task or milestone into one commit.
 4. Open a PR targeting `dev`. Describe user-visible behavior, validation evidence, limitations and related requirement or issue IDs.
 5. Keep the branch current with `dev` before merging. Resolve conflicts on the working branch and rerun affected checks.
-6. Merge only after review and required checks pass. Prefer squash merge for feature, bug-fix and documentation PRs, yielding one clear change in `dev` per PR. Delete the temporary branch after merge.
+6. Merge only after review and required checks pass. Preserve small, atomic commits. Use a merge commit when squashing would create a large aggregate commit; squash only when the resulting commit remains small and focused. Split large tasks into focused PRs rather than using squashing to hide oversized changes. Delete the temporary branch after merge.
 
 Never merge a feature branch directly into `main`. Never force-push a shared integration or release branch. Rebasing a personal branch before review is allowed; do not rewrite a shared branch after others depend on it.
 

CONTRIBUTING.md

@@ -83,6 +83,8 @@ Use English for all project documentation, PR titles and descriptions, commit me
    - Write clean, self-documenting code.
    - Maintain unit tests for new logic.
 4. **Commit with Conventional Commits**:
+   - Please commit frequently; large commits are prohibited.
+   - Commit small, coherent, verified increments throughout the work. Keep related implementation and tests together, and separate unrelated changes. Do not wait until an entire task or milestone is finished to commit.
    - Follow the standard format: `type(scope): description`.
    - Example: `feat(nodes): add ElevenLabs TTS voice synthesis node`
 5. **Run Checks Locally**:
@@ -114,5 +116,6 @@ Before submitting your PR, ensure:
 - [ ] Code adheres to TypeScript and Python formatting guidelines.
 - [ ] User-facing features include updated documentation or tooltips.
 - [ ] Commit history is clean and uses conventional commit messages.
+- [ ] Work was committed frequently in small, atomic increments; no large commits are included or created by squashing.
 
 Thank you for helping make AI creation accessible and enjoyable for everyone!