@ktpartners/dgs-platform 2.9.0 → 3.3.0

package/deliver-great-systems/workflows/help.md

@@ -12,14 +12,14 @@ Display the complete DGS command reference. Output ONLY the reference content. D
 ## Quick Start
 
 **Single-project (v1):**
-1. `/dgs:new-project` - Create project (questioning + PROJECT.md)
+1. `/dgs:new-project [<name>]` - Create project (thin skeleton)
 2. `/dgs:new-milestone` - First milestone (research, requirements, roadmap)
 3. `/dgs:plan-phase 1` - Create detailed plan for first phase
 4. `/dgs:execute-phase 1` - Execute the phase
 
 **Multi-project / multi-repo (v2):**
 1. `/dgs:init-product` - Set up product folder and register repos
-2. `/dgs:new-project` - Create a project (questioning + PROJECT.md)
+2. `/dgs:new-project [<name>]` - Create a project (thin skeleton)
 3. `/dgs:new-milestone` - First milestone (research, requirements, roadmap)
 4. `/dgs:plan-phase 1` - Plan first phase (repos tracked per task)
 5. `/dgs:execute-phase 1` - Execute (commits per-repo automatically)
@@ -73,22 +73,20 @@ Usage: `/dgs:init-product`
 
 ### Project Initialization
 
-**`/dgs:new-project`**
-Initialize new project through deep questioning. *(Tier 2: planning)*
+**`/dgs:new-project [<name>]`**
+Initialize a new project as a thin skeleton. *(Tier 2: planning)*
 
-One command takes you from idea to project identity:
-- Deep questioning to understand what you're building
-- Optional brownfield mapping for existing codebases
-- PROJECT.md creation with vision, requirements hypotheses, and key decisions
+- Creates `projects/<slug>/PROJECT.md` with title + one-line placeholder
+- Optional brownfield codebase mapping offer for existing code
+- No deep questioning, no `--auto` flag
 
-Creates project artifacts:
-- `PROJECT.md` — vision and requirements
+Projects are holders. Vision and principles live in `docs/product/PRODUCT-SUMMARY.md`
+(loaded via Tier 1). Specs live at the milestone level.
 
-**v2 additions:** Prompts for project name (used as folder slug), prompts for which repos this project touches (from REPOS.md). Artifacts are created under `projects/<project-slug>/`.
+**Next:** `/dgs:write-spec` to capture what you're building, then
+`/dgs:new-milestone --auto <spec-id>` to start the first milestone.
 
-After completion, run `/dgs:new-milestone` to start your first milestone.
-
-Usage: `/dgs:new-project`
+Usage: `/dgs:new-project [<name>]`
 
 **`/dgs:map-codebase [<repo-name>]`**
 Map registered repos with parallel agents to produce structured codebase documentation. *(Tier 2: planning)*
@@ -384,7 +382,7 @@ Usage: `/dgs:debug` (resume active session)
 Capture idea or task as todo from current conversation. *(Tier 1: lite)*
 
 - Extracts context from conversation (or uses provided description)
-- Creates structured todo file in the project's todos/pending/ directory
+- Creates structured todo file in the project's todos/ directory
 - Infers area from file paths for grouping
 - Checks for duplicates before creating
 - Updates STATE.md todo count
@@ -406,7 +404,7 @@ Usage: `/dgs:check-todos api`
 
 ### Ideas & Specs
 
-`capture ideas → develop idea → write spec → new-project --auto → new-milestone --auto`
+`capture ideas → develop idea → write spec → new-project → new-milestone --auto`
 
 #### Ideas
 
@@ -468,7 +466,7 @@ Usage: `/dgs:discuss-idea` (shows picker)
 Research an idea's feasibility and technical landscape. *(Tier 2: planning)*
 
 - Five dimensions: web search, codebase analysis, landscape survey, approaches, feasibility
