The CTFC framework: making prompts repeatable across a team

The reason most team-level prompt libraries fall apart is not that the prompts are bad. It is that they are structured inconsistently, which means every team member reads them differently, adapts them differently, and produces different outputs when they think they're using the same prompt.

CTFC — Context, Task, Format, Constraints — is the structural convention we use with clients to solve this. It is not a novel prompt technique. It is a specific ordering discipline, and the ordering is what makes it work at team scale.

The four parts

Context comes first. Before the model does anything, it needs to know the situation it is operating in. Who is the audience for the output. What is the decision the output is supporting. What has already been established that the model should carry through. Context anchors everything that follows, and a prompt that skips it produces generic output that has to be re-prompted into usefulness.

Task is second. What the model is being asked to do, stated as an action verb with a specific direct object. Draft. Summarize. Compare. Analyze. Extract. The task is the shortest of the four parts — often a single sentence — because it is defining the action, not the context or the shape of the output.

Format is third. What the output should look like structurally. A three-paragraph memo. A five-column table. A bulleted list of no more than seven items. A one-page brief with named sections. Format specification is what makes the output usable without additional editing. Skipping it is what produces AI drafts that require twenty minutes of formatting cleanup.

Constraints come last. What the model should not do. Length ceilings. Language to avoid. Assumptions that must not be made. Sources that must not be relied on. Constraints are the fence around the output, and they belong at the end because they are checked against the output the model is producing, not against the intent behind it.

Why the order matters

This is the part that matters most and gets least attention.

Every reordering of these four parts changes what the model foregrounds. Put constraints first, and the model treats them as the primary signal — you get outputs that satisfy the constraints and miss the intent. Put format before task, and the model produces well-shaped output that answers a different question than you asked. Put context last, and the model has already made its interpretation decisions by the time the anchoring information arrives, and the anchoring information gets treated as a footnote rather than a frame.

CTFC in this specific order maps to how you'd brief a competent junior team member on a task. You'd set the situation first. Then you'd tell them what to do. Then you'd tell them what the deliverable should look like. And you'd flag the things to watch out for last, as the fence around the work. The order is not arbitrary. It matches how directive briefings actually work.

Teams that adopt this ordering see two things happen fast. Prompts written by different people start producing consistent outputs, because the structure carries the discipline. And prompts get easier to reuse, because when you go back to a prompt written by a colleague three weeks ago, the CTFC structure tells you exactly where to change the situation-specific bits without breaking the pattern.

What a CTFC prompt actually looks like

Here is a working example, drawn lightly from one we use for client status updates.

Context. This status update is going to a client sponsor at [Organization], who is currently deciding whether to expand the pilot from one business unit to three. The sponsor has been engaged but skeptical about the change management readiness of the other two units.

Task. Draft a two-week project update that specifically addresses whether the change management readiness question can now be answered, based on the pilot results.

Format. Three sections: (1) what the pilot demonstrated about change readiness in section headers, (2) what remains uncertain, (3) our specific recommendation on the expansion decision. Total length under 400 words. Written in plain business English, no jargon.

Constraints. Do not overstate readiness — the sponsor will read overstatement as a credibility signal. If any of the three readiness dimensions is genuinely uncertain, say so directly rather than hedging. Do not recommend expansion if the pilot data does not support it. Do not use the phrases "leverage," "unlock," or "at scale."

Anyone on the team can pick that prompt up, replace the bracketed details, and produce an output that reads as if the same person wrote it. That is the team-level repeatability the framework is optimized for.

Adopting CTFC in one meeting

CTFC is not something to train on for hours. It is something to adopt in a single sixty-minute team meeting.

Spend fifteen minutes walking through the four parts and the reason the ordering matters. Fifteen minutes running the team's three most-used current prompts through CTFC structure and comparing before-and-after outputs. Fifteen minutes agreeing on which two or three prompts the team will convert into the shared library using this structure. Fifteen minutes assigning ownership and a follow-up date.

That's the adoption cycle. Everything else — the library maintenance, the review rhythm, the incremental improvement — happens naturally once the structural convention is in place. What CTFC changes is not how skilled the individual prompt writer is. It changes how portable and consistent the team's prompts become. And that is the leverage point for actual team-level AI capability.

---