.cursor/rules/avoid-debug-loops.mdc

@@ -0,0 +1,57 @@
+---
+description: When stuck in debugging loops, break the cycle by minimizing to an MVP, removing debugging cruft, and documenting the issue completely for a fresh approach
+globs: *.py
+alwaysApply: true
+---
+# Avoid Debug Loops
+
+When debugging becomes circular and unproductive, follow these steps:
+
+## Detection
+- You have made multiple unsuccessful attempts to fix the same issue
+- You are adding increasingly complex code to address errors
+- Each fix creates new errors in a cascading pattern
+- You are uncertain about the root cause after 2-3 iterations
+
+## Action Plan
+
+1. **Pause and acknowledge the loop**
+   - Explicitly state that you are in a potential debug loop
+   - Review what approaches have been tried and failed
+
+2. **Minimize to MVP**
+   - Remove all debugging cruft and experimental code
+   - Revert to the simplest version that demonstrates the issue
+   - Focus on isolating the core problem without added complexity
+
+3. **Comprehensive Documentation**
+   - Provide a clear summary of the issue
+   - Include minimal but complete code examples that reproduce the problem
+   - Document exact error messages and unexpected behaviors
+   - Explain your current understanding of potential causes
+
+4. **Format for Portability**
+   - Present the problem in quadruple backticks for easy copying:
+
+````
+# Problem Summary
+[Concise explanation of the issue]
+
+## Minimal Reproduction Code
+```python
+# Minimal code example that reproduces the issue
+```
+
+## Error/Unexpected Output
+```
+[Exact error messages or unexpected output]
+```
+
+## Failed Approaches
+[Brief summary of approaches already tried]
+
+## Suspected Cause
+[Your current hypothesis about what might be causing the issue]
+````
+
+This format enables the user to easily copy the entire problem statement into a fresh conversation for a clean-slate approach.

.cursor/rules/dev-loop.mdc

@@ -0,0 +1,187 @@
+---
+description: QA every edit
+globs: *.py
+alwaysApply: true
+---
+
+# Development Process
+
+## Project Stack
+
+The project uses the following tools and technologies:
+
+- **uv** - Python package management and virtual environments
+- **ruff** - Fast Python linter and formatter
+- **py.test** - Testing framework
+  - **pytest-watcher** - Continuous test runner
+- **mypy** - Static type checking
+- **doctest** - Testing code examples in documentation
+
+## 1. Start with Formatting
+
+Format your code first:
+
+```
+uv run ruff format .
+```
+
+## 2. Run Tests
+
+Verify that your changes pass the tests:
+
+```
+uv run py.test
+```
+
+For continuous testing during development, use pytest-watcher:
+
+```
+# Watch all tests
+uv run ptw .
+
+# Watch and run tests immediately, including doctests
+uv run ptw . --now --doctest-modules
+
+# Watch specific files or directories
+uv run ptw . --now --doctest-modules src/libtmux/_internal/
+```
+
+## 3. Commit Initial Changes
+
+Make an atomic commit for your changes using conventional commits.
+Use `@git-commits.mdc` for assistance with commit message standards.
+
+## 4. Run Linting and Type Checking
+
+Check and fix linting issues:
+
+```
+uv run ruff check . --fix --show-fixes
+```
+
+Check typings:
+
+```
+uv run mypy
+```
+
+## 5. Verify Tests Again
+
+Ensure tests still pass after linting and type fixes:
+
+```
+uv run py.test
+```
+
+## 6. Final Commit
+
+Make a final commit with any linting/typing fixes.
+Use `@git-commits.mdc` for assistance with commit message standards.
+
+## Development Loop Guidelines
+
+If there are any failures at any step due to your edits, fix them before proceeding to the next step.
+
+## Python Code Standards
+
+### Docstring Guidelines
+
+For `src/**/*.py` files, follow these docstring guidelines:
+
+1. **Use reStructuredText format** for all docstrings.
+   ```python
+   """Short description of the function or class.
+
+   Detailed description using reStructuredText format.
+
+   Parameters
+   ----------
+   param1 : type
+       Description of param1
+   param2 : type
+       Description of param2
+
+   Returns
+   -------
+   type
+       Description of return value
+   """
+   ```
+
+2. **Keep the main description on the first line** after the opening `"""`.
+
+3. **Use NumPy docstyle** for parameter and return value documentation.
+
+### Doctest Guidelines
+
+For doctests in `src/**/*.py` files:
+
+1. **Use narrative descriptions** for test sections rather than inline comments:
+   ```python
+   """Example function.
+
+   Examples
+   --------
+   Create an instance:
+
+   >>> obj = ExampleClass()
+
+   Verify a property:
+
+   >>> obj.property
+   'expected value'
+   """
+   ```
+
+2. **Move complex examples** to dedicated test files at `tests/examples/<path_to_module>/test_<example>.py` if they require elaborate setup or multiple steps.
+
+3. **Utilize pytest fixtures** via `doctest_namespace` for more complex test scenarios:
+   ```python
+   """Example with fixture.
+
+   Examples
+   --------
+   >>> # doctest_namespace contains all pytest fixtures from conftest.py
+   >>> example_fixture = getfixture('example_fixture')
+   >>> example_fixture.method()
+   'expected result'
+   """
+   ```
+
+4. **Keep doctests simple and focused** on demonstrating usage rather than comprehensive testing.
+
+5. **Add blank lines between test sections** for improved readability.
+
+6. **Test your doctests continuously** using pytest-watcher during development:
+   ```
+   # Watch specific modules for doctest changes
+   uv run ptw . --now --doctest-modules src/path/to/module.py
+   ```
+
+### Pytest Testing Guidelines
+
+1. **Use existing fixtures over mocks**:
+   - Use fixtures from conftest.py instead of `monkeypatch` and `MagicMock` when available
+   - For instance, if using libtmux, use provided fixtures: `server`, `session`, `window`, and `pane`
+   - Document in test docstrings why standard fixtures weren't used for exceptional cases
+
+2. **Preferred pytest patterns**:
+   - Use `tmp_path` (pathlib.Path) fixture over Python's `tempfile`
+   - Use `monkeypatch` fixture over `unittest.mock`
+
+### Import Guidelines
+
+1. **Prefer namespace imports**:
+   - Import modules and access attributes through the namespace instead of importing specific symbols
+   - Example: Use `import enum` and access `enum.Enum` instead of `from enum import Enum`
+   - This applies to standard library modules like `pathlib`, `os`, and similar cases
+
+2. **Standard aliases**:
+   - For `typing` module, use `import typing as t`
+   - Access typing elements via the namespace: `t.NamedTuple`, `t.TypedDict`, etc.
+   - Note primitive types like unions can be done via `|` pipes and primitive types like list and dict can be done via `list` and `dict` directly.
+
+3. **Benefits of namespace imports**:
+   - Improves code readability by making the source of symbols clear
+   - Reduces potential naming conflicts
+   - Makes import statements more maintainable

