Daily Workflow

Effective patterns for everyday Claude Code use

Modified

February 25, 2026

Intermediate 12 min read Phase 3: Daily Work

This guide covers the patterns and habits that make Claude Code most effective for daily research work.

Starting Your Day

1. Open your project

cd ~/rashid-lab-setup/my-project
claude

2. Get oriented

> What's the current state of this project? Check git status
> and any recent changes.

Claude checks: - Git status (uncommitted changes, current branch) - Recent commits - Pipeline status (if using targets)

3. Review your plan

> Read docs/plans/ and summarize what I should work on today

Core Pattern: Explore → Understand → Modify

The most effective pattern for working with Claude:

Step 1: Explore

> What functions are in R/models.R?
> Show me the data processing pipeline
> How does the simulation work?

Step 2: Understand

> Explain the fit_model() function in detail
> What are the inputs and outputs of the clean_data target?
> Why are we using this specific prior?

Step 3: Modify

> Add a parameter to fit_model() for the learning rate
> Update the simulation to include a new scenario
> Fix the bug in calculate_statistics()

Avoid the “Just Do It” Trap

Asking Claude to “just make it work” without understanding the code leads to: - Harder debugging when things break - Less learning - Potential violations of lab standards

Take time to understand what you’re changing.

Task-Specific Workflows

Bug Fixing

> I'm getting this error: [paste error message]
> Help me understand and fix it

Claude will: 1. Analyze the error message 2. Find the relevant code 3. Explain the cause 4. Suggest a fix

Adding Features

> I need to add bootstrap confidence intervals to the analysis.
> What files would need to change?

Claude maps out the changes before making them, letting you validate the approach.

Refactoring

> This function is getting too long. Can you suggest how to
> break it into smaller functions?

Writing Tests (TDD)

Test-driven development — writing the test first, then the implementation — is one of the most effective Claude Code workflows for research code.

The pattern: describe what you want → get tests → get implementation

> I need a function called summarize_scenarios that takes a data.table
> with columns scenario_id, metric, and value, and returns a summary
> table with mean and sd per scenario.
> Write the tests first using testthat.

Claude writes the test file to tests/testthat/test-summarize_scenarios.R. Then:

> Now implement the function to pass these tests

Claude writes the function in R/summarize_scenarios.R. Then:

> Run the tests

Claude runs Rscript -e "testthat::test_file('tests/testthat/test-summarize_scenarios.R')" and you see the results.

Why TDD matters for research: Simulation code runs for hours on Longleaf. A bug discovered after a week-long run means re-running everything. Writing tests first catches logic errors in minutes, not days. Claude generates edge-case tests you might not think of — empty inputs, single-row data.tables, NA handling, boundary conditions.

The checkpoint connection: Commit after tests are written, commit after implementation passes. If you later change the function and tests break, git diff shows exactly what you changed (see Commits as Checkpoints).

More TDD examples for research code:

> Write tests for the bootstrap_ci() function. It should:
> - Return a named list with lower, upper, and estimate
> - Handle single-observation input gracefully
> - Use the seed from globals.yml for reproducibility
> - Work with both numeric vectors and data.table columns

> I have an existing function fit_model() in R/models.R that has no tests.
> Read the function, then write a comprehensive test suite for it.

TDD for R Packages

Lab template repos include a tests/testthat/ directory ready to go. When starting a new project from a template, ask Claude to write tests for your core functions before writing the functions themselves. The tests become your specification.

Documentation

> Add roxygen documentation to all functions in R/utils.R

Managing Context

Claude has a fixed-size context window — think of it as a desk. Your CLAUDE.md files, the code Claude reads, your conversation, and Claude’s responses all compete for space. When the desk fills up, older conversation gets compressed automatically. Understanding this shapes how you work.

Check your context

Run /context to see a visual grid of what’s consuming space, or /cost to see token usage:

> /context
> /cost

Keep sessions focused

One task per session works better than marathon sessions covering many topics. When you finish a task, start fresh with /clear rather than continuing in a growing conversation.

Use explicit file references

# Less effective (Claude searches everything)
> Update the model function

# More effective (Claude goes directly there)
> Update the fit_bayesian_model function in R/models.R

Let Claude read files — don’t paste them

Asking Claude to “Read R/analysis.R and fix the bug on line 34” is better than copying the file contents into the chat. File reads are efficient; pasted text consumes conversation context permanently.

Three strategies when context gets heavy

/compact — compress the noise, stay in the flow:

> /compact focus on the bootstrap function

Summarizes older exchanges while keeping key content. Use when you’re mid-task but context is filling up.

/clear — fresh start, same terminal:

> /clear

Wipes the conversation completely. CLAUDE.md reloads. Use this when switching tasks or after writing a plan file (see Plan→Implement Pattern below).

/rename + --resume — pause and come back later:

> /rename sensitivity-analysis
> /exit

Then tomorrow:

claude -c                          # resume most recent session
claude -r "sensitivity-analysis"   # resume a specific session by name

Full conversation history restored — Claude remembers where you were. Name sessions before stopping so they’re easy to find later.

See the Session Management reference for the full command list.

Consistency Files

The lab uses several files to maintain project consistency. Claude reads these automatically.

