@bhargavvc/sdd-cc 1.35.0 → 1.42.4

package/commands/sdd/discuss-phase.md

@@ -1,7 +1,7 @@
 ---
 name: sdd:discuss-phase
-description: Gather phase context through adaptive questioning before planning. Use --auto to skip interactive questions (Claude picks recommended defaults). Use --chain for interactive discuss followed by automatic plan+execute. Use --power for bulk question generation into a file-based UI (answer at your own pace).
-argument-hint: "<phase> [--auto] [--chain] [--batch] [--analyze] [--text] [--power]"
+description: Gather phase context through adaptive questioning before planning.
+argument-hint: "<phase> [--all] [--auto] [--chain] [--batch] [--analyze] [--text] [--power] [--assumptions]"
 allowed-tools:
   - Read
   - Write
@@ -9,9 +9,10 @@ allowed-tools:
   - Glob
   - Grep
   - AskUserQuestion
-  - Task
+  - Agent
   - mcp__context7__resolve-library-id
   - mcp__context7__query-docs
+requires: [config, phase]
 ---
 
 <objective>
@@ -29,10 +30,8 @@ Extract implementation decisions that downstream agents need — researcher and
 </objective>
 
 <execution_context>
-@~/.claude/sdd/workflows/discuss-phase.md
-@~/.claude/sdd/workflows/discuss-phase-assumptions.md
-@~/.claude/sdd/workflows/discuss-phase-power.md
-@~/.claude/sdd/templates/context.md
+Workflow files are loaded on-demand in the <process> section below — not upfront.
+Do not pre-load any workflow files before reading the mode routing instructions.
 </execution_context>
 
 <runtime_note>
@@ -48,14 +47,22 @@ Context files are resolved in-workflow using `init phase-op` and roadmap/state t
 <process>
 **Mode routing:**
 ```bash
-DISCUSS_MODE=$(node "$HOME/.claude/sdd/bin/sdd-tools.cjs" config-get workflow.discuss_mode 2>/dev/null || echo "discuss")
+DISCUSS_MODE=$(sdd-sdk query config-get workflow.discuss_mode 2>/dev/null || echo "discuss")
 ```
 
-If `DISCUSS_MODE` is `"assumptions"`: Read and execute @~/.claude/sdd/workflows/discuss-phase-assumptions.md end-to-end.
+If `--assumptions` is in $ARGUMENTS:
+Read and execute `~/.claude/sdd/workflows/list-phase-assumptions.md` end-to-end.
+Stop here.
 
-If `DISCUSS_MODE` is `"discuss"` (or unset, or any other value): Read and execute @~/.claude/sdd/workflows/discuss-phase.md end-to-end.
+Otherwise, if `DISCUSS_MODE` is `"assumptions"`:
+Read and execute `~/.claude/sdd/workflows/discuss-phase-assumptions.md` end-to-end.
 
-**MANDATORY:** The execution_context files listed above ARE the instructions. Read the workflow file BEFORE taking any action. The objective and success_criteria sections in this command file are summaries — the workflow file contains the complete step-by-step process with all required behaviors, config checks, and interaction patterns. Do not improvise from the summary.
+Otherwise (`"discuss"` / unset / any other value):
+Read and execute `~/.claude/sdd/workflows/discuss-phase.md` end-to-end.
+
+**MANDATORY:** Read the appropriate workflow file BEFORE taking any action. The objective and success_criteria sections in this command file are summaries — the workflow file contains the complete step-by-step process with all required behaviors, config checks, and interaction patterns. Do not improvise from the summary.
+
+**Lazy loading:** `templates/context.md` is loaded inside the `write_context` step of the active workflow. `discuss-phase-power.md` is loaded inside `discuss-phase.md` when `--power` is detected. Do not load either here.
 </process>
 
 <success_criteria>

package/commands/sdd/docs-update.md

@@ -9,8 +9,9 @@ allowed-tools:
   - Bash
   - Glob
   - Grep
-  - Task
+  - Agent
   - AskUserQuestion
