Ds Implement

Overview

Apply output-first verification at every step of analysis implementation. This is Phase 3 of the /ds workflow.

Contents

• Delegation Pattern - Main chat orchestrates, subagents analyze
• The Iron Law - EVERY step MUST produce visible output
• Output-First Protocol - Required outputs by operation type
• Implementation Process - Step-by-step workflow
• Task Agent Invocation - Spawning sub-agents
• Verification Patterns - See references/verification-patterns.md
• Common Failures - Silent data loss, hidden nulls

Implementation (Output-First Verification)

YOU MUST NOT WRITE ANALYSIS CODE. This is not negotiable.

You orchestrate. Subagents analyze. STOP if you're about to write Python/R code.

Allowed in main chat:

• Spawn Task agents
• Review Task agent output
• Verify outputs exist and are reasonable
• Write to .claude/*.md files

NOT allowed in main chat:

• Write/Edit code files (.py, .R, .ipynb, etc.)
• Direct data manipulation
• "Quick analysis"

If you're about to write analysis code directly, STOP and spawn a Task agent instead.

Rationalization Prevention

Stop immediately when you encounter these rationalizations:

Delegation Pattern

For each task in PLAN.md:

1. Dispatch analyst subagent (does the work with output-first)
2. Verify outputs are present and reasonable
3. Dispatch methodology reviewer (for statistical tasks)
4. Log findings to LEARNINGS.md

Why delegate?

• Fresh context per task (no pollution from previous analysis)
• Enforced output verification (can't skip)
• Error isolation (bad analysis doesn't corrupt main context)

REQUIRED SUB-SKILL: For Task templates and detailed flow:

Skill(skill="workflows:ds-delegate")

Implement analysis with mandatory visible output at every step. NO TDD - instead, every code step MUST produce and verify output.

EVERY CODE STEP YOU WRITE MUST PRODUCE VISIBLE OUTPUT. This is not negotiable.

Before moving to the next step, you MUST execute the following:

1. Run the code
2. See the output (print, display, plot)
3. Verify output is correct/reasonable
4. Document in LEARNINGS.md
5. Only THEN proceed to next step

This applies even when YOU think:

• "I know this works"
• "It's just a simple transformation"
• "I'll check results at the end"
• "The code is straightforward"

If you're about to write code without outputting results, STOP.

What Output-First Means

The Mantra: If not visible, it cannot be trusted.

Red Flags - STOP Immediately

Output-First Protocol

For Every Data Operation:

# BEFORE
print(f"Before: {df.shape}")

# OPERATION
df = df.merge(other, on='key')

# AFTER - MANDATORY
print(f"After: {df.shape}")
print(f"Nulls introduced: {df.isnull().sum().sum()}")
df.head()

Required Outputs by Operation Type

Implementation Process

Step 1: Read Plan

Read the plan to understand task order:

cat .claude/PLAN.md  # View analysis plan and task sequence

Follow the task order defined in the plan.

Step 2: Implement with Output

For each task:

# Task N: [Description]
print("=" * 50)
print("Task N: [Description]")
print("=" * 50)

# Before state
print(f"Input shape: {df.shape}")

# Operation
result = do_operation(df)

# After state - MANDATORY
print(f"Output shape: {result.shape}")
print(f"Sample output:")
display(result.head())

# Verification
assert result.shape[0] > 0, "No rows returned!"
print("Task N complete")

Step 3: Log to LEARNINGS.md

Document every significant step:

## Step N: [Task Description]

**Input:** DataFrame with shape (10000, 15)

**Operation:** Merged with reference table on 'id'

**Output:**
- Shape: (9500, 20)
- 500 rows dropped (no match)
- 5 new columns added
- No new nulls introduced

**Verification:**
- Row count reasonable (5% drop expected due to filtering)
- Sample output matches expected format
- Key columns preserved

**Notes:** [Any observations, issues, or decisions]

Task Agent Invocation

Main chat spawns Task agent:

Task(subagent_type="general-purpose", prompt="""
Implement [TASK] following output-first protocol.

Context:
- Read .claude/LEARNINGS.md for prior steps
- Read .claude/PLAN.md for task details
- Read .claude/SPEC.md for objectives

Output-First Protocol:
1. Print state BEFORE each operation
2. Execute the operation
3. Print state AFTER with verification
4. Display sample output
5. Document in LEARNINGS.md

Required outputs per operation:
- Shape before/after
- Null counts
- Sample rows (head)
- Sanity checks (row counts, value ranges)

DO NOT proceed to next task without:
- Visible output showing operation worked
- LEARNINGS.md entry documenting the step

Report back: what was done, output observed, any issues.
""")

Verification Patterns

See references/verification-patterns.md for detailed code patterns for:

• Data loading, filtering, merging
• Aggregation and model training
• Quick reference table by operation type

Common Failures to Avoid

Logging

Append each step to .claude/LEARNINGS.md:

## Step N: [Description] - [STATUS]

**Input:** [Describe input state]

**Operation:** [What was done]

**Output:** [Shape, stats, sample]

[Paste actual output here]

**Verification:** [How you confirmed it worked]

**Next:** [What comes next]

If Output Looks Wrong

1. STOP - do not proceed
2. Investigate - print more details
3. Document - log the issue in LEARNINGS.md
4. Ask - if unclear, ask user for guidance
5. Fix - only proceed after output verified

Never hide failures. Bad output documented is better than silent failure.

No Pause Between Tasks

Your pausing between tasks is procrastination disguised as courtesy.

Phase Complete

REQUIRED SUB-SKILL: After all analysis steps complete with verified output, IMMEDIATELY invoke:

Skill(skill="workflows:ds-review")