GSD Configuration Reference

Full configuration schema, workflow toggles, model profiles, and git branching options. For feature context, see Feature Reference.

Configuration File

GSD stores project settings in .planning/config.json. Created during /gsd-new-project, updated via /gsd-settings.

Full Schema

{
  "mode": "interactive",
  "granularity": "standard",
  "model_profile": "balanced",
  "model_overrides": {},
  "models": {},
  "dynamic_routing": null,
  "planning": {
    "commit_docs": true,
    "search_gitignored": false,
    "sub_repos": []
  },
  "context": null,
  "workflow": {
    "research": true,
    "plan_check": true,
    "verifier": true,
    "auto_advance": false,
    "nyquist_validation": true,
    "ui_phase": true,
    "ui_safety_gate": true,
    "ui_review": true,
    "node_repair": true,
    "node_repair_budget": 2,
    "research_before_questions": false,
    "discuss_mode": "discuss",
    "max_discuss_passes": 3,
    "skip_discuss": false,
    "tdd_mode": false,
    "text_mode": false,
    "use_worktrees": true,
    "code_review": true,
    "code_review_depth": "standard",
    "plan_bounce": false,
    "plan_bounce_script": null,
    "plan_bounce_passes": 2,
    "plan_chunked": false,
    "code_review_command": null,
    "cross_ai_execution": false,
    "cross_ai_command": null,
    "cross_ai_timeout": 300,
    "security_enforcement": true,
    "security_asvs_level": 1,
    "security_block_on": "high",
    "post_planning_gaps": true,
    "build_command": null,
    "test_command": null
  },
  "hooks": {
    "context_warnings": true,
    "workflow_guard": false
  },
  "parallelization": {
    "enabled": true,
    "plan_level": true,
    "task_level": false,
    "skip_checkpoints": true,
    "max_concurrent_agents": 3,
    "min_plans_for_parallel": 2
  },
  "git": {
    "branching_strategy": "none",
    "phase_branch_template": "gsd/phase-{phase}-{slug}",
    "milestone_branch_template": "gsd/{milestone}-{slug}",
    "quick_branch_template": null
  },
  "gates": {
    "confirm_project": true,
    "confirm_phases": true,
    "confirm_roadmap": true,
    "confirm_breakdown": true,
    "confirm_plan": true,
    "execute_next_plan": true,
    "issues_review": true,
    "confirm_transition": true
  },
  "safety": {
    "always_confirm_destructive": true,
    "always_confirm_external_services": true
  },
  "project_code": null,
  "agent_skills": {},
  "response_language": null,
  "features": {
    "thinking_partner": false,
    "global_learnings": false
  },
  "learnings": {
    "max_inject": 10
  },
  "intel": {
    "enabled": false
  },
  "claude_md_path": "./CLAUDE.md"
}

Core Settings

Note: granularity was renamed from depth in v1.22.3. Existing configs are auto-migrated.

Integration Settings

Configured interactively via /gsd-settings-integrations. These are connectivity settings — API keys and cross-tool routing — and are intentionally kept separate from /gsd-settings (workflow toggles).

Search API keys

