microsoft/hve-core

---
agent: 'agent'
description: 'Stages all changes, generates a conventional commit message, shows it to the user, and commits using only git add/commit'
maturity: stable
---

# Stage, Generate, and Commit

Must follow all instructions provided by #file:../instructions/commit-message.instructions.md

Protocol:

1. **Pre-staging safety check**: Before staging, verify the repository has a `.gitignore` file. If `.gitignore` is missing or empty:
   * Warn the user: "⚠️ No .gitignore detected. Using `git add -A` may stage sensitive files (.env, node_modules/, build/, etc.)."
   * Offer two options: (a) proceed with `git add -u` (tracked files only, safer), or (b) proceed with `git add -A` if user explicitly confirms.
   * Default to `git add -u` if user does not respond.
2. Stage changes using the confirmed command (`git add -A` or `git add -u`).
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).
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.
5. Immediately commit the staged changes (without showing the message yet) using ONLY allowed git commands:

   * Pipe the exact commit message (including body + footer emoji line) via STDIN: `echo "<full message>" | git commit -F -`.
   * Preserve newlines exactly; ensure the footer emoji line is the final line (file ends with a newline).
   * DO NOT run any other git commands (no push, pull, fetch, diff, show, status, log, branch, switch, merge, rebase, tag, etc.).

6. After the commit succeeds, display to the user a success line followed by the full commit message in a fenced `markdown` code block.
7. If the commit fails, output a concise error summary and STOP (do not retry).

Rules & Constraints:

* 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.
* Never attempt to obtain diffs via git CLI; rely solely on `get_changed_files` tool output.
* If there are NO staged changes after staging, output a short notice and STOP (do not create an empty commit).
* Commit message MUST:
  * Use an allowed type and optional allowed scope.
  * Be present tense.
  * Keep description under 4 specific change points (comma-separated concise phrases).
  * Include an optional body ONLY for large, wide-reaching changes (list bullet points starting each line with `-`) preceded by a blank line.
  * Include a footer line starting with a blank line, containing an emoji, a space, `- Generated by Copilot`.
* Never wait for confirmation for any step in the Protocol.

Output Format:

* When proceeding (changes present):
  * Perform the commit first.
  * After success, print a single confirmation line: `Commit created successfully with the following message:`
  * Then a blank line.
  * Then the commit message inside a fenced ```markdown code block.
* For no-change scenario, skip code block and print: `No changes to commit.`

Example for a large change (structure illustration after committing):
<!-- <example-commit-and-commit-action-large> -->
Commit created successfully with the following message:

```markdown
feat: add repo-wide instruction files including prompts and agents

* add commit message, markdown, C# along with C# test instructions
* introduce task planner and researcher, prompt builder, and adr creation agents
* configure markdownlint and VS Code workspace settings
* add ADO work items prompts for getting and preparing my work items
* add .gitignore and cleanup README newlines

🧭 - Generated by Copilot
```

Commit display complete.
<!-- </example-commit-and-commit-action-large> -->

Example for a medium/small change (after committing):
<!-- <example-commit-and-commit-action> -->
Commit created successfully with the following message:

```markdown
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

🔒 - Generated by Copilot
```

Commit display complete.
<!-- </example-commit-and-commit-action> -->

Error Handling:

* If `git commit` fails (e.g., hooks reject), report a concise error summary with suggested fix and STOP without retries.

## Post-Commit Adjustments (Optional)

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.

Flow:

1. Verify last action created exactly one new commit in this session (assume true since we just committed; do not run git history commands).
2. Run `git reset --soft HEAD^` to uncommit while preserving index and working tree.
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.
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).
5. Regenerate the updated commit message (replace, do not append diffs unless justified) and re-commit using: `echo "<updated message>" | git commit -F -`.
6. Display a confirmation line: `Commit message updated successfully:` then a blank line, then the updated commit message in a fenced ```markdown code block.

Constraints:

* 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).
* Never use any other git commands (no amend, no rebase, no reflog). Use soft reset + fresh commit only.
* Preserve original staged content; never modify file contents in this flow—only the message.
* Re-validate description limits and footer formatting; fix user-proposed changes if they violate standards, silently correcting to compliant form.

User Request Interpretation:

* If user supplies only a new description: keep original type/scope and replace description.
* If user supplies a new type/scope: validate against allowed list; otherwise keep original.
* If user requests adding bullets/body: ensure a blank line before bullets and each bullet starts with `-`.
* Always ensure exactly one footer line with emoji + `- Generated by Copilot` remains last.

Error Handling (Adjustment Flow):

* If `git reset --soft HEAD^` fails: report concise error and STOP.
* If re-commit fails: report concise error and STOP.

Example Adjustment:
User: "Can you change the description to clarify it's adding instruction files?"
Action: soft reset, update description portion, re-commit, display updated message per formatting.

Example Undo Without New Message:
User: "Undo that commit" (no further message guidance)
Action: soft reset only; leave all changes staged; output undo confirmation line; no commit message block shown.

---

Proceed now following the protocol.