AI for Programming Clients Returning From Injury: A Real Workflow for the Post-Rehab Gap

There's a version of this client on every coach's roster eventually. They tore something or strained something. They did their time in physio. They got discharged with a sheet of band exercises and a "you're good to start loading again."

And now they're back in your inbox asking for a program. They are not ready for their old one. They're also not injured anymore, so the physio is done with them. The eight weeks between "discharged" and "training like before" belongs to you, and nobody's certification spent much time on it.

It's also a stretch where AI, used lazily, is at its most dangerous. Ask ChatGPT for a program and mention the injury in passing, and you'll get one of two failures: a plan that forgets the injury by exercise four, or a plan so wrapped in bubble wrap that your client, who was cleared and wants their life back, quits it in week two.

Here's the thing: the post-rehab gap is actually a strong use case for AI, because it's a programming problem with unusually explicit constraints. The physio handed you a list of rules. AI is good at following rules, if you make the rules impossible to ignore. That's what this workflow does.

One boundary before anything else, because it shapes every prompt in this article.

The Line You Don't Cross (And the Gap That's Yours)

You're a coach, not a clinician. The same logic we laid out for nutrition coaching when you're a trainer, not a dietitian applies here, and it's worth stating plainly:

The physio's job: diagnose, treat, rehabilitate, and decide when the client is cleared, and cleared for what.

Your job: program training forward from that clearance. You work within the restrictions, you don't reinterpret them, and you don't treat anything.

The practical rule: you program forward from discharge, never backward into treatment. If a client hasn't been discharged, or was never assessed at all ("it's been sore for a few months, I figured it'd sort itself out"), the first program you write is a referral. That referral is the difference between a client who rebuilds and one who re-tears something because their coach guessed.

But once they're discharged? The gap is genuinely yours. Physios rehabilitate the tissue; they don't program a training block. Most discharge advice amounts to "build back gradually." Turning that into eight weeks of actual training (sets, loads, substitutions, progression) is coaching work. It's the same population-specific programming we covered for coaching clients over 50, except here the constraints are temporary and they come with an expiry date you don't set.

Why AI Defaults Fail This Client in Both Directions

Generic AI programming has predictable failure modes. With a post-rehab client, four of them get sharper teeth:

1. Restriction decay. Tell a model "recovering from a shoulder injury, avoid heavy overhead pressing" and watch what happens across a long conversation. Week one of the output respects it. By the time you've asked three follow-up questions, there's a push press in Thursday's session. Models hold constraints loosely unless the constraint is restated and audited. Your client's shoulder does not get looser about it.

2. "Cleared" read as "back to baseline." Feed AI a training history with a 225 lb squat in it, and it will program from 225, because that's the number on the page. It has no concept of what twelve weeks of not squatting does to a person. The client's log is a record of who they were. The program has to start from who they are.

3. Bubble wrap. The opposite failure. Some models, primed by the word "injury," go so conservative the program stops being training. Everything becomes bands and bodyweight, including for the three-quarters of the body that was never hurt. A client who tweaked a hamstring does not need their bench press rehabilitated. Over-caution costs trust the way recklessness costs tissue. Clients can tell when a plan doesn't believe in them.

4. Confident clinical improvisation. Ask why it made a choice, and a model will produce fluent, medical-sounding reasoning it is not qualified to have: tissue healing timelines, "safe" ranges of motion, when pain is fine to push through. Some of it is right. You can't tell which part. Any answer that reads like a clinical judgment isn't the model's to make, and it isn't yours either. It's the physio's, and it should already be encoded in the restrictions.

The fix for all four is the same: get the clearance onto paper in programming terms, force every output to run through it, and keep the clinical judgments out of the loop entirely.

The Context Block: Turning a Discharge Into Programming Inputs

Everything starts with a short, structured block you write once and paste at the top of every prompt for this client. Building it is a ten-minute conversation at re-onboarding. Treat it like the intake it is.

Five sections:

1. What happened, in plain terms. The injury, when it happened, and how long they were out of normal training. No diagnosis codes, no speculation. "Right shoulder, rotator cuff strain, non-surgical, 10 weeks of physio" is enough.

2. The clearance, verbatim. This is the load-bearing section. Two lists, in the physio's words as relayed by the client: cleared for and not yet cleared for. If the client can't remember, have them ask. Physios answer this question happily, and "ask your physio these three questions" is a better re-onboarding step than guessing. If there's a review appointment coming, note the date: restrictions have an expiry.

3. Current demonstrated capacity. Skip the old log here and record what they can do now: what the physio had them doing in the final weeks, what they've tested pain-free since. This is the number the program starts from.

4. The pain rules. Most physios give discharge guidance like "some discomfort during is fine, sharp pain means stop, symptoms shouldn't be worse the next day." Write down whatever your client was actually told. These rules are the physio's, and they travel with the program. You're the courier.

5. The old normal. Their pre-injury training, so the model knows what we're rebuilding toward, and so the untouched parts of their body keep training like the trained parts they are.

A working example:

Client: M, 41, desk job, 8 years training. Right shoulder rotator
cuff strain (non-surgical), discharged last week after 10 weeks
of physio.

Cleared for: all lower body, all pulling, pressing below shoulder
height with dumbbells, gradual load progression.

Not yet cleared for: barbell bench, overhead pressing, dips,
anything overhead ballistic. Review appointment in 6 weeks.

Current capacity: pain-free DB floor press at 30 lb for 12 in
final physio weeks. Lower body untouched by the injury; squatted
275 before, hasn't squatted in 10 weeks.

Pain rules (from physio): mild ache during pressing OK if gone by
next morning. Sharp or radiating pain = stop the exercise, note it.

