feat(ultrathink): embed philosophy checkpoints across workflow phases

Integrates ultrathink deep thinking philosophy as lightweight checkpoints
throughout the development workflow, not just during explicit /ultrathink.

Phase Checkpoints:
- /spec: Think Different - Assumption inventory before requirements
- /plan: Obsess + Simplify - Codebase soul analysis, 3 alternatives
- /tasks: Simplify Ruthlessly - Task count validation, simplification review
- /implement: Craft, Don't Code - Anti-duplication ritual, abstraction check

Progressive Depth:
- Trivial (<5 tasks): Skip checkpoints, fast path
- Standard (5-30 tasks): Lightweight inline checkpoints
- Complex (30+ tasks): Full checkpoints + separate artifacts
- Epic (multi-sprint): Mandatory deep planning + craftsman-decision.md

New files:
- .spec-flow/config/ultrathink-integration.yaml

Modified commands:
- /spec: Added Step 0 assumption checkpoint
- /plan: Added Step 0.75 codebase soul + alternatives checkpoint
- /tasks: Added Step 2.6 simplification checkpoint
- /implement: Added Step 1.4.5 anti-duplication ritual
- /ultrathink: Added AskUserQuestion JSON, error handling for gh CLI

Updated:
- ultrathink skill with workflow_integration documentation

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Author: marcusgoll

.claude/commands/core/ultrathink.md

@@ -39,8 +39,17 @@ If there's a way to remove complexity without losing power, find it. Elegance is
 
 <context>
 **Guiding Principles**: @CLAUDE.md
-**Project Architecture**: @docs/project/system-architecture.md
-**Tech Stack Decisions**: @docs/project/tech-stack.md
+**Deep Planning Skill**: @.claude/skills/ultrathink/SKILL.md
+
+**Project docs (if they exist)**:
+- Architecture: `docs/project/system-architecture.md`
+- Tech Stack: `docs/project/tech-stack.md`
+
+Check file existence before referencing:
+```bash
+test -f docs/project/system-architecture.md && echo "ARCH_EXISTS"
+test -f docs/project/tech-stack.md && echo "TECH_EXISTS"
+```
 </context>
 
 <process>
@@ -131,7 +140,7 @@ If there's a way to remove complexity without losing power, find it. Elegance is
 
 13. **Offer roadmap materialization**
 
-    If features were extracted, ask user:
+    If features were extracted, display summary and ask user:
 
     ```
     Your analysis identified N actionable items:
@@ -145,19 +154,70 @@ If there's a way to remove complexity without losing power, find it. Elegance is
     Would you like to add these to the roadmap?
     ```
 
-    Use AskUserQuestion with options:
-    - **Add All** - Create GitHub Issues for all extracted features
-    - **Select** - Choose which features to add
-    - **Just Save** - Save thinking but don't create issues
-    - **Skip** - Don't save or create issues
+    Use AskUserQuestion:
+
+    ```json
+    {
+      "question": "Would you like to add these to the roadmap?",
+      "header": "Materialize",
+      "multiSelect": false,
+      "options": [
+        {"label": "Add All (Recommended)", "description": "Create GitHub Issues for all extracted features"},
+        {"label": "Select", "description": "Choose which features to add"},
+        {"label": "Just Save", "description": "Save thinking to file but don't create issues"},
+        {"label": "Skip", "description": "Don't save or create issues"}
+      ]
+    }
+    ```
+
+    **If "Select" chosen**, show multi-select:
+
+    ```json
+    {
+      "question": "Which features should be added to the roadmap?",
+      "header": "Select",
+      "multiSelect": true,
+      "options": [
+        {"label": "[Epic] Feature Name 1", "description": "[description]"},
+        {"label": "[Feature] Feature Name 2", "description": "[description]"}
+      ]
+    }
+    ```
 
 14. **Create GitHub Issues (if materializing)**
 
