AMindToThink/import-content

Import Content: Script-Generated Tables and Numbers

Core rule: Never hand-copy numbers into documents. Scripts generate output files, documents import them. This eliminates transcription errors.

The target document is: $ARGUMENTS

Step 1: Identify What Needs to Be Generated

Read the target document and find any tables, numeric results, or data-driven content that should come from a script. Look for:

• Tables with numeric data
• Inline statistics cited in prose
• Any number that came from a computation

Step 2: Find or Create the Generating Script

Check if a script already generates these numbers. Search for:

• Scripts that write to results/tables/, results/, or similar output directories
• Scripts that print summary tables to stdout
• Existing \input{} or include directives in the document

If no script exists, create one that:

• Reads from the authoritative data source (computed results, JSON sidecars, CSVs)
• Computes the exact metrics needed
• Writes output files in the appropriate format (see Step 3)

Step 3: Write the Output File

For LaTeX

Generate only the tabular body (not the full table environment). The document keeps \begin{table}, \caption{}, \label{}.

Output file (results/tables/my_table.tex):

% Generated by: scripts/my_analysis.py --run-tag my_tag
% Data source: results/my_data/summary.json
\begin{tabular}{@{}lrrr@{}}
\toprule
Metric & prompt\_gen & resp\_gen & story\_gen \\
\midrule
Our metric & +0.683 & +0.437 & +0.405 \\
Baseline   & +0.728 & +0.532 & +0.633 \\
\bottomrule
\end{tabular}

The document includes it:

\begin{table}[t]
\centering
\caption{My caption here.}
\label{tab:my-table}
\input{../results/tables/my_table.tex}
\end{table}

For Markdown

Markdown has no native include mechanism, so use marker comments that a script can find and replace. The table lives inline in the document (preserving readability) but is populated by the script, never by hand.

In the document, wrap each table with BEGIN/END markers:

Some prose introducing the results:

<!-- BEGIN GENERATED TABLE: my_table -->
<!-- END GENERATED TABLE: my_table -->

More prose continues here...

The generating script writes both:

1. A standalone .md file (for diffing/reference):

<!-- Generated by: scripts/my_analysis.py --run-tag my_tag -->
<!-- Data source: results/my_data/summary.json -->

| Metric | prompt_gen | resp_gen | story_gen |
|--------|-----------|---------|----------|
| Our metric | +0.683 | +0.437 | +0.405 |
| Baseline | +0.728 | +0.532 | +0.633 |

2. The same content inline into the document between the markers, via a --update-paper (or similar) flag that does a regex replace of everything between BEGIN and END for each table name.

The update flow is always: run the script, it reads data and writes into the document. Never edit the content between markers by hand.

Initial wiring: When first adding markers to a document with existing hand-written tables, create a one-time migration script that finds each table and wraps it with the appropriate BEGIN/END markers. Then run the generating script with --update-paper to replace the hand-written content with authoritative data.

Step 4: Wire the Document

Replace hand-written content with the import directive.

For LaTeX:

1. Keep the \begin{table}, \caption, \label in the document
2. Replace the \begin{tabular}...\end{tabular} block with \input{path/to/generated.tex}
3. Ensure \graphicspath or relative paths resolve correctly

For Markdown:

1. Wrap each table with <!-- BEGIN GENERATED TABLE: name --> / <!-- END GENERATED TABLE: name --> markers
2. Run the generating script with its update flag to populate content between markers from data
3. Do NOT hand-copy generated values into the markers — this defeats the entire purpose. The script writes into the document; you only add the empty markers.

Step 5: Verify the Round-Trip

1. Run the generating script
2. Check the output file exists and looks correct
3. Build the document (e.g., cd paper && latexmk -pdf)
4. Verify the rendered table matches the output file exactly
5. Confirm the provenance comment in the generated file cites the correct script and data source

Anti-Patterns — Do NOT

• Copy numbers from script output into the document by hand — even "just this once". For Markdown, always let the script's --update-paper flag write between the markers
• Round numbers differently between the script output and the document
• Use a different data subset than what the script computes (e.g., with_hds vs no_hds)
• Put captions inside the generated file — they'll be overwritten on regeneration
• Forget the provenance comment — every generated file must say how to regenerate it
• Write numbers from memory or conversation context — if you can't point to the file that contains the number, don't write it

Last Resort: Recovering Results from Claude Code Conversation Logs

If a script computed results but never saved them to a file (e.g., only printed to stdout, or run ad-hoc), the numbers may still exist in Claude Code's conversation logs. These logs store all tool outputs including bash stdout.

Where logs live: ~/.claude/projects/<project-path>/<conversation-uuid>.jsonl

Log format: JSONL, one JSON object per line. Tool outputs are in entries with "type": "tool_result" and the stdout is in toolUseResult.stdout.

Search tool: Use the trustable script ~/.claude/.claude-tools/search-claude-logs.py to search logs:

~/.claude/.claude-tools/search-claude-logs.py "pass@1.*0.432" --context 5
~/.claude/.claude-tools/search-claude-logs.py "power analysis" --project ~/.claude/projects/-home-user-myproject

It auto-detects the project from cwd, searches all conversation JSONL files, and shows matching tool outputs with context.

Recovery procedure:

1. Search logs with search-claude-logs.py using distinctive numbers or keywords from the missing results
2. Once you find the relevant tool output, identify the original data source or script that produced it
3. If the raw data still exists (e.g., eval_results.json) but was never summarized, write a script that reads the raw data, computes the summary, and saves it as JSON. This is preferred because it produces a clean, re-runnable pipeline
4. If neither the raw data nor a cheap rerun is possible, write a script that programmatically parses the log entry and saves the extracted values as JSON — still no hand-copying into the document

When to use log recovery vs. rerunning: If the experiment was cheap (minutes), rerunning with proper JSON output is simpler and more trustworthy. If the experiment was expensive (hours of GPU time), log recovery is the right call — that's the whole reason to do this.

This is a backup for results computed before the "always save structured output" protocol was in place. It should never be the primary data source for new work.

Provenance Comment Format

Every generated file MUST start with:

% Generated by: <script-path> <arguments>
% Data source: <input-data-path>

For Markdown, use <!-- --> comments instead of %.