Old normal: 4 days/wk upper/lower, main lifts 275 squat /
315 dead / 205 bench.

One thing that block deliberately doesn't contain: the discharge paperwork itself. Summarize, de-identify, keep names and clinic details out of the prompt. We covered the client-data boundary in the AI disclosure article, and it applies double when the data is about an injury.

Prompt 1: The Rebuild Block

Ask for the shape of the return, with the rules welded on:

You are helping an experienced coach program a return-to-training
block for a post-rehab client. The client is discharged from
physiotherapy. Here is the context:

[paste context block]

Draft a 6-week block, 4 days/week, upper/lower. Rules:
1. The "not yet cleared for" list is absolute. Do not include
   those movements or close variants, and do not schedule their
   return; that decision belongs to the physio at the review
   appointment.
2. Start all loading for the affected area from current
   demonstrated capacity, not pre-injury numbers. Load increases
   of no more than 10% per week for the affected area.
3. Program uninjured areas as a normal returning-from-a-layoff
   trainee: start around 70% of old working loads and rebuild
   over the block.
4. Include the pain rules in the program notes exactly as written.

State every assumption you made, and flag anything in my context
that is missing or contradictory.

The two-speed structure in rules 2 and 3 is what generic prompts never produce: the shoulder rebuilds on one timeline, the rest of the body on another, and neither gets the other's treatment. And the clause forbidding the model from scheduling the restricted movements' return keeps it from playing physio. The review appointment makes that call.

Prompt 2: The Substitution Map

Every restricted movement leaves a hole in the program. You want to know exactly what's filling each hole and what's still missing:

For each movement on the "not yet cleared" list, give me: the
cleared substitution you'd program in its place, what the
substitution preserves, and what it doesn't cover: the specific
quality we're accepting a pause on until clearance.

Review your own list against the client's constraints. If a
substitution is a close variant of a restricted movement,
replace it.

That second column (what the substitution doesn't do) is the honest one. A floor press keeps the pressing pattern alive; it doesn't maintain overhead capacity, and nothing cleared will. Knowing what's genuinely on pause tells you what the first weeks after full clearance need to reintroduce, gently. The self-review line catches the model's favorite trick of substituting a landmine press for an overhead press and calling it solved.

Prompt 3: The Restriction Audit

Same philosophy as the volume audit in our hypertrophy workflow: before any program reaches the client, make the model check its own work.

Audit the program below against the context block. Do not rewrite
anything yet.

1. List every exercise that appears on, or is a close variant of,
   the "not yet cleared" list.
2. For the affected area, calculate the week-over-week load
   progression and flag anything above 10%.
3. Flag any week where the affected area's volume or intensity
   jumps while the pain rules would have no data yet (e.g., a new
   movement and a load increase in the same week).
4. Confirm the pain rules appear in the client-facing notes.

Table first, then recommended fixes.

Run it on every revision, not only the first draft. Restriction decay happens across a conversation, so the audit belongs at the end of one, right before anything ships. Thirty seconds of prompt, and it catches the push press that crept into Thursday.

The Signals That Send It Back to the Physio

The workflow above handles the programming. This part is the coaching, and no prompt owns it:

• Pain outside the rules. Sharp, radiating, or worse the next morning: the client stops, you note it, and if it repeats they're messaging the physio, not pushing through week 4.
• Going backward. Capacity that was building and then drops without an obvious reason is a question for the physio.
• The client negotiating with the restriction list. "It feels fine, can we try bench?" is the most human sentence in post-rehab coaching, and the answer lives with the person who wrote the list. Your line: "If it's feeling that good, tell your physio at the review. That's how the list gets shorter."

None of this is AI's call, and honestly, none of it is yours either. The value you add is noticing early and routing it to the right professional. That habit is what keeps this client for the next five years. Clients don't remember the substitution map. They remember that you took the thing seriously and got them back to their old numbers without a setback.

What to Do Next

The post-rehab gap comes down to one intake conversation and three prompts: turn the discharge into a context block, ask for a two-speed rebuild, map the substitutions honestly, and audit every draft against the restriction list. The physio's rules travel with the program, and the clinical calls stay with the physio. The eight weeks of getting a person back to what their body can do are yours.

And when the review appointment clears the last restriction, you'll have a client with a rebuilt base and proof their coach knows what to do when things go wrong. That's worth more than any program.

Frequently Asked Questions

Is post-rehab programming even in scope for a personal trainer?

After discharge, yes: programming training within a clinician's stated restrictions is coaching, and it's a service physios are generally glad someone competent is providing. Before discharge, or with no assessment at all, no. The workflow in this article assumes a discharged client with explicit clearances. If you don't have those, your first step is sending the client to get them.

Can I paste the client's discharge notes into ChatGPT?

Don't upload the document. Summarize the relevant parts into the context block, stripped of names, clinic details, and anything identifying. The model needs "not cleared for overhead pressing, review in 6 weeks," not a PDF with a patient ID on it. Injury information is exactly the kind of client data worth being most careful with.

Should I use ChatGPT or Claude for post-rehab programming?

Either works with this prompt structure, and both exhibit restriction decay in long conversations, which is why the audit prompt exists. Claude tends to hold a constraint list a bit more reliably across a threaded back-and-forth; ChatGPT is fine when you paste the full context block fresh each time. The audit matters more than the model. Our full comparison goes deeper.

What if the client wants their old numbers back faster?

That impatience is normal and worth naming out loud: "You'll get there faster by not repeating the last ten weeks." The 10% cap and the two-speed structure exist because motivated clients returning from injury are the population most likely to overshoot. The program should feel slightly too easy to the client in weeks 1-2. That's the plan working.