Files
msd-core/CONTRIBUTING.md
Lex Christopherson c313f78f6a docs: add CONTRIBUTING.md with project guidelines
Based on PR #222 by @davesienkowski with minor edits.

Co-Authored-By: davesienkowski <davesienkowski@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-22 15:02:02 -06:00

332 lines
7.1 KiB
Markdown

# Contributing to Get Shit Done
No enterprise theater. Ship useful code.
---
## Philosophy
GSD optimizes for **solo developer + Claude workflow**. The release process follows the same principle: complexity lives in automation, not your workflow.
**What this means:**
- No sprint ceremonies or release committees
- No multi-week stabilization branches
- Checkpoints before risky changes, not bureaucratic gates
- Ship when ready, batch when sensible
---
## Branch Strategy
Two branches. That's it.
```
main ════════════════════════════════════════════►
▲ ▲ ▲ ▲
│ │ │ │
v1.9.0 v1.9.1 v1.10.0 v2.0.0
│ │ │
hotfix batched minor
fixes features
```
### `main`
Production. Always installable via `npx get-shit-done-cc`.
| Rule | Why |
|------|-----|
| No direct commits | Forces checkpoint thinking |
| PRs required | Creates revert points |
| Must pass CI | Catches Windows/path issues |
### Feature Work
Branch → PR → Merge. No `develop` branch. No release branches.
```bash
# Start work
git checkout -b feat/model-profiles
# or fix/windows-paths
# or docs/checkpoint-examples
# Ship it
git push origin feat/model-profiles
# Open PR, get review, merge
```
**Branch naming:**
- `feat/description` — New capability
- `fix/description` — Bug fix
- `docs/description` — Documentation only
- `refactor/description` — Internal changes, no behavior change
- `hotfix/version-description` — Emergency production fix
---
## When to Branch vs. Direct Commit
**Use a branch when:**
- Adding new commands or workflows
- Changing core behavior (orchestrator, context loading)
- Touching multiple files
- You'd want a clean revert point
**Direct commit to main (maintainers only):**
- Typo fixes
- README updates
- Single-line bug fixes with obvious correctness
---
## Commits
Use conventional commits. Claude already does this.
```
feat(checkpoints): add rollback capability
fix(install): use absolute paths on Windows (#207)
docs(readme): update installation instructions
refactor(orchestrator): extract context loading
chore: remove old planning files
revert: remove codebase intelligence system
```
**Format:** `type(scope): description`
| Type | Use |
|------|-----|
| `feat` | New feature |
| `fix` | Bug fix |
| `docs` | Documentation |
| `refactor` | Code change without behavior change |
| `chore` | Maintenance, dependencies |
| `revert` | Undoing previous commit |
---
## Releases & Tags
### Tag Sparingly
**Current problem:** 131 tags in one month. Too noisy.
**New rule:** Tag stable milestones, not every commit.
| Change Type | Tag? | Version Bump |
|-------------|------|--------------|
| Breaking change | Yes | MAJOR (2.0.0) |
| New feature | Yes | MINOR (1.10.0) |
| Bug fix | Batch | PATCH (1.9.x) |
| Documentation | No | — |
| Refactor | No | — |
### Version Cadence
- **Minor releases (1.X.0):** When features are ready. No fixed schedule.
- **Patch releases (1.9.X):** Batch fixes weekly, or immediately for critical bugs.
- **Major releases (X.0.0):** Breaking changes only. Rare.
### Pre-release Tags for Risky Features
The codebase intelligence system added 3,065 lines and a 21MB dependency. It got reverted. Pre-release tags prevent this:
```bash
# Experimental feature
git tag -a v1.10.0-alpha.1 -m "Alpha: experimental codebase intelligence"
# After testing
git tag -a v1.10.0-beta.1 -m "Beta: codebase intelligence stabilized"
# Ready for production
git tag -a v1.10.0 -m "Release: codebase intelligence"
```
Users opt-in: `npm install get-shit-done-cc@1.10.0-alpha.1`
**If it doesn't work out:** Delete pre-release tags, no messy public revert on main.
### Creating a Release
```bash
# Update version
npm version minor # or patch, or major
# Update CHANGELOG.md (already follows Keep a Changelog format)
# Commit
git add package.json CHANGELOG.md
git commit -m "chore: release v1.10.0"
# Tag
git tag -a v1.10.0 -m "Release v1.10.0"
git push origin main --tags
# Publish
npm publish
```
### GitHub Releases
Create formal releases for minor+ versions. Copy the CHANGELOG section.
```
Go to: github.com/glittercowboy/get-shit-done/releases/new
Select tag: v1.10.0
Title: v1.10.0
Description: [paste from CHANGELOG.md]
```
---
## Large Changes
If a feature touches >500 lines or adds dependencies, use a branch and PR. This creates a review point before the change lands on main.
---
## Hotfixes
Production broken? Skip the normal flow.
```bash
# Branch from main
git checkout main
git checkout -b hotfix/1.9.4-windows-crash
# Fix it
# ... make changes ...
# Ship immediately
git commit -m "fix(install): handle Windows UNC paths"
git push origin hotfix/1.9.4-windows-crash
# PR → merge → tag
npm version patch
git tag -a v1.9.5 -m "Hotfix: Windows UNC paths"
git push origin main --tags
npm publish
```
---
## Pull Request Guidelines
### Title
Use conventional commit format:
```
feat(checkpoints): add rollback capability
fix(install): use absolute paths on Windows
```
### Description
```markdown
## What
[One sentence: what does this PR do?]
## Why
[One sentence: why is this change needed?]
## Testing
[How did you verify it works?]
## Breaking Changes
[List any, or "None"]
```
### Review Checklist
- [ ] Follows GSD style (no enterprise patterns, no filler)
- [ ] Updates CHANGELOG.md for user-facing changes
- [ ] Doesn't add unnecessary dependencies
- [ ] Works on Windows (test paths with backslashes)
---
## What NOT to Do
Borrowed from GSD-STYLE.md:
**Enterprise Patterns (Banned):**
- Story points
- Sprint ceremonies
- RACI matrices
- Release committees
- Multi-week stabilization branches
- Change advisory boards
**Temporal Language (Banned in Code/Docs):**
- "We changed X to Y"
- "Previously"
- "No longer"
- "Instead of"
Exception: CHANGELOG.md, MIGRATION.md, git commits
**Vague Contributions (Banned):**
```
# BAD
"Improve performance"
"Fix bugs"
"Update documentation"
# GOOD
"Reduce orchestrator context load from 12KB to 4KB"
"Fix Windows path handling in hook commands (#207)"
"Add checkpoint rollback examples to README"
```
---
## Quick Reference
| I want to... | Do this |
|--------------|---------|
| Add a feature | Branch `feat/x` → PR → merge |
| Fix a bug | Branch `fix/x` → PR → merge |
| Fix production NOW | Branch `hotfix/version-x` → PR → merge → tag |
| Release features | `npm version minor` → tag → publish |
| Release fixes | Batch weekly, or `npm version patch` for critical |
| Try experimental feature | Tag as `v1.X.0-alpha.1` |
| Revert a mistake | `git revert` → PR → merge |
---
## Setting Up Development
```bash
# Clone
git clone https://github.com/glittercowboy/get-shit-done.git
cd get-shit-done
# Install
npm install
# Test locally
npm link
npx get-shit-done-cc
# Run tests
npm test
```
---
## Getting Help
- **Issues:** Bug reports, feature requests
- **Discussions:** Questions, ideas, show & tell
- **Discord:** [Link if exists]
---
*"The complexity is in the system, not in your workflow."*
— TÂCHES