zencommit 0.1.3 → 0.1.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zencommit",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "module": "./src/index.ts",
   "type": "module",
   "private": false,

package/src/llm/prompt.ts

@@ -1,5 +1,8 @@
 import { normalizePrompt, renderTemplate } from './prompt-template.js';
-import { promptTemplates } from './prompt-templates.js';
+import baseTemplatePath from './prompts/base.md' with { type: 'file' };
+import conventionalTemplatePath from './prompts/conventional.md' with { type: 'file' };
+import gitmojiTemplatePath from './prompts/gitmoji.md' with { type: 'file' };
+import systemTemplatePath from './prompts/system.md' with { type: 'file' };
 
 export interface PromptInput {
   style: 'conventional' | 'freeform';
@@ -17,19 +20,23 @@ export interface PromptOutput {
 }
 
 const templateCache = new Map<string, string>();
+const templateFiles: Record<string, string> = {
+  base: baseTemplatePath,
+  conventional: conventionalTemplatePath,
+  gitmoji: gitmojiTemplatePath,
+  system: systemTemplatePath,
+};
 
 const loadTemplate = async (name: string): Promise<string> => {
   const cached = templateCache.get(name);
   if (cached) {
     return cached;
   }
-  const inline = promptTemplates[name as keyof typeof promptTemplates];
-  if (inline) {
-    templateCache.set(name, inline);
-    return inline;
+  const templatePath = templateFiles[name];
+  if (!templatePath) {
+    throw new Error(`Unknown prompt template: ${name}`);
   }
-  const url = new URL(`./prompts/${name}.md`, import.meta.url);
-  const text = await Bun.file(url).text();
+  const text = await Bun.file(templatePath).text();
   templateCache.set(name, text);
   return text;
 };

package/src/types/assets.d.ts

@@ -0,0 +1,4 @@
+declare module '*.md' {
+  const path: string;
+  export default path;
+}

package/src/llm/prompt-templates.ts

@@ -1,6 +0,0 @@
-export const promptTemplates = {
-  system: "You are an expert software engineer specializing in writing precise, informative git commit messages.\n\n## Your Role\n\nYou analyze code diffs and generate commit messages that accurately describe the changes made. Your messages help developers understand the history of a codebase at a glance.\n\n## Core Principles\n\n1. **Accuracy over brevity**: Never fabricate or assume changes not present in the diff.\n2. **Intent over implementation**: Focus on _why_ a change was made, not _how_ (the diff shows the how).\n3. **Atomic summaries**: Treat the commit as a single logical unit, even if it touches multiple files.\n4. **Professional tone**: Write in clear, technical English appropriate for a professional codebase.\n\n## Constraints\n\n- Never mention that you are an AI, language model, or assistant.\n- Never reference the prompt, instructions, or your reasoning process.\n- Never include apologies, caveats, or meta-commentary.\n- Never use phrases like \"This commit...\" or \"This change...\" - just describe what happens.\n- Never include timestamps, author information, or ticket numbers unless explicitly in the diff context.\n- Output only the requested JSON format with no surrounding text, markdown fences, or explanation.\n",
-  base: "## Commit Message Guidelines\n\n### Subject Line Requirements\n\n1. **Imperative mood**: Write as a command - \"add feature\" not \"added feature\" or \"adding feature\".\n2. **Present tense**: Describe what applying the commit does, not what you did.\n3. **No period**: Do not end the subject with a period or any punctuation.\n4. **Concise**: Stay within {{maxSubjectChars}} characters - be specific but brief.\n5. **Informative**: A reader should understand the change's purpose without viewing the diff.\n\n### Writing Style\n\n- **Be specific**: \"fix null pointer in user validation\" is better than \"fix bug\".\n- **Describe intent**: Focus on _why_ the change matters, not _what_ files changed.\n- **Avoid vague terms**: Don't use \"update\", \"change\", \"modify\" without context - specify what was updated and why.\n- **No file paths**: Don't list filenames - summarize the logical change instead.\n- **No code snippets**: Don't include code, function names, or variable names unless absolutely essential for understanding.\n\n### What NOT to Include\n\n- Implementation details (the diff shows this)\n- File names or paths (unless the change is specifically about renaming/moving)\n- Line numbers or code references\n- Ticket/issue numbers (these belong in the body or are added separately)\n- Timestamps or dates\n- Author information\n- Phrases like \"This commit...\" or \"Changes include...\"\n\n### Analyzing the Diff\n\nWhen reading the diff to write the commit message:\n\n1. **Identify the primary change**: What is the main purpose? Bug fix, new feature, refactor?\n2. **Look for patterns**: Are multiple files changed for the same reason?\n3. **Check for side effects**: Are there secondary changes (cleanup, formatting) alongside the main change?\n4. **Consider impact**: How does this change affect users, developers, or the system?\n\nIf changes span multiple concerns, focus on the most significant one in the subject and mention others in the body (if body is enabled).\n\n---\n\n{{#if conventionalGuidelines}}\n\n## Conventional Commits\n\n{{conventionalGuidelines}}\n\n---\n\n{{/if}}\n\n{{#if gitmojiGuidelines}}\n\n## Gitmoji\n\n{{gitmojiGuidelines}}\n\n---\n\n{{/if}}\n\n## Body Guidelines\n\n{{includeBodyGuideline}}\n\nWhen writing a body:\n\n- Separate from subject with a blank line\n- Explain the motivation for the change\n- Contrast with previous behavior if relevant\n- Use bullet points for multiple related changes\n- Keep each line reasonably short (aim for ~72 characters)\n- Focus on \"why\" rather than \"what\" (the diff shows what)\n\n---\n\n## Input Context\n\n### Files Changed\n\nThe following files were modified in this commit:\n\n{{fileListBlock}}\n\n### Diff Content\n\n{{diffBlock}}\n\n---\n\n## Output Requirements\n\nGenerate a JSON object with exactly two keys:\n\n```json\n{\n  \"subject\": \"<the commit subject line>\",\n  \"body\": \"<the commit body, or empty string if no body>\"\n}\n```\n\n### Validation Checklist\n\nBefore outputting, verify:\n\n- [ ] Subject is {{maxSubjectChars}} characters or fewer\n- [ ] Subject uses imperative mood (\"add\" not \"added\")\n- [ ] Subject has no trailing period\n- [ ] Subject describes the actual changes in the diff (no fabrication)\n- [ ] Body is empty string if body is disabled, or meaningful content if enabled\n- [ ] Output is valid JSON with no extra text, markdown, or formatting\n- [ ] Language is {{language}}\n\n### Critical Rules\n\n1. **Output ONLY the JSON object** - no markdown code fences, no explanations, no preamble.\n2. **Never fabricate changes** - only describe what's actually in the diff.\n3. **Never exceed the character limit** - truncate intelligently if needed, don't just cut off.\n4. **Use the exact JSON format** - both keys must be present, body must be empty string (not null) when unused.\n",
-  conventional: "Follow the Conventional Commits specification (v1.0.0) precisely.\n\n### Format\n\n```\n<type>[optional scope][!]: <description>\n\n[optional body]\n\n[optional footer(s)]\n```\n\nFor this tool, output only the subject line in \"subject\" and the body (if requested) in \"body\".\n\n### Structure Rules\n\n1. **Type** (required): A noun describing the category of change. Must be lowercase.\n2. **Scope** (optional): A noun in parentheses describing the section of the codebase (e.g., `feat(parser):`).\n3. **Breaking change indicator** (optional): A `!` immediately before the `:` signals a breaking change.\n4. **Description** (required): A short summary immediately after the colon and space.\n5. **Body** (optional): Free-form text providing additional context, separated from subject by a blank line.\n\n### Allowed Types\n\nChoose the single most appropriate type based on the primary purpose of the change:\n\n| Type       | Description                                                               |\n| ---------- | ------------------------------------------------------------------------- |\n| `feat`     | A new feature visible to users or a significant capability addition       |\n| `fix`      | A bug fix that corrects incorrect behavior                                |\n| `docs`     | Documentation-only changes (README, comments, JSDoc, etc.)                |\n| `style`    | Code style/formatting changes that do not affect logic (whitespace, etc.) |\n| `refactor` | Code restructuring that neither fixes a bug nor adds a feature            |\n| `perf`     | Performance improvements without functional changes                       |\n| `test`     | Adding, updating, or fixing tests (no production code changes)            |\n| `build`    | Changes to build system, dependencies, or tooling (npm, webpack, etc.)    |\n| `ci`       | Changes to CI/CD configuration (GitHub Actions, Jenkins, etc.)            |\n| `chore`    | Maintenance tasks that don't fit other categories (deps update, cleanup)  |\n| `revert`   | Reverts a previous commit (reference the reverted commit in body)         |\n\n### Type Selection Guidelines\n\n- **feat vs refactor**: If the change adds new behavior users can observe, it's `feat`. If it restructures existing code without changing behavior, it's `refactor`.\n- **fix vs refactor**: If the code was broken and now works correctly, it's `fix`. If the code worked before and still works the same way, it's `refactor`.\n- **chore vs build**: Build system changes (webpack config, tsconfig) use `build`. Generic maintenance (updating .gitignore, cleaning up old files) uses `chore`.\n- **docs vs style**: Changes to documentation/comments use `docs`. Formatting changes to code itself use `style`.\n\n### Scope Guidelines\n\n- Use lowercase, kebab-case for scopes (e.g., `feat(user-auth):`, `fix(api-client):`).\n- Scope should identify the module, component, or area affected.\n- Common scopes: `api`, `ui`, `cli`, `config`, `core`, `deps`, `auth`, `db`, module names, component names.\n- Omit scope if the change is broad or the scope is obvious from context.\n- Be consistent with scopes used in the repository's existing commit history.\n\n### Description Rules\n\n1. Use imperative, present-tense verbs: \"add\", \"fix\", \"update\", \"remove\", \"refactor\" (not \"added\", \"fixes\", \"updating\").\n2. Start with a lowercase letter (unless it's a proper noun or acronym).\n3. Do not end with a period.\n4. Be specific but concise - aim for clarity in under 50 characters when possible (hard limit is the configured max).\n5. Describe _what_ the commit does when applied, not what you did.\n\n### Breaking Changes\n\nIf the commit introduces a breaking change (incompatible API change, removed feature, etc.):\n\n- Add `!` before the colon: `feat(api)!: remove deprecated endpoints`\n- Optionally explain in the body with `BREAKING CHANGE: <explanation>`\n\n### Examples\n\n**Simple feature:**\n\n```\nfeat(auth): add OAuth2 login support\n```\n\n**Bug fix with scope:**\n\n```\nfix(parser): handle empty input without throwing\n```\n\n**Refactor without scope:**\n\n```\nrefactor: extract validation logic into separate module\n```\n\n**Breaking change:**\n\n```\nfeat(api)!: change response format to JSON:API spec\n```\n\n**Documentation:**\n\n```\ndocs: update installation instructions for Windows\n```\n\n**Build/dependencies:**\n\n```\nbuild(deps): upgrade TypeScript to v5.3\n```\n\n**Chore:**\n\n```\nchore: remove unused development scripts\n```\n\n**With body (when body is enabled):**\n\n```\nfix(cache): prevent stale data on concurrent requests\n\nRace condition occurred when multiple requests invalidated\nthe cache simultaneously. Added mutex lock to ensure\natomic read-modify-write operations.\n```\n",
-  gitmoji: "Prefix the commit subject with exactly one gitmoji (Unicode emoji character) followed by a space.\n\n### Format\n\nWhen combined with conventional commits style:\n\n```\n<emoji> type(scope?): description\n```\n\nWhen used with freeform style:\n\n```\n<emoji> description\n```\n\n### Rules\n\n1. Use exactly ONE emoji per commit - choose the one that best represents the primary change.\n2. Use the actual Unicode emoji character, not the `:shortcode:` format.\n3. Place the emoji at the very beginning of the subject line.\n4. Add a single space between the emoji and the rest of the subject.\n5. If the change spans multiple categories, choose the emoji for the most significant aspect.\n\n### Gitmoji Reference\n\nSelect the most appropriate emoji from this reference:\n\n#### Features & Enhancements\n\n| Emoji | Code                     | Use When                                                                         |\n| ----- | ------------------------ | -------------------------------------------------------------------------------- |\n| ✨    | `:sparkles:`             | Introducing a new feature                                                        |\n| 💄    | `:lipstick:`             | Adding or updating UI/style files                                                |\n| 🎨    | `:art:`                  | Improving code structure/format (not style type - this is for code organization) |\n| 🚸    | `:children_crossing:`    | Improving user experience/usability                                              |\n| 💫    | `:dizzy:`                | Adding or updating animations/transitions                                        |\n| 🥅    | `:goal_net:`             | Catching errors                                                                  |\n| 🔍️    | `:mag:`                  | Improving SEO                                                                    |\n| 🌐    | `:globe_with_meridians:` | Internationalization and localization                                            |\n| ♿️    | `:wheelchair:`           | Improving accessibility                                                          |\n| 💬    | `:speech_balloon:`       | Adding or updating text/literals                                                 |\n| 🏷️    | `:label:`                | Adding or updating types (TypeScript, Flow)                                      |\n\n#### Bug Fixes\n\n| Emoji | Code                 | Use When                            |\n| ----- | -------------------- | ----------------------------------- |\n| 🐛    | `:bug:`              | Fixing a bug                        |\n| 🚑️    | `:ambulance:`        | Critical hotfix                     |\n| 🩹    | `:adhesive_bandage:` | Simple fix for a non-critical issue |\n| 🔒️    | `:lock:`             | Fixing security issues              |\n| 🍎    | `:apple:`            | Fixing something on macOS           |\n| 🐧    | `:penguin:`          | Fixing something on Linux           |\n| 🏁    | `:checkered_flag:`   | Fixing something on Windows         |\n| 🤖    | `:robot:`            | Fixing something on Android         |\n| 🍏    | `:green_apple:`      | Fixing something on iOS             |\n\n#### Performance & Optimization\n\n| Emoji | Code            | Use When                            |\n| ----- | --------------- | ----------------------------------- |\n| ⚡️    | `:zap:`         | Improving performance               |\n| 🔥    | `:fire:`        | Removing code or files              |\n| 🗑️    | `:wastebasket:` | Deprecating code that needs cleanup |\n\n#### Documentation\n\n| Emoji | Code               | Use When                                   |\n| ----- | ------------------ | ------------------------------------------ |\n| 📝    | `:memo:`           | Adding or updating documentation           |\n| 💡    | `:bulb:`           | Adding or updating comments in source code |\n| 📄    | `:page_facing_up:` | Adding or updating license                 |\n\n#### Testing\n\n| Emoji | Code                 | Use When                           |\n| ----- | -------------------- | ---------------------------------- |\n| ✅    | `:white_check_mark:` | Adding, updating, or passing tests |\n| 🧪    | `:test_tube:`        | Adding a failing test              |\n| 🤡    | `:clown_face:`       | Mocking things                     |\n| 📸    | `:camera_flash:`     | Adding or updating snapshots       |\n\n#### Dependencies & Build\n\n| Emoji | Code                    | Use When                                      |\n| ----- | ----------------------- | --------------------------------------------- |\n| ⬆️    | `:arrow_up:`            | Upgrading dependencies                        |\n| ⬇️    | `:arrow_down:`          | Downgrading dependencies                      |\n| 📌    | `:pushpin:`             | Pinning dependencies to specific versions     |\n| ➕    | `:heavy_plus_sign:`     | Adding a dependency                           |\n| ➖    | `:heavy_minus_sign:`    | Removing a dependency                         |\n| 📦️    | `:package:`             | Adding or updating compiled files or packages |\n| 👷    | `:construction_worker:` | Adding or updating CI build system            |\n| 💚    | `:green_heart:`         | Fixing CI build                               |\n| 🔧    | `:wrench:`              | Adding or updating configuration files        |\n| 🔨    | `:hammer:`              | Adding or updating development scripts        |\n\n#### Code Quality & Refactoring\n\n| Emoji | Code             | Use When                                            |\n| ----- | ---------------- | --------------------------------------------------- |\n| ♻️    | `:recycle:`      | Refactoring code                                    |\n| 🚚    | `:truck:`        | Moving or renaming resources (files, paths, routes) |\n| ✏️    | `:pencil2:`      | Fixing typos                                        |\n| 🩺    | `:stethoscope:`  | Adding or updating health checks                    |\n| 🧱    | `:bricks:`       | Infrastructure-related changes                      |\n| 🧑‍💻    | `:technologist:` | Improving developer experience                      |\n| 💩    | `:poop:`         | Writing bad code that needs improvement             |\n| 🍱    | `:bento:`        | Adding or updating assets                           |\n\n#### Version Control & Releases\n\n| Emoji | Code                          | Use When                             |\n| ----- | ----------------------------- | ------------------------------------ |\n| 🎉    | `:tada:`                      | Beginning a project (initial commit) |\n| 🔖    | `:bookmark:`                  | Releasing/version tags               |\n| 🚀    | `:rocket:`                    | Deploying stuff                      |\n| ⏪️    | `:rewind:`                    | Reverting changes                    |\n| 🔀    | `:twisted_rightwards_arrows:` | Merging branches                     |\n\n#### Database & Data\n\n| Emoji | Code              | Use When                            |\n| ----- | ----------------- | ----------------------------------- |\n| 🗃️    | `:card_file_box:` | Performing database-related changes |\n| 🌱    | `:seedling:`      | Adding or updating seed files       |\n\n#### Security & Secrets\n\n| Emoji | Code                     | Use When                             |\n| ----- | ------------------------ | ------------------------------------ |\n| 🔐    | `:closed_lock_with_key:` | Adding or updating secrets           |\n| 🛂    | `:passport_control:`     | Working on authorization/permissions |\n\n#### Work In Progress\n\n| Emoji | Code             | Use When                      |\n| ----- | ---------------- | ----------------------------- |\n| 🚧    | `:construction:` | Work in progress              |\n| 🙈    | `:see_no_evil:`  | Adding or updating .gitignore |\n\n#### Other\n\n| Emoji | Code            | Use When                                      |\n| ----- | --------------- | --------------------------------------------- |\n| 🍻    | `:beers:`       | Writing code drunkenly                        |\n| 🥚    | `:egg:`         | Adding or updating easter eggs                |\n| 🧵    | `:thread:`      | Adding or updating multithreading/concurrency |\n| 🦺    | `:safety_vest:` | Adding or updating validation                 |\n\n### Common Mappings to Conventional Commit Types\n\nWhen using both gitmoji and conventional commits, prefer these pairings:\n\n| Type       | Primary Emoji | Alternatives |\n| ---------- | ------------- | ------------ |\n| `feat`     | ✨            | 🚸 💄 🌐 ♿️  |\n| `fix`      | 🐛            | 🚑️ 🩹 🔒️     |\n| `docs`     | 📝            | 💡           |\n| `style`    | 🎨            |              |\n| `refactor` | ♻️            | 🚚 ✏️        |\n| `perf`     | ⚡️            |              |\n| `test`     | ✅            | 🧪           |\n| `build`    | 📦️            | 🔧 🔨        |\n| `ci`       | 👷            | 💚           |\n| `chore`    | 🔧            | 🙈           |\n| `revert`   | ⏪️            |              |\n\n### Examples\n\n**Feature (conventional):**\n\n```\n✨ feat(auth): add two-factor authentication\n```\n\n**Bug fix (conventional):**\n\n```\n🐛 fix(parser): handle null values in JSON input\n```\n\n**Documentation (freeform):**\n\n```\n📝 update API documentation with new endpoints\n```\n\n**Performance (conventional):**\n\n```\n⚡️ perf(db): add index for frequent queries\n```\n\n**Dependencies (conventional):**\n\n```\n⬆️ build(deps): upgrade React to v18.2\n```\n\n**Critical hotfix (conventional):**\n\n```\n🚑️ fix(auth): patch token validation vulnerability\n```\n\n**Refactor (freeform):**\n\n```\n♻️ extract common utilities into shared module\n```\n",
-} as const;