+requires: [update]
 ---
 <objective>
 Generate and update up to 9 documentation files for the current project. Each doc type is written by a sdd-doc-writer subagent that explores the codebase directly — no hallucinated paths, phantom endpoints, or stale signatures.
@@ -43,6 +44,6 @@ Arguments: $ARGUMENTS
 </context>
 
 <process>
-Execute the docs-update workflow from @~/.claude/sdd/workflows/docs-update.md end-to-end.
+Execute end-to-end.
 Preserve all workflow gates (preservation_check, flag handling, wave execution, monorepo dispatch, commit, reporting).
 </process>

package/commands/sdd/eval-review.md

@@ -1,6 +1,6 @@
 ---
 name: sdd:eval-review
-description: Retroactively audit an executed AI phase's evaluation coverage — scores each eval dimension as COVERED/PARTIAL/MISSING and produces an actionable EVAL-REVIEW.md with remediation plan
+description: Audit an executed AI phase's evaluation coverage and produce an EVAL-REVIEW.md remediation plan.
 argument-hint: "[phase number]"
 allowed-tools:
   - Read
@@ -8,8 +8,9 @@ allowed-tools:
   - Bash
   - Glob
   - Grep
-  - Task
+  - Agent
   - AskUserQuestion
+requires: [phase]
 ---
 <objective>
 Conduct a retroactive evaluation coverage audit of a completed AI phase.
@@ -27,6 +28,6 @@ Phase: $ARGUMENTS — optional, defaults to last completed phase.
 </context>
 
 <process>
-Execute @~/.claude/sdd/workflows/eval-review.md end-to-end.
+Execute end-to-end.
 Preserve all workflow gates.
 </process>

package/commands/sdd/execute-phase.md

@@ -1,7 +1,7 @@
 ---
 name: sdd:execute-phase
 description: Execute all plans in a phase with wave-based parallelization
-argument-hint: "<phase-number> [--wave N] [--gaps-only] [--interactive]"
+argument-hint: "<phase-number> [--wave N] [--gaps-only] [--interactive] [--tdd]"
 allowed-tools:
   - Read
   - Write
@@ -9,9 +9,10 @@ allowed-tools:
   - Glob
   - Grep
   - Bash
-  - Task
+  - Agent
   - TodoWrite
   - AskUserQuestion
+requires: [phase, verify-work]
 ---
 <objective>
 Execute all plans in a phase using wave-based parallel execution.
@@ -54,10 +55,10 @@ Phase: $ARGUMENTS
 - If none of these tokens appear, run the standard full-phase execution flow with no flag-specific filtering
 - Do not infer that a flag is active just because it is documented in this prompt
 
-Context files are resolved inside the workflow via `sdd-tools init execute-phase` and per-subagent `<files_to_read>` blocks.
+Context files are resolved inside the workflow via `sdd-sdk query init.execute-phase` and per-subagent `<files_to_read>` blocks.
 </context>
 
 <process>
-Execute the execute-phase workflow from @~/.claude/sdd/workflows/execute-phase.md end-to-end.
+Execute end-to-end.
 Preserve all workflow gates (wave execution, checkpoint handling, verification, state updates, routing).
 </process>

package/commands/sdd/explore.md

@@ -7,7 +7,7 @@ allowed-tools:
   - Bash
   - Grep
   - Glob
-  - Task
+  - Agent
   - AskUserQuestion
 ---
 <objective>
@@ -15,7 +15,7 @@ Open-ended Socratic ideation session. Guides the developer through exploring an
 probing questions, optionally spawns research, then routes outputs to the appropriate SDD
 artifacts (notes, todos, seeds, research questions, requirements, or new phases).
 
-Accepts an optional topic argument: `/sdd-explore authentication strategy`
+Accepts an optional topic argument: `/sdd:explore authentication strategy`
 </objective>
 
 <execution_context>
@@ -23,5 +23,5 @@ Accepts an optional topic argument: `/sdd-explore authentication strategy`
 </execution_context>
 
 <process>
-Execute the explore workflow from @~/.claude/sdd/workflows/explore.md end-to-end.
+Execute end-to-end.
 </process>

package/commands/sdd/extract-learnings.md