-- Creates research document at `docs/ideas/pending/{slug}-research.md` (relative to planning root)
+- Creates research document at `docs/ideas/{slug}-research.md` (relative to planning root)
 - Appends Research Log to idea file (Summary, Document link, Key Finding, Recommendation)
 - Can run multiple times; each run appends a new entry
 
@@ -658,6 +656,41 @@ Create phases to close gaps identified by audit. *(Tier 2: planning)*
 Usage: `/dgs:plan-milestone-gaps`
 Usage: `/dgs:plan-milestone-gaps --auto` (non-interactive gap closure)
 
+**`/dgs:diff-report [version|--quick slug] [--detailed]`**
+Generate a diff report (REVIEW.md) on demand. *(Tier 4: verification)*
+
+- Auto-detects context: active quick task or current milestone
+- Explicit target: version for milestones, `--quick slug` for quick tasks
+- `--detailed` flag invokes LLM-powered per-file analysis
+- Delegates to existing CLI commands (`jobs generate-review` / `quick generate-review`)
+
+Usage: `/dgs:diff-report`, `/dgs:diff-report v21.0`, `/dgs:diff-report --quick my-task --detailed`
+
+### Testing & Dependency Scanning
+
+**`/dgs:package-scan [flags]`**
+Scan every registered repo + product root for dependency vulnerabilities and licence issues. *(Tier 0: none — no STATE.md/ROADMAP.md auto-inject)*
+
+- **Tool cascade:** Snyk → OSV-Scanner → ecosystem-native (`npm audit`, `pip-audit`, `govulncheck`, `bundler-audit`)
+- **Ecosystems:** Node.js, Python, Go, Ruby, Java (Maven; Gradle treated as single-module, PKG-41 deferred)
+- **Monorepo-aware:** npm/pnpm/Yarn workspaces, Maven multi-module, Go workspaces
+- **Report placement:** active phase dir → active milestone dir → timestamped project-root file
+- **Findings in canonical shape** (forward-compatible with `/dgs:plan-test-gaps`)
+
+**Flags:**
+- `--threshold critical|high|medium|low` — filter by severity
+- `--repo <name>` — scan a single registered repo
+- `--json` — emit machine-readable JSON alongside the markdown report
+- `--include-dev-deps` / `--no-include-dev-deps` — toggle devDependencies scanning
+
+**Config keys:** `testing.packages.tool`, `testing.packages.severity_threshold`, `testing.packages.include_dev_dependencies`, `testing.packages.timeout_seconds` (all in `config.json`). `testing.packages.snyk_token` goes to `config.local.json` only.
+
+**Reference doc:** `~/.claude/deliver-great-systems/references/package-scan-config.md` — tool installation steps, Snyk-auth priority, report placement cascade.
+
+Usage: `/dgs:package-scan`
+Usage: `/dgs:package-scan --threshold high --repo api`
+Usage: `/dgs:package-scan --json` (pipe to jq, feed CI, etc.)
+
 ### Milestone Jobs
 
 | Command | What it does | When to use |
@@ -866,7 +899,7 @@ Example config:
 **Starting a new project (v1):**
 
 ```
-/dgs:new-project        # Questioning -> PROJECT.md
+/dgs:new-project        # Thin skeleton PROJECT.md
 /clear
 /dgs:new-milestone      # Research -> requirements -> roadmap
 /clear
@@ -879,7 +912,7 @@ Example config:
 
 ```
 /dgs:init-product       # One-time: register repos, create product structure
-/dgs:new-project        # Questioning -> PROJECT.md
+/dgs:new-project        # Thin skeleton PROJECT.md
 /clear
 /dgs:new-milestone      # Research -> requirements -> roadmap
 /clear
@@ -944,7 +977,7 @@ Example config:
 #   /dgs:research-idea              # Investigate feasibility
 /dgs:write-spec                     # Turn ideas into structured spec
 /clear
