Claude Code reads project files, edits files, and runs commands. This guide uses those capabilities in a workflow you define: prepare verified prospect data, write explicit first-line rules, name the input and output files in the prompt, then audit each result before outreach.
Prepare verified prospect data
Choose a structured format: CSV, JSON, or a plain text list. Include fields you can cite: company name, role, public launch, funding announcement, published article. Exclude inferred sentiment, guessed pain points, or unconfirmed internal projects. Name the file descriptively and reference it exactly in your prompt.
Claude Code accesses files in your current directory and subdirectories. You give permission through the tool's file read capability. Place your prospect file in the same directory where you'll run the claude command.
Data rule: If a field can't support a factual first line, remove it. 'Industry: SaaS' is too broad. 'Launched X feature last week' is specific. Use the specific.
Store your data in a format that preserves structure and clarity. If using CSV, ensure headers are lowercase and consistent, such as company_name, role, recent_event. For JSON, use arrays of objects with uniform keys. Avoid nested structures unless necessary and supported by your workflow.
Reference the filename exactly in your prompt to direct Claude Code's file access. For example, include 'Use data from prospects.csv' so the model knows which file to read. Verify file location by running pwd or ls in your terminal before starting.
- Use fields confirmed in public sources.
- Prefer recent, observable events over static attributes.
- If sourcing from LinkedIn or press, save a timestamped note for verification.
Write first-line rules in CLAUDE.md
CLAUDE.md is your instruction manual. Claude Code loads it at the start of a session. Write rules that define the task, constrain creativity, and specify the deliverable.
The official documentation states Claude Code gains access to your CLAUDE.md file when you run claude in a directory. It's part of the context window. Use it to store persistent rules.
Instruction example: Your CLAUDE.md might start with: 'Generate one cold email first line per row in prospects_verified.csv. Use the company_name and recent_activity columns. The line should reference the activity factually. Output format: one line per row, plain text.'
- State the input file: 'Read prospects_verified.csv.'
- List allowed source fields: 'Use company_name and recent_activity.'
- Define the tone: 'Write in a direct, professional voice.'
- Set factual boundaries: 'don't invent or assume any details.'
- Specify the output: 'Write each first line on its own line in a new file named first_lines.txt.'
Ask Claude Code to create the output file
Change to your project directory: cd /path/to/your_project. Start Claude Code: claude. Issue your prompt: "Read prospects_verified.csv and write first lines to first_lines_candidates.txt per CLAUDE.md rules." Let Claude Code finish.
Prompt note: Be explicit. Name the input file, reference CLAUDE.md, and name the output file. Claude Code follows these instructions but won't guess your intent.
Once in your project directory, initialize Claude Code with claude. Confirm the input file path is correct, choose a filename and name it explicitly in your prompt, such as prospects_verified.csv. Reference your rule file by name: CLAUDE.md. Specify the desired output: first_lines_candidates.txt.
This directs Claude Code to read, process, and write based on your defined logic.
- Ensure prospects_verified.csv includes fields like name, company, and recent_activity as placeholders for personalization.
- Verify CLAUDE.md contains clear, actionable formatting and content rules for first lines.
- After prompting, review the generated file for adherence to rules before proceeding.
The workflow this guide walks through, end to end. Focus: Ask Claude Code to create the output file.
Audit facts, style, and readability
Review each generated line. Compare it to the source data row. Reject lines that add facts, use vague language, or sound robotic.
Weak output usually points to a problem in the input data or the instructions. If lines are generic, your rules might be too vague. If facts are wrong, your data might be noisy.
Audit checklist: For each candidate: 1. Match to source row. 2. Verify no added facts. 3. Check for clichés. 4. Read it aloud. Does it sound like email? If yes, keep it.
- Fact check: Does the line contain only data from the prospect file?
- Style check: Is the tone consistent with your CLAUDE.md rules?
- Readability check: Is the sentence clear, concise, and natural?
- Uniqueness check: Are multiple lines using the same template phrase?
Refine the failed instruction and rerun
Update CLAUDE.md based on audit failures. Keep the prospect data unchanged. Rerun Claude Code to generate new candidates. Compare results to measure improvement.
Refinement rule: Change only one instruction at a time. Test the change. Isolate what fixes the problem. This keeps your rules minimal and understandable.
If the output misses the mark, revisit CLAUDE.md with a focus on precision. Did the model overgeneralize or underuse provided data? Adjust one rule at a time to influence phrasing, specificity, or tone. Keep the prospect data constant to isolate changes in behavior.
Rerun the workflow and observe shifts in output quality.
Audit-forward refinement: For example, if first lines lack personalization, add: 'Include the prospect's recent_activity verbatim when present.' This grounds output in data without overreach. Test iteratively.
- Is the output too generic? Add a rule: 'Use the exact activity phrase from the data.'
- Is the output invented? Add a rule: 'don't infer any context beyond the provided fields.'
- Is the output awkward? Add a rule: 'Write in simple, declarative sentences.'
- Rerun: claude and prompt again with the updated CLAUDE.md.
Export audit-passed first lines
Create a clean export file containing only the first lines that passed your audit. Include a reference to the source prospect for tracking.
The output is plain text. It works with any system that accepts CSV or simple lists. The workflow doesn't integrate with a specific tool. It produces a file you use elsewhere.
Export format: Keep it simple: prospect_id,first_line. One row per approved opener. This is portable and easy to validate.
Use a consistent naming convention for export files, such as first_lines_approved_YYYYMMDD.csv. This supports versioning and traceability across runs. Automate the export step with a script if repeating frequently.
Process tip: Review the final list one last time before export. A quick scan catches edge cases like duplicated lines or truncated text. This final check improves reliability.
- Create a new CSV or text file for the final output.
- Map each passing first line back to its prospect identifier.
- Don't include the audit-failed lines.
- Use this file as the input for your email sending workflow.
Scale the workflow with batch processing
Process large prospect lists in batches. Generate lines for each batch, audit them separately, then combine the results. Use background sessions if you want to queue the generation step.
The official CLI reference includes a --bg flag to start a session as a background agent.
For a systematic audit, maintain a simple checklist in your project notes. Check for factual accuracy against the source data, adherence to your style rules, and natural readability before approving a batch for export.
- Split your prospect CSV into files of 20-30 rows each.
- Run claude separately on each file, adjusting the input filename in your prompt.
- Audit each output file before moving to the next batch.
- Combine all audit-passed lines into one final export file.
Decide when this method beats a template
Choose this method for high-value, data-rich outreach. Use templates for high-volume, low-context campaigns. The decision hinges on your data quality and your tolerance for setup time.
Recommendation: Start with a 50-prospect test. Run this workflow. Send the emails. Track replies. Compare to your baseline. Let the results guide your investment.
Recommendation: Run this workflow. Send the emails. Track replies.
If your test shows a clear reply-rate lift, you've validated the investment. If not, inspect your data freshness and prompt specificity before scaling. This method thrives on precise, actionable signals from your prospects.
- Use personalized first lines when you have verified, recent prospect activity.
- Use templates when data is generic or outdated.
- Test both methods on similar prospect segments.
- Measure reply rates, not just open rates.
Frequently Asked Questions
Which prospect details should the input include?
Use verified fields that the first-line rules reference. Prospect name, role, company, and a concrete research note are useful examples; leave out speculative details.
How should I write the first-line rules?
State the allowed source fields, forbidden phrases, desired shape, and output filename explicitly. Include a short tone example instead of depending on implied intent.
How should I audit the generated first lines?
Compare each line with its source record and every written rule. A line fails when it invents a fact, misstates the prospect, repeats a pattern, or ignores a constraint.
What should I change when the output misses a rule?
Make the failed rule more specific, rerun the same prompt, and audit the replacement output. Keep the verified input unchanged unless the source record itself is wrong.