Skip to content
Back to skills

Code Commit

ASecurity

Must be invoked when the user asks to commit code, submit code, or any similar request.

  • 1,709 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added May 26, 2026
developmentgobashnoderefactoringgitapiperformancedocumentation

Works with

  • vscode
  • api

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add openkursar/hello-halo --skill code-commit --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Code Commit?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Code Commit
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/openkursar-code-commit/badge)](https://www.skillsdirectory.com/skills/openkursar-code-commit)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: code-commit
description: Must be invoked when the user asks to commit code, submit code, or any similar request.
---

# Code Commit Skill

## Commit Workflow

### 1. Review Changes

Run `git status` and `git diff` in the repository to understand all current changes.

### 2. Pre-commit Checks

Review all changed files. **If any issues are found, report them to the user and wait for confirmation before committing.**

#### 2.1 Temporary Code Detection

Use your judgment to identify code that looks temporary or was clearly left in by accident -- things like `debugger` statements, placeholder values (`test123`, `asdf`, `foo`), commented-out code blocks, or anything that reads like a quick hack not meant for production. Don't be overly rigid; focus on what obviously doesn't belong.

#### 2.2 Temporary File Detection

Check whether any files that should not be committed are included in the changes:

- OS files: `.DS_Store`, `Thumbs.db`, etc.
- Temp files: `*.log`, `*.tmp`, `*.bak`, `*.swp`, etc.
- IDE configs: non-shared files under `.idea/`, `.vscode/`, etc.
- Build artifacts: `node_modules/`, `dist/`, `build/`, etc.
- Sensitive files: `.env`, `credentials.json`, private keys, etc.

#### 2.3 Internationalization & Open-source Readiness

Ensure the code is suitable for an internationalized, open-source project:

- **No hardcoded Chinese strings** in user-facing text (UI labels, prompts, error messages). These should go through the project's i18n mechanism.
- **Comments in English** to align with open-source conventions.
- **No pinyin naming** for variables, functions, or identifiers. Use meaningful English names.
- **No internal/private information** such as internal IP addresses, intranet domains, personal emails, phone numbers, API keys, or secrets.
- **No specific company or brand names** in code, comments, or commit messages — this includes but is not limited to Microsoft, Google, Tencent, Alibaba, Apple, Meta, Amazon, Baidu, ByteDance, etc. Use generic terms instead (e.g., "cloud provider", "search engine", "platform").

### 3. Generate Commit Message

Format:

```
<type>: #AI commit# <concise description>. collaboration and commit by halo
```

**Supported types:**

| type     | usage                                      |
|----------|--------------------------------------------|
| feat     | New feature                                |
| fix      | Bug fix                                    |
| docs     | Documentation changes                      |
| style    | Code formatting (no logic changes)         |
| refactor | Refactoring (no new features or bug fixes) |
| perf     | Performance improvement                    |
| test     | Test-related changes                       |
| chore    | Build, tooling, dependency updates, etc.   |

**Examples:**

```bash
git commit -m "feat: #AI commit# add user authentication module. collaboration and commit by halo"
git commit -m "fix: #AI commit# resolve memory leak in event listener. collaboration and commit by halo"
```

### 4. Execute Commit

```bash
git add <relevant files>
git commit -m "<generated commit message>"
```

- Only stage files that pass the checks. Do not blindly `git add .`.
- Run `git status` after committing to verify.

## Notes

- If there are no changes, inform the user that there is nothing to commit.
- Do not run `git push` unless the user explicitly asks.
- When issues are found during checks, list all of them and ask the user how to proceed. Do not skip issues on your own.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…