-/dgs:new-project --auto @spec.md    # Create project from spec
+/dgs:new-project <name>             # Create project holder
 /clear
 /dgs:new-milestone --auto <spec-id> # First milestone from spec
 ```

package/deliver-great-systems/workflows/import-spec.md

@@ -201,6 +201,60 @@ This is the core AI conversion step. Restructure `SOURCE_CONTENT` into a 9-secti
 Store the full converted PRD as `CONVERTED_PRD`.
 </step>
 
+<step name="run_cross_llm_review">
+Run cross-LLM review on the converted PRD before presenting to the user. This matches the review pattern from write-spec.
+
+Load the review loop reference for detailed API call mechanics:
+@~/.claude/deliver-great-systems/references/spec-review-loop.md
+
+**1. Load review config:**
+
+```bash
+node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs review-config
+```
+
+Parse JSON result. If `has_any_key = false`: warn "No review API keys configured. Edit review-keys.json in your planning root to add OpenAI or Gemini keys. Skipping review." and proceed directly to `present_and_review`.
+
+**2. Initialize tracking:**
+
+- `round = 0`
+- `total_tokens = { openai: { prompt: 0, completion: 0 }, gemini: { prompt: 0, completion: 0 } }`
+- `rejected_items_history = []`
+- `REVIEW_HISTORY = ""`
+
+**3. Loop** (while round < max_rounds):
+
+   a. Increment round.
+   b. Send `CONVERTED_PRD` to available reviewers in parallel using the API call patterns from the reference doc. Issue both curl commands via parallel Bash tool calls.
+   c. Handle failures per reference doc error handling rules (retry once, then mark failed).
+   d. Parse feedback items from each reviewer's response. Each item: section, severity, feedback text, reviewer name.
+   e. **Auto-reject Non-Goal contradictions:** read the `## Non-Goals` section of `CONVERTED_PRD`, reject any feedback that suggests adding something explicitly listed as a Non-Goal. Disposition: `rejected-non-goal`.
+   f. **Check convergence:** compare rejected items against `rejected_items_history`. If an item (or substantially similar item) was rejected in the previous round too, move the concern to `## Open Questions` tagged as "From review: [concern]". Disposition: `moved-to-open-questions`.
+   g. **Apply accepted feedback:** Claude reads each remaining item and decides whether to apply it by modifying `CONVERTED_PRD`. Disposition: `accepted` (with change description) or `no-action` (with reason).
+   h. Build round history entry with all dispositions in the review history table format.
+   i. Append round history to `REVIEW_HISTORY` string.
+   j. Update token totals from response usage metadata.
+   k. **Check exit conditions:**
+      - No changes applied (all items rejected, no-action, or moved-to-open-questions) -> EXIT
+      - Green-only (all reviewers responded "LGTM" or no actionable feedback) -> EXIT
+      - Max rounds reached -> EXIT
+   If none met: continue to next round.
+
+**4. Display token/cost summary:**
+
+```
+Review complete (N rounds).
+Tokens: OpenAI [X prompt + Y completion] | Gemini [X prompt + Y completion]
+Estimated cost: ~$X.XX
+```
+
+**5. Append review history to CONVERTED_PRD:**
+
+If `REVIEW_HISTORY` is non-empty, append it to `CONVERTED_PRD` as a `## Review History` section at the end. This ensures the review history is included when the spec is saved.
+
+**Note:** Unlike write-spec, there is no spec file on disk yet. The review operates entirely on the in-memory `CONVERTED_PRD` string. The review history is appended to the content and persisted when the user chooses "save" in the next step.
+</step>
+
 <step name="present_and_review">
 Present the converted PRD for user review and handle the review loop.
 
@@ -217,7 +271,7 @@ Present the converted PRD for user review and handle the review loop.
 {CONVERTED_PRD}
 
 ---