-    For each selected feature:
+    **Pre-flight checks**:
+
+    ```bash
+    # Verify gh CLI is authenticated
+    if ! gh auth status &>/dev/null; then
+      echo "ERROR: GitHub CLI not authenticated"
+      echo "Run: gh auth login"
+      echo ""
+      echo "Saving thinking to file instead..."
+      # Fall back to --save behavior
+    fi
+
+    # Verify we're in a git repo with a remote
+    if ! git remote get-url origin &>/dev/null; then
+      echo "WARNING: No git remote found"
+      echo "Issues will be created but may not link correctly"
+    fi
+
+    # Check if required labels exist, create if missing
+    gh label list | grep -q "status:backlog" || \
+      gh label create "status:backlog" --color "FBCA04" --description "In backlog, not started"
+    gh label list | grep -q "type:epic" || \
+      gh label create "type:epic" --color "7057FF" --description "Large multi-sprint work"
+    gh label list | grep -q "type:feature" || \
+      gh label create "type:feature" --color "0E8A16" --description "Single feature implementation"
+    ```
+
+    **Create issues** for each selected feature:
 
     ```bash
     # Create issue with proper labels
-    gh issue create \
+    ISSUE_URL=$(gh issue create \
       --title "[type]: [name]" \
       --body "$(cat <<EOF
     ## Origin
@@ -181,10 +241,20 @@ If there's a way to remove complexity without losing power, find it. Elegance is
     EOF
     )" \
       --label "status:backlog" \
-      --label "type:[epic/feature]"
+      --label "type:[epic/feature]" 2>&1)
+
+    # Check for errors
+    if [[ $? -ne 0 ]]; then
+      echo "ERROR creating issue: $ISSUE_URL"
+      # Continue with remaining issues
+    else
+      echo "Created: $ISSUE_URL"
+      # Extract issue number for tracking
+      ISSUE_NUM=$(echo "$ISSUE_URL" | grep -oE '[0-9]+$')
+    fi
     ```
 
-    Display created issues:
+    **Display summary**:
 
     ```
     ✅ Created roadmap items from your thinking:
@@ -195,6 +265,18 @@ If there's a way to remove complexity without losing power, find it. Elegance is
 
     Next: /feature #43 to start implementing
     ```
+
+    **If any issues failed**, show partial success:
+
+    ```
+    ⚠️ Partially completed:
+
+    ✅ #42 Epic: Notification Service
+    ❌ Feature: Push Notification API (label missing)
+    ✅ #44 Feature: User Preferences
+
+    Fix issues manually or re-run: /roadmap from-ultrathink specs/ultrathink/[slug].yaml
+    ```
 </process>
 
 <mindset>

.claude/commands/phases/implement.md

@@ -392,6 +392,99 @@ Group tasks for parallel execution:
 
 ---
 