docs/plans/*.md

Design documents and implementation plans:

> Read docs/plans/2026-01-15-simulation-design.md and help me
> implement the next phase

config/globals.yml

Single source of truth for project constants:

# config/globals.yml
simulation:
  n_iterations: 1000
  seed: 42

model:
  prior_mean: 0
  prior_sd: 1

Tell Claude to use these values:

> Use the n_iterations value from globals.yml for the simulation

CHANGELOG.md

Track what’s changed:

> Add an entry to CHANGELOG.md summarizing today's changes

docs/DATA_PROVENANCE.md

Document where data came from:

> Update DATA_PROVENANCE.md with the new dataset I added

See the Project Consistency Framework for the full documentation.

Workflow Patterns

These three patterns build on each other and form the core of effective Claude Code usage.

Plan→Implement Pattern

The single most important workflow: plan in one context, implement in a fresh one.

When you’re thinking through a problem with Claude — exploring approaches, asking questions, debating tradeoffs — your context fills up with exploratory conversation. That’s fine for planning. But when you’re ready to build, you want full context capacity for writing code.

Session 1 — Plan:

> I need to add bootstrap confidence intervals to the analysis.
> Let's think through the design. What are the key decisions?

After a few exchanges, when you’ve converged on an approach:

> Write this plan to docs/plans/2026-03-01-bootstrap-ci-design.md.
> Include the decisions we made, the approach, and implementation steps.
> Commit this plan file.

Switch context:

> /clear

Session 2 — Implement:

> Read docs/plans/2026-03-01-bootstrap-ci-design.md and implement step 1

Claude has everything it needs from CLAUDE.md + the plan file, with full context capacity for writing code. The planning conversation is gone, but the decisions survive in the file.

When to use this pattern:

5-minute tasks — just do them, no plan needed
Anything requiring real design thought — new analysis pipeline, package architecture, manuscript restructuring — plan first, implement fresh

If you need to stop mid-implementation:

> /rename bootstrap-implementation
> /exit

Next day: claude -r "bootstrap-implementation" picks up exactly where you left off.

Commits as Checkpoints

Every commit is a save point. When Claude makes changes, commit early and often — not because you’re done, but because you’re creating checkpoints to debug from.

The pattern:

> Add a comment block explaining what this function does
> Commit this change

> Now refactor the function to use a helper for the repeated logic
> Commit this change

You now have two atomic commits. If the refactor introduced a bug:

> Show me what changed in the last commit

Claude runs git diff HEAD~1 and summarizes in plain English. Then:

> Something is broken after the last commit. Compare the current
> code to the previous commit and identify what might have caused it.

Claude reads the diff and pinpoints the issue — you don’t have to read the raw diff yourself.

Recovery options when a commit introduces a bug:

Approach	When to use
Ask Claude to fix it	Bug is clear, fix is small
`git checkout -- file.R`	Restore just one file to its pre-commit state
`git revert HEAD`	Undo the entire last commit cleanly

Key principle: Atomic commits = debuggable history. A 500-line commit is a nightmare to debug. A series of small, focused commits lets Claude trace exactly where things went wrong.

Improving CLAUDE.md Over Time

CLAUDE.md is a living document that gets smarter as you work. Every time Claude makes a systematic mistake, update CLAUDE.md so it won’t repeat it.

The feedback loop:

Claude makes mistake → you catch it (often via commit diff) →
fix the code → update CLAUDE.md with the lesson →
next session, Claude won't repeat it

Example — add a Lessons Learned section:

> In my CLAUDE.md, add a 'Lessons Learned' section. Include:
> - Never use tidyverse/dplyr — use base R and data.table
> - Never hardcode numerical values — always read from config/globals.yml
> - Never create renv.lock — dependencies go in DESCRIPTION
> - Always preserve random seeds for reproducibility

Example — add a naming taxonomy when Claude uses inconsistent names:

## Naming Conventions

| Canonical | Avoid |
|-----------|-------|
| `total_n` | `nmax`, `N`, `max_n` |
| `type1`   | `alpha`, `type_1_error` |
| `n_interim` | `n_looks`, `interim_count` |

After adding this to CLAUDE.md, Claude uses the right names in every future session.

What to add to CLAUDE.md:

Coding conventions Claude keeps violating
Project-specific naming rules
Common patterns that should be followed (e.g., “always use loader functions for config”)
Mistakes that have cost you time — prevent repeats

What not to add: Temporary task context, session-specific notes, or anything that changes frequently. CLAUDE.md should contain stable, long-lived project knowledge.

End of Day Checklist

Before ending your session:

1. Commit your work

> /commit

2. Update documentation

> Have I changed anything that should be documented?

3. Note tomorrow’s tasks

> What should I work on next? Add a note to docs/plans/

4. Push to remote

> Push to origin

Common Prompts

Task	Prompt
Check status	“What’s the git status and pipeline status?”
Run pipeline	“Run tar_make()”
Review changes	“/review”
Commit	“/commit”
Explain code	“Explain how [function] works”
Debug error	“I’m getting this error: [paste]”
Add feature	“I need to add [feature]. What files need to change?”
Clean up	“Are there any unused functions in R/?”

Efficiency Tips

Use skills

Skills are pre-defined workflows for common tasks:

> /review    # Code review
> /commit    # Commit workflow
> /validate  # Check project consistency

Batch similar tasks

> Add roxygen documentation to all functions in R/utils.R,
> R/models.R, and R/simulation.R

Let Claude suggest next steps

> What should I do next to finish this feature?

Use templates

When starting a new analysis or function:

> Create a new function following the pattern in analyze_data()

What Not to Do

Avoid	Instead
“Just make it work”	Understand the problem first
Huge multi-hour sessions	Focused 30-60 minute sessions; use `/clear` between tasks
Pasting file contents into chat	Ask Claude to read the file — saves context
Committing without review	Always run `/review` first
Ignoring lab standards	Reference globals.yml, follow style guide
Skipping documentation	Update docs as you go
Leaving CLAUDE.md stale	Update it when Claude makes repeated mistakes

Next Steps

Lab Integration — Deep dive into targets, git, Quarto
HPC Usage — Running Claude on Longleaf
Advanced — Custom skills, agents, and automation