git-commit

$npx mdskill add cloudflare/sandbox-sdk/git-commit

Enforce concise, imperative commit messages following seven strict rules.

  • Ensures commit messages adhere to project standards for clarity and brevity.
  • Applies the seven rules for great commit messages including subject limits.
  • Uses imperative mood and separates subject from body with a blank line.
  • Prevents verbose explanations and bullet points in commit messages.

SKILL.md

.github/skills/git-commitView on GitHub ↗
---
name: git-commit
description: Use when creating git commits to ensure commit messages follow project standards. Applies the 7 rules for great commit messages with focus on conciseness and imperative mood.
---

# Git Commit Guidelines

Follow these rules when creating commits for this repository.

## The 7 Rules

1. **Separate subject from body with a blank line**
2. **Limit the subject line to 50 characters**
3. **Capitalize the subject line**
4. **Do not end the subject line with a period**
5. **Use the imperative mood** ("Add feature" not "Added feature")
6. **Wrap the body at 72 characters**
7. **Use the body to explain what and why vs. how**

## Key Principles

**Be concise, not verbose.** Every word should add value. Avoid unnecessary details about implementation mechanics - focus on what changed and why it matters.

**Subject line should stand alone** - don't require reading the body to understand the change. Body is optional and only needed for non-obvious context.

**Focus on the change, not how it was discovered** - never reference "review feedback", "PR comments", or "code review" in commit messages. Describe what the change does and why, not that someone asked for it.

**Avoid bullet points** - write prose, not lists. If you need bullets to explain a change, you're either committing too much at once or over-explaining implementation details.

## Format

Always use a HEREDOC to ensure proper formatting:

```bash
git commit -m "$(cat <<'EOF'
Subject line here

Optional body paragraph explaining what and why.
EOF
)"
```

## Good Examples

```
Add session isolation for concurrent executions
```

```
Fix encoding parameter handling in file operations

The encoding parameter wasn't properly passed through the validation
layer, causing base64 content to be treated as UTF-8.
```

## Bad Examples

```
Update files

Changes some things related to sessions and also fixes a bug.
```

Problem: Vague subject, doesn't explain what changed

```
Add file operations support

Implements FileClient with read/write methods and adds FileService
in the container with a validation layer. Includes comprehensive test
coverage for edge cases and supports both UTF-8 text and base64 binary
encodings. Uses proper error handling with custom error types from the
shared package for consistency across the SDK.
```

Problem: Over-explains implementation details, uses too many words

## Checklist Before Committing

- [ ] Subject is ≤50 characters
- [ ] Subject uses imperative mood
- [ ] Subject is capitalized, no period at end
- [ ] Body (if present) explains why, not how
- [ ] No references to review feedback or PR comments
- [ ] No bullet points in body
- [ ] Not committing sensitive files (.env, credentials)

More from cloudflare/sandbox-sdk

SkillDescription
architectureUse when navigating the codebase for the first time, adding a new client method, adding a new container handler/service, or understanding how a request flows from Worker through the Sandbox DO into the container. Covers the three-layer architecture, client pattern, container runtime structure, and monorepo layout. (project)
changesetsUse when creating a changeset, preparing a release, or bumping versions. Covers which packages to reference, how to write user-facing changeset descriptions, the release automation flow, and the npm/Docker version sync requirement. (project)
coding-standardsUse when writing or reviewing TypeScript in this repo. Covers the no-`any` rule and where to put new types, the uppercase-acronym style guide, and the rules for code comments (no historical context). (project)
examplesUse when working in the examples/ directory, running an example with wrangler dev, adding a new example, or answering questions about EXPOSE directives and the local Docker dev loop. (project)
loggingUse when adding logs, debugging, or working with the Logger across the SDK and container runtime. Covers the constructor-injection pattern, child loggers, env-var configuration, and test mocking. (project)
sandbox-bridgeUse when you need to exercise a real, running Sandbox deployment via HTTP — for example to validate SDK changes against a live container, reproduce a user-reported issue, or experiment with the API (including FUSE bucket mounts) without spinning up `wrangler dev`. Documents the Sandbox bridge worker reachable via `SANDBOX_WORKER_URL` + `SANDBOX_API_KEY` when the host injects them.
session-executionUse when working on or reviewing session execution, command handling, shell state, FIFO-based streaming, or stdout/stderr separation. Relevant for session.ts, command handlers, exec/execStream, or anything involving shell process management. (project)
testingUse when writing or running tests for this project. Covers unit vs E2E test decisions, test file locations, mock patterns, and project-specific testing conventions. (project)