* docs(#956): address adr-phase-coverage findings on the MemPalace capability proposal Resolves the findings from the adr-phase-coverage audit (matrix + interpreted gaps posted on #956) by embedding durable decision→phase ownership and the cross-doc gating item into the proposal, so no deliverable sits ownerless between phases: - §15.1 Decision → Phase ownership: every §10 decision + user-facing capability is the explicit responsibility of one phase. Cross-cutting policies get a primary owner (D6 onError:skip → P1 manifest-encoded; D3 transport → P2 MCP-primary rendering, P5 CLI-fallback headless). - §15.2 Dependencies & gating items: Phase 6 is GATED on ADR-857's Migrate phase (workflows calling loop render-hooks) — recorded as a traced gating item, not prose. UX-auto + UX-curator have no other wiring surface; if ADR-857's Migrate is descoped, Phase 6 is formally blocked, not silently dropped. De-risk: Phases 1–5 ship the full manual-invocation value ahead. - Phase 3 gate: explicitly verifies the inherited UX-enable surface (gsd capability enable mempalace + config-set), not just the internal state resolver. - Phase 6 gate: names the user-observable automatic surface (a /gsd-execute-phase run auto-produces MEMORY-RECALL.md at plan:pre, curator spawns at ship:post) instead of the wiring mechanism. - §17 open questions: each is traced to the phase whose acceptance must resolve it (wing-identity→P0, replace-migration→P4, curator-tier→P2, headless-MCP→P5, phase-6-dep→§15.2 gate, diary-namespacing→P6). Docs-only (proposal refinement); no runtime change. Closes #956 * docs(#956): correct the Phase-6 framing — ADR-857 is released, auto-fire is wired and verified Retracts the 'Phase 6 GATED on ADR-857 Migrate' framing introduced in the prior commit. ADR-857 (capability system + loop render-hooks + workflow call sites) is released; the host-loop workflows call loop render-hooks at each canonical point, so mempalace auto-fires when mempalace.enabled. Verified end-to-end: 'gsd-tools loop render-hooks plan:pre --raw' with mempalace.enabled:true returns the mempalace-recall step (capId: mempalace, produces MEMORY-RECALL.md). - Phase 6 row: 'Loop wiring (shipped via ADR-857)' with the verified gate. - §15.1 Phase 6 row: wired via shipped ADR-857 infra (no gate). - §15.2: rewritten from 'Dependencies & gating items' (false premise) to 'Loop wiring status' — documents the released/shipped state + the retraction. - §17.5: 'Phase-6 dependency' → 'Loop wiring (resolved — shipped)'. The §15.1 decision→phase ownership matrix, Phase 3 UX-enable gate, and §17 open-question traceability from the prior commit stand (those were accurate). --------- Co-authored-by: review-bot <review-bot@gsd>
GSD Core documentation
Documentation is organised into four quadrants: tutorials help you learn by doing, how-to guides solve specific tasks, reference states authoritative facts, and explanation explores concepts and design decisions.
Language versions: English · Português (pt-BR) · 日本語 · 简体中文
Tutorials
- Your first project — install to first shipped phase, one guaranteed path
- Onboarding an existing codebase — bring GSD Core to a brownfield repo
- Build your first capability — author a tiny declarative capability and watch it act in the loop
- Install your first capability — install a third-party capability end-to-end: consent, verify, check for updates, remove
How-to guides
- Install on your runtime — runtime-specific install steps for all 16 supported runtimes
- Install a minimal GSD and add skills later — install only the core skills, then grow the surface with profiles and
/gsd:surface - Attach a plugin-provided skill to a GSD agent — use the
global:plugin:skillentry form to load Claude Code plugin skills into agent prompts - Discuss a phase — capture implementation decisions before planning begins
- Resolve edge-coverage findings — turn the spec phase's surfaced domain-boundary edges into covered, dismissed, or backstopped spec decisions
- Resolve prohibition findings — turn the spec phase's surfaced must-NOT constraints into resolved, dismissed, or deferred spec decisions
- Plan a phase — run research, decompose work, and verify plan quality
- Execute a phase — run plans in parallel waves with fresh-context subagents
- Verify and ship — walk through completed work, diagnose failures, and create the PR
- Run phases autonomously — use autonomous mode for unattended phase execution
- Handle quick and fast tasks — use
/gsd-quickand/gsd-fastfor ad-hoc work outside the phase loop - Configure model profiles — switch between quality, balanced, and budget model tiers
- Set up cross-AI review — configure a second AI to review code produced by the primary agent
- Work in parallel with workstreams — run independent lines of work simultaneously using workstreams
- Isolate work with workspaces — use workspaces to sandbox experimental or risky changes
- Debug a failed execution — diagnose and recover from broken or incomplete phase execution
- Spike and sketch — use
/gsd-spikeand/gsd-sketchfor exploratory work before committing to a plan - Design a UI phase — use the UI phase loop for frontend and visual work
- Develop a Capability for GSD 1.5+ — add feature Capabilities, hook fragments, and registry entries
- Add or update a host's integration — set a host's documentation-sourced
runtime.hostIntegrationaxes (ADR-1239 Phase A), with theundocumentedsentinel rule - Turn a capability off (and keep it off) — disable a capability via the surface, or gate individual hooks off without removing the capability
- Drive GSD from a tracker issue — start a phase from a GitHub, Linear, or Jira issue
- Migrate from GSD 2 — upgrade an existing GSD 2 project to GSD Core
- Update GSD — re-run the installer to pick up the latest release
- Clean up get-shit-done-cc — remove leftover old-package artifacts that cause a spurious
⬆ /gsd:updateindicator after migrating to@opengsd/gsd-core - Fix the worktree base-mismatch (exit 42) error — resolve the branch-divergence condition that halts parallel phase execution
- Recover and troubleshoot — fix common problems, rebuild context, and uninstall
Reference
- Commands — every command with flags and examples
- Configuration — full config schema, model profiles, git branching strategies
- CLI tools —
gsd-tools.cjsprogrammatic API for workflows and agents - Features — complete feature index
- Inventory — installed skills and surface map
- STATE.md schema — field-by-field reference for
.planning/STATE.md - CONTEXT.md schema — field-by-field reference for
.planning/phases/<N>/CONTEXT.md - PLAN.md schema — field-by-field reference for
.planning/phases/<N>/PLAN.md - Planning artifacts — all
.planning/files and their roles - Review and verification capabilities — code review, security, and Nyquist capability ownership and hook contracts
- Capability matrix — generated catalogue of every capability's role, tier, extension points, hook kinds, and
engines.gsd - Capability manifest — the full
capability.jsonschema and validation rules gsd capabilitycommand — install / update / remove / list reference for third-party capabilities
Explanation
- Context engineering — how context rot forms and how GSD Core prevents it
- The phase loop — design rationale for the Discuss → Plan → Execute → Verify → Ship cycle
- Multi-agent orchestration — how subagents are spawned, scoped, and coordinated
- Security model — trust boundaries, permissions, and safe automation
- The capability trust model — why third-party capabilities are gated by consent + integrity + reversibility, not a sandbox
- How overlay capabilities compose — why first-party always wins and how the loader resolves precedence, conflicts, and fail-closed gates
- Architecture — system architecture, agent model, and data flow
- Discuss modes — assumptions mode vs interview mode for
/gsd-discuss-phase - Context monitoring — context window monitoring hook architecture
- Issue-driven orchestration — recipe for driving GSD from a tracker issue using existing primitives
Related
- Root README — landing page, quickstart, and documentation overview
- Changelog — release history