.cursor/rules/git-commits.mdc

@@ -0,0 +1,95 @@
+---
+description: git-commits: Git commit message standards and AI assistance
+globs: git-commits: Git commit message standards and AI assistance | *.git/* .gitignore .github/* CHANGELOG.md CHANGES.md
+alwaysApply: true
+---
+# Optimized Git Commit Standards
+
+## Commit Message Format
+```
+Component/File(commit-type[Subcomponent/method]): Concise description
+
+why: Explanation of necessity or impact.
+what:
+- Specific technical changes made
+- Focused on a single topic
+
+refs: #issue-number, breaking changes, or relevant links
+```
+
+## Component Patterns
+### General Code Changes
+```
+Component/File(feat[method]): Add feature
+Component/File(fix[method]): Fix bug
+Component/File(refactor[method]): Code restructure
+```
+
+### Packages and Dependencies
+| Language   | Standard Packages                  | Dev Packages                  | Extras / Sub-packages                          |
+|------------|------------------------------------|-------------------------------|-----------------------------------------------|
+| General    | `lang(deps):`                      | `lang(deps[dev]):`            |                                               |
+| Python     | `py(deps):`                        | `py(deps[dev]):`              | `py(deps[extra]):`                            |
+| JavaScript | `js(deps):`                        | `js(deps[dev]):`              | `js(deps[subpackage]):`, `js(deps[dev{subpackage}]):` |
+
+#### Examples
+- `py(deps[dev]): Update pytest to v8.1`
+- `js(deps[ui-components]): Upgrade Button component package`
+- `js(deps[dev{linting}]): Add ESLint plugin`
+
+### Documentation Changes
+Prefix with `docs:`
+```
+docs(Component/File[Subcomponent/method]): Update API usage guide
+```
+
+### Test Changes
+Prefix with `tests:`
+```
+tests(Component/File[Subcomponent/method]): Add edge case tests
+```
+
+## Commit Types Summary
+- **feat**: New features or enhancements
+- **fix**: Bug fixes
+- **refactor**: Code restructuring without functional change
+- **docs**: Documentation updates
+- **chore**: Maintenance (dependencies, tooling, config)
+- **test**: Test-related updates
+- **style**: Code style and formatting
+
+## General Guidelines
+- Subject line: Maximum 50 characters
+- Body lines: Maximum 72 characters
+- Use imperative mood (e.g., "Add", "Fix", not "Added", "Fixed")
+- Limit to one topic per commit
+- Separate subject from body with a blank line
+- Mark breaking changes clearly: `BREAKING:`
+- Use `See also:` to provide external references
+
+## AI Assistance Workflow in Cursor
+- Stage changes with `git add`
+- Use `@commit` to generate initial commit message
+- Review and refine generated message
+- Ensure adherence to these standards
+
+## Good Commit Example
+```
+Pane(feat[capture_pane]): Add screenshot capture support
+
+why: Provide visual debugging capability
+what:
+- Implement capturePane method with image export
+- Integrate with existing Pane component logic
+- Document usage in Pane README
+
+refs: #485
+See also: https://example.com/docs/pane-capture
+```
+
+## Bad Commit Example
+```
+fixed stuff and improved some functions
+```
+
+These guidelines ensure clear, consistent commit histories, facilitating easier code review and maintenance.