@@ -0,0 +1,23 @@
+---
+name: sdd:extract-learnings
+description: Extract decisions, lessons, patterns, and surprises from completed phase artifacts
+argument-hint: <phase-number>
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+  - Glob
+  - Agent
+type: prompt
+requires: [phase]
+---
+<objective>
+Extract structured learnings from completed phase artifacts (PLAN.md, SUMMARY.md, VERIFICATION.md, UAT.md, STATE.md) into a LEARNINGS.md file that captures decisions, lessons learned, patterns discovered, and surprises encountered.
+</objective>
+
+<execution_context>
+@~/.claude/sdd/workflows/extract-learnings.md
+</execution_context>
+
+Execute the extract-learnings workflow from @~/.claude/sdd/workflows/extract-learnings.md end-to-end.

package/commands/sdd/fast.md

@@ -9,6 +9,7 @@ allowed-tools:
   - Bash
   - Grep
   - Glob
+requires: [config, quick]
 ---
 
 <objective>
@@ -16,8 +17,8 @@ Execute a trivial task directly in the current context without spawning subagent
 or generating PLAN.md files. For tasks too small to justify planning overhead:
 typo fixes, config changes, small refactors, forgotten commits, simple additions.
 
-This is NOT a replacement for /sdd-quick — use /sdd-quick for anything that
-needs research, multi-step planning, or verification. /sdd-fast is for tasks
+This is NOT a replacement for /sdd:quick — use /sdd:quick for anything that
+needs research, multi-step planning, or verification. /sdd:fast is for tasks
 you could describe in one sentence and execute in under 2 minutes.
 </objective>
 
@@ -26,5 +27,5 @@ you could describe in one sentence and execute in under 2 minutes.
 </execution_context>
 
 <process>
-Execute the fast workflow from @~/.claude/sdd/workflows/fast.md end-to-end.
+Execute end-to-end.
 </process>

package/commands/sdd/forensics.md

@@ -1,7 +1,7 @@
 ---
 type: prompt
 name: sdd:forensics
-description: Post-mortem investigation for failed SDD workflows — analyzes git history, artifacts, and state to diagnose what went wrong
+description: Post-mortem investigation for failed SDD workflows — diagnoses what went wrong.
 argument-hint: "[problem description]"
 allowed-tools:
   - Read
@@ -9,6 +9,7 @@ allowed-tools:
   - Bash
   - Grep
   - Glob
+requires: [phase, progress, update]
 ---
 
 <objective>
@@ -36,7 +37,7 @@ Output: Forensic report saved to `.planning/forensics/`, presented inline, with
 </context>
 
 <process>
-Read and execute the forensics workflow from @~/.claude/sdd/workflows/forensics.md end-to-end.
+Execute end-to-end.
 </process>
 
 <success_criteria>

package/commands/sdd/graphify.md

