🔧 chore(tools): add test and ci types, update prompts and model

Author: Jannchie

tgit/changelog.py

@@ -278,7 +278,7 @@ def group_commits_by_type(commits: list[TGITCommit]) -> dict[str, list[TGITCommi
 
 
 def generate_changelog(commits_by_type: dict[str, list[TGITCommit]], from_ref: str, to_ref: str, remote_uri: str | None = None) -> str:
-    order = ["breaking", "feat", "fix", "refactor", "perf", "style", "docs", "chore"]
+    order = ["breaking", "feat", "fix", "refactor", "perf", "style", "docs", "test", "ci", "chore"]
     names = [
         ":rocket: Breaking Changes",
         ":sparkles: Features",
@@ -287,6 +287,8 @@ def generate_changelog(commits_by_type: dict[str, list[TGITCommit]], from_ref: s
         ":zap: Performance Improvements",
         ":lipstick: Styles",
         ":memo: Documentation",
+        ":test_tube: Tests",
+        ":construction_worker: CI",
         ":wrench: Chores",
     ]
     out_str = ""

tgit/commit.py

@@ -22,7 +22,7 @@
 with importlib.resources.path("tgit", "prompts") as prompt_path:
     env = Environment(loader=FileSystemLoader(prompt_path), autoescape=True)
 
-commit_types = ["feat", "fix", "chore", "docs", "style", "refactor", "perf", "wip"]
+commit_types = ["feat", "fix", "chore", "docs", "style", "refactor", "perf", "test", "ci"]
 commit_file = "commit.txt"
 commit_prompt_template = env.get_template("commit.txt")
 DEFAULT_MAX_OUTPUT_TOKENS = 256
@@ -321,7 +321,7 @@ def _stage_all_changes_if_confirmed(repo: git.Repo) -> bool:
 def _get_commit_choices() -> list[str]:
     """Return all supported commit type choices."""
     prefix = ["", "!"]
-    return ["".join(data) for data in itertools.product(commit_types, prefix)] + ["ci", "test", "version"]
+    return ["".join(data) for data in itertools.product(commit_types, prefix)] + ["version"]
 
 
 def _get_manual_commit_command(args: CommitArgs, choices: list[str]) -> str | None:

tgit/constants.py

@@ -1,4 +1,4 @@
 """Global constants used across the TGIT project."""
 
-DEFAULT_MODEL = "gpt-5-mini"
+DEFAULT_MODEL = "gpt-5.4-mini"
 REASONING_MODEL_HINTS = ("-reasoning", "o1", "o3", "gpt-5")

tgit/prompts/commit.txt

@@ -1,18 +1,55 @@
 # Git Commit Message Generator
 
-You are a git commit message generator. Analyze the provided diff and generate an appropriate commit message following the Conventional Commits specification.
+You are a git commit message generator. Analyze the provided diff and generate an appropriate commit message following the Conventional Commits specification (https://www.conventionalcommits.org/en/v1.0.0/).
+
+Your type selection directly determines how the project version is bumped according to Semantic Versioning (https://semver.org/). Choose types carefully.
 
 ## Current Context
 - **Branch**: {{ branch }}
 - **Commit Type**: {% if specified_type is not none %}"{{ specified_type }}" (user-specified - MUST be used){% else %}Choose from: {{ types | join(', ') }}{% endif %}
 
-## Commit Message Requirements
+## Semantic Versioning Impact
+
+Each commit type maps to a version bump level. You MUST choose the type that accurately reflects the nature of the change:
+
+| Version Bump | Trigger | When to Use |
+|---|---|---|
+| **MAJOR** (x.0.0) | `is_breaking: true` on ANY type | Incompatible API changes: removed public APIs, renamed exports, changed function signatures, changed return types, removed configuration options, or any change that requires consumers to modify their code |
+| **MINOR** (0.x.0) | `feat` | A new feature or capability is added. The change introduces new behavior that did not exist before. Existing behavior remains unchanged |
+| **PATCH** (0.0.x) | `fix`, `perf`, `refactor`, `style`, `docs`, `chore`, `test`, `ci` | Bug fixes, performance improvements, internal refactors, documentation, and maintenance. No new features, no breaking changes |
+
+### Critical Rules for Type Selection
+- **`feat`** = something genuinely NEW is added (new endpoint, new CLI option, new user-facing capability). Do NOT use `feat` for improving, updating, or fixing existing functionality.
+- **`fix`** = corrects a bug or incorrect behavior in existing functionality.
+- **`refactor`** = restructures existing code without changing its external behavior.
+- **`perf`** = a code change that improves performance without adding features or fixing bugs.
+- **`docs`** = documentation-only changes.
+- **`style`** = formatting, whitespace, semicolons — no logic changes.
+- **`chore`** = build process, tooling, dependency updates, or other maintenance tasks.
+- **`test`** = adding or correcting tests.
+- **`ci`** = CI/CD configuration changes.
+
+### Breaking Change Guidelines
+Mark `is_breaking: true` ONLY when the change is genuinely incompatible — consumers of the code must take action to adapt. Concrete examples:
+- Removing or renaming a public function, class, CLI command, or API endpoint
+- Changing the type signature of a public interface (parameters, return values)
+- Changing default behavior that users rely on
+- Removing a configuration option or changing its semantics
+- Changing data formats in a way that breaks existing consumers
+
+Do NOT mark as breaking:
+- Internal refactors that don't affect the public API
+- Adding new optional parameters with defaults
+- Adding new features alongside existing ones
+- Bug fixes (even if they change incorrect behavior to correct behavior)
+
+## Commit Message Format
 
 ### Type
 {% if specified_type is not none %}
 **MANDATORY**: Use "{{ specified_type }}" as specified by the user.
 {% else %}
-Select the most appropriate type from the available options based on the nature of the changes.
+Select the most appropriate type based on the semantic versioning rules above.
 {% endif %}
 
 ### Scope
@@ -28,33 +65,19 @@ Select the most appropriate type from the available options based on the nature
 - Cover the primary change(s) in the diff
 - If multiple distinct changes, separate with " && " (e.g., "update api && fix validation")
 
-### Breaking Changes
-Mark `is_breaking: true` only if changes:
-- Break existing API contracts
-- Require user action for compatibility
-- Remove or significantly change existing functionality
-
 ### Secret Detection
 - Review the diff for potential secrets (API keys, tokens, passwords, private keys, credentials, etc.).
 - For every suspected secret, add an entry to the `secrets` array with the file path, a brief description, and a `level`.
 - Use `level: "error"` when an actual secret value appears (tokens, passwords, private keys, credentials, connection strings, or high-entropy values).
 - Use `level: "warning"` when only key names or variable names appear without values (e.g., `API_KEY`, `SECRET_KEY`, `PASSWORD`).
 - If no secrets are found, return an empty array.
 
-## Analysis Process
-1. Review the diff comprehensively
-2. Identify the primary type of change
-3. Determine appropriate scope from modified files/areas
-4. Craft a concise message covering main changes
-5. Assess backward compatibility impact
-6. Flag any suspected secrets
-
 ## Output Format
 Return valid JSON matching this structure:
 ```json
 {
   "type": "string",
-  "scope": "string|null", 
+  "scope": "string|null",
   "msg": "string",
   "is_breaking": "boolean",
   "secrets": [
@@ -69,10 +92,11 @@ Return valid JSON matching this structure:
 
 ## Examples
 ```json
-{"type": "feat", "scope": "auth", "msg": "add oauth2 login", "is_breaking": false, "secrets": []}
+{"type": "feat", "scope": "auth", "msg": "add oauth2 login support", "is_breaking": false, "secrets": []}
 {"type": "fix", "scope": "api", "msg": "handle null user responses", "is_breaking": false, "secrets": []}
-{"type": "refactor", "scope": null, "msg": "restructure project layout", "is_breaking": true, "secrets": []}
-{"type": "chore", "scope": "config", "msg": "update secrets storage", "is_breaking": false, "secrets": [{"file": "config/.env", "description": "detected value resembling api key", "level": "error"}]}
+{"type": "refactor", "scope": "api", "msg": "restructure endpoint handlers", "is_breaking": false, "secrets": []}
+{"type": "feat", "scope": "api", "msg": "add user deletion endpoint", "is_breaking": true, "secrets": []}
+{"type": "chore", "scope": "deps", "msg": "update dependencies", "is_breaking": false, "secrets": [{"file": "config/.env", "description": "detected value resembling api key", "level": "error"}]}
 ```
 
 Now analyze the provided diff and generate the commit message.