菜单
Commit, branch, and pull request standards - conventional commits, atomic changes, branch naming, commit timing, and PR quality. Use when committing, branching, staging changes, or creating/updating a pull request.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | git-policy |
| description | Commit, branch, and pull request standards - conventional commits, atomic changes, branch naming, commit timing, and PR quality. Use when committing, branching, staging changes, or creating/updating a pull request. |
git clone --depth=1 <url>.--single-branch (one branch only) and --no-tags (skip tag refs).git fetch --unshallow (full) or git fetch --depth=<n> (more commits). Prefer this over re-cloning.--filter=blob:none (blobless partial clone) or sparse-checkout instead of a full clone.attribution.commit / attribution.pr set to "", and includeCoAuthoredBy: false); the enigma installer sets this automatically. The rule here still applies on every runtime, settings or not.<emoji> <type>: <short description>.
Example: ✨ feat: add dual-provider matching.<type>: after the emoji; the emoji augments it, never replaces it.<type>: <short description>; everything else in this policy is unchanged..enigma.json (in the repo root or the user home) contains "commitEmoji": false,
or via enigma config commit-emoji off. Re-enable with enigma config commit-emoji on.Applies ONLY when remediating sensitive data the user wants removed from a repository - a committed secret, credential, private path, internal/customer name, PII value, or an asset rendered from one (e.g. a screenshot). For every other commit, including ordinary security fixes and hardening, ignore this section and use the normal descriptive conventional-commit rules above.
When such a removal is requested, FIRST present the remediation choices and let the user decide (visibility and irreversibility are their call), then act:
git filter-repo / BFG + force-push) - the only option that truly
removes the data. Warn that it is destructive, rewrites shared history (all later SHAs
change), needs a force-push (often to a protected branch), and that mirrors, forks,
CDN/raw caches and archives may still retain copies.Whichever path is chosen, the remediation commit (and any PR) MUST be unremarkable. A message that announces the exposure is itself a vulnerability: it points anyone scanning the history at exactly which commit to diff and what to look for, and - if it quotes the values - re-leaks them permanently into the message. So, in this case only:
🔒 security type. Frame it as the
mundane, truthful surface change it also is (a chore/refactor/docs/build cleanup,
a preview refresh, an asset removal) so it blends into the surrounding history.Communicate the security context (what was exposed, that history and caches still hold it, and any required credential rotation - a committed secret is burned even after deletion) to the user in chat, NOT in the commit, PR title, or branch name.
PR communication must assume ownership and responsibility for the changes.
Never refer to "the author", "the agent", "the AI", or third-person wording.
Use direct ownership language such as:
Avoid meta-commentary about the development process unless strictly relevant.
Do not mention:
PR descriptions must contain only information relevant for reviewers and maintainers.
Prefer standard ASCII punctuation in commits, PR titles, and technical communication.
Avoid typographic punctuation such as "—", smart quotes, or decorative Unicode characters.
Use "-" instead of "—".
Do not use arrows (→). Use "->".
Avoid robotic or overly templated phrasing.
Keep PR communication concise, natural, and technically relevant.
Remove filler sections that do not help code review or maintenance.
Before creating a commit or PR:
Minimal-code discipline for a lazy senior engineer - the YAGNI ladder (does it need to exist, stdlib, native platform feature, installed dependency, one line, then minimum), deletion over addition, no unrequested abstractions, and the `enigma:` comment convention for marking deliberate shortcuts and their upgrade path. Use whenever writing or refactoring implementation code, and whenever the user says "be lazy", "lazy mode", "simplest/minimal solution", "yagni", "do less", "what can we delete", "simplify", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Intensity is set by the minimal-code config setting (off|lite|full|ultra).
On-demand review that hunts ONLY over-engineering and reports what to delete - reinvented standard library, unneeded dependencies, speculative abstractions, dead flexibility. Three one-shot modes, none apply fixes: diff review, whole-repo audit, and an enigma: debt-marker ledger. Use when the user says "review for over-engineering", "what can we delete", "is this over-engineered", "simplify review", "audit this codebase", "find bloat", "what did we defer", "list the shortcuts", or "what did we mark to do later". Complements code-review-policy (which owns correctness, security, and performance); this one only cuts complexity.
Backend/API architecture - controller-service-repository layering, request/response handling, API and request optimization (batching, avoiding redundant calls), server-side caching (Redis) with invalidation, and Zod boundary validation. Use when designing or changing API endpoints, services, controllers, server business logic, or backend request flow.
Ciphera code style conventions - mandatory formatting and language idioms for source code (TypeScript-first, applies to every language) - American-English naming, double quotes, string interpolation, length-sorted imports, 4-space indentation, comment/JSDoc format, compact single-line blocks, and code-level anti-patterns (barrel files, external CDN/hosting dependencies). Use whenever writing, refactoring, or reviewing source code.
Pre-delivery self-review gate and prioritized review dimensions (security, correctness, data integrity, reuse, performance, readability) with change-quality criteria. Use BEFORE declaring any code change complete, and when asked to review a diff, PR, or branch.
Highest-authority engineering rules - priority hierarchy, modular architecture, code reuse, naming, language/output conventions, and the harness map that routes work to specialized policies. Use at the START of ANY engineering task (writing, refactoring, designing, or reviewing code), and whenever resolving a conflict between other policies.