-Original: will be saved to ${project_root}/{attachment_path}
+Original: will be saved to {attachment_path} (relative to planning root)
 {If IDEA_IDS is non-empty: "Linking to: " followed by comma-separated IDEA_DISPLAY entries, e.g., "Linking to: IDEA-1 (Phase 0 Foundation Infrastructure), IDEA-3 (Other Idea)"}
 
 **Review options:**
@@ -233,7 +287,7 @@ Original: will be saved to ${project_root}/{attachment_path}
 
 **If "save":**
 1. Generate the slug from `SPEC_TITLE` (lowercase, replace non-alphanumeric with hyphens, trim leading/trailing hyphens).
-2. Check if `${project_root}/specs/spec-{slug}.md` already exists. If it does, use AskUserQuestion to prompt: `A spec with slug '{slug}' already exists. Enter a new title:` -- then regenerate the slug from the new title and re-check. Loop until no conflict.
+2. Check if `specs/spec-{slug}.md` (relative to planning root) already exists. If it does, use AskUserQuestion to prompt: `A spec with slug '{slug}' already exists. Enter a new title:` -- then regenerate the slug from the new title and re-check. Loop until no conflict.
 3. Compute the slugified source filename: take `SOURCE_FILENAME`, lowercase it, replace non-alphanumeric chars (except dots) with hyphens, trim leading/trailing hyphens, preserve file extension. This matches `docs.slugifyFilename()` behaviour.
 4. Compute the attachment path: `specs/spec-{slug}/docs/{slugified-source-filename}` (relative to the planning root).
 5. Call specs create (with --source-ideas when ideas are linked):
@@ -264,7 +318,7 @@ Original: will be saved to ${project_root}/{attachment_path}
 
    **Execute the commit:**
    ```bash
-   node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "specs: import {id} - {title} (from {original-filename})" --push --files ${project_root}/specs/spec-{slug}.md ${project_root}/{attachment_path} ${project_root}/specs/spec-{slug}/docs/INDEX.md ${project_root}/specs/spec-{slug}/docs/.names.json
+   node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "specs: import {id} - {title} (from {original-filename})" --push --files specs/spec-{slug}.md {attachment_path} specs/spec-{slug}/docs/INDEX.md specs/spec-{slug}/docs/.names.json
    ```
    The `dgs-tools.cjs commit` helper with `--files` stages only the specified files and commits them. This ensures other unstaged/uncommitted changes in the working tree are not included. The `.names.json` file is included because `docs add` creates it as internal metadata for INDEX rebuilds.
 
@@ -283,8 +337,8 @@ Original: will be saved to ${project_root}/{attachment_path}
      ID: {id}
      Title: {SPEC_TITLE}
      Status: draft
-     File: ${project_root}/{filename path from specs create result}
-     Source: ${project_root}/{attachment_path}
+     File: {filename path from specs create result} (relative to planning root)
+     Source: {attachment_path} (relative to planning root)
      Committed: specs: import {id} - {title} (from {original-filename})
      {If IDEA_IDS is non-empty: "Linked ideas: IDEA-1, IDEA-3 (unchanged state)"}
 
@@ -298,8 +352,8 @@ Original: will be saved to ${project_root}/{attachment_path}
      ID: {id}
      Title: {SPEC_TITLE}
      Status: draft
-     File: ${project_root}/{filename path from specs create result}
-     Source: ${project_root}/{attachment_path}
+     File: {filename path from specs create result} (relative to planning root)
+     Source: {attachment_path} (relative to planning root)
      {If IDEA_IDS is non-empty: "Linked ideas: IDEA-1, IDEA-3 (unchanged state)"}
 
    Next steps:
@@ -360,6 +414,10 @@ Stop execution.
 - [ ] Requirements use explicit language signal mapping (must/critical -> P0, should/important -> P1, could/nice-to-have -> P2) with P1 default
 - [ ] Requirements preserve original identifiers if numbered in source
 - [ ] Implementation Notes reference real files and patterns when codebase context available
