Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

Commencer

commit

Étoiles1

Forks0

Mis à jour13 février 2026 à 20:16

Read this skill before making git commits

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

sergical

sergical/pi-config

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	commit
description	Read this skill before making git commits
license	From mitsuhiko/agent-stuff

Create a git commit for the current changes using Conventional Commits format with a polished, highly descriptive message.

Format

<type>(<scope>): <summary>

type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.
scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).
summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.

Notes

Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of git log should understand the change without looking at the diff.
Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

Steps

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run git log -n 50 --pretty=format:%s to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Run git commit -m "<subject>" (and -m "<body>" if needed).

Plus depuis ce dépôt

même dépôt

cmux

sergical/pi-config

Manage terminal sessions via cmux — spawn workspaces for dev servers, test runners, and background tasks. Read output, send commands, and orchestrate multi-terminal workflows.

2026-03-131

brainstorm

sergical/pi-config

Structured brainstorming that always follows the full execution chain: investigate → clarify → explore → validate design → write plan → create todos → create feature branch → execute with subagents. No shortcuts.

2026-03-131

visual-tester

sergical/pi-config

Visually test web UIs using Chrome CDP — spot layout issues, interaction bugs, responsive breakage, and produce a structured report

2026-03-131

semantic-compression

sergical/pi-config

Aggressively remove grammatical scaffolding LLMs reconstruct while preserving meaning-carrying content. Output may be fragments. Use when compressing text for prompts, reducing token count, preparing context for LLM input, or making documentation more token-efficient. Applies LLM-aware compression rules that delete predictable grammar while preserving semantics.

2026-03-111

system-prompts

sergical/pi-config

Write system prompts, tool docs, and agent definitions. Combines research-backed prompt engineering (+15-30% measured improvements) with project XML conventions. Covers tag hierarchy, structural templates, high-impact interventions, anti-patterns.

2026-03-111

tmux

sergical/pi-config

Remote control tmux sessions for interactive CLIs (python, gdb, etc.) by sending keystrokes and scraping pane output.

2026-03-091

name	commit
description	Read this skill before making git commits
license	From mitsuhiko/agent-stuff

Create a git commit for the current changes using Conventional Commits format with a polished, highly descriptive message.

Format

<type>(<scope>): <summary>

type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.
scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).
summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.

Notes

Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of git log should understand the change without looking at the diff.
Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

Steps

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run git log -n 50 --pretty=format:%s to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Run git commit -m "<subject>" (and -m "<body>" if needed).