docs: rebrand to GSD Core and restructure docs with Diataxis (#605)

* chore: wire docs/agents config into AGENTS.md Agent skills section

Add the `## Agent skills` discovery block pointing the engineering
skills at the existing docs/agents/{issue-tracker,triage-labels,domain}.md
files (issue tracker, triage label mapping, single-context domain docs).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* docs: rebrand to GSD Core and restructure docs with Diataxis

Reorganise the root README and docs/ around the Diataxis framework
(tutorials, how-to guides, reference, explanation), add new how-to
guides and schema references (STATE.md / CONTEXT.md / PLAN.md /
planning artifacts), and cross-link the whole set. Update the lone
legacy gsd-build reference to open-gsd; keep internal get-shit-done/
filesystem paths unchanged (directory rename tracked separately in
open-gsd/gsd-core#604). Regenerate the ja-JP, ko-KR, pt-BR and zh-CN
localised trees to mirror the new structure.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* docs: backfill changeset PR number (#605)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Tom Boucher
2026-06-02 08:13:09 -04:00
committed by GitHub
parent 8c47dcb1c1
commit 3bb2f8f1c5
200 changed files with 46813 additions and 8415 deletions

View File

@@ -1,13 +1,14 @@
# Discuss Mode: Assumptions vs Interview
GSD's discuss-phase has two modes for gathering implementation context before planning.
GSD Core's discuss-phase offers two modes for gathering implementation context before planning begins. Understanding when to use each helps you move from question-answering to a confirmed `CONTEXT.md` with less back-and-forth.
For step-by-step instructions on running either mode, see the [Discuss a phase how-to](how-to/discuss-a-phase.md).
## Modes
### `discuss` (default)
The original interview-style flow. Claude identifies gray areas in the phase, presents them
for selection, then asks ~4 questions per area. Good for:
The original interview-style flow. Claude identifies grey areas in the phase, presents them for selection, then asks approximately four questions per area. Good for:
- Early phases where the codebase is new
- Phases where the user has strong opinions they want to express proactively
@@ -15,13 +16,11 @@ for selection, then asks ~4 questions per area. Good for:
### `assumptions`
A codebase-first flow. Claude deeply analyzes the codebase via a subagent (reading 5-15
relevant files), forms assumptions with evidence, and presents them for confirmation or
correction. Good for:
A codebase-first flow. Claude deeply analyses the codebase via a subagent (reading 5–15 relevant files), forms assumptions with evidence, and presents them for confirmation or correction. Good for:
- Established codebases with clear patterns
- Users who find the interview questions obvious
- Faster context gathering (~2-4 interactions vs ~15-20)
- Faster context gathering (~2–4 interactions vs ~15–20)
## Configuration
@@ -33,12 +32,12 @@ node gsd-tools.cjs config-set workflow.discuss_mode assumptions
node gsd-tools.cjs config-set workflow.discuss_mode discuss
```
The setting is per-project (stored in `.planning/config.json`).
The setting is per-project (stored in `.planning/config.json`). See the [CONTEXT.md schema](reference/context-md.md) for the full structure of the file both modes produce.
## How Assumptions Mode Works
1. **Init** — Same as discuss mode (load prior context, scout codebase, check todos)
2. **Deep analysis** — Explore subagent reads 5-15 codebase files related to the phase
2. **Deep analysis** — Explore subagent reads 5–15 codebase files related to the phase
3. **Surface assumptions** — Each assumption includes:
- What Claude would do and why (citing file paths)
- What goes wrong if the assumption is incorrect
@@ -57,7 +56,8 @@ The setting is per-project (stored in `.planning/config.json`).
## Output
Both modes produce identical CONTEXT.md with the same 6 sections:
Both modes produce an identical `CONTEXT.md` with the same six sections:
- `<domain>` — Phase boundary
- `<decisions>` — Locked implementation decisions
- `<canonical_refs>` — Specs/docs downstream agents must read
@@ -65,4 +65,11 @@ Both modes produce identical CONTEXT.md with the same 6 sections:
- `<specifics>` — User references and preferences
- `<deferred>` — Ideas noted for future phases
Downstream agents (researcher, planner, checker) consume this identically regardless of mode.
Downstream agents (researcher, planner, checker) consume this file identically regardless of which mode produced it. See the [CONTEXT.md schema](reference/context-md.md) for the full field reference.
## Related
- [Discuss a phase](how-to/discuss-a-phase.md) — step-by-step how-to for running `/gsd-discuss-phase` in either mode.
- [CONTEXT.md schema](reference/context-md.md) — full field reference for the file both modes produce.
- [The phase loop](explanation/the-phase-loop.md) — how discuss fits into the broader discuss → plan → execute → verify → ship cycle.
- [docs index](README.md) — full table of contents for GSD Core documentation.