@bhargavvc/sdd-cc 1.30.1 → 1.42.3

package/sdd/templates/spec.md

@@ -0,0 +1,307 @@
+# Phase Spec Template
+
+Template for `.planning/phases/XX-name/{phase_num}-SPEC.md` — locks requirements before discuss-phase.
+
+**Purpose:** Capture WHAT a phase delivers and WHY, with enough precision that requirements are falsifiable. discuss-phase reads this file and focuses on HOW to implement (skipping "what/why" questions already answered here).
+
+**Key principle:** Every requirement must be falsifiable — you can write a test or check that proves it was met or not. Vague requirements like "improve performance" are not allowed.
+
+**Downstream consumers:**
+- `discuss-phase` — reads SPEC.md at startup; treats Requirements, Boundaries, and Acceptance Criteria as locked; skips "what/why" questions
+- `sdd-planner` — reads locked requirements to constrain plan scope
+- `sdd-verifier` — uses acceptance criteria as explicit pass/fail checks
+
+---
+
+## File Template
+
+```markdown
+# Phase [X]: [Name] — Specification
+
+**Created:** [date]
+**Ambiguity score:** [score] (gate: ≤ 0.20)
+**Requirements:** [N] locked
+
+## Goal
+
+[One precise sentence — specific and measurable. NOT "improve X" — instead "X changes from A to B".]
+
+## Background
+
+[Current state from codebase — what exists today, what's broken or missing, what triggers this work. Grounded in code reality, not abstract description.]
+
+## Requirements
+
+1. **[Short label]**: [Specific, testable statement.]
+   - Current: [what exists or does NOT exist today]
+   - Target: [what it should become after this phase]
+   - Acceptance: [concrete pass/fail check — how a verifier confirms this was met]
+
+2. **[Short label]**: [Specific, testable statement.]
+   - Current: [what exists or does NOT exist today]
+   - Target: [what it should become after this phase]
+   - Acceptance: [concrete pass/fail check]
+
+[Continue for all requirements. Each must have Current/Target/Acceptance.]
+
+## Boundaries
+
+**In scope:**
+- [Explicit list of what this phase produces]
+- [Each item is a concrete deliverable or behavior]
+
+**Out of scope:**
+- [Explicit list of what this phase does NOT do] — [brief reason why it's excluded]
+- [Adjacent problems excluded from this phase] — [brief reason]
+
+## Constraints
+
+[Performance, compatibility, data volume, dependency, or platform constraints.
+If none: "No additional constraints beyond standard project conventions."]
+
+## Acceptance Criteria
+
+- [ ] [Pass/fail criterion — unambiguous, verifiable]
+- [ ] [Pass/fail criterion]
+- [ ] [Pass/fail criterion]
+
+[Every acceptance criterion must be a checkbox that resolves to PASS or FAIL.
+No "should feel good", "looks reasonable", or "generally works" — those are not checkboxes.]
+
+## Ambiguity Report
+
+| Dimension          | Score | Min  | Status | Notes                              |
+|--------------------|-------|------|--------|------------------------------------|
+| Goal Clarity       |       | 0.75 |        |                                    |
+| Boundary Clarity   |       | 0.70 |        |                                    |
+| Constraint Clarity |       | 0.65 |        |                                    |
+| Acceptance Criteria|       | 0.70 |        |                                    |
+| **Ambiguity**      |       | ≤0.20|        |                                    |
+
+Status: ✓ = met minimum, ⚠ = below minimum (planner treats as assumption)
+
+## Interview Log
+
+[Key decisions made during the Socratic interview. Format: round → question → answer → decision locked.]
+
+| Round | Perspective    | Question summary         | Decision locked                    |
+|-------|----------------|-------------------------|------------------------------------|
+| 1     | Researcher     | [what was asked]        | [what was decided]                 |
+| 2     | Simplifier     | [what was asked]        | [what was decided]                 |
+| 3     | Boundary Keeper| [what was asked]        | [what was decided]                 |
+
+[If --auto mode: note "auto-selected" decisions with the reasoning Claude used.]
+
+---
+
+*Phase: [XX-name]*
+*Spec created: [date]*
+*Next step: /sdd:discuss-phase [X] — implementation decisions (how to build what's specified above)*
+```
+
+<good_examples>
+
+**Example 1: Feature addition (Post Feed)**
+
+```markdown
+# Phase 3: Post Feed — Specification
+
+**Created:** 2025-01-20
+**Ambiguity score:** 0.12
+**Requirements:** 4 locked
+
+## Goal
+
+Users can scroll through posts from accounts they follow, with new posts available after pull-to-refresh.
+
+## Background
+
+The database has a `posts` table and `follows` table. No feed query or feed UI exists today. The home screen shows a placeholder "Your feed will appear here." This phase builds the feed query, API endpoint, and the feed list component.
+
+## Requirements
+
+1. **Feed query**: Returns posts from followed accounts ordered by creation time, descending.
+   - Current: No feed query exists — `posts` table is queried directly only from profile pages
+   - Target: `GET /api/feed` returns paginated posts from followed accounts, newest first, max 20 per page
+   - Acceptance: Query returns correct posts for a user who follows 3 accounts with known post counts; cursor-based pagination advances correctly
+
+2. **Feed display**: Posts display in a scrollable card list.
+   - Current: Home screen shows static placeholder text
+   - Target: Home screen renders feed cards with author, timestamp, post content, and reaction count
+   - Acceptance: Feed renders without error for 0 posts (empty state shown), 1 post, and 20+ posts
+
+3. **Pull-to-refresh**: User can refresh the feed manually.
+   - Current: No refresh mechanism exists
+   - Target: Pull-down gesture triggers refetch; new posts appear at top of list
+   - Acceptance: After a new post is created in test, pull-to-refresh shows the new post without full app restart
+
+4. **New posts indicator**: When new posts arrive, a banner appears instead of auto-scrolling.
+   - Current: No such mechanism
+   - Target: "3 new posts" banner appears when refetch returns posts newer than the oldest visible post; tapping banner scrolls to top and shows new posts
+   - Acceptance: Banner appears for ≥1 new post, does not appear when no new posts, tap navigates to top
+
+## Boundaries
+
+**In scope:**
+- Feed query (backend) — posts from followed accounts, paginated
+- Feed list UI (frontend) — post cards with author, timestamp, content, reaction counts
+- Pull-to-refresh gesture
+- New posts indicator banner
+- Empty state when user follows no one or no posts exist
+
+**Out of scope:**
+- Creating posts — that is Phase 4
+- Reacting to posts — that is Phase 5
+- Following/unfollowing accounts — that is Phase 2 (already done)
+- Push notifications for new posts — separate backlog item
+
+## Constraints
+
+- Feed query must use cursor-based pagination (not offset) — the database has 500K+ posts and offset pagination is unacceptably slow beyond page 3
+- The feed card component must reuse the existing `<AvatarImage>` component from Phase 2
+
+## Acceptance Criteria
+
+- [ ] `GET /api/feed` returns posts only from followed accounts (not all posts)
+- [ ] `GET /api/feed` supports `cursor` parameter for pagination
+- [ ] Feed renders correctly at 0, 1, and 20+ posts
+- [ ] Pull-to-refresh triggers refetch
+- [ ] New posts indicator appears when posts newer than current view exist
+- [ ] Empty state renders when user follows no one
+
+## Ambiguity Report
+
+| Dimension          | Score | Min  | Status | Notes                            |
+|--------------------|-------|------|--------|----------------------------------|
+| Goal Clarity       | 0.92  | 0.75 | ✓      |                                  |
+| Boundary Clarity   | 0.95  | 0.70 | ✓      | Explicit out-of-scope list       |
+| Constraint Clarity | 0.80  | 0.65 | ✓      | Cursor pagination required       |
+| Acceptance Criteria| 0.85  | 0.70 | ✓      | 6 pass/fail criteria             |
+| **Ambiguity**      | 0.12  | ≤0.20| ✓      |                                  |
+
+## Interview Log
+
+| Round | Perspective     | Question summary              | Decision locked                         |
+|-------|-----------------|------------------------------|-----------------------------------------|
+| 1     | Researcher      | What exists in posts today?  | posts + follows tables exist, no feed  |
+| 2     | Simplifier      | Minimum viable feed?         | Cards + pull-refresh, no auto-scroll   |
+| 3     | Boundary Keeper | What's NOT this phase?       | Creating posts, reactions out of scope |
+| 3     | Boundary Keeper | What does done look like?    | Scrollable feed with 4 card fields     |
+
+---
+
+*Phase: 03-post-feed*
+*Spec created: 2025-01-20*
+*Next step: /sdd:discuss-phase 3 — implementation decisions (card layout, loading skeleton, etc.)*
+```
+
+**Example 2: CLI tool (Database backup)**
+
+```markdown
+# Phase 2: Backup Command — Specification
+
+**Created:** 2025-01-20
+**Ambiguity score:** 0.15
+**Requirements:** 3 locked
+
+## Goal
+
+A `sdd backup` CLI command creates a reproducible database snapshot that can be restored by `sdd restore` (a separate phase).
+
+## Background
+
+No backup tooling exists. The project uses PostgreSQL. Developers currently use `pg_dump` manually — there is no standardized process, no output naming convention, and no CI integration. Three incidents in the last quarter involved restoring from wrong or corrupt dumps.
+
+## Requirements
+
+1. **Backup creation**: CLI command executes a full database backup.
+   - Current: No `backup` subcommand exists in the CLI
+   - Target: `sdd backup` connects to the database (via `DATABASE_URL` env or `--db` flag), runs pg_dump, writes output to `./backups/YYYY-MM-DD_HH-MM-SS.dump`
+   - Acceptance: Running `sdd backup` on a test database creates a `.dump` file; running `pg_restore` on that file recreates the database without error
+
+2. **Network retry**: Transient network failures are retried automatically.
+   - Current: pg_dump fails immediately on network error
+   - Target: Backup retries up to 3 times with 5-second delay; 4th failure exits with code 1 and a message to stderr
+   - Acceptance: Simulating 2 sequential network failures causes 2 retries then success; simulating 4 failures causes exit code 1 and stderr message
+
+3. **Partial cleanup**: Failed backups do not leave corrupt files.
+   - Current: Manual pg_dump leaves partial files on failure
+   - Target: If backup fails after starting, the partial `.dump` file is deleted before exit
+   - Acceptance: After a simulated failure mid-dump, no `.dump` file exists in `./backups/`
+
+## Boundaries
+
+**In scope:**
+- `sdd backup` subcommand (full dump only)
+- Output to `./backups/` directory (created if missing)
+- Network retry (3 attempts)
+- Partial file cleanup on failure
+
+**Out of scope:**
+- `sdd restore` — that is Phase 3
+- Incremental backups — separate backlog item (full dump only for now)
+- S3 or remote storage — separate backlog item
+- Encryption — separate backlog item
+- Scheduled/cron backups — separate backlog item
+
+## Constraints
+
+- Must use `pg_dump` (not a custom query) — ensures compatibility with standard `pg_restore`
+- `--no-retry` flag must be available for CI use (fail fast, no retries)
+
+## Acceptance Criteria
+
+- [ ] `sdd backup` creates a `.dump` file in `./backups/YYYY-MM-DD_HH-MM-SS.dump` format
+- [ ] `sdd backup` uses `DATABASE_URL` env var or `--db` flag for connection
+- [ ] 3 retries on network failure, then exit code 1 with stderr message
+- [ ] `--no-retry` flag skips retries and fails immediately on first error
+- [ ] No partial `.dump` file left after a failed backup
+
+## Ambiguity Report
+
+| Dimension          | Score | Min  | Status | Notes                          |
+|--------------------|-------|------|--------|--------------------------------|
+| Goal Clarity       | 0.90  | 0.75 | ✓      |                                |
+| Boundary Clarity   | 0.95  | 0.70 | ✓      | Explicit out-of-scope list     |
+| Constraint Clarity | 0.75  | 0.65 | ✓      | pg_dump required               |
+| Acceptance Criteria| 0.80  | 0.70 | ✓      | 5 pass/fail criteria           |
+| **Ambiguity**      | 0.15  | ≤0.20| ✓      |                                |
+
+## Interview Log
+
+| Round | Perspective     | Question summary              | Decision locked                         |
+|-------|-----------------|------------------------------|-----------------------------------------|
+| 1     | Researcher      | What backup tooling exists?  | None — pg_dump manual only             |
+| 2     | Simplifier      | Minimum viable backup?       | Full dump only, local only             |
+| 3     | Boundary Keeper | What's NOT this phase?       | Restore, S3, encryption excluded       |
+| 4     | Failure Analyst | What goes wrong on failure?  | Partial files, CI fail-fast needed     |
+
+---
+
+*Phase: 02-backup-command*
+*Spec created: 2025-01-20*
+*Next step: /sdd:discuss-phase 2 — implementation decisions (progress reporting, flag design, etc.)*
+```
+
+</good_examples>
+
+<guidelines>
+**Every requirement needs all three fields:**
+- Current: grounds the requirement in reality — what exists today?
+- Target: the concrete change — not "improve X" but "X becomes Y"
+- Acceptance: the falsifiable check — how does a verifier confirm this?
+
+**Ambiguity Report must reflect the actual interview.** If a dimension is below minimum, mark it ⚠ — the planner knows to treat it as an assumption rather than a locked requirement.
+
+**Interview Log is evidence of rigor.** Don't skip it. It shows that requirements came from discovery, not assumption.
+
+**Boundaries protect the phase from scope creep.** The out-of-scope list with reasoning is as important as the in-scope list. Future phases that touch adjacent areas can point to this SPEC.md to understand what was intentionally excluded.
+
+**SPEC.md is a one-way door for requirements.** discuss-phase will treat these as locked. If requirements change after SPEC.md is written, the user should update SPEC.md first, then re-run discuss-phase.
+
+**SPEC.md does NOT replace CONTEXT.md.** They serve different purposes:
+- SPEC.md: what the phase delivers (requirements, boundaries, acceptance criteria)
+- CONTEXT.md: how the phase will be implemented (decisions, patterns, tradeoffs)
+
+discuss-phase generates CONTEXT.md after reading SPEC.md.
+</guidelines>

