feat(python): add template kind (#1789)

CHANGELOG.md

@@ -8,6 +8,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ## [Unreleased]
 
 ### Added
+- Python template kind for Python-oriented project scaffolds, automation helpers, packages, and service/tooling skeletons (#1773)
 - Static template kind for technology-agnostic file and directory boilerplates (#1786)
 - Named generation output paths via `generate --name` / `-n` (#1783)
 - Exhaustive dependency matrix validation for rendering reachable template states, with optional kind-specific validators (#1780)
@@ -19,6 +20,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Default library migration now rewrites the built-in repository from `christianlempa/boilerplates` to `christianlempa/boilerplates-library`, with startup notices and legacy `/library` path fallback (#1762)
 - Variable definitions now use the `secret` type and nested `config` metadata for options, placeholders, sliders, and secret autogeneration across the runtime, schemas, and migrated template specs (#1767)
 
+### Fixed
+- Ansible templates can now contain literal downstream Jinja expressions like `{{ variable }}` without boilerplate validation treating them as undeclared variables (#1775)
+
 ## [0.2.0-2] - 2026-04-23
 
 ### Fixed

README.md

@@ -18,6 +18,12 @@ It combines template-defined variables and defaults, guided interactive prompts,
 
 ℹ️ New templates must use `template.json`, keep renderable content under `files/`, and use the custom *Jinja2*-like delimiters `<< >>`, `<% %>`, and `<# #>` instead of default *Jinja2* syntax.
 
+### Template kinds
+
+Use a dedicated kind when the template's primary output matches that technology. Use `python` for Python-oriented project scaffolds, automation helpers, packages, and service/tooling skeletons. Keep Python files inside another kind, such as `compose` or `terraform`, when they are only supporting files for that primary infrastructure template.
+
+Initial `python` validation is intentionally minimal: the CLI validates template syntax, declared variables, rendering, and generic semantic checks where applicable. Python-specific validation such as compilation, formatting, or test execution can be added as a follow-up once template conventions are established.
+
 ### Installation
 
 #### Automated installer script

cli/modules/python/__init__.py

@@ -0,0 +1,14 @@
+"""Python templates module."""
+
+from ...core.module import Module
+from ...core.registry import registry
+
+
+class PythonModule(Module):
+    """Python templates module."""
+
+    name = "python"
+    description = "Manage Python project and automation templates"
+
+
+registry.register(PythonModule)

tests/test_python_module.py

@@ -0,0 +1,20 @@
+"""Tests for the Python template module."""
+
+from __future__ import annotations
+
+import cli.modules.python  # noqa: F401 - import registers the module
+from cli.core.registry import registry
+from cli.modules.python import PythonModule
+
+
+def test_python_module_metadata() -> None:
+    """The Python module should expose the expected CLI metadata."""
+    assert PythonModule.name == "python"
+    assert PythonModule.description == "Manage Python project and automation templates"
+
+
+def test_python_module_registers_with_registry() -> None:
+    """Importing the module should make the Python kind discoverable."""
+    registered_modules = dict(registry.iter_module_classes())
+
+    assert registered_modules["python"] is PythonModule