GSD Core

This is an opinionated fork of GET SHIT DONE by TÂCHES — originally at gsd-build/get-shit-done (retired 2026), now continued as GSD Core at open-gsd/gsd-core. This fork tracks the active upstream and integrates a comprehensive SDLC methodology that adds quality gates, testing discipline, issue tracking, and verification rigor as first-class defaults. See FORK.md for the full list of changes.

Why this fork?

The upstream GSD is designed to work for everyone. This fork is designed for engineers who believe:

• Tests are contracts, not suggestions. The agent fixes the implementation, never the tests. If a test is wrong, the agent stops and asks.
• Quality only moves forward. Coverage thresholds, strict types, lint rules, and CI steps can never regress (the ratchet effect).
• Dead code is context pollution. Commented-out blocks, orphaned exports, and parallel implementations are flagged automatically.
• Adversarial review at every stage. A Devil's Advocate challenges plans before execution. An Edge Case Hunter reviews code in parallel during execution. Finder, critic, and referee agents cross-validate after execution. Three layers, three stages.
• Every change traces back to an issue. Branch naming, PR titles, and PR bodies link to your issue tracker automatically.
• Spec the outcome, not the process. Plans describe what success looks like. The executor figures out the how.
• Playwright tests are first-class. Screenshots are verification evidence. Manual UAT is the fallback, not the default.
• Projects should be scaffolded right from day one. Makefile, pre-commit hooks, preflight checks, and domain-scoped rules — all generated based on your stack.

All of these are on by default. Every feature is configurable — turn anything off with /gsd-settings — but the defaults encode an engineering philosophy where quality is automated, not aspirational.

Getting Started with this Fork

What's different from upstream

When you run /gsd-new-project, you'll be asked additional questions:

1. Issue tracker — Where do you track issues? (GitHub Issues, Linear, Jira)
2. Branch naming — What's your convention? (e.g., prefix-NN/description)
3. PR conventions — Title pattern, body requirements, CI commands
4. Scaffolding — Makefile, pre-commit hooks, preflight checks, domain rules

These generate a fully configured project with quality gates from day one.

What happens during development

The enriched pipeline looks like this:

/gsd-new-project
  → Issue tracker, branch naming, PR conventions configured
  → Makefile, preflight.yaml, .claude/rules/ scaffolded

/gsd-discuss-phase
  → All questions asked per area (no arbitrary cutoff)
  → Architectural decisions auto-propagated to CLAUDE.md

/gsd-plan-phase
  → Outcome-focused task specs (what, not how)
  → One-sentence objectives required
  → Plan-checker validates goals
  → Devil's Advocate challenges approach, surfaces risks

/gsd-execute-phase
  → Tests are read-only (completion contracts)
  → Executor prefers Makefile targets
  → Edge Case Hunter reviews code in parallel (boundary conditions, error paths, security)
  → Playwright tests run automatically

  After execution:
  → Adversarial validation (finder + critic + referee)
  → Dead code / context pollution scan
  → Ratchet effect enforcement (quality can't regress)
  → Migration safety checks
  → Definition of Done checklist
  → Preflight checks + auto PR creation

Auditing your project