+- [ ] Cross-LLM review runs after conversion (when review keys configured)
+- [ ] Review feedback applied to CONVERTED_PRD in-memory before user presentation
+- [ ] Review history appended to spec content and persisted on save
+- [ ] Missing review keys skip review with warning (non-blocking)
 - [ ] Spec title is auto-generated from source content
 - [ ] Full converted PRD is displayed for review with attachment path shown
 - [ ] Linked ideas displayed in review when --ideas provided

package/deliver-great-systems/workflows/init-product.md

@@ -88,51 +88,15 @@ Created:
   - .gitignore
 ```
 
-**b2. Configure Base Branch:**
+**b2. Configure Workflow Discipline (non-interactive):**
 
-Prompt the user for their code repo base branch:
-
-```
-AskUserQuestion([{
-  question: "What is the base branch for your code repos? (e.g., main, develop, dev)",
-  header: "Git Configuration",
-  multiSelect: false,
-  freeform: true,
-  placeholder: ""
-}])
-```
-
-Always ask — no auto-detection, no default pre-fill. The user types the branch name explicitly.
-
-After receiving the answer, write to config:
-```bash
-node /Users/adrian/.claude/deliver-great-systems/bin/dgs-tools.cjs config-set git.base_branch "$USER_ANSWER"
-```
-
-If the user provides an empty answer or skips, do NOT write anything — the default `main` from config-ensure-section already provides the fallback.
-
-**b3. Configure Workflow Discipline:**
+Workflow discipline is always enabled by default — it adds a CLAUDE.md file that routes code changes through `/dgs:*` commands for traceability and atomic commits. Read-only operations (searching, tests, git log) stay unrestricted. Users can disable later via `/dgs:settings`.
 
 Read the CLAUDE.md template:
 ```bash
 CLAUDE_TEMPLATE=$(cat /Users/adrian/.claude/deliver-great-systems/templates/claude-md.md)
 ```
 
-Use AskUserQuestion:
-```
-AskUserQuestion([{
-  question: "Enable workflow discipline? This adds a CLAUDE.md file that routes code changes through /dgs:* commands for traceability and atomic commits. Read-only operations (searching, tests, git log) stay unrestricted.",
-  header: "Workflow Discipline",
-  multiSelect: false,
-  options: [
-    { label: "Yes (Recommended)", description: "Creates CLAUDE.md with DGS command routing rules" },
-    { label: "No", description: "Skip — no CLAUDE.md created" }
-  ]
-}])
-```
-
-**If "Yes":**
-
 Check if `./CLAUDE.md` already exists in the project root (cwd):
 
 - **If CLAUDE.md does NOT exist:** Create `./CLAUDE.md` with DGS section delimiters wrapping the template content:
@@ -162,158 +126,72 @@ node /Users/adrian/.claude/deliver-great-systems/bin/dgs-tools.cjs config-set wo
 
 Display: `Workflow discipline enabled — CLAUDE.md added.`
 
-Add `CLAUDE.md` to the commit file list for the init commit that follows (the `dgs-tools.cjs commit` call at the end of the flow).
+CLAUDE.md is always included in the init commit file list (b4 below).
 
-**If "No":**
+**b3. Apply Recommended Defaults (non-interactive):**
+
+All other recommended defaults (`model_profile=balanced`, `commit_docs=true`, `workflow.research=true`, `workflow.plan_check=true`, `workflow.verifier=true`, `git.base_branch=main`) are already applied by `repos init-product` in step 2 — they live in `config.cjs`'s hardcoded defaults and are merged with any per-user overrides from `~/.dgs/defaults.json` (saved via `/dgs:settings save-as-defaults`). The three keys below are the only ones the underlying init does not pre-populate, so they are set explicitly here:
 
-Set config:
 ```bash
