ワンクリックで
git-conventions
Use when creating a git commit or preparing changes for a pull request
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when creating a git commit or preparing changes for a pull request
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | git-conventions |
| description | Use when creating a git commit or preparing changes for a pull request |
| metadata | {"user-invocable":false,"type":"reference"} |
| Element | Rule |
|---|---|
| Format | type(scope): short description |
| Types | feat, fix, refactor, docs, test, chore, ci, perf, style, build |
| Scope | Optional, reflects module/area changed |
| Subject | Max 72 chars, lowercase start, imperative mood, no period, no emoji |
| Body | Optional, blank line after subject, 72 char line wrap |
| Footers | BREAKING CHANGE:, Refs:, Closes:, Fixes:, Implements:, See: |
feat(helmrelease): add Phase 3.3 services
fix(pg-non-prod): correct API key environment variable mappings
refactor: simplify context provider logic
chore(deps): update terraform to v1.6.0
git -C <path>, git --git-dir=<path>, and git --work-tree=<path> break
the permission system. Allow/deny rules match command prefixes like
git commit:* -- path flags inserted before the subcommand shift the prefix
and bypass all rules silently. Run cd as a separate Bash call, then run git.
Push to the feature branch. Only push directly to main when explicitly
instructed or when the work is already on main. Force-push (--force)
requires explicit user instruction.
The commit_validator.py hook validates against standards inlined as
module-level constants in that file (TYPE_ALLOWED, SUBJECT_MAX_LENGTH,
SUBJECT_RULES, BODY_MAX_LINE_LENGTH) -- it covers the conventional-commits
format, subject, and body rules. Forbidden-footer detection lives separately
in bash_validator (hardcoded there). Format violations block the commit.
Body line length triggers warnings only.
Use when constructing or interpreting the approval handoff envelope between subagent and orchestrator -- sealed_payload schema, approval_id format, APPROVAL_REQUEST contract shape, and reading a granted approval from the DB
Use when producing any agent response
Use when classifying any operation before executing it, or deciding whether user approval is required
Use when a mutative command was blocked by the hook and you need to request user approval, or when presenting a plan for a T3 operation before executing it
Use when the user wants to build, design, or extend a diagram — an architecture overview, a timeline, a planner board, a flow diagram, a presentation, a comparison, or a mind-map — as a portable, data-driven deck rendered from plain YAML. Triggers — "build a diagram", "architecture diagram", "diagram deck", "timeline", "flow diagram", "planner board", "add a page/section/component to the diagram".
Use when the user wants something to run routinely / on a schedule rather than once now -- "tarea programada", "rutinariamente", "cada mañana", "cada N horas", "todas las noches", "schedule", "cron". Covers mounting, structuring, and running an unattended headless task that reports back, plus consuming its reports. NOT for a live in-session agentic loop (that is agentic-loop).