git-commit
$
npx mdskill add cloudflare/sandbox-sdk/git-commitEnforce 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
- 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)