API key fields accept a string value (the key itself). They can also be set to the sentinels true/false/null to override auto-detection from env vars / ~/.gsd/*_api_key files (legacy behavior, see rows above).

Masking convention (get-shit-done/bin/lib/secrets.cjs): keys 8+ characters render as ****<last-4>; shorter keys render as ****; null/empty renders as (unset). Plaintext is written as-is to .planning/config.json — that file is the security boundary — but the CLI, confirmation tables, logs, and AskUserQuestion descriptions never display the plaintext. This applies to the config-set command output itself: config-set brave_search <key> returns a JSON payload with the value masked.

Code-review CLI routing

review.models.<cli> maps a reviewer flavor to a shell command. The code-review workflow shells out using this command when a matching flavor is requested.

The <cli> slug is validated against [a-zA-Z0-9_-]+. Empty or path-containing slugs are rejected by config-set.

Agent-skill injection (dynamic)

agent_skills.<agent-type> extends the agent_skills map documented below. Slug is validated against [a-zA-Z0-9_-]+ — no path separators, no whitespace, no shell metacharacters. Configured interactively via /gsd-settings-integrations.

Workflow Toggles

All workflow toggles follow the absent = enabled pattern. If a key is missing from config, it defaults to true.

Recommended Presets

Planning Settings

Project-Root Resolution in Multi-Repo Workspaces

When sub_repos is set and gsd-tools.cjs or gsd-sdk query is invoked from inside a listed child repo, both CLIs walk up to the parent workspace that owns .planning/ before dispatching handlers. Resolution order (checked at each ancestor up to 10 levels, never above $HOME):

1. If the starting directory already has its own .planning/, it is the project root (no walk-up).
2. Parent has .planning/config.json listing the starting directory's top-level segment in sub_repos (or the legacy planning.sub_repos shape).
3. Parent has .planning/config.json with legacy multiRepo: true and the starting directory is inside a git repo.
4. Parent has .planning/ and an ancestor up to the candidate parent contains .git (heuristic fallback).

If none match, the starting directory is returned unchanged. Explicit --project-dir /path/to/workspace is idempotent under this resolution.

Auto-Detection

If .planning/ is in .gitignore, commit_docs is automatically false regardless of config.json. This prevents git errors.

Hook Settings

The prompt injection guard hook (gsd-prompt-guard.js) is always active and cannot be disabled — it's a security feature, not a workflow toggle.

Private Planning Setup

To keep planning artifacts out of git:

1. Set planning.commit_docs: false and planning.search_gitignored: true
2. Add .planning/ to .gitignore
3. If previously tracked: git rm -r --cached .planning/ && git commit -m "chore: stop tracking planning docs"

Agent Skills Injection

Inject custom skill files into GSD subagent prompts. Skills are read by agents at spawn time, giving them project-specific instructions beyond what CLAUDE.md provides.

Configuration

Add an agent_skills section to .planning/config.json mapping agent types to arrays of skill directory paths (relative to project root):

{
  "agent_skills": {
    "gsd-executor": ["skills/testing-standards", "skills/api-conventions"],
    "gsd-planner": ["skills/architecture-rules"],
    "gsd-verifier": ["skills/acceptance-criteria"]
  }
}

Each path must be a directory containing a SKILL.md file. Paths are validated for safety (no traversal outside project root).

Supported Agent Types

Any GSD agent type can receive skills. Common types:

• gsd-executor -- executes implementation plans
• gsd-planner -- creates phase plans
• gsd-checker -- verifies plan quality
• gsd-verifier -- post-execution verification
• gsd-researcher -- phase research
• gsd-project-researcher -- new-project research
• gsd-debugger -- diagnostic agents
• gsd-codebase-mapper -- codebase analysis
• gsd-advisor -- discuss-phase advisors
• gsd-ui-researcher -- UI design contract creation
• gsd-ui-checker -- UI spec verification
• gsd-roadmapper -- roadmap creation
• gsd-synthesizer -- research synthesis

How It Works

At spawn time, workflows call gsd-sdk query agent-skills <type> (or legacy node gsd-tools.cjs agent-skills <type>) to load configured skills. If skills exist for the agent type, they are injected as an <agent_skills> block in the Task() prompt:

<agent_skills>
Read these user-configured skills:
- @skills/testing-standards/SKILL.md
- @skills/api-conventions/SKILL.md
</agent_skills>

If no skills are configured, the block is omitted (zero overhead).

CLI

Set skills via the CLI:

gsd-sdk query config-set agent_skills.gsd-executor '["skills/my-skill"]'

Feature Flags

Toggle optional capabilities via the features.* config namespace. Feature flags default to false (disabled) — enabling a flag opts into new behavior without affecting existing workflows.

<a id="graphify-settings"></a>

Graphify Settings

Usage

# Enable a feature
gsd-sdk query config-set features.global_learnings true

# Disable a feature
gsd-sdk query config-set features.thinking_partner false

The features.* namespace is a dynamic key pattern — new feature flags can be added without modifying VALID_CONFIG_KEYS. Any key matching features.<name> is accepted by the config system.

Parallelization Settings

Pre-commit hooks and parallel execution: When parallelization is enabled, executor agents commit with --no-verify to avoid build lock contention (e.g., cargo lock fights in Rust projects). The orchestrator validates hooks once after each wave completes. STATE.md writes are protected by file-level locking to prevent concurrent write corruption. If you need hooks to run per-commit, set parallelization.enabled: false.

Git Branching

Strategy Comparison

Template Variables

Example quick-task branching:

"git": {
  "quick_branch_template": "gsd/quick-{num}-{slug}"
}

Merge Options at Milestone Completion

Gate Settings

Control confirmation prompts during workflows.

Safety Settings

Security Settings

Settings for the security enforcement feature (v1.31). All follow the absent = enabled pattern. These keys live under workflow.* in .planning/config.json — matching the shipped template and the runtime reads in workflows/plan-phase.md, workflows/execute-phase.md, workflows/secure-phase.md, and workflows/verify-work.md.

These keys live under workflow.* — that is where the workflows and installer write and read them. Setting them at the top level of config.json is silently ignored.

Decision Coverage Gates (workflow.context_coverage_gate)

When discuss-phase writes implementation decisions into CONTEXT.md <decisions>, two gates ensure those decisions survive the trip into plans and shipped code (issue #2492).

What the gates do

Plan-phase translation gate (BLOCKING). Runs immediately after the existing requirements coverage gate, before plans are committed. For each trackable decision in <decisions>, it checks that the decision id (D-NN) or its text appears in at least one plan's must_haves, truths, or body. A miss surfaces the missing decision by id and refuses to mark the phase planned.

Verify-phase validation gate (NON-BLOCKING). Runs alongside the other verify steps. Searches every shipped artifact (PLAN.md, SUMMARY.md, files modified, recent commit subjects) for each trackable decision. Misses are written to VERIFICATION.md as a warning section but do not flip the overall verification status. The asymmetry is deliberate — by verify time the work is done, and a fuzzy substring miss should not fail an otherwise green phase.

How to write decisions the gates accept

The discuss-phase template already produces D-NN-numbered decisions. The gate is happiest when:

1. Every plan that implements a decision cites the id somewhere — must_haves.truths: ["D-12: bit offsets exposed"] or a D-12: mention in the plan body. Strict id match is the cheapest, deterministic path.
2. Soft phrase matching is a fallback for paraphrases — if a 6+-word slice of the decision text appears verbatim in a plan/summary, it counts.

Opt-outs

A decision is not subject to the gates when any of the following apply:

• It lives under the ### Claude's Discretion heading inside <decisions>.
• It is tagged [informational], [folded], or [deferred] in its bullet (e.g., - **D-08 [informational]:** Naming style for internal helpers).

Use these escape hatches when a decision genuinely doesn't need plan coverage — implementation discretion, future ideas captured for the record, or items already deferred to a later phase.

Review Settings

Configure per-CLI model selection for /gsd-review. When set, overrides the CLI's default model for that reviewer.

Example

{
  "review": {
    "models": {
      "gemini": "gemini-2.5-pro",
      "qwen": "qwen-max"
    }
  }
}

Falls back to each CLI's configured default when a key is absent. Added in v1.35.0 (#1849).

Manager Passthrough Flags

Configure per-step flags that /gsd-manager appends to each dispatched command. This allows customizing how the manager runs discuss, plan, and execute steps without manual flag entry.

Example:

{
  "manager": {
    "flags": {
      "discuss": "--auto",
      "plan": "--skip-research",
      "execute": "--validate"
    }
  }
}

Invalid flag tokens are sanitized and logged as warnings. Only recognized GSD flags are passed through.

Model Profiles

Profile Definitions

Fallback semantics for unlisted agents. The profiles table above covers 18 of 31 shipped agents. Agents without an explicit profile row (gsd-advisor-researcher, gsd-assumptions-analyzer, gsd-security-auditor, gsd-user-profiler, and the nine advanced agents — gsd-ai-researcher, gsd-domain-researcher, gsd-eval-planner, gsd-eval-auditor, gsd-framework-selector, gsd-code-reviewer, gsd-code-fixer, gsd-debug-session-manager, gsd-intel-updater) inherit the runtime default model for the selected profile. To pin a specific model for any of these agents, use model_overrides (next section) — model_overrides accepts any shipped agent name regardless of whether it has a profile row here. The authoritative profile table lives in get-shit-done/bin/lib/model-profiles.cjs; the authoritative 31-agent roster lives in docs/INVENTORY.md.

Per-Agent Overrides

Override specific agents without changing the entire profile:

{
  "model_profile": "balanced",
  "model_overrides": {
    "gsd-executor": "opus",
    "gsd-planner": "haiku"
  }
}

Valid override values: opus, sonnet, haiku, inherit, or any fully-qualified model ID (e.g., "openai/o3", "google/gemini-2.5-pro").

model_overrides can be set in either .planning/config.json (per-project) or ~/.gsd/defaults.json (global). Per-project entries win on conflict and non-conflicting global entries are preserved, so you can tune a single agent's model in one repo without re-setting global defaults. This applies uniformly across Claude Code, Codex, OpenCode, Kilo, and the other supported runtimes. On Codex and OpenCode, the resolved model is embedded into each agent's static config at install time — spawn_agent and OpenCode's task interface do not accept an inline model parameter, so running gsd install <runtime> after editing model_overrides is required for the change to take effect. See issue #2256.

Per-Phase-Type Models (models) — added in v1.40

Express tuning at the phase level (planning, research, execution, verification) without learning the agent taxonomy. Added in #3023.

model_overrides is per-agent (precise but verbose; you have to know that gsd-codebase-mapper is research and gsd-doc-writer is execution). The models block lets you say "Opus for planning and execution, Sonnet for the rest" in two lines:

{
  "model_profile": "balanced",
  "models": {
    "planning": "opus",
    "discuss": "opus",
    "research": "sonnet",
    "execution": "opus",
    "verification": "sonnet",
    "completion": "sonnet"
  },
  "model_overrides": {
    "gsd-codebase-mapper": "haiku"
  }
}

Phase-type → agent mapping

discuss and completion are accepted by the schema for forward compatibility; setting them today is a no-op until a subagent maps to them.

Resolution precedence (highest → lowest)

1. model_overrides[<agent>]              ← per-agent; full IDs; targeted exception
2. dynamic_routing.tier_models[<tier>]   ← when enabled (see §Dynamic Routing)
3. models[<phase_type>]                  ← coarse phase-level tier (this section)
4. model_profile (per-agent col)         ← global tier strategy
5. Runtime default                       ← when nothing else applies

The five layers compose top-down: model_profile is the base tier, models[<phase_type>] overrides at the phase level, dynamic_routing (when enabled) escalates per-attempt on soft failure, model_overrides[<agent>] carves per-agent exceptions at the top, and the runtime default applies when nothing else does. In the example above, all five research agents resolve to sonnet except gsd-codebase-mapper, which the per-agent override pins to haiku. dynamic_routing is disabled by default — when off (enabled: false or block omitted), this section's behavior is unchanged from today.

Accepted values

models.<phase_type> accepts only tier aliases:

If you need a fully-qualified model ID ("openai/gpt-5", "google/gemini-2.5-pro"), use model_overrides per agent instead. models.* is intentionally tier-only so the runtime-aware mapping stays correct on Codex / OpenCode / Gemini CLI installs.

When to use which

Mix freely — the precedence rule above resolves any overlap deterministically.

Validation

config-set rejects unknown phase-types:

$ gsd config-set models.deployment opus
Error: 'models.deployment' is not a valid config key

# Valid:
$ gsd config-set models.research sonnet

Direct edits to .planning/config.json are looser — the resolver simply ignores values it doesn't recognize and falls through to the profile tier — so a typo doesn't silently break tier resolution.

Dynamic Routing with Failure-Tier Escalation (dynamic_routing) — added in v1.40

Start cheap, escalate only when the agent fails the gate. Added in #3024.

dynamic_routing lets you pay for the cheap tier by default and only escalate to the more expensive tier when the orchestrator detects a soft failure (verification inconclusive, plan-check FLAG, etc.).

{
  "dynamic_routing": {
    "enabled": true,
    "tier_models": {
      "light":    "haiku",
      "standard": "sonnet",
      "heavy":    "opus"
    },
    "escalate_on_failure": true,
    "max_escalations": 1
  }
}

Agent default tiers

Each agent in MODEL_PROFILES declares one of three default tiers. The resolver picks tier_models[default_tier] for the first attempt.

Escalation flow

1. Orchestrator spawns agent → resolver returns tier_models[default_tier]
2. Soft failure?
   ├─ no → ✓ done (cheap path)
   └─ yes → orchestrator re-spawns at attempt+1
            → resolver returns tier_models[next_tier_up]
            → cap at max_escalations
3. Hard failure (exception/crash) → bypass escalation, surface immediately

If dynamic_routing.escalate_on_failure: false, soft failures do not advance the tier — every respawn keeps using tier_models[default_tier] regardless of the attempt counter. The kill-switch overrides the soft-failure branch above.

light → standard → heavy → heavy (heavy stays at heavy; can't go further).

Resolution precedence (highest → lowest)

1. model_overrides[<agent>] — full IDs accepted; targeted exception
2. dynamic_routing.tier_models[<tier>] (when enabled: true)
3. models[<phase_type>] — coarse phase-level (#3023)
4. model_profile — per-agent column from active profile
5. Runtime default

The dynamic_routing block is disabled by default — enabled: false (or omitting the block) preserves today's static resolution exactly.

Settings

When to use which

dynamic_routing is structurally a cost lever: you pay Opus rates only for the hard cases that warrant Opus. Compose with model_overrides for per-agent exceptions (override always wins).

Non-Claude Runtimes (Codex, OpenCode, Gemini CLI, Kilo)

When GSD is installed for a non-Claude runtime, the installer automatically sets resolve_model_ids: "omit" in ~/.gsd/defaults.json. This causes GSD to return an empty model parameter for all agents, so each agent uses whatever model the runtime is configured with. No additional setup is needed for the default case.

If you want different agents to use different models, use model_overrides with fully-qualified model IDs that your runtime recognizes:

{
  "resolve_model_ids": "omit",
  "model_overrides": {
    "gsd-planner": "o3",
    "gsd-executor": "o4-mini",
    "gsd-debugger": "o3",
    "gsd-codebase-mapper": "o4-mini"
  }
}

The intent is the same as the Claude profile tiers -- use a stronger model for planning and debugging (where reasoning quality matters most), and a cheaper model for execution and mapping (where the plan already contains the reasoning).

When to use which approach:

resolve_model_ids values:

Runtime-Aware Profiles (#2517)

When runtime is set, profile tiers (opus/sonnet/haiku) resolve to runtime-native model IDs instead of Claude aliases. This lets a single shared .planning/config.json work cleanly across Claude and Codex.

Built-in tier maps:

Codex example — one config, tiered models, no large model_overrides block:

{
  "runtime": "codex",
  "model_profile": "balanced"
}

This resolves gsd-planner → gpt-5.4 (xhigh), gsd-executor → gpt-5.3-codex (medium), gsd-codebase-mapper → gpt-5.4-mini (medium). The Codex installer embeds model = "..." and model_reasoning_effort = "..." in each generated agent TOML.

Claude example — explicit opt-in resolves to full Claude IDs (no resolve_model_ids: true needed):

{
  "runtime": "claude",
  "model_profile": "quality"
}

Per-runtime overrides — replace one or more tier defaults:

{
  "runtime": "codex",
  "model_profile": "quality",
  "model_profile_overrides": {
    "codex": {
      "opus": "gpt-5-pro",
      "haiku": { "model": "gpt-5-nano", "reasoning_effort": "low" }
    }
  }
}

Precedence (highest to lowest):

1. model_overrides[<agent>] — explicit per-agent ID always wins.
2. Runtime-aware tier resolution (this section) — when runtime is set and profile is not inherit.
3. resolve_model_ids: "omit" — returns empty string when no runtime is set.
4. Claude-native default — model_profile tier as alias (current default).
5. inherit — propagates literal inherit for Task(model="inherit") semantics.

Backwards compatibility. Setups without runtime set see zero behavior change — every existing config continues to work identically. Codex installs that auto-set resolve_model_ids: "omit" continue to omit the model field unless the user opts in by setting runtime: "codex".

Unknown runtimes. If runtime is set to a value with no built-in tier map and no model_profile_overrides[<runtime>], GSD falls back to the Claude-alias safe default rather than emit a model ID the runtime cannot accept. To support a new runtime, populate model_profile_overrides.<runtime>.{opus,sonnet,haiku} with valid IDs.

Profile Philosophy

Environment Variables

Global Defaults

Save settings as global defaults for future projects:

Location: ~/.gsd/defaults.json

When /gsd-new-project creates a new config.json, it reads global defaults and merges them as the starting configuration. Per-project settings always override globals.