Prompt Chain: Carry a SAP Through TLF Shells to Programming Specs

What This Builds

A single Claude conversation, or a thread inside your existing SAP Project, that carries one study's approved SAP analysis section through three connected drafting steps: TLF shells, then programming specifications for each shell, with your review sitting between every step. The Level 3 Project drafts SAP sections in isolation. This chain starts one step later, after the SAP section is approved, and keeps going. It hands its own output back to itself twice, so the shells and specs come from the same conversation instead of three separate blank-page sessions.

Prerequisites

• A Claude Project already holding your SAP templates and house style, built from the Level 3 guide
• An approved SAP primary and secondary analysis section for the study you're working on
• Pro subscription ($20/month). This is the same plan the Level 3 Project setup already requires, so building this chain adds no new subscription cost.

The Concept

Think of this less as three separate requests and more as handing a colleague the same folder three times in a row, each time with your corrections from the last pass already applied. The output of step one, the TLF shells, becomes part of the input for step two, the programming specs. Because it all happens in one conversation, Claude can see the shells it already drafted when it writes the specs, so the column names, population definitions, and statistical methods stay consistent across both documents instead of drifting the way they can when two people draft them separately on two different days.

The chain only works if you read and correct each step before moving to the next one. Feeding an uncorrected shell into the spec step just propagates whatever was wrong with the shell.

Build It Step by Step

Part 1: Start the chain in your SAP Project

Open the Claude Project you built in the Level 3 guide. Start a new chat inside that Project so it has access to your uploaded SAP templates and house style notes. Paste the approved SAP analysis section for the study, with any subject-level detail stripped, and prompt for the first link in the chain:

I'm starting a three-step drafting chain for [study name/ID]. Step 1: draft TLF
shells for the primary efficacy table and two secondary tables described in the
SAP section below, using our standard shell format (title, population, row and
column structure, footnote placeholders). Do not draft the programming
specifications yet, I'll review the shells first.

[paste SAP primary and secondary analysis section]

Read the shells against the SAP line by line. Fix anything that's wrong for that study, a missing stratification factor, a subgroup the shell dropped, directly in the chat, either by editing your own message or replying with a correction and asking Claude to regenerate just the affected shell.

Part 2: Feed the approved shells into the spec step

Once the shells are right, keep the same conversation open and move to the second link:

The shells above are now approved. Step 2: draft a programming specification for
the primary efficacy table shell, covering the analysis dataset, the population
definition, the statistical method and any assumptions, and the derivation logic
for each column. Match the format of our standard programming spec, not a
generic template.

Repeat for each secondary table shell, one prompt per table, rather than asking for all three specs at once. A single request covering three tables is harder to check carefully. Mistakes in one spec are easier to catch before they leak into the drafting habits used for the other two.

Part 3: Check the chain end to end

Before the specs leave your hands, reread the whole thread from the SAP section down through the last spec. Check that the population definition in the spec matches the shell, that the shell matches the SAP, and that no table picked up a stray assumption Claude introduced along the way, a default alpha, a missing-data handling rule you didn't specify. This end-to-end reread catches drift a single-step review misses, because an error introduced in step one can look locally correct in step two even though it no longer matches the SAP.

Real Example: A Phase 2 Efficacy Analysis

Setup: A biostatistician has an approved SAP section describing a stratified randomized trial, 400 participants, an intent-to-treat primary analysis using a mixed-effects model, with two secondary endpoints analyzed by logistic regression.

Input: The SAP's primary and secondary analysis paragraphs, pasted into a Claude Project chat that already holds the organization's shell and spec templates.

Output: Step 1 produces three TLF shells, one primary and two secondary, in the house format, with placeholder footnotes for the exact stratification factors. The statistician corrects one shell where Claude used the wrong denominator population, and then approves all three. Step 2 produces a full programming specification for each shell, referencing the corrected population definitions and the mixed-effects model structure from the SAP, ready for a programmer to pick up.

Time saved: Drafting three shells and three specs from scratch across separate sessions typically runs 3 to 4 hours combined. The chained version, including the review time between steps, runs 1 to 2 hours. The specs no longer need to be checked against the shells from a cold start, since they were already built from the approved versions.

What to Do When It Breaks

• Claude drops a detail between steps, like a stratification factor mentioned in step 1 but missing from step 2 → Paste the missing detail back in explicitly rather than assuming the model remembers everything from ten messages ago in a long thread. Long conversations lose fidelity on details that weren't restated recently.
• The programming spec reads like a generic template instead of matching your house format → Point Claude back to a specific uploaded example in the Project and ask it to match that document's structure section by section, rather than asking generally for "our format."
• A correction you made to one shell doesn't carry through to its spec → This means you approved and moved on before the correction actually registered. Always paste the corrected shell text back into the step 2 prompt rather than trusting the model to remember your edit from a few messages earlier.

Variations

• Simpler version: Run just steps 1 and 2 for the primary table alone, skipping secondary tables, when you only need to move fast on the one table that matters for a go/no-go decision.
• Extended version: Add a fourth step that drafts a QC checklist tailored to each spec's data flow, so the reviewer who eventually validates the program has a starting checklist instead of using the generic team one.

What to Do Next

• This week: Run the chain on one real study and time it against your usual process, so you have your own comparison number instead of taking this guide's estimate on faith.
• This month: Save the chain's prompt structure, the "Step 1... Step 2..." framing, as a template in the Project's instructions so every new study starts the chain the same way.
• Advanced: Pair this chain with the Custom GPT QC reviewer guide, running the finished specs' eventual code through that reviewer before the human QC pass.

Advanced guide for statistician professionals. These techniques use more sophisticated AI features that may require paid subscriptions.