Add template testing prompt

Author: tedivm

.github/prompts/template-testing.prompt.md

@@ -0,0 +1,197 @@
+---
+description: "Comprehensive testing of the cookiecutter template across all configurations."
+---
+
+# Template Testing Prompt
+
+Please perform comprehensive testing of the cookiecutter template to ensure all configurations generate working projects with passing tests, type checking, and linting.
+
+## Task Requirements:
+
+### 1. Standard Test Configurations
+
+Test ALL three standard configurations located in the `tests/` directory:
+
+- **Full configuration** (`tests/full.yaml`): All features enabled (FastAPI, Celery, QuasiQueue, Database, Caching, Docker)
+- **Library configuration** (`tests/library.yaml`): Minimal setup for Python library development
+- **Bare configuration** (`tests/bare.yaml`): Basic project with no optional features
+
+### 2. Testing Workflow
+
+For EACH configuration, perform these steps:
+
+#### Step 1: Generate Project
+
+```bash
+cd /Users/tedivm/Repositories/tedivm/robs_awesome_python_template
+rm -rf workspaces/<config_name>
+cookiecutter --config-file tests/<config_name>.yaml --no-input --output-dir workspaces .
+cd workspaces/<config_name>
+```
+
+#### Step 2: Run Test Suite
+
+Run the key validation checks:
+
+```bash
+make pytest      # Run all tests with coverage
+make mypy_check  # Type checking
+make ruff_check  # Linting
+```
+
+Note: Formatting issues (dapperdata, tomlsort, paracelsus) can be auto-fixed with `make chores` and are not critical for validation.
+
+#### Step 3: Verify Results
+
+Check that:
+
+- ✅ All tests pass (exit code 0)
+- ✅ Test coverage meets expectations (typically 90%+ for full/library, 100% for bare)
+- ✅ No mypy type errors
+- ✅ No ruff linting errors
+- ✅ Code formatting is correct
+
+### 3. Context-Specific Testing
+
+**IMPORTANT:** In addition to the three standard configurations, create and test additional custom configurations relevant to your current work session.
+
+For example:
+
+- If you modified caching functionality, test a config with caching enabled and one with it disabled
+- If you updated Docker configurations, test with and without Docker components
+- If you modified CLI functionality, test with and without optional CLI features
+- If you modify a component with hooks into a lot of other systems, create multiple configurations to validate those changes
+
+#### Creating Custom Test Configurations
+
+Create temporary YAML config files in the `workspaces/` directory (these won't be committed):
+
+```yaml
+# Example: workspaces/custom_test.yaml
+default_context:
+  project_name: "Custom Test"
+  project_slug: "custom_test"
+  package_name: "custom_test"
+  include_fastapi: "y"
+  include_celery: "n"
+  include_database: "y"
+  include_caching: "y"
+  # ... other settings as needed
+```
+
+Then test with:
+
+```bash
+cookiecutter --config-file workspaces/custom_test.yaml --no-input --output-dir workspaces .
+```
+
+### 4. Expected Test Results
+
+Standard configurations should produce these results:
+
+#### Bare Configuration
+
+- **Tests**: ~11 tests
+- **Coverage**: 100%
+- **Files tested**: Core settings and configuration
+
+#### Library Configuration
+
+- **Tests**: ~26 tests
+- **Coverage**: ~93%
+- **Files tested**: CLI, settings, basic project structure
+- **Note**: CLI should have version and hello commands
+
+#### Full Configuration
+
+- **Tests**: ~147 tests
+- **Coverage**: ~94%
+- **Files tested**: All services (cache, db, jinja), celery, CLI, QuasiQueue, FastAPI, settings
+- **Note**: Most comprehensive test suite with all features
+
+### 5. Common Issues and Troubleshooting
+
+#### Issue: Jinja2 Template Errors
+
+- **Cause**: Raw Jinja2 code in documentation or examples
+- **Solution**: Ensure all Jinja2 examples in markdown files are wrapped in `{% raw %}...{% endraw %}`
+
+#### Issue: Mypy Type Errors
+
+- **Cause**: Missing type annotations or untyped library imports
+- **Solution**: Check pyproject.toml has strict mypy settings enabled; use `# type: ignore` for untyped third-party libraries as a last resort only
+
+#### Issue: CLI Tests Failing
+
+- **Cause**: Typer single-command behavior or missing commands
+- **Solution**: Ensure CLI always has at least 2 commands (version + hello minimum)
+
+#### Issue: Import Errors
+
+- **Cause**: Optional dependencies not properly handled
+- **Solution**: Check that conditional imports use try/except blocks or are properly guarded
+
+### 6. Reporting Results
+
+After testing, provide a summary that includes:
+
+1. **Configuration Results**: For each tested configuration
+
+   - Configuration name
+   - Number of tests run
+   - Number of tests passed/failed
+   - Code coverage percentage
+   - Any errors or warnings
+
+2. **Test Output Analysis**: Key findings from test execution
+
+   - Any deprecation warnings
+   - Performance issues
+   - Coverage gaps in important modules
+
+3. **Validation Status**: Overall health check
+   - ✅ All standard configurations passing
+   - ✅ Context-specific configurations passing
+   - ✅ Type checking clean (mypy)
+   - ✅ Linting clean (ruff)
+   - ✅ Formatting correct (black)
+
+### 7. Performance Considerations
+
+- Run tests in sequence, not parallel (to avoid resource conflicts)
+- Clean up workspace directories between runs to ensure fresh state
+- Virtual environments can be reused within a configuration but should be recreated between different configurations
+
+### 8. Template Context Awareness
+
+Remember that this is a **cookiecutter template project**, which means:
+
+- The actual template files are in `{{cookiecutter.__package_slug}}/`
+- Test configurations are in `tests/*.yaml`
+- Generated projects appear in `workspaces/`
+- Many files contain Jinja2 templating syntax that looks like broken Python/YAML
+- The `hooks/post_gen_project.py` script removes unnecessary files based on configuration
+
+### 9. Success Criteria
+
+Testing is considered successful when:
+
+- ✅ All three standard configurations generate working projects
+- ✅ All test suites pass with high coverage (90%+)
+- ✅ No type checking errors (mypy clean)
+- ✅ No linting errors (ruff clean)
+- ✅ All formatting is correct (black clean)
+- ✅ Any context-specific configurations relevant to recent changes also pass
+- ✅ Exit codes are 0 for all test runs
+- ✅ No warnings or errors in test output
+
+## Implementation Approach:
+
+1. **Prepare**: Understand what changes were made in the current session
+2. **Plan**: Identify which configurations are most relevant to test
+3. **Execute**: Run standard configurations (bare, library, full) sequentially
+4. **Validate**: Create and test custom configurations for specific scenarios
+5. **Report**: Provide clear summary of all test results
+6. **Iterate**: If any tests fail, investigate and fix before proceeding
+
+Remember: Testing is not just about running commands—it's about validating that the template produces high-quality, production-ready Python projects across all supported configurations.

.github/prompts/upgrade-actions.prompt.md

@@ -1,6 +1,5 @@
 ---
-mode: 'agent'
-description: 'Upgrade action versions in workflows of the template.'
+description: "Upgrade action versions in workflows of the template."
 ---
 
 # GitHub Actions Version Upgrade Prompt
@@ -10,33 +9,39 @@ Please update all GitHub workflow files in the template directory (`{{cookiecutt
 ## Task Requirements:
 
 ### 1. File Location
+
 - Target directory: `{{cookiecutter.__package_slug}}/.github/workflows/`
 - Update ALL `.yaml` workflow files in this directory
 - These are Jinja template files, so YAML formatting may appear broken due to template syntax - this is expected and should be preserved
 
 ### 2. Actions to Update
+
 - **First, discover all GitHub Actions used** by reading through all workflow files in the target directory
 - **Research each action's latest version** by checking their respective GitHub releases pages
 - **Categorize actions appropriately**:
-  - Core GitHub actions (actions/*)
-  - Docker actions (docker/*)
-  - PyPI/Python actions (pypa/*)
+  - Core GitHub actions (actions/\*)
+  - Docker actions (docker/\*)
+  - PyPI/Python actions (pypa/\*)
   - Third-party actions (other organizations)
 - **Apply appropriate update strategies** based on action type and current version patterns
 
 ### 3. Version Format Rules
+
 - **Use MAJOR versions only** (e.g., `v5`, `v6`, not `v5.2.1` or `v6.18.0`)
 - Major version tags automatically receive compatible updates
 - Exception: `pypa/gh-action-pypi-publish@release/v1` should stay as-is
 
 ### 4. Research Method
+
 - Look up latest versions by fetching GitHub releases pages
 - Infer GitHub URLs from action names (e.g., `actions/checkout` → `https://github.com/actions/checkout/releases`)
 - Use the web to find the most recent stable major version
 - Don't update to pre-release or beta versions
 
 ### 5. Template Preservation
+
 **CRITICAL:** Preserve ALL existing Jinja template syntax:
+
 - `{% raw %}${{ github.actor }}{% endraw %}`
 - `{% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}`
 - `{% raw %}${{ matrix.version }}{% endraw %}`
@@ -45,20 +50,24 @@ Please update all GitHub workflow files in the template directory (`{{cookiecutt
 - Template comments and whitespace
 
 ### 6. File Discovery
+
 - **Discover all workflow files** by listing all `.yaml` files in the target directory
 - **Don't assume file names** - read the directory contents to find all workflow files that need updating
 
 ### 7. Verification Steps
+
 After updating:
+
 1. Confirm all action versions are updated to latest major versions
 2. Verify Jinja templating is intact
 3. Check that YAML structure is preserved (even if it looks broken due to templates)
 
 ### 8. Example Updates
+
 ```yaml
 # Before:
 - uses: actions/checkout@v4
-- uses: actions/setup-python@v5  
+- uses: actions/setup-python@v5
 - uses: docker/[email protected]
 
 # After:
@@ -68,6 +77,7 @@ After updating:
 ```
 
 ## Implementation Approach:
+
 1. **Discover**: List all workflow files and identify all GitHub Actions used
 2. **Research**: Look up current latest versions for each discovered action
 3. **Plan**: Create a mapping of old version → new version