Should Your Team Use a Framework at All?
Teams with 1–2 people writing simple prompts for a single use case can skip a formal framework — the overhead is not justified. Teams with 3 or more people, multiple use cases, or inconsistent output quality should standardize on one framework before adding more people.
The cost of not using a framework scales with team size. Two people can align on prompt style informally. At five people, output inconsistency increases to the point where reviews become contentious and model comparison tests become hard to interpret because prompts vary too much.
Onboarding cost doubles without a framework. A new team member with a documented framework learns to write acceptable prompts in 2–3 days. Without one, the same member spends 1–2 weeks studying examples and making avoidable mistakes. Standardizing on one framework before the team grows is lower-effort than retrofitting one after inconsistency has embedded itself.
Decision Matrix: Which Framework Fits Your Use Case?
Use this matrix to match your team's primary use case to the framework designed for it. Select the framework that covers 80%+ of your prompts — handle the remaining 20% with a secondary framework or minor prompt-level adjustments.
| Framework | Best for | Avoid when | Onboarding time |
|---|---|---|---|
| CO-STAR | Complex multi-step tasks, research, analysis, compliance briefs | Simple one-turn tasks where most components are unnecessary overhead | 2 hours |
| CRAFT | Content, marketing copy, creative writing, brand voice | Technical or structured output where role and format are less relevant | 1 hour |
| RISEN | Instructional writing, training material, educational explanations | Open-ended creative tasks without defined steps or goals | 1.5 hours |
| RTF | Technical documentation, structured data extraction, API references | Narrative, creative, or persuasive writing where format is less important | 1 hour |
| Custom | Domain-specific workflows with 3+ unique components no standard framework covers | An existing framework fits with minor tweaks — custom adds build and maintenance cost | 4–8 hours to build |
When to Use CO-STAR
CO-STAR is the right choice when your prompts require multiple constraints that must be defined explicitly before the task: audience, style, tone, and response format all vary between prompts. If all your prompts share the same audience and style, CO-STAR adds components you fill in identically every time — use CRAFT or RTF instead.
CO-STAR components: Context (background the model needs), Objective (what the output must accomplish), Style (writing style — formal, conversational, technical), Tone (emotional register — neutral, encouraging, authoritative), Audience (who will read it and their knowledge level), Response (format and length of the output).
Example use case: generating a compliance report brief. Context = regulatory environment. Objective = summarize violations and remediation steps. Style = formal. Tone = neutral. Audience = board of directors (non-technical). Response = 1-page executive summary with action items. Each component changes per report, justifying CO-STAR's six-field structure.
When to Use CRAFT
CRAFT is the right choice for content teams, marketing copy, and brand voice work where the model's role and the target outcome are the primary drivers. CRAFT is faster to complete than CO-STAR when audience and tone are fixed — you define the role (writer, editor, copywriter), action (write, rewrite, summarize), format (paragraph, list, tagline), and target (conversion, awareness, retention).
CRAFT components: Context (background on the content need), Role (what the model is acting as — brand copywriter, product manager, technical editor), Action (the specific task), Format (output structure), Target (goal or intended effect of the output).
Example use case: generating product descriptions for a new feature. Context = feature launch, existing product voice guide. Role = brand copywriter. Action = write 3 variant product descriptions. Format = 60-word paragraph each. Target = conversion on product detail page. This prompt writes itself once you know the components — no audience or style negotiation needed.
When a Custom Framework Is Better Than an Existing One
Build a custom framework when three signals appear: you modify a standard framework the same way every time, output requires a component no standard framework covers, or team compliance with the framework is below 80%. Meeting any one of these signals is sufficient reason to invest in a custom framework.
Signal 1 — consistent modification: if you always add a policy constraint, a persona anchor, or a domain vocabulary to CO-STAR, those additions are framework components — not ad-hoc choices. Formalizing them as components removes a manual step from every prompt.
Signal 2 — missing component: if your prompts require something no standard framework includes (escalation logic, regulatory citation, output schema enforcement, persona tier), that component belongs in a framework. Signal 3 — compliance below 80%: if members skip sections of the current framework because the sections don't apply to their work, the framework doesn't fit. A 20%+ skip rate means switching frameworks or building a custom one. See the build-your-own-framework article for the full 5-step design process.
How to Onboard Your Team to a New Framework
Onboarding to a new framework takes 1–2 hours of guided instruction and 1 week of supervised practice — not months of independent experimentation. The fastest onboarding path: one 90-minute session covering the framework structure, then 5 supervised prompts with structured feedback, then 2 weeks of independent prompting with a weekly review.
Run the 5 supervised prompts across GPT-4o and Claude 4.6 Sonnet via PromptQuorum so new team members see how the framework performs across models from day one. Cross-model testing during onboarding catches component definitions that only work on one model — fixing those early prevents model-specific brittleness later.
Document the framework in the team's prompt library with 3 annotated example prompts covering the most common use cases. Without annotated examples, new members invent their own interpretations of each component and drift from the intended structure within the first week.
Frequently Asked Questions
Which prompt framework should a team use?
Use CO-STAR for complex multi-step tasks with defined audience and style constraints. Use CRAFT for content, marketing, and creative work. Use RISEN for instructional, training, or educational material. Use RTF for technical documentation and structured data output. If your team modifies the same framework consistently in 3+ ways, build a custom framework instead.
Do small teams need a prompt framework?
Teams with 1–2 people writing simple, one-off prompts typically do not need a formal framework. Teams with 3 or more people, multiple use cases, or inconsistent output quality benefit from standardizing on one framework.
What is the difference between CO-STAR and CRAFT?
CO-STAR is designed for complex tasks with multiple constraints and explicitly requires audience and style definitions. CRAFT is designed for content and creative tasks where the role and target are primary drivers, making it faster when audience and tone are fixed.
When should a team build a custom prompt framework instead of using an existing one?
Build a custom framework when: you apply the same 3+ modifications to a standard framework for every prompt, output requires a domain-specific component no standard framework covers, or team compliance with the current framework is below 80%.
How long does framework onboarding take?
Onboarding ranges from 1 hour (CRAFT, RTF) to 2 hours (CO-STAR) for learning, plus 1 week of supervised practice. Custom frameworks take 4–8 hours to build, plus 2 weeks of team familiarization.
Can I combine components from multiple frameworks?
Yes, you can combine CO-STAR, CRAFT, and RISEN components, but the result should be named, documented, and tested as a custom framework, not treated as a hybrid of existing ones.