-node /Users/adrian/.claude/deliver-great-systems/bin/dgs-tools.cjs config-set workflow.discipline false
+node /Users/adrian/.claude/deliver-great-systems/bin/dgs-tools.cjs config-set mode yolo
+node /Users/adrian/.claude/deliver-great-systems/bin/dgs-tools.cjs config-set granularity standard
+node /Users/adrian/.claude/deliver-great-systems/bin/dgs-tools.cjs config-set workflow.codereview true
 ```
 
-Display: `Skipped.`
+Commit the applied defaults:
+```bash
+node /Users/adrian/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "chore: apply recommended defaults" --files ${config_path}
+```
 
-Do NOT create or modify CLAUDE.md. Do NOT add CLAUDE.md to any commit.
+**b4. Commit initialized files:**
 
-**b4. Configure Workflow Preferences (Round 1 — Core settings):**
+Extract the `scaffolded_files` array from the init response (`RESULT` captured in step 2) and pass those paths to the commit step alongside the explicitly-named files. The `scaffolded_files` array is the AGENT-13 contract field — it lists every path `cmdReposInitProduct` guaranteed on disk that the caller MUST commit (today the array contains the per-directory keep-files written under `specs/`, `docs/product/`, and `quick/`; future scaffold additions automatically flow through without workflow edits):
 
-```
-AskUserQuestion([
-  {
-    header: "Mode",
-    question: "How do you want to work?",
-    multiSelect: false,
-    options: [
-      { label: "YOLO (Recommended)", description: "Auto-approve, just execute" },
-      { label: "Interactive", description: "Confirm at each step" }
-    ]
-  },
-  {
-    header: "Depth",
-    question: "How thorough should planning be?",
-    multiSelect: false,
-    options: [
-      { label: "Quick", description: "Ship fast (3-5 phases, 1-3 plans each)" },
-      { label: "Standard", description: "Balanced scope and speed (5-8 phases, 3-5 plans each)" },
-      { label: "Comprehensive", description: "Thorough coverage (8-12 phases, 5-10 plans each)" }
-    ]
-  },
-  {
-    header: "Git Tracking",
-    question: "Commit planning docs to git?",
-    multiSelect: false,
-    options: [
-      { label: "Yes (Recommended)", description: "Planning docs tracked in version control" },
-      { label: "No", description: "Keep planning docs local-only (add to .gitignore)" }
-    ]
-  },
-  {
-    header: "Branching",
-    question: "Git branching strategy?",
-    multiSelect: false,
-    options: [
-      { label: "None (Recommended)", description: "Commit to current branch (fine for single projects)" },
-      { label: "Per Phase", description: "Branch per phase, review before merging" },
-      { label: "Per Milestone", description: "Branch per project, merge all at end (for parallel projects)" }
-    ]
-  }
-])
+```bash
+# AGENT-13: consume scaffolded_files from cmdReposInitProduct (per references/workflow-conventions.md)
+SCAFFOLDED=$(printf '%s' "$RESULT" | jq -r '.scaffolded_files[]?' | tr '\n' ' ')
+node /Users/adrian/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "docs: initialize product ${product_name}" --files REPOS.md PROJECTS.md config.json .gitignore CLAUDE.md ${SCAFFOLDED}
 ```
 
-**b5. Configure Workflow Preferences (Round 2 — Agents):**
+CLAUDE.md is always included (workflow discipline is now always enabled by default — see b2). The `${SCAFFOLDED}` token is unquoted intentionally so word-splitting expands the multiple paths into separate `--files` arguments.
 
