v1.36.0 Features

108. Plan Bounce

Command: /gsd-plan-phase N --bounce

Purpose: After plans pass the checker, optionally refine them through an external script (a second AI, a linter, a custom validator). The bounce step backs up each plan, runs the script, validates YAML frontmatter integrity on the result, re-runs the plan checker, and restores the original if anything fails.

Requirements:

• REQ-BOUNCE-01: --bounce flag or workflow.plan_bounce: true activates the step; --skip-bounce always disables it
• REQ-BOUNCE-02: workflow.plan_bounce_script must point to a valid executable; missing script produces a warning and skips
• REQ-BOUNCE-03: Each plan is backed up to *-PLAN.pre-bounce.md before the script runs
• REQ-BOUNCE-04: Bounced plans with broken YAML frontmatter or that fail the plan checker are restored from backup
• REQ-BOUNCE-05: workflow.plan_bounce_passes (default: 2) controls how many refinement passes the script receives

Configuration: workflow.plan_bounce, workflow.plan_bounce_script, workflow.plan_bounce_passes

---

109. External Code Review Command

Command: /gsd-ship (enhanced)

Purpose: Before the manual review step in /gsd-ship, automatically run an external code review command if configured. The command receives the diff and phase context via stdin and returns a JSON verdict (APPROVED or REVISE). Falls through to the existing manual review flow regardless of outcome.

Requirements:

• REQ-EXTREVIEW-01: workflow.code_review_command must be set to a command string; null means skip
• REQ-EXTREVIEW-02: Diff is generated against BASE_BRANCH with --stat summary included
• REQ-EXTREVIEW-03: Review prompt is piped via stdin (never shell-interpolated)
• REQ-EXTREVIEW-04: 120-second timeout; stderr captured on failure
• REQ-EXTREVIEW-05: JSON output parsed for verdict, confidence, summary, issues fields

Configuration: workflow.code_review_command

---

110. Cross-AI Execution Delegation

Command: /gsd-execute-phase N --cross-ai

Purpose: Delegate individual plans to an external AI runtime for execution. Plans with cross_ai: true in their frontmatter (or all plans when --cross-ai is used) are sent to the configured command via stdin. Successfully handled plans are removed from the normal executor queue.

Requirements:

• REQ-CROSSAI-01: --cross-ai forces all plans through cross-AI; --no-cross-ai disables it
• REQ-CROSSAI-02: workflow.cross_ai_execution: true and plan frontmatter cross_ai: true required for per-plan activation
• REQ-CROSSAI-03: Task prompt is piped via stdin to prevent injection
• REQ-CROSSAI-04: Dirty working tree produces a warning before execution
• REQ-CROSSAI-05: On failure, user chooses: retry, skip (fall back to normal executor), or abort

Configuration: workflow.cross_ai_execution, workflow.cross_ai_command, workflow.cross_ai_timeout

---

111. Architectural Responsibility Mapping

Command: /gsd-plan-phase (enhanced research step)

Purpose: During phase research, the phase-researcher now maps each capability to its architectural tier owner (browser, frontend server, API, CDN/static, database). The planner cross-references tasks against this map, and the plan-checker enforces tier compliance as Dimension 7c.

Requirements:

• REQ-ARM-01: Phase researcher produces an Architectural Responsibility Map table in RESEARCH.md (Step 1.5)
• REQ-ARM-02: Planner sanity-checks task-to-tier assignments against the map
• REQ-ARM-03: Plan checker validates tier compliance as Dimension 7c (WARNING for general mismatches, BLOCKER for security-sensitive ones)

Produces: ## Architectural Responsibility Map section in \{phase\}-RESEARCH.md

---

112. Extract Learnings

Command: /gsd-extract-learnings N

Purpose: Extract structured knowledge from completed phase artifacts. Reads PLAN.md and SUMMARY.md (required) plus VERIFICATION.md, UAT.md, and STATE.md (optional) to produce four categories of learnings: decisions, lessons, patterns, and surprises. Optionally captures each item to an external knowledge base via capture_thought tool.

Requirements:

• REQ-LEARN-01: Requires PLAN.md and SUMMARY.md; exits with clear error if missing
• REQ-LEARN-02: Each extracted item includes source attribution (artifact and section)
• REQ-LEARN-03: If capture_thought tool is available, captures items with source, project, and phase metadata
• REQ-LEARN-04: If capture_thought is unavailable, completes successfully and logs that external capture was skipped
• REQ-LEARN-05: Running twice overwrites the previous LEARNINGS.md

