---
name: Investigate Before Commit
trigger: "Should I commit to this approach?"
answer: "Investigate first, gather evidence"
description: Pause and investigate before committing to any technical decision
---

# Investigate Before Commit


**When to use:** Before committing to ANY technical decision or implementation approach

**Trigger:** Thinking "Let's build X" or "This should work"

**Action:** STOP → Investigate → Gather evidence → Then decide

## Core Principle

**Before commitment, gather evidence. Before implementation, validate assumptions.**

## Decision-Making Protocol

1. **Pause** → Don't react immediately to requests
2. **Investigate** → Gather data, read code, test assumptions
3. **Analyze** → Identify patterns, risks, trade-offs
4. **Evaluate** → Weigh options against evidence
5. **Respond** → Provide recommendation with supporting data

## Evidence Gathering Before Commitment

**Pattern:** Investigate first, commit later

**For simple tasks:** Quick validation (read existing code, check patterns)
**For complex features:** Multi-stage investigation (see @.genie/spells/wish-lifecycle.md)

### Investigation Discipline

**Phase 1: Evidence Collection**
- Read existing code and patterns
- Test current behavior
- Validate assumptions with proof-of-concept
- Document findings in reports (`.genie/reports/`)

**Phase 2: Risk Assessment**
- What could go wrong?
- What are the trade-offs?
- What dependencies exist?
- What's the blast radius of failure?

**Phase 3: Decision Matrix**
- Ease: How difficult is the change?
- Impact: What improves and by how much?
- Risk: What's the probability × severity of failure?
- Confidence: How certain are we about the approach?

**Phase 4: Recommendation**
- Go/No-Go with confidence score
- Timeline and resource requirements
- Phased rollout strategy (if applicable)
- Success criteria and validation checkpoints

### Example: Issue #120 (Forge Executor Replacement)

**Investigation Phase:**
- 7 comprehensive reports (~5,000 lines)
- POC implementation (300 lines, working code)
- API validation (80+ endpoints tested)
- Comparison analysis (Forge vs existing patterns)

**Decision Matrix:**
- Ease: 7/10 (moderate complexity)
- Impact: 9/10 (eliminates bugs, simplifies code)
- Risk: 3/10 (POC validated, phased rollout planned)
- Confidence: 9.2/10 (STRONG YES)

**Outcome:** Evidence-backed decision with clear implementation roadmap

## Communication Patterns

### Validation Openers

Use these phrases to signal evidence-based approach:
- "Let me investigate that claim..."
- "I'll validate this assumption by..."
- "Before we commit, let me check..."
- "The evidence suggests..."
- "Testing shows that..."

### Respectful Disagreement

When evidence contradicts assumptions:
1. Acknowledge the assumption: "I understand the intuition that..."
2. Present evidence: "However, testing shows..."
3. Explain implications: "This means we should..."
4. Offer alternative: "Instead, I recommend..."

## Anti-Patterns

❌ **Assume without testing:** "This should work" → Test it first
❌ **Commit before investigation:** "Let's build X" → Investigate feasibility first
❌ **Ignore contradicting evidence:** "But I thought..." → Update beliefs
❌ **No decision checkpoint:** Jump from idea → implementation without Go/No-Go
❌ **Claim process knowledge without investigation:** Listing implementation steps when automation exists
  - Example: "Update package.json" (automated by GitHub Actions)
  - Correct: "Let me investigate the release workflow first"
  - Pattern: Read workflow files, check automation, THEN provide orchestration steps

## Evidence

**Pattern discovered:** Issue #120 investigation flow (2025-10-18)
**Result:** High-confidence decision (9.2/10) with comprehensive implementation plan
**Key learning:** Investigation time is investment, not waste