diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index 2fb47823d..000000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,331 +0,0 @@ -# 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 diff --git a/GSD-STYLE.md b/GSD-STYLE.md deleted file mode 100644 index bc3c24079..000000000 --- a/GSD-STYLE.md +++ /dev/null @@ -1,513 +0,0 @@ -# GSD-STYLE.md - -> **Comprehensive reference.** Core rules auto-load from `.claude/rules/`. This document provides deep explanations and examples for when you need the full picture. - -This document explains how GSD is written so future Claude instances can contribute consistently. - -## Core Philosophy - -GSD is a **meta-prompting system** where every file is both implementation and specification. Files teach Claude how to build software systematically. The system optimizes for: - -- **Solo developer + Claude workflow** (no enterprise patterns) -- **Context engineering** (manage Claude's context window deliberately) -- **Plans as prompts** (PLAN.md files are executable, not documents to transform) - ---- - -## File Structure Conventions - -### Slash Commands (`commands/gsd/*.md`) - -```yaml ---- -name: gsd:command-name -description: One-line description -argument-hint: "" or "[optional]" -allowed-tools: [Read, Write, Bash, Glob, Grep, AskUserQuestion] ---- -``` - -**Section order:** -1. `` — What/why/when (always present) -2. `` — @-references to workflows, templates, references -3. `` — Dynamic content: `$ARGUMENTS`, bash output, @file refs -4. `` or `` elements — Implementation steps -5. `` — Measurable completion checklist - -**Commands are thin wrappers.** Delegate detailed logic to workflows. - -### Workflows (`get-shit-done/workflows/*.md`) - -No YAML frontmatter. Structure varies by workflow. - -**Common tags** (not all workflows use all of these): -- `` — What this workflow accomplishes -- `` or `` — Decision criteria -- `` — Prerequisite files -- `` — Container for steps -- `` — Individual execution step - -Some workflows use domain-specific tags like ``, ``, ``, ``. - -**When using `` elements:** -- `name` attribute: snake_case (e.g., `name="load_project_state"`) -- `priority` attribute: Optional ("first", "second") - -**Key principle:** Match the style of the specific workflow you're editing. - -### Templates (`get-shit-done/templates/*.md`) - -Structure varies. Common patterns: -- Most start with `# [Name] Template` header -- Many include a `