Produces: \{phase\}-LEARNINGS.md with YAML frontmatter (phase, project, counts per category, missing_artifacts)

Optional integration — capture_thought: capture_thought is a convention, not a bundled tool. GSD does not ship one and does not require one. The workflow checks whether any MCP server in the current session exposes a tool named capture_thought and, if so, calls it once per extracted learning with the signature below. If no such tool is present, the step is skipped silently and LEARNINGS.md remains the primary output.

Expected tool signature:

capture_thought({
  category: "decision" | "lesson" | "pattern" | "surprise",
  phase: <phase_number>,
  content: <learning_text>,
  source: <artifact_name>
})

Users who run a memory / knowledge-base MCP server (for example, ExoCortex-style servers, claude-mem, or mem0-style servers) can implement this tool name to have learnings routed into their knowledge base automatically with project, phase, and source metadata. Everyone else can use /gsd-extract-learnings without any extra setup — the LEARNINGS.md artifact is the feature.

---

113. SDK Workstream Support

Command: gsd-sdk init @prd.md --ws my-workstream

Purpose: Route all SDK .planning/ paths to .planning/workstreams/<name>/, enabling multi-workstream projects without "Project already exists" errors. The --ws flag validates the workstream name and propagates to all subsystems (tools, config, context engine).

Requirements:

• REQ-WS-01: --ws <name> routes all .planning/ paths to .planning/workstreams/<name>/
• REQ-WS-02: Without --ws, behavior is unchanged (flat mode)
• REQ-WS-03: Name validated to alphanumeric, hyphens, underscores, and dots only
• REQ-WS-04: Config resolves from workstream path first, falls back to root .planning/config.json

---

114. Context-Window-Aware Prompt Thinning

Purpose: Reduce static prompt overhead by ~40% for models with context windows under 200K tokens. Extended examples and anti-pattern lists are extracted from agent definitions into reference files loaded on demand via @ required_reading.

Requirements:

• REQ-THIN-01: When CONTEXT_WINDOW < 200000, executor and planner agent prompts omit inline examples
• REQ-THIN-02: Extracted content lives in references/executor-examples.md and references/planner-antipatterns.md
• REQ-THIN-03: Standard (200K-500K) and enriched (500K+) tiers are unaffected
• REQ-THIN-04: Core rules and decision logic remain inline; only verbose examples are extracted

Reference files: executor-examples.md, planner-antipatterns.md

---

115. Configurable CLAUDE.md Path

Purpose: Allow projects to store their CLAUDE.md in a non-root location. The claude_md_path config key controls where /gsd-profile-user and related commands write the generated CLAUDE.md file.

Requirements:

• REQ-CMDPATH-01: claude_md_path defaults to ./CLAUDE.md
• REQ-CMDPATH-02: Profile generation commands read the path from config and write to the specified location
• REQ-CMDPATH-03: Relative paths are resolved from the project root

Configuration: claude_md_path

---

116. TDD Pipeline Mode

Purpose: Opt-in TDD (red-green-refactor) as a first-class phase execution mode. When enabled, the planner aggressively selects type: tdd for eligible tasks and the executor enforces RED/GREEN/REFACTOR gate sequence with fail-fast on unexpected GREEN before RED.

Requirements:

• REQ-TDD-01: workflow.tdd_mode config key (boolean, default false)
• REQ-TDD-02: When enabled, planner applies TDD heuristics from references/tdd.md to all eligible tasks (business logic, APIs, validations, algorithms, state machines)
• REQ-TDD-03: Executor enforces gate sequence for type: tdd plans — RED commit (test(...)) must precede GREEN commit (feat(...))
• REQ-TDD-04: Executor fails fast if tests pass unexpectedly during RED phase (feature already exists or test is wrong)
• REQ-TDD-05: End-of-phase collaborative review checkpoint verifies gate compliance across all TDD plans (advisory, non-blocking)
• REQ-TDD-06: Gate violations surfaced in SUMMARY.md under ## TDD Gate Compliance section

Configuration: workflow.tdd_modeReference files: tdd.md, checkpoints.md