@@ -0,0 +1,199 @@
+---
+name: sdd:graphify
+description: "Build, query, and inspect the project knowledge graph in .planning/graphs/"
+argument-hint: "[build|query <term>|status|diff]"
+allowed-tools:
+  - Read
+  - Bash
+requires: [config, fast, phase, update]
+---
+
+**STOP -- DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's command system. Using the Read tool on this file wastes tokens. Begin executing Step 0 immediately.**
+
+**CJS-only (graphify):** `graphify` subcommands are not registered on `sdd-sdk query`. Use `node $HOME/.claude/sdd/bin/sdd-tools.cjs graphify …` as documented in this command and in `docs/CLI-TOOLS.md`. Other tooling may still use `sdd-sdk query` where a handler exists.
+
+## Step 0 -- Banner
+
+**Before ANY tool calls**, display this banner:
+
+```
+SDD > GRAPHIFY
+```
+
+Then proceed to Step 1.
+
+## Step 1 -- Config Gate
+
+Check if graphify is enabled by reading `.planning/config.json` directly using the Read tool.
+
+**DO NOT use the sdd-tools config get-value command** -- it hard-exits on missing keys.
+
+1. Read `.planning/config.json` using the Read tool
+2. If the file does not exist: display the disabled message below and **STOP**
+3. Parse the JSON content. Check if `config.graphify && config.graphify.enabled === true`
+4. If `graphify.enabled` is NOT explicitly `true`: display the disabled message below and **STOP**
+5. If `graphify.enabled` is `true`: proceed to Step 2
+
+**Disabled message:**
+
+```
+SDD > GRAPHIFY
+
+Knowledge graph is disabled. To activate:
+
+  node $HOME/.claude/sdd/bin/sdd-tools.cjs config-set graphify.enabled true
+
+Then run /sdd:graphify build to create the initial graph.
+```
+
+---
+
+## Step 2 -- Parse Argument
+
+Parse `$ARGUMENTS` to determine the operation mode:
+
+| Argument | Action |
+|----------|--------|
+| `build` | Run inline build (Step 3) |
+| `query <term>` | Run inline query (Step 2a) |
+| `status` | Run inline status check (Step 2b) |
+| `diff` | Run inline diff check (Step 2c) |
+| No argument or unknown | Show usage message |
+
+**Usage message** (shown when no argument or unrecognized argument):
+
+```
+SDD > GRAPHIFY
+
+Usage: /sdd:graphify <mode>
+
+Modes:
+  build           Build or rebuild the knowledge graph
+  query <term>    Search the graph for a term
+  status          Show graph freshness and statistics
+  diff            Show changes since last build
+```
+
+### Step 2a -- Query
+
+Run:
+
+```bash
+node $HOME/.claude/sdd/bin/sdd-tools.cjs graphify query <term>
+```
+
+Parse the JSON output and display results:
+- If the output contains `"disabled": true`, display the disabled message from Step 1 and **STOP**
+- If the output contains `"error"` field, display the error message and **STOP**
+- If no nodes found, display: `No graph matches for '<term>'. Try /sdd:graphify build to create or rebuild the graph.`
+- Otherwise, display matched nodes grouped by type, with edge relationships and confidence tiers (EXTRACTED/INFERRED/AMBIGUOUS)
+
+**STOP** after displaying results. Do not spawn an agent.
+
+### Step 2b -- Status
+
+Run:
+
+```bash
+node $HOME/.claude/sdd/bin/sdd-tools.cjs graphify status
+```
+
+Parse the JSON output and display:
+- If `exists: false`, display the message field
+- Otherwise show last build time, node/edge/hyperedge counts, and STALE or FRESH indicator
+- If `built_at_commit` is non-null, also display a `Source commit:` line:
+  - `commit_stale === false` (rebuilt at HEAD): `Source commit: <built_at_commit> (current)`
+  - `commit_stale === true` (graph behind HEAD): `Source commit: <built_at_commit> (<commits_behind> commits behind HEAD)`
+  - `commit_stale === null` (unreachable commit / no git): `Source commit: <built_at_commit> (freshness unknown)`
+- If `built_at_commit` is null (pre-graphify-v0.7 graph), omit the source-commit line entirely — do not render "Source commit: unknown"
+
+The mtime-based STALE/FRESH flag and the commit-based `commit_stale` measure
+different things and can disagree (e.g., a CI-built graph rebuilt minutes ago
+against an old checkout reads as FRESH on mtime but `commit_stale: true`).
+Surface both so the agent can choose.
+
+**STOP** after displaying status. Do not spawn an agent.
+
+### Step 2c -- Diff
+
+Run:
+
+```bash
+node $HOME/.claude/sdd/bin/sdd-tools.cjs graphify diff
+```
+
+Parse the JSON output and display:
+- If `no_baseline: true`, display the message field
+- Otherwise show node and edge change counts (added/removed/changed)
+
+If no snapshot exists, suggest running `build` twice (first to create, second to generate a diff baseline).
+
+**STOP** after displaying diff. Do not spawn an agent.
+
+---
+
+## Step 3 -- Build (Inline)
+
+Run the pre-flight check first:
+
+```bash
+node "$HOME/.claude/sdd/bin/sdd-tools.cjs" graphify build
+```
+
+Parse the JSON output:
+- If `disabled: true`: display the disabled message from Step 1 and **STOP**
+- If `error`: display the error message and **STOP**
+- If `action: "spawn_agent"`: pre-flight passed -- proceed with the inline build below
+
+(The `spawn_agent` action name is historical. The skill now performs the build inline because graphify v0.7+ split the build into a fast AST-extraction phase and a separate clustering + report-write phase. Sub-agent isolation kept the cached extraction phase alive but SIGTERM'd the post-extraction phase when the agent exited, leaving the cache populated but no `graph.json` artifacts written. The CLI still emits the `spawn_agent` signal so external callers and tests keep working.)
+
+Display:
+
+```text
+SDD > Building knowledge graph...
+```
+
+Run the build, copy artifacts, write the diff snapshot, and report the summary in a single foreground Bash call so the whole pipeline survives to completion. Use a `timeout` of `600000` ms (10 minutes), which covers the `graphify.build_timeout` ceiling (default 300 s) with margin:
+
+```bash
+graphify update . \
+  && cp graphify-out/graph.json .planning/graphs/graph.json \
+  && cp graphify-out/graph.html .planning/graphs/graph.html \
+  && cp graphify-out/GRAPH_REPORT.md .planning/graphs/GRAPH_REPORT.md \
+  && node "$HOME/.claude/sdd/bin/sdd-tools.cjs" graphify build snapshot \
+  && node "$HOME/.claude/sdd/bin/sdd-tools.cjs" graphify status
+```
+
+Do NOT pass `run_in_background: true`. Typical builds complete in 15-60 seconds and the entire chain must run foreground.
+
+If the chain fails (non-zero exit):
+- Display: `## GRAPHIFY BUILD FAILED` followed by the captured stderr
+- Do NOT delete `.planning/graphs/` -- the prior valid graph remains available
+- **STOP**
+
+If the chain succeeds:
+- Parse the trailing `graphify status` JSON
+- Display: `## GRAPHIFY BUILD COMPLETE` with the node, edge, and hyperedge counts
+
+---
+
+## MVP-Mode Node Rendering
+
+**MVP-mode rendering.** When a phase has `**Mode:** mvp` in ROADMAP.md (resolved via `sdd-sdk query roadmap.get-phase --pick mode`), render its graph node with two distinct visual signals:
+
+1. **Distinct fill color.** Use `#22c55e` (green) for MVP-mode phase nodes. Standard phases keep the default fill color. Two-channel signaling (color + label) handles color-blind and grayscale renders.
+2. **`MVP` label suffix.** Append ` (MVP)` to the node's label text. Example: a phase originally labeled `Phase 1: User Auth` renders as `Phase 1: User Auth (MVP)`.
+
+Both signals fire together — never just one. Per PRD Q5 decision, the goal is unambiguous visual distinction in any render context.
+
+When the phase mode is null/absent, render with the standard color and label — no behavioral change for non-MVP phases.
+
+---
+
+## Anti-Patterns
+
+1. DO NOT spawn an agent for any operation -- build, query, status, and diff all run inline. Sub-agent isolation terminates background bash when the agent exits, which previously truncated graphify builds mid-write and left only the cache populated (#3166).
+2. DO NOT pass `run_in_background: true` for the build chain -- the operation is fast and must complete in the foreground.
+3. DO NOT modify graph files directly -- always go through `graphify update .` and the snapshot CLI.
+4. DO NOT skip the config gate check.
+5. DO NOT use `sdd-tools config get-value` for the config gate -- it exits on missing keys.

package/commands/sdd/health.md

@@ -1,15 +1,24 @@
 ---
 name: sdd:health
 description: Diagnose planning directory health and optionally repair issues
-argument-hint: [--repair]
+argument-hint: "[--repair] [--context]"
 allowed-tools:
   - Read
   - Bash
   - Write
   - AskUserQuestion
+requires: [thread]
 ---
 <objective>
 Validate `.planning/` directory integrity and report actionable issues. Checks for missing files, invalid configurations, inconsistent state, and orphaned plans.
+
+`--context` runs an orthogonal check: the running session's context utilization. The workflow asks for the model's tokensUsed + contextWindow, calls `sdd-sdk query validate.context`, and renders one of three states:
+
+| Utilization | State    | Action                                                |
+|-------------|----------|-------------------------------------------------------|
+| < 60%       | healthy  | no action — context is comfortable                    |
+| 60% – 70%   | warning  | recommend `/sdd:thread` to start fresh                |
+| ≥ 70%       | critical | reasoning quality may degrade past the fracture point |
 </objective>
 
 <execution_context>
@@ -17,6 +26,6 @@ Validate `.planning/` directory integrity and report actionable issues. Checks f
 </execution_context>
 
 <process>
-Execute the health workflow from @~/.claude/sdd/workflows/health.md end-to-end.
-Parse --repair flag from arguments and pass to workflow.
+Execute end-to-end.
+Parse `--repair` and `--context` flags from arguments and pass to workflow.
 </process>

package/commands/sdd/help.md

@@ -19,6 +19,6 @@ Output ONLY the reference content below. Do NOT add:
 </execution_context>
 
 <process>
-Output the complete SDD command reference from @~/.claude/sdd/workflows/help.md.
+Execute end-to-end.
 Display the reference content directly — no additions or modifications.
 </process>

package/commands/sdd/import.md

@@ -1,7 +1,7 @@
 ---
 name: sdd:import
 description: Ingest external plans with conflict detection against project decisions before writing anything.
-argument-hint: "--from <filepath>"
+argument-hint: "--from <filepath> | --from-sdd2"
 allowed-tools:
   - Read
   - Write
@@ -10,21 +10,21 @@ allowed-tools:
   - Glob
   - Grep
   - AskUserQuestion
-  - Task
+  - Agent
 ---
 
 <objective>
 Import external plan files into the SDD planning system with conflict detection against PROJECT.md decisions.
 
 - **--from**: Import an external plan file, detect conflicts, write as SDD PLAN.md, validate via sdd-plan-checker.
-
-Future: `--prd` mode for PRD extraction is planned for a follow-up PR.
+- **--from-sdd2**: Reverse-migrate a SDD-2 project (`.sdd/` directory) back to SDD v1 (`.planning/`) format. Runs `sdd-tools.cjs from-sdd2`. Pass `--path <dir>` to migrate a project at a different path.
 </objective>
 
 <execution_context>
 @~/.claude/sdd/workflows/import.md
 @~/.claude/sdd/references/ui-brand.md
 @~/.claude/sdd/references/gate-prompts.md
+@~/.claude/sdd/references/doc-conflict-engine.md
 </execution_context>
 
 <context>
@@ -32,5 +32,10 @@ $ARGUMENTS
 </context>
 
 <process>
-Execute the import workflow end-to-end.
+If `--from-sdd2` is in $ARGUMENTS:
+Run: `node "$HOME/.claude/sdd/bin/sdd-tools.cjs" from-sdd2`
+Pass `--path <dir>` if provided. Present the migration result to the user.
+Stop here (do not run the standard import workflow).
+
+Otherwise, execute the import workflow end-to-end.
 </process>

package/commands/sdd/inbox.md

@@ -0,0 +1,39 @@
+---
+name: sdd:inbox
+description: Triage and review open GitHub issues and PRs against project templates and contribution guidelines.
+argument-hint: "[--issues] [--prs] [--label] [--close-incomplete] [--repo owner/repo]"
+allowed-tools:
+  - Read
+  - Bash
+  - Write
+  - Grep
+  - Glob
+  - AskUserQuestion
+requires: [review]
+---
+<objective>
+One-command triage of the project's GitHub inbox. Fetches all open issues and PRs,
+reviews each against the corresponding template requirements (feature, enhancement,
+bug, chore, fix PR, enhancement PR, feature PR), reports completeness and compliance,
+and optionally applies labels or closes non-compliant submissions.
+
+**Flow:** Detect repo → Fetch open issues + PRs → Classify each by type → Review against template → Report findings → Optionally act (label, comment, close)
+</objective>
+
+<execution_context>
+@~/.claude/sdd/workflows/inbox.md
+</execution_context>
+
+<context>
+**Flags:**
+- `--issues` — Review only issues (skip PRs)
+- `--prs` — Review only PRs (skip issues)
+- `--label` — Auto-apply recommended labels after review
+- `--close-incomplete` — Close issues/PRs that fail template compliance (with comment explaining why)
+- `--repo owner/repo` — Override auto-detected repository (defaults to current git remote)
+</context>
+
+<process>
+Execute end-to-end.
+Parse flags from arguments and pass to workflow.
+</process>

package/commands/sdd/ingest-docs.md

@@ -0,0 +1,42 @@
+---
+name: sdd:ingest-docs
+description: Bootstrap or merge a .planning/ setup from existing ADRs, PRDs, SPECs, and docs in a repo.
+argument-hint: "[path] [--mode new|merge] [--manifest <file>] [--resolve auto|interactive]"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - Agent
+---
+
+<objective>
+Build the full `.planning/` setup (or merge into an existing one) from multiple pre-existing planning documents — ADRs, PRDs, SPECs, DOCs — in one pass.
+
+- **Net-new bootstrap** (`--mode new`, default when `.planning/` is absent): produces PROJECT.md + REQUIREMENTS.md + ROADMAP.md + STATE.md from synthesized doc content, delegating final generation to `sdd-roadmapper`.
+- **Merge into existing** (`--mode merge`, default when `.planning/` is present): appends phases and requirements derived from the ingested docs; hard-blocks any contradiction with existing locked decisions.
+
+Auto-synthesizes most conflicts using the precedence rule `ADR > SPEC > PRD > DOC` (overridable via manifest). Surfaces unresolved cases in `.planning/INGEST-CONFLICTS.md` with three buckets: auto-resolved, competing-variants, unresolved-blockers. The BLOCKER gate from the shared conflict engine prevents any destination file from being written when unresolved contradictions exist.
+
+**Inputs:** directory-convention discovery (`docs/adr/`, `docs/prd/`, `docs/specs/`, `docs/rfc/`, root-level `{ADR,PRD,SPEC,RFC}-*.md`), or an explicit `--manifest <file>` YAML listing `{path, type, precedence?}` per doc.
+
+**v1 constraints:** hard cap of 50 docs per invocation; `--resolve interactive` is reserved for a future release.
+</objective>
+
+<execution_context>
+@~/.claude/sdd/workflows/ingest-docs.md
+@~/.claude/sdd/references/ui-brand.md
+@~/.claude/sdd/references/gate-prompts.md
+@~/.claude/sdd/references/doc-conflict-engine.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+Execute the ingest-docs workflow end-to-end. Preserve all approval gates (discovery, conflict report, routing) and the BLOCKER safety rule.
+</process>

package/commands/sdd/manager.md

@@ -1,6 +1,7 @@
 ---
 name: sdd:manager
 description: Interactive command center for managing multiple phases from one terminal
+argument-hint: "[--analyze-deps]"
 allowed-tools:
   - Read
   - Write
@@ -9,7 +10,8 @@ allowed-tools:
   - Grep
   - AskUserQuestion
   - Skill
-  - Task
+  - Agent
+requires: [phase]
 ---
 <objective>
 Single-terminal command center for managing a milestone. Shows a dashboard of all phases with visual status indicators, recommends optimal next actions, and dispatches work — discuss runs inline, plan/execute run as background agents.
@@ -31,10 +33,13 @@ Designed for power users who want to parallelize work across phases from one ter
 <context>
 No arguments required. Requires an active milestone with ROADMAP.md and STATE.md.
 
-Project context, phase list, dependencies, and recommendations are resolved inside the workflow using `sdd-tools.cjs init manager`. No upfront context loading needed.
+Project context, phase list, dependencies, and recommendations are resolved inside the workflow using `sdd-sdk query init.manager`. No upfront context loading needed.
 </context>
 
 <process>
-Execute the manager workflow from @~/.claude/sdd/workflows/manager.md end-to-end.
+If `--analyze-deps` is in $ARGUMENTS:
+Read and execute `~/.claude/sdd/workflows/analyze-dependencies.md` end-to-end.
+
+Execute end-to-end.
 Maintain the dashboard refresh loop until the user exits or all phases complete.
 </process>