+### Step 1.4.5: Ultrathink Checkpoint — Craft, Don't Code
+
+> **Philosophy**: "Would a junior developer understand this in 5 minutes?"
+
+Before executing each task batch, apply the anti-duplication ritual.
+
+**Display thinking prompt** (once per batch):
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│ 💭 ULTRATHINK CHECKPOINT: Craft, Don't Code                 │
+├─────────────────────────────────────────────────────────────┤
+│ Before implementing, always ask:                            │
+│                                                             │
+│ • Have I searched for similar patterns? (mgrep first!)      │
+│ • Can I extend existing code instead of creating new?       │
+│ • Does this abstraction earn its complexity?                │
+│ • Would a junior dev understand this in 5 minutes?          │
+└─────────────────────────────────────────────────────────────┘
+```
+
+**Pre-Coding Ritual** (execute before EACH new file creation):
+
+```bash
+# Step 1: Anti-duplication search
+echo "=== Anti-Duplication Check ==="
+
+# Use mgrep for semantic search (finds similar by meaning)
+TASK_DESCRIPTION="[task description from tasks.md]"
+mgrep "$TASK_DESCRIPTION"
+
+# If mgrep unavailable, fallback to Grep
+Grep "similar pattern keywords" --type ts
+```
+
+**Decision tree after search:**
+
+```
+Search Results:
+  │
+  ├─ Found similar code
+  │   └─ Q: "Can we extend this instead of creating new?"
+  │       ├─ Yes → Extend existing file (preferred)
+  │       └─ No → Document why in NOTES.md, then create new
+  │
+  └─ No similar code found
+      └─ Proceed with new implementation
+         └─ Follow existing codebase patterns (from plan.md)
+```
+
+**Abstraction check** (for new files):
+
+```markdown
+## Abstraction Justification
+
+| New File | Justification | Alternatives Considered |
+|----------|---------------|------------------------|
+| [path] | [why this earns its complexity] | [what was ruled out] |
+```
+
+**Quality questions per task:**
+
+Before writing code, answer mentally:
+1. **Reuse**: Did I search for existing patterns?
+2. **Simplicity**: Is this the simplest approach that works?
+3. **Clarity**: Would someone understand this without comments?
+4. **Testability**: Can this be tested in isolation?
+
+**If creating an abstraction** (interface, base class, utility):
+
+```json
+{
+  "question": "You're about to create a new abstraction. Does it earn its complexity?",
+  "header": "Abstraction",
+  "multiSelect": false,
+  "options": [
+    {"label": "Yes, multiple consumers", "description": "This will be used by 2+ implementations"},
+    {"label": "Yes, complex logic", "description": "Encapsulates genuinely complex behavior"},
+    {"label": "No, premature", "description": "I should inline this for now"},
+    {"label": "Skip check", "description": "I've already considered this"}
+  ]
+}
+```
+
+**Red flags to catch:**
+
+- Creating interface with only 1 implementation
+- Adding "for future use" code
+- Generic utility for a single use case
+- Inheritance hierarchy deeper than 2 levels
+
+---
+
 ### Step 1.5: EXECUTE TASK BATCHES (MANDATORY)
 
 **For each batch group, execute tasks using specialist agents.**

.claude/commands/phases/plan.md

@@ -276,6 +276,123 @@ This ensures architecture decisions are grounded in existing codebase patterns a
 
 ---
 
+### Step 0.75: Ultrathink Checkpoint — Obsess Over Details + Simplify Ruthlessly
+
+> **Philosophy**: "What's the simplest architecture that could possibly work?"
+
+Before designing architecture, understand the codebase soul and explore alternatives.
+
+**Display thinking prompt** (for standard+ complexity):
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│ 💭 ULTRATHINK CHECKPOINT: Obsess + Simplify                 │
+├─────────────────────────────────────────────────────────────┤
+│ Before architecting, consider:                              │
+│                                                             │
+│ • What patterns dominate this codebase?                     │
+│ • What existing code can we reuse?                          │
+│ • What's the SIMPLEST architecture that works?              │
+│ • Does each new component earn its complexity?              │
+└─────────────────────────────────────────────────────────────┘
+```
+
+**Codebase Soul Analysis** (required for complex/epic, recommended for standard):
+
+```bash
+# Quick soul analysis - find dominant patterns
+echo "=== Codebase Soul Analysis ==="
+
+# Backend patterns
+SERVICE_COUNT=$(find . -name "*[Ss]ervice*" -type f 2>/dev/null | wc -l)
+REPO_COUNT=$(find . -name "*[Rr]epository*" -type f 2>/dev/null | wc -l)
+CONTROLLER_COUNT=$(find . -name "*[Cc]ontroller*" -type f 2>/dev/null | wc -l)
+
+echo "Services: $SERVICE_COUNT | Repositories: $REPO_COUNT | Controllers: $CONTROLLER_COUNT"
+
+# Frontend patterns
+COMPONENT_COUNT=$(find . -name "*.tsx" -path "*/components/*" 2>/dev/null | wc -l)
+HOOK_COUNT=$(grep -r "^export.*function use" --include="*.ts" --include="*.tsx" 2>/dev/null | wc -l)
+
+echo "Components: $COMPONENT_COUNT | Hooks: $HOOK_COUNT"
+
+# Determine dominant pattern
+if [ "$SERVICE_COUNT" -gt 5 ]; then
+    echo "Dominant: Service Layer Pattern"
+fi
+```
+
+**Document in plan.md** (inline section):
+
+```markdown
+## Codebase Soul Summary
+
+**Dominant Patterns**: [Service Layer / Repository / MVC / Hooks-based]
+**Philosophy**: [Thin controllers | Fat services | Composition-first]
+**Conventions**: [Naming, file structure, error handling observed]
+
+**Reuse Opportunities**:
+- [Existing service/component that can be extended]
+- [Existing pattern to follow]
+
+**Anti-Patterns to Avoid**:
+- [File/pattern observed that shouldn't be repeated]
+```
+
+**Generate 3 Alternatives** (required for complex/epic):
+
+```markdown
+## Architecture Alternatives
+
+### Approach A: [Name] (Initial Thought)
+- New components: [list]
+- Pros: [list]
+- Cons: [list]
+
+### Approach B: [Name] (Simplified)
+- New components: [list]
+- Pros: [list]
+- Cons: [list]
+
+### Approach C: [Name] (Alternative)
+- New components: [list]
+- Pros: [list]
+- Cons: [list]
+
+### Selected: Approach [X]
+**Reasoning**: [Why this is the simplest approach that works]
+```
+
+**Complexity Budget** (required for complex/epic):
+
+```markdown
+## Complexity Budget
+
+| Component | Complexity | Justification |
+|-----------|------------|---------------|
+| [NewService] | Medium | Core logic requires dedicated service |
+| [NewComponent] | Low | Composition of existing primitives |
+| [NewAbstraction] | REJECTED | Premature - can refactor later if needed |
+
+**Simplification Applied**:
+- Before: [X] new components, [Y] new services
+- After: [A] new components, [B] new services
+- Removed: [What was eliminated and why]
+```
+
+**When to generate craftsman-decision.md** (full artifact):
+
+```bash
+# Check if deep mode or complex feature
+if [ "$PLANNING_MODE" = "deep" ] || [ "$TASK_ESTIMATE" -ge 30 ]; then
+    # Generate separate craftsman-decision.md
+    CRAFTSMAN_FILE="${BASE_DIR}/${SLUG}/craftsman-decision.md"
+    echo "Generating: $CRAFTSMAN_FILE"
+fi
+```
+
+---
+
 ### Step 0.5: MIGRATION DETECTION (v10.5)
 
 **Detect if this feature requires database schema changes:**