microsoft/hve-core
Publicmirrored fromhttps://github.com/microsoft/hve-coreAvailable
.github/prompts/git-commit.prompt.md
129lines · modecode
| 1 | --- |
| 2 | agent: 'agent' |
| 3 | description: 'Stages all changes, generates a conventional commit message, shows it to the user, and commits using only git add/commit' |
| 4 | maturity: stable |
| 5 | --- |
| 6 | |
| 7 | # Stage, Generate, and Commit |
| 8 | |
| 9 | Must follow all instructions provided by #file:../instructions/commit-message.instructions.md |
| 10 | |
| 11 | Protocol: |
| 12 | |
| 13 | 1. **Pre-staging safety check**: Before staging, verify the repository has a `.gitignore` file. If `.gitignore` is missing or empty: |
| 14 | * Warn the user: "⚠️ No .gitignore detected. Using `git add -A` may stage sensitive files (.env, node_modules/, build/, etc.)." |
| 15 | * Offer two options: (a) proceed with `git add -u` (tracked files only, safer), or (b) proceed with `git add -A` if user explicitly confirms. |
| 16 | * Default to `git add -u` if user does not respond. |
| 17 | 2. Stage changes using the confirmed command (`git add -A` or `git add -u`). |
| 18 | 3. Use the `get_changed_files` tool and always specify "staged" for the sourceControlState to retrieve the now-staged changes, and "repositoryPath" with the full project path (DO NOT use git diff / show / status / log / fetch / pull / push). |
| 19 | 4. Analyze the staged changes and produce a clean Conventional Commit message (per the commit message instructions file referenced above). This message is authoritative once generated. |
| 20 | 5. Immediately commit the staged changes (without showing the message yet) using ONLY allowed git commands: |
| 21 | |
| 22 | * Pipe the exact commit message (including body + footer emoji line) via STDIN: `echo "<full message>" | git commit -F -`. |
| 23 | * Preserve newlines exactly; ensure the footer emoji line is the final line (file ends with a newline). |
| 24 | * DO NOT run any other git commands (no push, pull, fetch, diff, show, status, log, branch, switch, merge, rebase, tag, etc.). |
| 25 | |
| 26 | 6. After the commit succeeds, display to the user a success line followed by the full commit message in a fenced `markdown` code block. |
| 27 | 7. If the commit fails, output a concise error summary and STOP (do not retry). |
| 28 | |
| 29 | Rules & Constraints: |
| 30 | |
| 31 | * Allowed git commands: `git add -A` or `git add -u` (based on safety check), `git commit -F -` (stdin) or `git commit -m` variants if single-line only (multi-line must use `-F -`), and conditionally `git reset --soft HEAD^` ONLY when performing an immediate post-commit message revision explicitly requested by the user right after showing the commit. |
| 32 | * Never attempt to obtain diffs via git CLI; rely solely on `get_changed_files` tool output. |
| 33 | * If there are NO staged changes after staging, output a short notice and STOP (do not create an empty commit). |
| 34 | * Commit message MUST: |
| 35 | * Use an allowed type and optional allowed scope. |
| 36 | * Be present tense. |
| 37 | * Keep description under 4 specific change points (comma-separated concise phrases). |
| 38 | * Include an optional body ONLY for large, wide-reaching changes (list bullet points starting each line with `-`) preceded by a blank line. |
| 39 | * Include a footer line starting with a blank line, containing an emoji, a space, `- Generated by Copilot`. |
| 40 | * Never wait for confirmation for any step in the Protocol. |
| 41 | |
| 42 | Output Format: |
| 43 | |
| 44 | * When proceeding (changes present): |
| 45 | * Perform the commit first. |
| 46 | * After success, print a single confirmation line: `Commit created successfully with the following message:` |
| 47 | * Then a blank line. |
| 48 | * Then the commit message inside a fenced ```markdown code block. |
| 49 | * For no-change scenario, skip code block and print: `No changes to commit.` |
| 50 | |
| 51 | Example for a large change (structure illustration after committing): |
| 52 | <!-- <example-commit-and-commit-action-large> --> |
| 53 | Commit created successfully with the following message: |
| 54 | |
| 55 | ```markdown |
| 56 | feat: add repo-wide instruction files including prompts and agents |
| 57 | |
| 58 | * add commit message, markdown, C# along with C# test instructions |
| 59 | * introduce task planner and researcher, prompt builder, and adr creation agents |
| 60 | * configure markdownlint and VS Code workspace settings |
| 61 | * add ADO work items prompts for getting and preparing my work items |
| 62 | * add .gitignore and cleanup README newlines |
| 63 | |
| 64 | 🧭 - Generated by Copilot |
| 65 | ``` |
| 66 | |
| 67 | Commit display complete. |
| 68 | <!-- </example-commit-and-commit-action-large> --> |
| 69 | |
| 70 | Example for a medium/small change (after committing): |
| 71 | <!-- <example-commit-and-commit-action> --> |
| 72 | Commit created successfully with the following message: |
| 73 | |
| 74 | ```markdown |
| 75 | feat(prompts): update summarize-my-work-items.prompt.md to clarify json output, correct get-my-work-items.prompt.md to fallback to wit_my_work_items |
| 76 | |
| 77 | 🔒 - Generated by Copilot |
| 78 | ``` |
| 79 | |
| 80 | Commit display complete. |
| 81 | <!-- </example-commit-and-commit-action> --> |
| 82 | |
| 83 | Error Handling: |
| 84 | |
| 85 | * If `git commit` fails (e.g., hooks reject), report a concise error summary with suggested fix and STOP without retries. |
| 86 | |
| 87 | ## Post-Commit Adjustments (Optional) |
| 88 | |
| 89 | Trigger: Only initiate this flow if, immediately after displaying the commit, the user explicitly asks to (a) modify the commit message, or (b) undo the just-created commit without providing a replacement message. If no such explicit request occurs, do nothing further. |
| 90 | |
| 91 | Flow: |
| 92 | |
| 93 | 1. Verify last action created exactly one new commit in this session (assume true since we just committed; do not run git history commands). |
| 94 | 2. Run `git reset --soft HEAD^` to uncommit while preserving index and working tree. |
| 95 | 3. If user only wants to undo (no new message requested): STOP after reset and output: `Commit undone (changes staged, no new commit message requested).` Do not auto-create a new commit. |
| 96 | 4. If user wants a new/modified message: Re-interpret the user's requested edits to the prior message; merge them into the authoritative previous commit message while enforcing all Conventional Commit rules (type, optional scope, description length, bullet list formatting, footer emoji line). |
| 97 | 5. Regenerate the updated commit message (replace, do not append diffs unless justified) and re-commit using: `echo "<updated message>" | git commit -F -`. |
| 98 | 6. Display a confirmation line: `Commit message updated successfully:` then a blank line, then the updated commit message in a fenced ```markdown code block. |
| 99 | |
| 100 | Constraints: |
| 101 | |
| 102 | * Use `git reset --soft HEAD^` strictly once per original commit; if user requests further tweaks again, repeat only if they just acknowledged the previous updated message (still limited to a single soft reset per actual commit creation cycle). |
| 103 | * Never use any other git commands (no amend, no rebase, no reflog). Use soft reset + fresh commit only. |
| 104 | * Preserve original staged content; never modify file contents in this flow—only the message. |
| 105 | * Re-validate description limits and footer formatting; fix user-proposed changes if they violate standards, silently correcting to compliant form. |
| 106 | |
| 107 | User Request Interpretation: |
| 108 | |
| 109 | * If user supplies only a new description: keep original type/scope and replace description. |
| 110 | * If user supplies a new type/scope: validate against allowed list; otherwise keep original. |
| 111 | * If user requests adding bullets/body: ensure a blank line before bullets and each bullet starts with `-`. |
| 112 | * Always ensure exactly one footer line with emoji + `- Generated by Copilot` remains last. |
| 113 | |
| 114 | Error Handling (Adjustment Flow): |
| 115 | |
| 116 | * If `git reset --soft HEAD^` fails: report concise error and STOP. |
| 117 | * If re-commit fails: report concise error and STOP. |
| 118 | |
| 119 | Example Adjustment: |
| 120 | User: "Can you change the description to clarify it's adding instruction files?" |
| 121 | Action: soft reset, update description portion, re-commit, display updated message per formatting. |
| 122 | |
| 123 | Example Undo Without New Message: |
| 124 | User: "Undo that commit" (no further message guidance) |
| 125 | Action: soft reset only; leave all changes staged; output undo confirmation line; no commit message block shown. |
| 126 | |
| 127 | --- |
| 128 | |
| 129 | Proceed now following the protocol. |
| 130 | |