بنقرة واحدة
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 المهني
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).
| 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.