Menü
Use when suggesting a commit message, branching, staging, committing, merging, resolving conflicts, or pushing in any project of this workspace.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
| name | git-commit |
| description | Use when suggesting a commit message, branching, staging, committing, merging, resolving conflicts, or pushing in any project of this workspace. |
Format every commit message per the convention below. Derive the ticket ID from
the current branch name (branches are feature/<ticket-id>-<slug>, e.g.
feature/DEMO-101-close-guard → DEMO-101); if none can be derived, ask the
user — never guess or invent a ticket ID.
feature/<ticket-id>-<slug>, started from an
up-to-date main. Never push directly to main.Suggest message — read-only: git status, git diff HEAD,
git branch --show-current, git log --oneline -10. Present the message in a
fenced code block with the files it covers. Do not modify the repository.
Stage — stage only the files belonging to the change (no blanket
git add -A). If the diff contains unrelated changes, propose a split with
file groupings and stage only one group.
Commit — commit the staged files with a message following the convention. Show the resulting commit (hash + message + file list).
Push — NEVER push without asking the user first; prior approval to commit is not approval to push:
git fetch origin, then git status -sb (without a fetch, status is stale).git log origin/<branch>..HEAD --oneline)
and diff, then ask for explicit approval and wait for a yes. Never force-push.<ticket-id>: <Capitalized imperative summary>
Co-Authored-By / "Generated with" are AI-tooling defaults, not ours.-F <file>, never inline \n escapes.Examples:
DEMO-101: Block closing a task while its scan is pending
DEMO-101: Add functional test for close-guard against the simulator
Basierend auf der SOC-Berufsklassifikation
Python coding conventions for this workspace. Use when writing or reviewing Python in taskflow-api or scan-simulator — apply automatically, without asking for confirmation.
Draft well-structured Pull Request titles and descriptions. Use whenever the user wants to open a PR, write a pull request, draft a PR description, or prepare a PR for review — also when they give a ticket ID or branch name alongside code changes without saying "pull request".
Multi-step pipeline that takes a ticket from research to PR — research → spec → code → review + test → PR. Use for any ticket in agent-hub/tickets/.
Draft a release note from recent commits/closed tickets. Used in Part 2 of the session as the "simple skill" example.
Answer "what code implements this?" from a ticket, spec, or plain question — returns the registered call chain from the flow registry plus the impact of changing it.
