Skip to main content

sdk-commit

Commit-message conventions for dd-sdk-android. Use when drafting or reviewing commit messages and PR titles, making a requested commit, or generating messages for other skills.

Informações da origem

Repositório
DataDog/dd-sdk-android
Última atividade na origem
20 de outubro de 2026 às 14:30
Idioma detectado do SKILL.md
inglês
Estrelas
227
Forks
87

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
name
sdk-commit
description
Commit-message conventions for dd-sdk-android. Use when drafting or reviewing commit messages and PR titles, making a requested commit, or generating messages for other skills.
when_to_use
Writing commit subjects and bodies, formatting a requested Git commit, or preparing commit messages and PR titles.
# sdk-commit — Commit Message Format ## Structure ``` <header> <blank line> <body> ``` ## Rules ### 1. Header (first line) - Write a short, imperative summary in English. - Follow the repository format: `<JIRA-KEY>-<number>: <short description>`. - Extract the ticket from the current branch, including branches following `<username>/<ticket>/<short-description>`; normalize the ticket to uppercase. - Example branch: `jdoe/rum-1234/add-logging` - Example header: `RUM-1234: Add structured logging to ingest pipeline` - Keep the header at most 72 characters. Put longer explanations in the body. - If the ticket cannot be determined from the branch or session context, ask the user before committing. Never invent a ticket or omit it. ### 2. Body (second line onward) - Leave one blank line between the header and the body. - Use the body for a short description of what was changed. - Any longer explanation MUST go in the body, never in the header. - If another skill produces a commit message, place its output in the body — always below the header line. ### 3. Attribution - NEVER add `Co-authored-by: Claude` or any similar co-authorship/attribution trailer. ### 4. File endings Every text file touched by a commit must end with exactly one newline character, with no blank lines after the last line of content. Before committing: - For `.kt`/`.kts` files, run `./gradlew ktlintFormatAll` instead of checking them manually. - Check other text files manually: - If a file has no trailing newline — add one. - If a file ends with blank lines — remove them, leaving a single trailing newline. - Never touch binary files (images, archives, keystores, etc.). ### 5. Commit body vs. PR description — keep them separate The commit body and the GitHub PR description serve different audiences and must NOT be conflated. - **Commit body** (what goes in git history): a brief 1–3 line description of *what* changed and *why*, written for a future reader of `git log`. Keep it technical and concise — it is not a PR description. - **PR description** (what goes on GitHub): a separate artifact. Do NOT embed PR descriptions in commit bodies. **When to add a body to the commit:** Add a body when the change is non-trivial and a one-line header does not fully capture the intent. A body is NOT needed for tiny, obviously self-explanatory changes. If the branch name encodes a ticket (`RUM-xxxx`), add `Ref: RUM-xxxx` on its own line in the body so GitHub/Jira auto-links it. The header prefix alone is not enough for some integrations. Commit bodies are always in English, regardless of session language.
Ver no GitHub