# Commit Task Work

> Commit task-scoped work across personal_os task artifacts and any external codebases touched by the task. Use when the user asks to commit relevant files, save task work in git, commit personal_os context files, commit a task folder, or commit changes spanning personal_os plus another repo. Infer the active task and branches from context; stage only related paths; ask before committing an external repo when the branch or ownership is ambiguous.

- Skill: `ma08/commit-task-work` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ma08/commit-task-work`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ma08/commit-task-work/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: ma08 (https://skillmd.com/u/ma08)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ma08/commit-task-work

---


# Commit Task Work

Commit only the work that belongs to the current task, even when several repos have unrelated dirty state.

## Workflow

1. Resolve the task scope.
   - Prefer an explicit task folder, status file, tracker id, branch name, or paths from the conversation.
   - If unclear, run `get-task-details` or inspect recent task folders under `context/daily/`.
   - Treat the task folder in `personal_os` as the durable notes/artifacts scope.

2. Identify repos touched by the task.
   - Always check `personal_os` when task notes or artifacts were created there.
   - Check external codebases mentioned in the status file, task artifacts, current branch, recent commands, or user prompt.
   - Use `git -C <repo> status --short --branch` for each repo.

3. Classify each repo before staging.
   - `personal_os`: usually commit task folders and task-specific support files on `main`; do not stage unrelated dirty files elsewhere in the repo.
   - External code repo with a task-specific feature branch: commit task-related source/test/docs changes when the branch, upstream, and diff clearly match the task.
   - External code repo on `main`, detached HEAD, shared branch, or ambiguous branch: ask before committing.
   - Clean external repo: note that no commit is needed.

4. Stage explicitly.
   - Use pathspecs, not broad `git add .`, unless the repo is freshly created for this task and fully in scope.
   - Include untracked files only when they are clearly task artifacts or intentional source files.
   - Keep generated scratch logs/artifacts if they are part of the task record; exclude caches, local env files, build products, and secrets.

5. Review before committing.
   - Run `git diff --cached --stat`.
   - Run `git diff --cached --check`.
   - For sensitive repos or logs, scan staged content for obvious secret patterns such as API keys, tokens, `.env` contents, private keys, and credential dumps.
   - If the staged set includes unrelated changes, unstage the unrelated paths and recheck.

6. Commit with a direct message.
   - Use one commit per repo unless the user asks for a different structure.
   - Keep messages task-specific, for example `Add Marin PPL circuit task artifacts` or `Add commit task workflow skill`.
   - Do not push unless the user asks to push or the existing task workflow explicitly requires it.

7. Report the outcome.
   - List each repo, branch, commit hash, and what was committed.
   - Mention repos checked but left clean or skipped.
   - Call out any ambiguity that required skipping or asking.

## Safety Rules

- Never stage unrelated dirty work just because it is present.
- Never reset, checkout, clean, or otherwise discard changes unless the user explicitly asks.
- Do not commit external repos when branch ownership is unclear; ask first.
- Do not expose secret values in the response. If a staged secret is found, stop and report the file/path class, not the secret.
- GitHub comments, PR bodies, and issue updates need the configured agent byline; local git commits do not require that byline unless the user requests it.