gh-navidemad-claude-code-plugins-prd-plugin/skills/code-prd/references/ux-enhancements.md

UX Enhancements Reference

Purpose: Detailed implementation specifications for all UX enhancements in the code-prd skill.

Location: skills/code-prd/references/ux-enhancements.md

How to use this reference:

• Main workflow is in SKILL.md with callout markers (📚 🧪 📋 💾 🔍 🎯)
• When you see a callout, read the corresponding section here for full implementation
• See "UX Enhancement Reference Map" in SKILL.md for quick navigation

File Type: Reference documentation (loaded as needed, not executed directly)

---

Section 1: Learning Mode (Step 4.0 - Before each substory)

When enabled, show explanation before implementing:

💡 Learning Mode: ON

About to implement: Substory 1.2 - OAuth callback handler

📚 My Approach:

**What I'll build:**
Create `/auth/callback` endpoint to handle OAuth provider redirects

**Why this pattern:**
- Follows RESTful routing (established in Substory 1.1)
- Separates concerns: Controller handles HTTP, Service handles OAuth logic
- Pattern from CLAUDE.md: Thin controller pattern

**Key decisions:**
1. Use OAuthService (created in 1.1) for token exchange
2. Store tokens in encrypted format (Security best practice)
3. Handle errors with custom OAuthError class (Consistent error handling)

**Files I'll create/modify:**
- `app/controllers/auth_controller.rb` - Add callback action
- `app/services/oauth_service.rb` - Add token_exchange method
- `spec/controllers/auth_controller_spec.rb` - Test callback flow

**Estimated complexity:** Medium (involves external API calls)

Ready to proceed? [yes/explain-more/adjust-approach]

Smart mode (only explain new patterns):

• Only shows explanation when introducing a pattern not seen in prior substories
• Skips explanation for repetitive patterns

Disabled mode:

• Proceeds directly to implementation without explanation

Section 2: Dependency Warnings (Step 4.1 - Before substory execution)

Before implementing each substory, check for dependencies:

# Detect dependencies from substory description and acceptance criteria
dependencies=()

# Check for API keys/credentials
if grep -qi "api\|oauth\|key\|secret\|credential" <<< "$substory_text"; then
    # Check environment or config files
    if ! grep -q "GOOGLE_CLIENT_ID\|GITHUB_CLIENT_ID" .env 2>/dev/null; then
        dependencies+=("oauth_credentials")
    fi
fi

# Check for database migrations
if grep -qi "database\|migration\|schema\|table" <<< "$substory_text"; then
    # Check if migrations are pending
    if [[ $(rails db:migrate:status 2>/dev/null | grep -c "down") -gt 0 ]]; then
        dependencies+=("pending_migrations")
    fi
fi

# Check for external services
if grep -qi "redis\|elasticsearch\|postgres\|mysql" <<< "$substory_text"; then
    # Check if services are running
    if ! pgrep -x "redis-server" > /dev/null 2>&1; then
        dependencies+=("redis_not_running")
    fi
fi

# Check for package dependencies
if grep -qi "npm install\|bundle install\|pip install" <<< "$substory_text"; then
    # Check if lock file is newer than node_modules
    if [[ package-lock.json -nt node_modules ]]; then
        dependencies+=("packages_outdated")
    fi
fi

Show dependency warnings:

⚠️  Dependency Check: Substory 1.3 - Token encryption

Found 2 potential blockers:

1. 🔑 OAuth Credentials Required
   - Need: GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET
   - Status: ❌ Not found in .env file

   Options:
   a. Set up credentials now (I'll guide you)
   b. Skip this substory for now (mark as blocked)
   c. Use mock credentials for testing

2. 📦 Package Dependencies
   - Package 'jose' (JWT library) not installed
   - Required for token encryption

   Options:
   a. Install now: npm install jose
   b. Use alternative library
   c. Skip encryption for now (not recommended)

How would you like to proceed? [resolve-all/skip/continue-anyway]

If user chooses "resolve-all": Guide through each dependency setup step-by-step.

If user chooses "skip": Mark substory as blocked, move to next unblocked substory.

If user chooses "continue-anyway": Warn about potential failures, proceed with implementation.

Section 3: Rollback Protection (Step 4.9 - Phase boundaries)

Before starting each new phase, create automatic checkpoint:

# Create rollback checkpoint before Phase start
phase_number="$1"
checkpoint_dir=".claude/checkpoints"
checkpoint_name="phase-${phase_number}-$(date +%Y%m%d-%H%M%S)"
checkpoint_path="${checkpoint_dir}/${checkpoint_name}"

mkdir -p "$checkpoint_path"

# Note: checkpoints directory and gitignore are created in Phase 0/Step 1

# Save git state
git diff > "${checkpoint_path}/git-diff.patch"
git diff --cached > "${checkpoint_path}/git-diff-staged.patch"
git status --porcelain > "${checkpoint_path}/git-status.txt"
git rev-parse HEAD > "${checkpoint_path}/git-commit.txt"

# Save PRD state
cp "$prd_file" "${checkpoint_path}/prd.md"
cp "$context_file" "${checkpoint_path}/context.json"

# Save file list
find . -type f -newer "${checkpoint_path}/../last-checkpoint" 2>/dev/null > "${checkpoint_path}/modified-files.txt" || true

# Create rollback script
cat > "${checkpoint_path}/rollback.sh" <<'ROLLBACK'
#!/bin/bash
echo "🔄 Rolling back to checkpoint: ${checkpoint_name}"
echo ""
echo "This will:"
echo "- Restore PRD and context files"
echo "- Undo all uncommitted changes since checkpoint"
echo "- Restore modified files"
echo ""
read -p "Continue with rollback? [yes/no]: " confirm

if [[ "$confirm" == "yes" ]]; then
    git apply --reverse git-diff.patch 2>/dev/null || true
    git apply --reverse git-diff-staged.patch 2>/dev/null || true
    cp prd.md "$prd_file"
    cp context.json "$context_file"
    echo "✅ Rollback complete"
else
    echo "Rollback cancelled"
fi
ROLLBACK

chmod +x "${checkpoint_path}/rollback.sh"

# Update last checkpoint marker
touch "${checkpoint_dir}/last-checkpoint"

Show checkpoint confirmation:

💾 Checkpoint Created: Phase 2 Start

Saved current state before beginning Phase 2

Checkpoint includes:
- Current code state (3 files modified)
- PRD status (Phase 1 complete, 66% overall)
- Context data (patterns, decisions, files)

If something goes wrong during Phase 2:
- Type "rollback" to undo Phase 2 changes
- Run: .claude/checkpoints/phase-2-20251026-143022/rollback.sh

Checkpoint expires: 24 hours (auto-cleanup)

Proceeding to Phase 2...

Section 4: Smart Test Suggestions (Step 5a - Test writing)

Analyze code complexity before writing tests:

# Analyze code complexity for smart test suggestions
analyze_code_complexity() {
    local file="$1"

    # Cyclomatic complexity (count branches: if, case, for, while, &&, ||)
    complexity=$(grep -c "if\|case\|for\|while\|&&\|||" "$file" 2>/dev/null || echo 0)

    # Count public methods/functions
    public_methods=$(grep -c "def \|function \|export function" "$file" 2>/dev/null || echo 0)

    # Count edge cases (null checks, empty checks, error handling)
    edge_cases=$(grep -c "nil?\|null\|undefined\|empty?\|rescue\|catch\|raise\|throw" "$file" 2>/dev/null || echo 0)

    # Lines of code
    loc=$(wc -l < "$file" 2>/dev/null || echo 0)

    # Determine complexity level
    if [[ $complexity -lt 3 ]] && [[ $loc -lt 50 ]]; then
        echo "low"
    elif [[ $complexity -lt 8 ]] && [[ $loc -lt 150 ]]; then
        echo "medium"
    else
        echo "high"
    fi
}

Show test strategy suggestion:

🧪 Test Strategy: Substory 1.3 - OAuth token encryption

📊 Code Complexity Analysis:
- Complexity score: Medium (cyclomatic complexity: 5)
- Public API: 3 methods (encrypt_token, decrypt_token, validate_token)
- Edge cases detected: 4 (nil token, invalid format, expired token, encryption error)
- Lines of code: 87 lines

🎯 Recommended Test Coverage:

Unit Tests (Recommended: 10 tests)
  ✅ Happy paths: 3 tests
     - encrypt_token with valid data
     - decrypt_token with valid encrypted token
     - validate_token with valid token

  ✅ Error handling: 4 tests
     - nil/empty token input
     - malformed encrypted data
     - expired token validation
     - encryption key missing

  ✅ Edge cases: 3 tests
     - Very long tokens (>4KB)
     - Special characters in tokens
     - Concurrent encryption requests

Integration Tests (Optional: 1 test)
  ⚡ Full OAuth flow with token encryption/decryption

E2E Tests (Skip)
  ⏭️  Not needed - no direct user interaction

📋 Test Plan Summary:
- Total tests: 10-11
- Estimated coverage: 95%+
- Focus: Error handling (high risk area)

Proceed with this test plan? [yes/add-more/minimal/custom]

If user chooses "minimal": Only write happy path tests (3 tests).

If user chooses "add-more": Ask what additional scenarios to cover.

If user chooses "custom": Let user specify exact test cases.

Section 5: Code Review Insights Summary (Step 5b - After review)

Enhanced review output with trends and gamification:

📋 Code Review Complete: Substory 1.3

🎯 Quality Score: 89/100 (Excellent ✅)

📈 Trend Analysis:
  Security:     ██████████ 95% (+5% from last substory ⬆️)
  Performance:  ████████░░ 85% (+2% ⬆️)
  Readability:  █████████░ 92% (same)
  Testability:  ████████░░ 88% (+8% ⬆️)
  Maintainability: ████████░░ 87% (+3% ⬆️)

🏆 Achievements Unlocked:
  ✨ Security Champion - 3 substories in a row with 90%+ security score
  🎯 Test Master - Achieved 95%+ test coverage
  📚 Pattern Consistency - 100% adherence to established patterns

✅ Top Wins:
  • Excellent error handling with custom exception hierarchy
  • Clear naming conventions throughout
  • Comprehensive test coverage (96%)
  • Good documentation in complex methods

💡 Focus Areas for Next Substory:
  • Consider extracting magic constants (found 2 instances)
  • Add database index for oauth_tokens.user_id (performance optimization)
  • Document the encryption algorithm choice (maintainability)

🔄 Iteration History:
  • Iteration 1: Found 2 major issues → Auto-fixed
  • Iteration 2: Clean ✅

All critical and major issues resolved!

Section 6: Parallel Work Detection (Step 6.5 - Before continuing to next phase)

Check for concurrent changes on main branch:

# Detect parallel work that might conflict
current_branch=$(git rev-parse --abbrev-ref HEAD)
base_branch=$(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')

# Get files changed in current branch
our_files=$(git diff --name-only $base_branch...HEAD)

# Fetch latest from remote
git fetch origin $base_branch --quiet 2>/dev/null

# Get files changed on base branch since we branched off
their_files=$(git diff --name-only HEAD...origin/$base_branch)

# Find overlapping files
conflicts=$(comm -12 <(echo "$our_files" | sort) <(echo "$their_files" | sort))

if [[ -n "$conflicts" ]]; then
    # Analyze conflict risk
    conflict_count=$(echo "$conflicts" | wc -l)

    # Get commit authors
    for file in $conflicts; do
        author=$(git log -1 --format='%an <%ae>' origin/$base_branch -- "$file")
        timestamp=$(git log -1 --format='%ar' origin/$base_branch -- "$file")
    done
fi

Show parallel work warning:

⚠️  Parallel Work Detected

While working on this PRD, changes were made to ${base_branch}:

Potentially Conflicting Files:
  1. src/services/oauth_service.rb
     - Modified by: Sarah Chen <sarah@example.com>
     - When: 2 hours ago
     - Commit: "refactor: extract token validation logic"

  2. app/controllers/auth_controller.rb
     - Modified by: Mike Johnson <mike@example.com>
     - When: 45 minutes ago
     - Commit: "feat: add rate limiting to auth endpoints"

Risk Level: 🟡 MEDIUM
  - 2 files overlap with your changes
  - Affects Substories: 1.2, 1.3

📊 Impact Analysis:
  - Both files are in your current phase
  - oauth_service.rb: Moderate overlap (refactored same methods)
  - auth_controller.rb: Minor overlap (different endpoints)

Options:
1. 🔄 Merge ${base_branch} now (recommended)
   - Pauses PRD implementation
   - Resolves conflicts immediately
   - Continues with updated code

2. ⏭️  Continue and merge later
   - Higher risk of complex conflicts
   - May require rework

3. 📞 Coordinate with team
   - Notify Sarah and Mike
   - Discuss approach before proceeding

4. 🔍 Show detailed diff
   - Review exactly what changed

What would you like to do? [1/2/3/4]

Section 7: Context-Aware Expansion Suggestions (Step 7 - Core PRD completion)

Analyze codebase to suggest smart expansions:

# Analyze core implementation for expansion suggestions
analyze_for_expansions() {
    local prd_file="$1"
    local context_file="$2"

    suggestions=()

    # Strategy 1: Analyze "Out of Scope" section from PRD
    out_of_scope=$(sed -n '/Out of Scope/,/^##/p' "$prd_file")

    # Strategy 2: Find TODO comments in implemented files
    files_created=$(jq -r '.files_created[]' "$context_file")
    todos=$(grep -rh "TODO\|FIXME\|ENHANCEMENT" $files_created 2>/dev/null || true)

    # Strategy 3: Analyze data model for missing relationships
    # Look for foreign keys without inverse relationships

    # Strategy 4: Check CLAUDE.md for planned features
    planned_features=$(sed -n '/Planned Features\|Roadmap/,/^##/p' CLAUDE.md 2>/dev/null || true)

    # Strategy 5: Analyze usage patterns (if analytics/logs available)
    # Find commonly accessed fields that don't exist yet

    # Rank suggestions by:
    # - Effort (lines of code, complexity)
    # - Impact (usage frequency, business value from comments)
    # - Dependencies (what else is needed)
}

Show smart expansion suggestions:

🎯 Smart Expansion Suggestions

Based on your core implementation, here are natural next steps:

┌─────────────────────────────────────────────────────────┐
│ 1. 🔥 Customer Details (HIGH PRIORITY)                   │
├─────────────────────────────────────────────────────────┤
│ Why recommended:                                         │
│ • Found 73% of invoices reference 'customer_id' in DB   │
│ • Listed in "Out of Scope" section of core PRD          │
│ • 5 TODO comments mention customer information          │
│                                                          │
│ Effort: ██████░░░░ Medium (2-3 substories)               │
│ Impact: ██████████ Very High (critical for production)  │
│ Builds on: Invoice model, InvoiceService pattern        │
│                                                          │
│ Would add:                                               │
│ • Customer model with name, email, address              │
│ • Invoice-Customer association                          │
│ • Customer selection in invoice forms                   │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│ 2. 💡 Line Items (QUICK WIN)                             │
├─────────────────────────────────────────────────────────┤
│ Why recommended:                                         │
│ • Follows same service pattern as InvoiceService        │
│ • Mentioned in CLAUDE.md planned features               │
│ • Low complexity, high value                            │
│                                                          │
│ Effort: ████░░░░░░ Small (1-2 substories)                │
│ Impact: ████████░░ High (enables itemized invoices)     │
│ Builds on: Invoice model, existing CRUD patterns        │
│                                                          │
│ Would add:                                               │
│ • LineItem model (description, quantity, unit_price)   │
│ • Has-many relationship with Invoice                    │
│ • Automatic total calculation                           │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│ 3. 🚀 Tax Calculations (HIGH IMPACT)                     │
├─────────────────────────────────────────────────────────┤
│ Why recommended:                                         │
│ • TODO comment: "Add tax calculation for compliance"    │
│ • Required for production use                           │
│ • Blocked until Line Items implemented                  │
│                                                          │
│ Effort: ████████░░ Large (4-5 substories)                │
│ Impact: ██████████ Critical (regulatory requirement)    │
│ Depends on: Line Items expansion                        │
│ Complexity: Tax rules, multi-jurisdiction support       │
│                                                          │
│ Would add:                                               │
│ • TaxRule model with regional rates                     │
│ • Tax calculation service                               │
│ • Tax line items in invoices                            │
└─────────────────────────────────────────────────────────┘

📊 Recommended Order:
  1st: Customer Details (unblocks other features)
  2nd: Line Items (enables Tax Calculations)
  3rd: Tax Calculations (compliance requirement)

Which expansion interests you? [1/2/3/custom/plan-all]:

If user selects number: Trigger plan-prd skill with pre-filled expansion context.

If user chooses "plan-all": Create PRDs for all three expansions in sequence.

If user chooses "custom": Let user describe their own expansion idea.

Section 8: Adaptive Difficulty (Phase 0 - Session configuration)

Track user progress and adapt workflow:

# Calculate user skill level based on history
calculate_skill_level() {
    local prds_completed=$(find .claude/prds/context -name "*.json" -exec jq -r 'select(.status=="complete") | .prd_name' {} \; | wc -l)
    local avg_quality=$(find .claude/prds/context -name "*.json" -exec jq -r '.code_quality_scores[]' {} \; | awk '{sum+=$1; n++} END {if (n>0) print sum/n; else print 0}')
    local avg_coverage=$(find .claude/prds/context -name "*.json" -exec jq -r '.test_coverage' {} \; | awk '{sum+=$1; n++} END {if (n>0) print sum/n; else print 0}')

    # Determine level
    if [[ $prds_completed -ge 10 ]] && [[ $(echo "$avg_quality > 90" | bc) -eq 1 ]]; then
        echo "advanced"
    elif [[ $prds_completed -ge 5 ]] && [[ $(echo "$avg_quality > 80" | bc) -eq 1 ]]; then
        echo "intermediate"
    else
        echo "beginner"
    fi
}

Advanced mode unlocked message:

🎓 Level Up! Advanced Mode Unlocked

Based on your track record:
- ✅ PRDs completed: 12
- ✅ Avg code quality: 94/100
- ✅ Test coverage: Consistently 92%+
- ✅ Pattern consistency: Excellent

You've unlocked Advanced Mode features:

🚀 Speed Optimizations:
  • Auto-approve low-risk changes (skip simple confirmations)
  • Skip repetitive explanations in Learning Mode
  • Parallel substory execution where possible
  • Fast-track phase approvals for clean code

🎯 Advanced Features:
  • Custom code review rules
  • Configurable test thresholds
  • Advanced refactoring suggestions
  • Performance profiling integration

⚙️ Customization:
  • Define your own quality gates
  • Set preferred patterns per project
  • Custom commit message templates

Enable Advanced Mode? [yes/not-yet/customize]

(You can always change this in .claude/user-preferences.json)

Adaptive behaviors by level:

Beginner:

• Learning Mode ON by default
• Detailed explanations
• All confirmations required
• Guided dependency resolution
• Thorough code review

Intermediate:

• Learning Mode Smart by default
• Condensed explanations
• Skip trivial confirmations
• Suggested fixes with approval
• Standard code review

Advanced:

• Learning Mode OFF by default
• Minimal explanations
• Auto-approve safe changes
• Auto-fix simple issues
• Streamlined code review with trends

---

Implementation Notes

All these features integrate seamlessly into the existing code-prd workflow:

1. Learning Mode: Triggered before each substory if enabled (Step 4.0)
2. Dependency Warnings: Checked before substory execution (Step 4.1)
3. Rollback Protection: Created at phase boundaries (Step 4.9)
4. Smart Test Suggestions: Integrated into test writing step (Step 5a)
5. Code Review Insights: Enhanced review output format (Step 5b)
6. Parallel Work Detection: Checked at phase boundaries before continuing (Step 6.5)
7. Context-Aware Suggestions: Shown at PRD completion (Step 7)
8. Adaptive Difficulty: Calculated at session start, influences all steps (Phase 0)

User preferences stored in .claude/user-preferences.json (auto-gitignored):

{
  "skill_level": "intermediate",
  "learning_mode": true,
  "auto_approve_safe_changes": false,
  "last_updated": "2025-10-26T14:30:22Z"
}

Important: This file is automatically added to .gitignore to prevent:

• Merge conflicts between developers
• Accidentally committing personal preferences
• Team preferences overwriting individual settings

The skill automatically ensures .gitignore contains:

# Claude Code user-specific files (do not commit)
.claude/user-preferences.json
.claude/checkpoints/