git-commit
Use when suggesting a commit message, branching, staging, committing, merging, resolving conflicts, or pushing in any project of this workspace.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when suggesting a commit message, branching, staging, committing, merging, resolving conflicts, or pushing in any project of this workspace.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Python coding conventions for this workspace. Use when writing or reviewing Python in taskflow-api or scan-simulator — apply automatically, without asking for confirmation.
Draft well-structured Pull Request titles and descriptions. Use whenever the user wants to open a PR, write a pull request, draft a PR description, or prepare a PR for review — also when they give a ticket ID or branch name alongside code changes without saying "pull request".
Multi-step pipeline that takes a ticket from research to PR — research → spec → code → review + test → PR. Use for any ticket in agent-hub/tickets/.
Draft a release note from recent commits/closed tickets. Used in Part 2 of the session as the "simple skill" example.
Answer "what code implements this?" from a ticket, spec, or plain question — returns the registered call chain from the flow registry plus the impact of changing it.
基于 SOC 职业分类
| name | git-commit |
| description | Use when suggesting a commit message, branching, staging, committing, merging, resolving conflicts, or pushing in any project of this workspace. |
Format every commit message per the convention below. Derive the ticket ID from
the current branch name (branches are feature/<ticket-id>-<slug>, e.g.
feature/DEMO-101-close-guard → DEMO-101); if none can be derived, ask the
user — never guess or invent a ticket ID.
feature/<ticket-id>-<slug>, started from an
up-to-date main. Never push directly to main.Suggest message — read-only: git status, git diff HEAD,
git branch --show-current, git log --oneline -10. Present the message in a
fenced code block with the files it covers. Do not modify the repository.
Stage — stage only the files belonging to the change (no blanket
git add -A). If the diff contains unrelated changes, propose a split with
file groupings and stage only one group.
Commit — commit the staged files with a message following the convention. Show the resulting commit (hash + message + file list).
Push — NEVER push without asking the user first; prior approval to commit is not approval to push:
git fetch origin, then git status -sb (without a fetch, status is stale).git log origin/<branch>..HEAD --oneline)
and diff, then ask for explicit approval and wait for a yes. Never force-push.<ticket-id>: <Capitalized imperative summary>
Co-Authored-By / "Generated with" are AI-tooling defaults, not ours.-F <file>, never inline \n escapes.Examples:
DEMO-101: Block closing a task while its scan is pending
DEMO-101: Add functional test for close-guard against the simulator