菜单
Team commit-message conventions. Use when writing a commit message, committing or amending changes, or when asked about the project's commit format. Reads the per-project style from .codex/idev/commit-style.md.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | commit-style |
| description | Team commit-message conventions. Use when writing a commit message, committing or amending changes, or when asked about the project's commit format. Reads the per-project style from .codex/idev/commit-style.md. |
Write commit messages that pass the team's commit-msg hook on the first try
and read well in git log years later.
Read the project's style file first: .codex/idev/commit-style.md.
If it exists, its rules override everything below. If it doesn't exist,
apply the defaults below (and mention that $idev:hooks install-git-hooks
sets up the style file + enforcement hooks).
Derive the ticket ID from the branch name when the style requires one:
git branch --show-current, extract the first ABC-123-shaped token.
The prepare-commit-msg hook does this automatically too — don't add the
prefix twice.
Write the message:
type(scope): imperative summary — conventional-commit types
(feat, fix, docs, refactor, perf, test, build, ci,
chore), ≤ 72 chars, no trailing period.Co-Authored-By:, Refs:), per
the team's policy in the style file.Check before committing: if .git/hooks/commit-msg exists, the message
must match its pattern (default: optional ABC-123: ticket prefix +
conventional-commit subject). If the hook rejects a commit, fix the
message — never bypass with --no-verify unless the user explicitly asks.
feat(auth): add refresh-token rotation
Sessions died after 15 minutes because the access token was never
refreshed. Rotate the refresh token on each renewal per OWASP.
Refs: ABC-123
When creating a PR (any platform — az repos pr create on Azure DevOps,
gh pr create on GitHub), unless .codex/idev/commit-style.md overrides:
## What
2-4 bullets of user-visible change (not a commit list — the platform shows those).
## Why
The problem/ticket context in 1-3 sentences.
## Testing
What was actually run: build, tests, browser-test report path if UI.
## Notes for reviewer
Risky spots, decisions needing eyes, rollback hint. Omit if none.
Senior backend architect for system design decisions — service decomposition, database schema design, API contract governance, migration strategy, reliability and observability patterns. Use when designing a new backend system or service, choosing between monolith/microservices, designing schemas or APIs, or planning a data migration. Advisory only — produces specifications, does not write code.
Branch synchronization agent — merges the team base branch into the current feature branch before a PR, resolves merge conflicts with three-way evidence and intent analysis, verifies the merge with a build and targeted tests, and reports what was merged and how each conflict was resolved. Use when preparing a branch for a PR, when a PR has conflicts with its target, or when asked to sync/update a feature branch with developer/main.
Browser testing agent — verifies web features and user flows end-to-end by writing and running re-runnable Playwright scripts, capturing screenshot/console/network evidence, and producing structured test reports. Use when a UI change needs real-browser verification, a user flow needs smoke testing, a UI bug needs reproduction, or the user asks to test the site in a browser and report results.
Expert code reviewer providing constructive, prioritized feedback on correctness, security, maintainability, performance, and test coverage — not style preferences. Use when reviewing a diff, branch, or PR for general quality. For a security-only deep audit, use the security-reviewer agent instead.
Expert frontend developer for building and improving web UI — components, state management, responsive layouts, accessibility, and Core Web Vitals performance. Use when implementing UI features or component libraries, fixing layout/responsiveness issues, improving accessibility compliance, or optimizing bundle size and page performance.
"Codebase onboarding specialist — builds fast, accurate mental models of unfamiliar repositories by reading source, tracing execution paths, and stating only facts grounded in inspected code. Use when onboarding into a new codebase, asking "where should I start", "what owns this behavior", or "how does a request flow through this system". Strictly read-only and descriptive — no reviews, refactors, or recommendations."