package/sdd/templates/state.md

@@ -66,6 +66,14 @@ None yet.
 
 None yet.
 
+## Deferred Items
+
+Items acknowledged and carried forward from previous milestone close:
+
+| Category | Item | Status | Deferred At |
+|----------|------|--------|-------------|
+| *(none)* | | | |
+
 ## Session Continuity
 
 Last session: [YYYY-MM-DD HH:MM]
@@ -145,10 +153,10 @@ Updated after each plan completion.
 
 **Decisions:** Reference to PROJECT.md Key Decisions table, plus recent decisions summary for quick access. Full decision log lives in PROJECT.md.
 
-**Pending Todos:** Ideas captured via /sdd:add-todo
+**Pending Todos:** Ideas captured via /sdd-add-todo
 - Count of pending todos
 - Reference to .planning/todos/pending/
-- Brief list if few, count if many (e.g., "5 pending todos — see /sdd:check-todos")
+- Brief list if few, count if many (e.g., "5 pending todos — see /sdd:capture --list")
 
 **Blockers/Concerns:** From "Next Phase Readiness" sections
 - Issues that affect future work

package/sdd/workflows/add-backlog.md

@@ -0,0 +1,90 @@
+# Add Backlog Item Workflow
+
+Invoked by `/sdd:capture --backlog` (`commands/sdd/capture.md`).
+
+Adds an idea to the ROADMAP.md backlog parking lot using 999.x numbering. Backlog items
+are unsequenced ideas that aren't ready for active planning — they live outside the normal
+phase sequence and accumulate context over time.
+
+<process>
+
+## Step 1: Read ROADMAP.md
+
+Check for existing backlog entries:
+
+```bash
+cat .planning/ROADMAP.md
+```
+
+## Step 2: Find next backlog number
+
+```bash
+NEXT=$(sdd-sdk query phase.next-decimal 999 --raw)
+```
+
+If no 999.x phases exist yet, `phase.next-decimal` returns `999.1`. Sparse numbering
+is fine (e.g. 999.1, 999.3) — always use `phase.next-decimal`, never guess.
+
+## Step 3: Write ROADMAP entry
+
+**Write the ROADMAP entry BEFORE creating the directory.** Directory existence is a
+reliable indicator that the phase is already registered, which prevents false duplicate
+detection in any hook that checks for existing 999.x directories (#2280).
+
+Add under a `## Backlog` section. If the section doesn't exist, create it at the end
+of ROADMAP.md:
+
+```markdown
+## Backlog
+
+### Phase {NEXT}: {description} (BACKLOG)
+
+**Goal:** [Captured for future planning]
+**Requirements:** TBD
+**Plans:** 0 plans
+
+Plans:
+- [ ] TBD (promote with /sdd:review-backlog when ready)
+```
+
+## Step 4: Create the phase directory
+
+Apply the `project_code` prefix (if set in `.planning/config.json`) so the backlog directory name is consistent with all other phase-creation paths:
+
+```bash
+SLUG=$(sdd-sdk query generate-slug "$ARGUMENTS" --raw)
+PROJECT_CODE=$(sdd-sdk query config-get project_code --raw 2>/dev/null || echo "")
+PREFIX=$([ -n "$PROJECT_CODE" ] && echo "${PROJECT_CODE}-" || echo "")
+PHASE_DIR=".planning/phases/${PREFIX}${NEXT}-${SLUG}"
+mkdir -p "${PHASE_DIR}"
+touch "${PHASE_DIR}/.gitkeep"
+```
+
+## Step 5: Commit
+
+```bash
+sdd-sdk query commit "docs: add backlog item ${NEXT} — ${ARGUMENTS}" --files .planning/ROADMAP.md "${PHASE_DIR}/.gitkeep"
+```
+
+## Step 6: Report
+
+```
+## 📋 Backlog Item Added
+
+Phase {NEXT}: {description}
+Directory: {PHASE_DIR}/
+
+This item lives in the backlog parking lot.
+Use /sdd:discuss-phase {NEXT} to explore it further.
+Use /sdd:review-backlog to promote items to active milestone.
+```
+
+</process>
+
+<notes>
+- 999.x numbering keeps backlog items out of the active phase sequence
+- Phase directories are created immediately so /sdd:discuss-phase and /sdd:plan-phase work on them
+- No `Depends on:` field — backlog items are unsequenced by definition
+- Sparse numbering is fine (999.1, 999.3) — always uses next-decimal
+- Promote backlog items to the active milestone with /sdd:review-backlog
+</notes>

package/sdd/workflows/add-phase.md

@@ -11,15 +11,15 @@ Read all files referenced by the invoking prompt's execution_context before star
 <step name="parse_arguments">
 Parse the command arguments:
 - All arguments become the phase description
-- Example: `/sdd:add-phase Add authentication` → description = "Add authentication"
-- Example: `/sdd:add-phase Fix critical performance issues` → description = "Fix critical performance issues"
+- Example: `/sdd-add-phase Add authentication` → description = "Add authentication"
+- Example: `/sdd-add-phase Fix critical performance issues` → description = "Fix critical performance issues"
 
 If no arguments provided:
 
 ```
 ERROR: Phase description required
-Usage: /sdd:add-phase <description>
-Example: /sdd:add-phase Add authentication system
+Usage: /sdd-add-phase <description>
+Example: /sdd-add-phase Add authentication system
 ```
 
 Exit.
@@ -29,7 +29,7 @@ Exit.
 Load phase operation context:
 
 ```bash
-INIT=$(node "$HOME/.claude/sdd/bin/sdd-tools.cjs" init phase-op "0")
+INIT=$(sdd-sdk query init.phase-op "0")
 if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
 ```
 
@@ -42,10 +42,10 @@ Exit.
 </step>
 
 <step name="add_phase">
-**Delegate the phase addition to sdd-tools:**
+**Delegate the phase addition to `sdd-sdk query phase.add`:**
 
 ```bash
-RESULT=$(node "$HOME/.claude/sdd/bin/sdd-tools.cjs" phase add "${description}")
+RESULT=$(sdd-sdk query phase.add "${description}")
 ```
 
 The CLI handles:
@@ -83,18 +83,18 @@ Roadmap updated: .planning/ROADMAP.md
 
 ---
 
-## ▶ Next Up
+## ▶ Next Up — [${PROJECT_CODE}] ${PROJECT_TITLE}
 
 **Phase {N}: {description}**
 
-`/sdd:plan-phase {N}`
+`/clear` then:
 
-<sub>`/clear` first → fresh context window</sub>
+`/sdd:plan-phase {N}`
 
 ---
 
 **Also available:**
-- `/sdd:add-phase <description>` — add another phase
+- `/sdd-add-phase <description>` — add another phase
 - Review roadmap
 
 ---
@@ -104,7 +104,7 @@ Roadmap updated: .planning/ROADMAP.md
 </process>
 
 <success_criteria>
-- [ ] `sdd-tools phase add` executed successfully
+- [ ] `sdd-sdk query phase.add` executed successfully
 - [ ] Phase directory created
 - [ ] Roadmap updated with new phase entry
 - [ ] STATE.md updated with roadmap evolution note

package/sdd/workflows/add-tests.md

@@ -33,7 +33,7 @@ Exit.
 Load phase operation context:
 
 ```bash
-INIT=$(node "$HOME/.claude/sdd/bin/sdd-tools.cjs" init phase-op "${PHASE_ARG}")
+INIT=$(sdd-sdk query init.phase-op "${PHASE_ARG}")
 if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
 ```
 
@@ -108,6 +108,9 @@ Read each file to verify classification. Don't classify based on filename alone.
 <step name="present_classification">
 Present the classification to the user for confirmation before proceeding:
 
+
+**Text mode (`workflow.text_mode: true` in config or `--text` flag):** Set `TEXT_MODE=true` if `--text` is present in `$ARGUMENTS` OR `text_mode` from init JSON is `true`. When TEXT_MODE is active, replace every `AskUserQuestion` call with a plain-text numbered list and ask the user to type their choice number. This is required for non-Claude runtimes (OpenAI Codex, Gemini CLI, etc.) where `AskUserQuestion` is not available.
+
 ```
 AskUserQuestion(
   header: "Test Classification",
@@ -297,7 +300,7 @@ Create a test coverage report and present to user:
 
 Record test generation in project state:
 ```bash
-node "$HOME/.claude/sdd/bin/sdd-tools.cjs" state-snapshot
+sdd-sdk query state-snapshot
 ```
 
 If there are passing tests to commit:
@@ -312,7 +315,7 @@ Present next steps:
 ```
 ---
 
-## ▶ Next Up
+## ▶ Next Up — [${PROJECT_CODE}] ${PROJECT_TITLE}
 
 {if bugs discovered:}
 **Fix discovered bugs:** `/sdd:quick fix the {N} test failures discovered in phase ${phase_number}`

package/sdd/workflows/add-todo.md

@@ -12,7 +12,7 @@ Read all files referenced by the invoking prompt's execution_context before star
 Load todo context:
 
 ```bash
-INIT=$(node "$HOME/.claude/sdd/bin/sdd-tools.cjs" init todos)
+INIT=$(sdd-sdk query init.todos)
 if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
 ```
 
@@ -20,7 +20,7 @@ Extract from init JSON: `commit_docs`, `date`, `timestamp`, `todo_count`, `todos
 
 Ensure directories exist:
 ```bash
-mkdir -p .planning/todos/pending .planning/todos/done
+mkdir -p .planning/todos/pending .planning/todos/completed
 ```
 
 Note existing areas from the todos array for consistency in infer_area step.
@@ -28,7 +28,7 @@ Note existing areas from the todos array for consistency in infer_area step.
 
 <step name="extract_content">
 **With arguments:** Use as the title/focus.
-- `/sdd:add-todo Add auth token refresh` → title = "Add auth token refresh"
+- `/sdd-add-todo Add auth token refresh` → title = "Add auth token refresh"
 
 **Without arguments:** Analyze recent conversation to extract:
 - The specific problem, idea, or task discussed
@@ -70,6 +70,8 @@ If potential duplicate found:
 1. Read the existing todo
 2. Compare scope
 
+
+**Text mode (`workflow.text_mode: true` in config or `--text` flag):** Set `TEXT_MODE=true` if `--text` is present in `$ARGUMENTS` OR `text_mode` from init JSON is `true`. When TEXT_MODE is active, replace every `AskUserQuestion` call with a plain-text numbered list and ask the user to type their choice number. This is required for non-Claude runtimes (OpenAI Codex, Gemini CLI, etc.) where `AskUserQuestion` is not available.
 If overlapping, use AskUserQuestion:
 - header: "Duplicate?"
 - question: "Similar todo exists: [title]. What would you like to do?"
@@ -84,7 +86,7 @@ Use values from init context: `timestamp` and `date` are already available.
 
 Generate slug for the title:
 ```bash
-slug=$(node "$HOME/.claude/sdd/bin/sdd-tools.cjs" generate-slug "$title" --raw)
+slug=$(sdd-sdk query generate-slug "$title" --raw)
 ```
 
 Write to `.planning/todos/pending/${date}-${slug}.md`:
@@ -119,7 +121,7 @@ If `.planning/STATE.md` exists:
 Commit the todo and any updated state:
 
 ```bash
-node "$HOME/.claude/sdd/bin/sdd-tools.cjs" commit "docs: capture todo - [title]" --files .planning/todos/pending/[filename] .planning/STATE.md
+sdd-sdk query commit "docs: capture todo - [title]" --files .planning/todos/pending/[filename] .planning/STATE.md
 ```
 
 Tool respects `commit_docs` config and gitignore automatically.
@@ -141,7 +143,7 @@ Would you like to:
 
 1. Continue with current work
 2. Add another todo
-3. View all todos (/sdd:check-todos)
+3. View all todos (/sdd:capture --list)
 ```
 </step>