Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

commit-message

Sterne2

Forks1

Aktualisiert3. Juli 2026 um 15:17

Write repository commit messages. Use when an agent creates commits, prepares commit text, reviews commit history, or updates workflow guidance that mentions commit messages.

Installation

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.

In Manus ausführen

Quelle

docs-as-code-toolkit

docs-as-code-toolkit/architecture-knowledge-toolkit

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name	commit-message
description	Write repository commit messages. Use when an agent creates commits, prepares commit text, reviews commit history, or updates workflow guidance that mentions commit messages.

Commit Message Skill

Purpose

Write clear, traceable commit messages for this repository without assuming a specific AI engine or runtime.

Format

For work done for an issue, start the summary with the issue number:

issue_<issue number>: <imperative summary>

Example:

issue_123: Add metadata validation

For work that does not refer to an issue, start directly with the imperative summary:

Add metadata validation

Rules

Keep the first line short, with 50 characters or less.
Use the imperative mood, such as Add feature instead of Added feature.
Leave a blank line after the summary when adding a body.
Use the body only when more detail is needed.
Describe why the change was made, not only what changed.

Issue References

Use the issue_<issue number>: prefix only when the commit belongs to a known issue. Do not invent an issue number.

Mehr aus diesem Repository

gleiches Repository

architecture-core

docs-as-code-toolkit/architecture-knowledge-toolkit

Apply the architecture-knowledge-toolkit baseline for architecture documentation, traceability, metadata, quality scenarios, risks, ADRs, and adapter boundaries. Use before architecture-sensitive work or when creating derived agent adapters from canonical skills.

2026-07-102

bdd-specification

docs-as-code-toolkit/architecture-knowledge-toolkit

Enforce Living Documentation through Behaviour-Driven Development by writing a language-agnostic Gherkin feature specification for any new or changed observable behaviour and mapping each scenario to at least one automated verification, even when the target language has no native BDD framework. This is the strict default for features, behavioural enhancements, and behaviour-changing bug fixes; relax it only with an explicit recorded human waiver. Use when Codex is asked to specify feature or behaviour, write or update .feature files, add BDD or acceptance tests, keep behaviour specs and tests in sync, bridge Gherkin scenarios to classic tests, or apply a scenario-to-test naming convention with Given/When/Then structure.

2026-07-102

architecture-impact

docs-as-code-toolkit/architecture-knowledge-toolkit

Analyze and document architecture impact for feature requests, Epic issues, UserStory issues, refactoring tasks, issue implementation, and review tasks. Use when Codex is asked to handle a feature request, decide whether feature work should become an Epic or UserStory, create or refine an Epic, mark a UserStory or refactoring issue, implement feature or refactoring work, review a pull request or review task, assess whether code changes affect architecture documentation, update affected arc42 sections, connect features or refactorings to ADRs, quality goals, quality scenarios, risks, components, runtime scenarios, deployment views, or create follow-up ADRs with diagrams.

2026-07-102

implement-issue-workflow

docs-as-code-toolkit/architecture-knowledge-toolkit

Implement GitHub issue work using the repository workflow: start from the latest main branch, create an issue_<number> branch, make focused changes, verify, commit using the commit-message skill, push, and open a pull request. Use when Codex is asked to implement or fix a GitHub issue, continue issue work, prepare a PR for issue work, or address pull request review comments.

2026-07-102

adr

docs-as-code-toolkit/architecture-knowledge-toolkit

Create proposed Architecture Decision Records and analyze their impact on related architecture artifacts. Use when Codex needs to draft or update ADRs, inspect existing architecture documentation and source code, compare options with a Pugh matrix, identify affected risks and quality scenarios, propose traceability metadata relations, update impacted artifacts only when justified, or produce an ADR impact report.

2026-07-102

quality-scenario

docs-as-code-toolkit/architecture-knowledge-toolkit

Create proposed quality scenarios and analyze their traceability to quality objectives, ADRs, risks, requirements, architecture artifacts, and code evidence. Use when Codex needs to draft or update measurable quality scenarios, inspect existing arc42 Chapter 10 quality requirements, derive scenarios from source evidence without inventing targets, propose metadata relations, or produce a quality scenario impact report.

2026-07-102

name	commit-message
description	Write repository commit messages. Use when an agent creates commits, prepares commit text, reviews commit history, or updates workflow guidance that mentions commit messages.

Commit Message Skill

Purpose

Write clear, traceable commit messages for this repository without assuming a specific AI engine or runtime.

Format

For work done for an issue, start the summary with the issue number:

issue_<issue number>: <imperative summary>

Example:

issue_123: Add metadata validation

For work that does not refer to an issue, start directly with the imperative summary:

Add metadata validation

Rules

Keep the first line short, with 50 characters or less.
Use the imperative mood, such as Add feature instead of Added feature.
Leave a blank line after the summary when adding a body.
Use the body only when more detail is needed.
Describe why the change was made, not only what changed.

Issue References

Use the issue_<issue number>: prefix only when the commit belongs to a known issue. Do not invent an issue number.