Menü
Covers commit message conventions including format, structure, and content guidelines. Use when writing commits to ensure consistent, meaningful commit history across Datum Cloud repositories.
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.
Basierend auf der SOC-Berufsklassifikation
Covers GitHub conventions for pull requests, issues, and comments including linking, language style, formatting, and callout syntax. Use when creating PRs, writing issues, or posting comments on Datum Cloud repositories.
Turn raw engineering notes, PR/issue links, commit messages, or a one-line feature description into a changelog entry for Datum Cloud's GitHub Discussions Changelog category: a benefit-led title plus a markdown body, drafted for users and ready to hand off for final capture and publish. Use when someone says "write a changelog entry", "announce this in the changelog", or "post this to the changelog discussions" — this is the community-facing changelog POST, not the Keep a Changelog release file (that lives in `gtm-templates`).
Provides templates for go-to-market communications including blog posts, changelogs, social media, and enablement briefs. Use when writing launch announcements or marketing content.
Create a new GitHub release. Verifies CI is green on the release commit and refreshes the third-party NOTICE file before tagging, determines the next version from the latest tag, summarizes merged PRs since the last release, drafts release notes in the established style, and publishes via gh release create. Works for any datum-cloud service repository.
Scan a project repository for strict AGPL-3.0 license compliance across Go, Rust, and JavaScript/React codebases. Use this skill whenever the user asks to check, audit, verify, or enforce AGPL license compliance on a project, repo, or codebase. Triggers on phrases like "check agpl compliance", "audit license headers", "is this project agpl compliant", "scan for license headers", "check my license files", "agpl audit", or any request involving ensuring a project is properly licensed under AGPL. Always use this skill — don't wing AGPL compliance checks from general knowledge.
Covers producing weekly operational reports for the Datum AI Edge. Use when asked for an ops review, traffic report, latency analysis, provisioning report, or edge performance summary. Guides metric queries, anomaly detection, and publishing to datum-cloud/engineering.
| name | commit-conventions |
| description | Covers commit message conventions including format, structure, and content guidelines. Use when writing commits to ensure consistent, meaningful commit history across Datum Cloud repositories. |
This skill covers commit message conventions for all Datum Cloud repositories.
Write commit messages for future maintainers who need context months or years later. A well-crafted commit history enables effective use of git log, blame, revert, and rebase.
Based on How to Write a Git Commit Message:
| Rule | Guidance |
|---|---|
| 1. Separate subject from body with blank line | Required for multi-line commits |
| 2. Limit subject line to 50 characters | 50 is target, 72 is hard limit |
| 3. Capitalize the subject line | Begin with capital letter after type prefix |
| 4. Do not end subject with a period | Conserves space, cleaner appearance |
| 5. Use imperative mood | "Add feature" not "Added feature" |
| 6. Wrap body at 72 characters | Allows Git indentation in diffs |
| 7. Use body to explain what and why | Code shows how; commit explains why |
Use Conventional Commits format:
<type>: <subject>
<body>
<trailers>
| Type | Use When |
|---|---|
feat | Adding new functionality |
fix | Fixing a bug |
docs | Documentation only changes |
refactor | Code change that neither fixes a bug nor adds a feature |
test | Adding or updating tests |
chore | Maintenance tasks, dependencies, tooling |
feat:, fix:, etc.Imperative mood test: "If applied, this commit will [subject]"
feat: Add user authentication endpoint ✓ reads naturally
feat: Added user authentication endpoint ✗ awkward phrasing
feat: Adding user authentication endpoint ✗ awkward phrasing
Single-line commits are acceptable for:
Include a body for:
Focus on why, not what (the diff shows what changed).
Answer these questions:
fix: Correct typo in error message
feat: Add rate limiting to API endpoints
The public API was vulnerable to abuse from automated clients
making excessive requests. This adds a token bucket rate limiter
with configurable limits per endpoint.
Default limits are set conservatively (100 req/min) and can be
adjusted via environment variables.
Resolves: #234
refactor: Extract validation logic into separate package
Validation rules were duplicated across three controllers. Moving
them to a shared package reduces maintenance burden and ensures
consistent behavior.
This is a pure refactor with no behavior changes.
fix: Fix the bug
Why is this bad? Which bug? What was wrong? Future maintainers have no context.
refactor: Move function to different file
Why is this bad? The diff already shows this. Why was it moved?
feat: add new user authentication endpoint that validates credentials and returns JWT tokens
Why is this bad? Exceeds 72 characters. Use body for details.
When generating commit messages:
Claude Code agents include the Co-Authored-By trailer:
feat: Add resource quota enforcement
Implements quota checking at resource creation time to prevent
tenants from exceeding their allocated limits.
Co-Authored-By: Claude <claude@anthropic.com>
<type>: <Subject line under 50 chars>
<Explain the problem this solves. Wrap at 72 characters. Focus on
the motivation and context, not the implementation details.>
<If relevant, explain why this approach was chosen over alternatives.>
<Bullet points are acceptable:>
- Point one
- Point two
Resolves: #<issue-number>
Co-Authored-By: Claude <claude@anthropic.com>