Dev Git Guard

Enforce a git-first workflow for repository coding tasks. Use when Codex is working inside a local git repository to inspect, modify, debug, refactor, implem...

Security Scan

The skill's requirements and instructions are coherent with its stated purpose: it inspects and manipulates a local git worktree and recommends/creates commits (in Chinese); there are no unrelated credentials, installs, or hidden endpoints.

Purpose & Capability

Name/description (git-first workflow, guarding dirty worktrees and commits) match the instructions: the SKILL.md only references git commands, repository files, and repository-local validation steps. No unrelated binaries, env vars, or external services are requested.

Instruction Scope

Instructions explicitly tell the agent to run git commands, inspect diffs, read repository files, and run repo-provided tests/lint/build commands. That is appropriate for a git-guard skill, but note that running tests/builds executes code from the repository (which could be malicious or destructive); the skill advises avoiding destructive git commands unless requested.

Install Mechanism

Instruction-only skill with no install spec and no code files to execute at install time — minimal installation risk.

Credentials

No environment variables, credentials, or external config paths are requested. The skill's actions are limited to the local repository context, which is proportionate to its purpose.

Persistence & Privilege

The skill is user-invocable and allow_implicit_invocation is true in the agent manifest (normal default). always:false (not force-included). Autonomous invocation is permitted but not unusual; users should be aware the skill can be invoked by the agent to read/modify the repo and create commits.

Assessment

This skill appears coherent and low-risk relative to its purpose, but consider the following before installing or letting an agent use it automatically: - The skill will read and modify files in your repository and create commits (it will write history). If you don't want automatic commits, require a review step or run the skill on a branch. - It instructs the agent to run tests, lint, build, and other repo-provided commands. Those commands execute code from the repo and can perform arbitrary actions on the host — run in a sandbox or CI environment if you have any suspicion about the repo's safety. - Commit messages will be written in Chinese by policy; ensure this matches your project's conventions. - The skill does not request external credentials or installs, which is good. Still review commits before pushing and consider making backups or requiring explicit user confirmation before any push or destructive git operation. If you want stronger safety: restrict autonomous invocation, require explicit approval before commits, or configure the agent to create commits only on a dedicated branch that you can inspect before merging.

Git Commit Guard

Treat every coding task as operating on a potentially valuable worktree.

Start Of Turn

1. Run git status --short --branch first.
2. If the repository is clean, continue to the requested work.
3. If the repository is dirty, stop new development first.
4. Inspect modified, deleted, and untracked files with git diff --stat, git diff, and targeted file reads.
5. Summarize what changed by file and by intent before editing anything else.
6. Infer the strongest reasonable validation from the repo itself. Prefer existing test, lint, type-check, compile, or build commands over ad hoc checks.
7. Use the narrowest command that gives real signal for the dirty changes, then broaden if the change is cross-cutting.
8. If validation fails, surface the blocker immediately. Fix it only when that is in scope and safe; otherwise do not create a normal commit.
9. If validation passes and the dirty changes are intentional, create a detailed Chinese git commit before starting the next implementation step.

Dirty Worktree Handling

When git status is not clean, do all of the following before new development:

• Review whether the changes look coherent, risky, incomplete, or broken.
• Inspect tests related to the changed files when feasible.
• Call out uncertainty if unrelated edits may have been mixed together.
• Preserve the user's existing work. Do not discard, overwrite, or silently clean up unrelated changes.

During Work

1. Keep unrelated changes in separate commits whenever practical.
2. Do not mix pre-existing dirty changes with new feature work without reviewing both scopes.
3. Before starting a new logical phase that depends on a clean base, commit the validated current state.
4. Avoid destructive git commands unless the user explicitly asks for them.

Verification Standard

Before committing existing dirty changes, prefer this order:

1. Targeted tests for touched modules or packages
2. Fast lint, type-check, or compile commands relevant to touched files
3. Broader project test commands if the repository is small or the change is cross-cutting

Before the final commit, run a broader validation pass whenever practical:

• Full or broader unit test coverage
• Lint
• Type check
• Build or compile
• Targeted smoke test for the implemented flow

If the full sweep is not feasible, state exactly what was run and what was not run.

End Of Turn

1. Re-read the final diff before the last commit.
2. If files changed during the turn, run the strongest reasonable final validation.
3. If the requested development is finished, or the conversation is likely ending, prefer comprehensive validation over a narrow spot check.
4. If validation passes, stage the final diff and create a detailed Chinese git commit before sending the final response.
5. If no files changed, do not create an empty commit.
6. Confirm git status is clean after the final commit.
7. If the repository is not a git repo, say that this skill is not applicable.

Commit Policy

1. Write every commit message in Chinese.
2. Use a concise subject line plus a detailed body.
3. Explain what changed, why it changed, implementation details, verification status, and any known limitation or follow-up.
4. If a commit preserves user changes before new work begins, say that explicitly so the history remains auditable.
5. When drafting the message, read references/commit-template.md for the preferred structure and examples.

Recommended type values:

• feat
• fix
• refactor
• test
• docs
• chore

Response Behavior

1. Mention early when the worktree is dirty and what you are reviewing.
2. Tell the user what you verified before each commit.
3. Surface failures immediately with the likely cause.
4. After each commit, report the commit purpose clearly in Chinese.
5. In the final response, include the validation that ran, the commit hash or hashes created during the turn, and any residual risk.