a7abc6df2f
* test(3657): RED+shape-lock for verify-reapply-patches pristine-drift Adds tests/bug-3657-verify-reapply-patches-pristine-drift.test.cjs: - Core regression: exits 0 with reason=OK_PRISTINE_DRIFT_DETECTED when on-disk gsd-pristine/ hash does not match backup-meta.json.pristine_hashes - Counter-tests: real FAIL_USER_LINES_MISSING still caught when hashes match; over-broad mode unchanged when backup-meta.json is absent; clean run reports 0 failures when everything matches - Multi-file: drift + real-failure handled independently per file Updates tests/bug-2969-verify-reapply-patches.test.cjs REASON shape-lock to include OK_PRISTINE_DRIFT_DETECTED (added by the #3657 fix). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(3657): verify-reapply-patches skips pristine when hash drifts When gsd-pristine/ is refreshed to a newer GSD version after a backup is captured, the on-disk pristine's SHA-256 no longer matches the hash recorded in backup-meta.json.pristine_hashes. Using the wrong-version pristine as the diff baseline inverts the delta: every line the upstream removed between the two versions appears as a "user-added line that must survive", producing spurious FAIL_USER_LINES_MISSING false positives (Bug #3657). Fix: - Add sha256() and readPristineHashes() helpers to verify-reapply-patches.cjs - In verifyFile(), when a pristine_hashes entry exists for the file, compare the on-disk pristine's SHA-256 against it before accepting the baseline - On hash mismatch, return immediately with status=ok and the new REASON.OK_PRISTINE_DRIFT_DETECTED code, skipping the diff rather than false-failing - When no pristine_hashes entry exists (older installer / absent backup-meta), fall through to the pre-fix behaviour (use on-disk pristine as-is) - Export sha256, readPristineHashes, and OK_PRISTINE_DRIFT_DETECTED New REASON code OK_PRISTINE_DRIFT_DETECTED is added to the frozen enum. Exit code contract is unchanged: 0 for gate pass (including skipped-due-drift files), 1 for real user-content failures, 2 for structural errors. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * chore(3657): update changeset to reference PR #3767 * fix(3657): surface drifted_files in verify-reapply-patches JSON report Extend the top-level JSON report shape with two additive fields: - `drifted: N` — count of files skipped due to pristine-snapshot drift - `drifted_files: [...]` — relative paths of those files Per-file shape is unchanged (status:'ok' + reason:OK_PRISTINE_DRIFT_DETECTED) for backward compat. Drift still exits 0; `failures` count is unaffected. This gives workflow Step 5a structured data to gate on so drifted files are no longer silently treated as a full PASS (codex adversarial-review finding 1). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(3657): reapply-patches workflow halts on drifted files instead of silent pass Insert a "Step 5a: drift check" block between the exit-code check and the failures check in workflows/reapply-patches.md Step 5a. The new block: 1. Parses `drifted` + `drifted_files` from the JSON report (added in the companion prod-code commit). 2. When DRIFTED_COUNT > 0, emits a formatted HALT message naming each drifted file and instructs the user to re-baseline before re-running. 3. Sets DRIFT_DETECTED=true and exits non-zero so subsequent steps cannot execute while drift is unresolved. Drift is a distinct third state: it is not a failure (no missing user lines were proven) but it is also not a clean pass (the diff was skipped entirely). Existing pass/fail logic for VERIFY_STATUS and failures count is unchanged. Closes the silent-skip gap identified in codex adversarial-review finding 1. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * test(3657): assert drifted_files report shape + workflow Step 5a drift check Finding 1 (BLOCKER) — three new tests in bug-3657 test file: - Single drifted file: drifted=1, drifted_files contains the file path, failures=0, per-file shape unchanged (backward compat). - Multi-file drift: drifted=2, drifted_files lists both paths, clean file absent from array. - No-drift baseline: drifted=0, drifted_files=[] always present in output. Finding 2 (WARNING) — structural test on workflow source: - Asserts Step 5a contains "Step 5a: drift check" heading. - Asserts DRIFTED_COUNT, drifted_files, and DRIFT_DETECTED are referenced (confirming the gate exists and uses the structured report fields). - Asserts drift-check block appears before VERIFY_STATUS check (exit-code is 0 for drift, so the drift check must precede the non-zero gate). Also updates bug-2969 shape-lock to include the two new additive fields (drifted, drifted_files) per the contract change in the prod-code commit. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(3657): address pr-review-toolkit + codex review + CI failures - lint-tests: add // allow-test-rule: source-text-is-the-product at file top of bug-3657 test file; the inline comment at line 477 was a prose sentence, not a file-level annotation, so the lint scanner did not recognise it as the bypass token - Windows test failures (4 subtests): normalize relPath to forward slashes before pristineHashes key lookup in verifyFile(); on Windows path.join produces backslash-separated relPath values but backup-meta.json stores keys with forward slashes, causing the hash lookup to silently return undefined, falling through to use-as-is mode and producing the same false FAIL_USER_LINES_MISSING that the fix was meant to prevent Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(tests): bump verify allowlist ceiling 9→10 for bug-3657 test file Adding tests/bug-3657-verify-reapply-patches-pristine-drift.test.cjs in the previous commit pushed the verify module from 9 to 10 test files. The lint-test-file-count gate (added in #6313baad on main) enforces that modules cannot exceed their allowlist ceiling, so all 6 test platforms plus lint-tests and coverage failed with: FAIL_EXCEEDS_ALLOWLIST: verify count=10 ceiling=9 The fix is to raise the ceiling from 9 to 10 and set issue=3767. This file does not exist on this branch yet (introduced on main after the branch diverged) so we add it here. The merged CI state will see the bumped ceiling and pass. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
GET SHIT DONE
English · Português · 简体中文 · 日本語 · 한국어
A light-weight meta-prompting, context engineering, and spec-driven development system for Claude Code, OpenCode, Gemini CLI, Kilo, Codex, Copilot, Cursor, Windsurf, and more.
Solves context rot — the quality degradation that happens as your AI fills its context window.
npx get-shit-done-cc@latest
Works on Mac, Windows, and Linux.
"If you know clearly what you want, this WILL build it for you. No bs."
"I've done SpecKit, OpenSpec and Taskmaster — this has produced the best results for me."
"By far the most powerful addition to my Claude Code. Nothing over-engineered. Literally just gets shit done."
Trusted by engineers at Amazon, Google, Shopify, and Webflow.
Important
Returning to GSD?
Run
/gsd-map-codebaseto re-index your codebase, then/gsd-new-projectto rebuild GSD's planning context. Your code is fine — GSD just needs its context rebuilt. See the CHANGELOG for what's new.
Why I Built This
I'm a solo developer. I don't write code — Claude Code does.
Other spec-driven tools exist, but they're all built for 50-person engineering orgs — sprint ceremonies, story points, stakeholder syncs, Jira workflows. I'm not that. I'm a creative person trying to build great things consistently.
So I built GSD. The complexity is in the system, not in your workflow. Behind the scenes: context engineering, XML prompt formatting, subagent orchestration, state management. What you see: a few commands that just work.
The system gives Claude everything it needs to do the work and verify it. I trust the workflow. It just does a good job.
— TÂCHES
How It Works
The loop is six commands. Each one does exactly one thing.
1. Initialize
/gsd-new-project
Questions → research → requirements → roadmap. You approve it, then you're ready to build.
Already have code? Run
/gsd-map-codebasefirst. It analyzes your stack, architecture, and conventions so/gsd-new-projectasks the right questions.
2. Discuss
/gsd-discuss-phase 1
Your roadmap has a sentence per phase. That's not enough to build it the way you imagine it. Discuss captures your decisions before anything gets planned: layouts, API shapes, error handling, data structures — whatever gray areas exist for this specific phase.
The output feeds directly into research and planning. Skip it, get reasonable defaults. Use it, get your vision.
3. Plan
/gsd-plan-phase 1
Research → plan → verify, in a loop until the plans pass. Each plan is small enough to execute in a fresh context window.
4. Execute
/gsd-execute-phase 1
Plans run in parallel waves. Each executor gets a fresh 200k-token context. Each task gets its own atomic commit. Walk away, come back to completed work with a clean git history.
Your main context window stays at 30–40%. The work happens in the subagents.
5. Verify
/gsd-verify-work 1
Walk through what was built. Anything broken gets a diagnosed fix plan — ready for immediate re-execution. You don't debug manually; you just run execute again.
6. Repeat → Ship
/gsd-ship 1
/gsd-complete-milestone
/gsd-new-milestone
Loop discuss → plan → execute → verify → ship until the milestone is done. Then archive, tag, and start the next one fresh.
Getting Started
npx get-shit-done-cc@latest
The installer prompts for your runtime (Claude Code, OpenCode, Gemini CLI, Kilo, Codex, Copilot, Cursor, Windsurf, and more) and whether to install globally or locally.
claude --dangerously-skip-permissions
GSD is built for frictionless automation. Skip-permissions is how it's intended to run.
Install only the skills you need with --profile=core (six core-loop skills), --profile=standard (core + phase management), or the default full install. Profiles compose: --profile=core,audit. --minimal is an alias for --profile=core. See docs/USER-GUIDE.md for the full walkthrough, non-interactive install flags for all 15 runtimes, and permissions configuration. See ADR-0011 for the profile model and runtime surface control.
Current release highlights are in docs/RELEASE-v1.42.1.md: package legitimacy checks, safer installer migrations, runtime surface control, custom ship PR sections, reviewer defaults, fallow structural review, and quota-aware execution recovery.
Commands
The main loop:
| Command | What it does |
|---|---|
/gsd-new-project |
Questions → research → requirements → roadmap |
/gsd-discuss-phase [N] |
Capture implementation decisions before planning |
/gsd-plan-phase [N] |
Research + plan + verify |
/gsd-execute-phase <N> |
Execute plans in parallel waves |
/gsd-verify-work [N] |
Manual acceptance testing |
/gsd-ship [N] |
Create PR from verified phase work |
/gsd-progress --next |
Auto-detect and run the next step |
/gsd-complete-milestone |
Archive milestone and tag release |
/gsd-new-milestone |
Start next version |
/gsd:surface |
Enable/disable skill clusters at runtime without reinstall |
For ad-hoc tasks, autonomous mode, codebase analysis, forensics, and the full command surface — see docs/COMMANDS.md.
Why It Works
Three things most AI-coding setups get wrong:
1. Context bloat. As a session grows, quality degrades. GSD keeps your main context clean by doing the heavy work in fresh subagent contexts. Researchers, planners, and executors each start fresh with exactly what they need.
2. No shared memory. GSD maintains structured artifacts that survive session boundaries: PROJECT.md (vision), REQUIREMENTS.md (scope), ROADMAP.md (where you're going), STATE.md (current position and decisions), CONTEXT.md (per-phase implementation decisions). Every new session loads these and knows exactly where things stand.
3. No verification. Code that "runs" isn't code that "works." GSD's verify step walks you through what was built, diagnoses failures with dedicated debug agents, and generates fix plans before you declare a phase done.
See docs/ARCHITECTURE.md for how the multi-agent orchestration and context engineering work in detail.
Configuration
Settings live in .planning/config.json. Configure during /gsd-new-project or update with /gsd-settings.
Key dials:
| Setting | What it controls |
|---|---|
mode |
interactive (confirm each step) or yolo (auto-approve) |
| Model profiles | quality / balanced / budget — controls which model each agent uses |
workflow.research / plan_check / verifier |
Toggle the quality agents that add tokens and time |
parallelization.enabled |
Run independent plans simultaneously |
Optional structural review: set code_quality.fallow.enabled to true to add a fallow pre-pass to /gsd-code-review. GSD writes .planning/phases/<phase>/FALLOW.json and surfaces a Structural Findings (fallow) section in REVIEW.md. Install with npm install -D fallow@^2.70.0 (or system-wide via cargo install fallow; note that the Rust binary's JSON schema must match the documented v2.70+ contract — older versions may produce silent zero-finding output).
Package legitimacy checks are built into the research, planning, and execution path: recommended dependencies get audited, unverified packages require a human checkpoint, and failed installs stop instead of trying similarly named alternatives.
For the full configuration reference — all settings, git branching strategies, per-runtime model overrides, workstream config inheritance, agent skills injection — see docs/CONFIGURATION.md.
Documentation
| Doc | What's in it |
|---|---|
| User Guide | End-to-end walkthrough, install options, all runtime flags, configuration reference |
| Commands | Every command with flags and examples |
| Configuration | Full config schema, model profiles, git branching |
| Architecture | How the multi-agent orchestration works |
| CLI Tools | gsd-sdk query and programmatic SDK dispatch seams |
| Features | Complete feature index |
| Changelog | What changed in each release |
Troubleshooting
Commands not showing up? Restart your runtime after install. GSD installs to ~/.claude/skills/gsd-*/ (Claude Code), ~/.codex/skills/gsd-*/ (Codex), or the equivalent for your runtime.
Codex users — minimum supported CLI version is 0.130.0. Codex CLI 0.130.0 (release notes) removed extra-skill-roots discovery via openai/codex#21485; from that version onward Codex discovers skills from standard roots (including ~/.codex/skills/<name>/SKILL.md). GSD installs there directly. Earlier Codex CLI versions may still discover additional roots, which can surface duplicate gsd-* entries (one from extra-roots discovery, one from ~/.codex/skills/); restart Codex after install and either upgrade or accept the duplicate listing.
Something broken? Re-run the installer — it's idempotent:
npx get-shit-done-cc@latest
Containers or Docker? Set CLAUDE_CONFIG_DIR before installing to avoid tilde-expansion issues:
CLAUDE_CONFIG_DIR=/home/youruser/.claude npx get-shit-done-cc --global
Full troubleshooting and uninstall instructions in docs/USER-GUIDE.md.
Community
| Project | Platform |
|---|---|
| gsd-opencode | Original OpenCode port |
| Discord | Community support |
Star History
License
MIT License. See LICENSE for details.
Claude Code is powerful. GSD makes it reliable.