commit

分类: 测试与安全 | 上传者: Women-Coding-Community | 下载: 0 | 版本: v1.0（最新）

安全地提交更改。检查暂存/修改的文件中的敏感数据，写入带有正文的提交消息。从不添加合著者行。

更新日志: Source: GitHub https://github.com/Women-Coding-Community/wcc-backend

目录结构

当前层级: tree/main/.claude/skills/commit/

📄 SKILL.md 4.4 KB

SKILL.md

---
name: commit
description: Safely commit changes. Reviews staged/modified files for sensitive data, writes a commit message with body. Never adds co-author lines.
disable-model-invocation: true
allowed-tools: Bash
---

# Commit Skill

> **Canonical runbook**: `.ai/skills/commit.md`
> This file is the Claude Code adapter. The workflow logic is defined in the canonical skill
> so it can be shared with other agents (Codex, Copilot, Cursor). Any changes to the workflow
> should be made in `.ai/skills/commit.md` first.

You are now in commit mode. Follow these steps **in order**, stopping if any check fails.

## Step 1: Gather status and diff

Run these in parallel:
- `git status --short`
- `git diff HEAD`
- `git log --oneline -5`

If there are no staged or modified files, tell the user there is nothing to commit and stop.

## Step 2: Scan for sensitive data

Review ALL output from Step 1 carefully. Look for any of the following in file names or diff content:

**Sensitive patterns to detect:**
- API keys, tokens, secrets (patterns like `sk-`, `ghp_`, `xoxb-`, `AKIA`, `Bearer `, `token`, `api_key`, `apikey`)
- Passwords or credentials (`password`, `passwd`, `secret`, `credential`)
- Private keys or certificates (-----BEGIN, `.pem`, `.key`, `.p12`, `.pfx`)
- Environment files (`.env`, `.env.local`, `.env.production`, any `.env*`)
- AWS/cloud credentials (`aws_access_key`, `aws_secret`, `client_secret`)
- Database connection strings with credentials
- Hard-coded IP addresses or internal hostnames with credentials
- SSH private keys

**If ANY sensitive data is detected:**

Stop immediately and output:

```
WARNING: Sensitive data detected — commit aborted.

Found in: <file(s)>
Issue: <brief description of what was found>

Please remove the sensitive data before committing. Consider using environment variables or a secrets manager instead.
```

Do NOT proceed further.

## Step 3: Check Java test conventions (if Java test files are changed)

Scan the diff for any added or modified Java test files (`src/test/**`, `src/testInt/**`). For each, flag:

| Rule | Violation | Severity |
|---|---|---|
| `should` prefix | Method name starts with `test` instead of `should` | WARNING |
| `@DisplayName` present | Test method has no `@DisplayName` | WARNING |
| Given-When-Then wording | `@DisplayName` text does not follow `"Given …, when …, then …"` | WARNING |
| No useless `eq()` | `eq(literal)` in Mockito `when()`/`verify()` when no other matcher is used in the same call | WARNING |
| No inline phase comments | `// Arrange`, `// Act`, or `// Assert` in test body | INFO |
| `.getFirst()` preferred | `.get(0)` on a `List` in new/changed test code | INFO |

List violations and ask the user whether to fix them before committing or proceed as-is.

## Step 4: Draft the commit message

Analyze the diff and status to write a commit message:

- **Subject line**: 50-72 chars, imperative mood, no period at end
- **Blank line**
- **Body**: Explain *why* the change is being made, not just what. Describe context, motivation, and any trade-offs. Minimum 2-3 sentences.

**Body formatting rules:**
- Wrap every line at **72 characters** — keeps the message readable in terminals, `git log`, and GitHub PR descriptions
- Do **not** mention test fixes or test convention changes unless the PR is exclusively about tests — focus on the business or technical motivation
- Write the body so it can be re-used directly as a PR description: describe the *problem being solved* and *why*, not the mechanical steps

Format:
```
<subject line>

<body — each line ≤72 chars, focused on why, no test details>
```

**NEVER include any Co-Authored-By, Co-authored-by, or similar trailer lines.**

Show the draft commit message to the user before proceeding.

## Step 5: Stage files

Stage the specific files using `git add <files>` (never use `git add .` or `git add -A` — always add files by name to avoid accidentally including sensitive files).

## Step 6: Create the commit

Run:

```bash
git commit -m "$(cat <<'EOF'
<subject line>

<body>
EOF
)"
```

**Do NOT append any Co-Authored-By or similar lines to the commit message.**

After committing, run `git status` to confirm success.

## Rules summary

- Never use `git add .` or `git add -A`
- Never include Co-Authored-By or any co-author lines in commit messages
- Always write a commit body (not just a subject line)
- Stop immediately if sensitive data is detected
- Never force push

登录后下载/点赞/收藏 ❤ 20 | ★ 0

commit

目录结构

SKILL.md

举报内容

提示