Agentkernel commit task

Commit an AgentKernel Task

Create exactly one local commit for one completed logical task. Treat a successful commit as part of the task's definition of done.

Workflow

1. Inspect repository state.

   • Run git status --short, git branch --show-current, and relevant unstaged diffs.
   • Treat all pre-existing changes as user-owned unless they were created for the current task.
   • Detect merge conflicts before staging.
   • If there are no repository changes for the task, do not create an empty commit.

2. Establish the commit scope.

   • Include only files required by the completed task.
   • Keep unrelated modified or untracked files untouched.
   • Split multiple already-completed logical tasks into separate commits when their changes can be isolated safely.
   • If safe isolation is impossible, stop and report the overlapping files instead of staging them speculatively.

3. Choose the commit message.

   • For a task with an AgentKernel task ID, use <type>(AK-ID): <imperative summary>.
   • Otherwise use <type>(<scope>): <imperative summary> when a useful scope exists.
   • Use feat, fix, refactor, test, docs, or chore according to the actual diff.
   • Keep the subject concise and describe the result, not the process.

   Examples:

   feat(AK-M0-05): add typed tool registry
   fix(AK-RPL-11): reject replay hash divergence
   docs(tasks): add phased implementation backlog
   chore(skills): add atomic task commit workflow
   

4. Run proportionate validation before staging.

   • Prefer commands defined by pyproject.toml, project scripts, CI, or the affected package.
   • For Python code, run the relevant formatter check, linter, type check, and tests when configured.
   • For Replay changes, run affected unit tests and Golden Trace replay tests.
   • For Markdown-only changes, run git diff --check and verify local Markdown links when practical.
   • For Skill changes, run the Skill Creator quick_validate.py validator on the Skill directory.
   • If a required check fails, fix the in-scope issue and rerun it. Do not commit known failing work as completed.

5. Stage explicit paths.

   • Use git add -- <path>... with the exact task files.
   • Do not use git add -A, git add ., or broad pathspecs in a mixed worktree.
   • Inspect git diff --cached --stat and git diff --cached after staging.

6. Perform final safety checks.

   • Run git diff --cached --check.
   • Search the staged diff for conflict markers and likely credentials.
   • Confirm the staged diff contains no unrelated formatting, generated artifacts, local traces, caches, secrets, or machine-specific paths.
   • Unstage an incorrect path without discarding its working-tree changes.

7. Commit and verify.

   • Run git commit -m "<message>".
   • If a hook fails, correct the in-scope problem, restage explicit files, rerun validation, and retry.
   • Verify with git show --stat --oneline --summary HEAD and git status --short.
   • Report the commit hash, subject, validation performed, and any remaining unrelated changes.

Safety Rules

• Never stage or commit unrelated user changes.
• Never create an empty commit to satisfy the workflow mechanically.
• Never bypass hooks or validation with --no-verify unless the user explicitly requests it and understands the failure.
• Never amend, rebase, reset, or rewrite existing history unless explicitly requested.
• Never push, create a branch, or open a pull request unless explicitly requested.
• Never commit credentials, .env files, private traces, caches, or generated build output.
• Do not claim the task is complete until the commit succeeds, unless Git itself is blocked; in that case report the exact blocker.