-```
-AskUserQuestion([
-  {
-    header: "AI Models",
-    question: "Which AI models for planning agents?",
-    multiSelect: false,
-    options: [
-      { label: "Balanced (Recommended)", description: "Sonnet for most agents — good quality/cost ratio" },
-      { label: "Quality", description: "Opus for research/roadmap — higher cost, deeper analysis" },
-      { label: "Budget", description: "Haiku where possible — fastest, lowest cost" }
-    ]
-  },
-  {
-    header: "Research",
-    question: "Research before planning each phase? (adds tokens/time)",
-    multiSelect: false,
-    options: [
-      { label: "Yes (Recommended)", description: "Investigate domain, find patterns, surface gotchas" },
-      { label: "No", description: "Plan directly from requirements" }
-    ]
-  },
-  {
-    header: "Plan Check",
-    question: "Verify plans will achieve their goals? (adds tokens/time)",
-    multiSelect: false,
-    options: [
-      { label: "Yes (Recommended)", description: "Catch gaps before execution starts" },
-      { label: "No", description: "Execute plans without verification" }
-    ]
-  },
-  {
-    header: "Verifier",
-    question: "Verify work satisfies requirements after each phase? (adds tokens/time)",
-    multiSelect: false,
-    options: [
-      { label: "Yes (Recommended)", description: "Confirm deliverables match phase goals" },
-      { label: "No", description: "Trust execution, skip verification" }
-    ]
-  }
-])
-```
+**b5. Display Defaults Summary:**
+
+After commits land, print a summary block listing every applied setting and the recommended next step:
 
-**b6. Write config.json** with all values collected above:
-
-```json
-{
-  "mode": "yolo|interactive",
-  "depth": "quick|standard|comprehensive",
-  "parallelization": true,
-  "commit_docs": true|false,
-  "model_profile": "quality|balanced|budget",
-  "workflow": {
-    "research": true|false,
-    "plan_check": true|false,
-    "verifier": true|false,
-    "nyquist_validation": true,
-    "auto_advance": false,
-    "discipline": true|false
-  },
-  "git": {
-    "branching_strategy": "none|phase|milestone",
-    "base_branch": "[from earlier question]",
-    "sync_push": "prompt",
-    "sync_pull": "prompt"
-  }
-}
 ```
+───────────────────────────────────────────────────────────────
 
-Smart defaults (not asked): `parallelization: true`, `auto_advance: false`, `nyquist_validation: true`.
+## ✓ Defaults Applied
 
-**If commit_docs = No:** Add the planning root directory to `.gitignore`.
+The following recommended settings were applied automatically:
 
-**Commit config:**
+| Setting                    | Value      |
+|----------------------------|------------|
+| mode                       | yolo       |
+| granularity                | standard   |
+| commit_docs                | true       |
+| model_profile              | balanced   |
+| workflow.research          | true       |
+| workflow.plan_check        | true       |
+| workflow.verifier          | true       |
+| workflow.codereview        | true       |
+| workflow.discipline        | true       |
+| git.base_branch            | main       |
 
-```bash
-node /Users/adrian/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "chore: add product config" --files ${config_path}
-```
+Change any of them with `/dgs:settings`.
 
-**Branch name preview:** If `branching_strategy` is not `"none"`, show:
-```
-Branch names will look like: dgs/{project-slug}/phase-03-auth
-```
+## ▶ Recommended Next Step — Upload Product-Context Docs
 
-**b7. Commit initialized files:**
+`/dgs:add-doc PRODUCT-SUMMARY.md`   *what the product is, who it serves, key constraints*
+`/dgs:add-doc ARCHITECTURE.md`      *module boundaries, data flow, tech choices, security model*
 
-Use the `files_created` array from the init response to build the commit file list:
+Drop the file path, or paste/attach the file when prompted. These give every downstream workflow (research, planning, review) the context to do its job.
 
-```bash
-node /Users/adrian/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "docs: initialize product ${product_name}" --files REPOS.md PROJECTS.md config.json .gitignore CLAUDE.md
+Don't have these docs yet? Skip for now — you can run `/dgs:add-doc` anytime later. (A guided "answer questions to generate" path is on the roadmap.)
 ```
 
-Only include CLAUDE.md in the --files list if workflow discipline was enabled (user answered Yes).
+The summary is informational only — no commits, no config writes.
 
 **c. Route to next step:**