AI Prompt Framework for Teams: Shared Fields That Stick

TL;DR: An AI prompt framework helps a team only when everyone fills the same fields the same way. Pick one base framework, often CO-STAR for writing-heavy teams, trim it to the fields your work needs, and write a one-page field dictionary that says what a good entry looks like. Turn that into a house template, score shared prompts with a 0 to 2 rubric per field, store winners on one wiki page, and teach new hires in thirty minutes. You leave with a paste-ready house template, a sample dictionary, a review rubric, and adoption signals. Draft the first version at https://promptmake.net/frameworks/costar, then lock your house rules on top.

Why one shared AI prompt framework beats a menu of five

Teams that let each person pick a favorite acronym end up with prompts nobody else can review. One writer uses CO-STAR, another uses RISEN, a third writes freeform paragraphs, and the Monday review turns into a debate about taste. A single shared framework gives everyone the same slots, so a reviewer can scan a prompt and see in seconds that Audience is blank or Response has no length limit. The framework matters less than the agreement. CO-STAR, CRAFT, and RISEN all cover context, task, and output shape. Your team wins when the field names mean the same thing to the support lead, the marketer, and the new analyst.

Shared fields also make prompts portable. When a colleague goes on leave, you can open their saved prompt and rerun it without guessing what they meant by a loose paragraph. When the model changes, you edit one field and rerun your test cases instead of rewriting everything.

Pick your base framework and trim the fields

Start with the framework that matches the bulk of your team's work, then cut. Most rollouts fail because the template asks for eight fields when the job needs four, and people start skipping boxes within a week. Look at the last twenty prompts your team saved or shared in Slack. Tag which pieces showed up in the good ones: background facts, a clear verb, a target reader, a tone note, a length limit, a list of things to avoid. The pieces that appear in most winners become required fields. The rest become optional or disappear. The subsections below show how to pick the base and how to mark each field.

Match the base framework to your team's main job

Pick CO-STAR (Context, Objective, Style, Tone, Audience, Response) when your team writes for readers: marketing, support, comms, sales. Its separate Tone and Audience slots stop the classic “too formal for customers” miss.

Pick CRAFT (Context, Role, Action, Format, Tone) when you want five fields and a strong output spec, common for ops and product teams. Pick RISEN (Role, Instructions, Steps, End goal, Narrowing) when your prompts describe procedures, such as QA checks or data cleanup runs. PromptMake has live generators for all three at https://promptmake.net/frameworks/costar, https://promptmake.net/frameworks/craft, and https://promptmake.net/frameworks/risen.

Mark each field required, optional, or cut

Required fields must appear in every shared prompt. For most teams that means Context, Objective (or Action), Audience, and Response (or Format). Optional fields appear when they change the output, such as Style for a report versus a social post.

Cut any field that people fill with the same filler every time. If Tone always says “professional,” move that line into a team default and drop the slot. Fewer boxes means more of them get filled with care.

Add one or two house fields

Most teams need one field the acronym lacks. Common picks: Sources (which documents or data the model may use), Avoid (banned phrases, claims legal will not approve), and Owner (who maintains this prompt). Keep house fields to two or fewer so the template stays short.

Write a field dictionary your team can follow

A field dictionary is a one-page reference that defines each slot in plain words, shows a good and a weak entry, and names the most common miss. It turns “fill in Context” into a shared standard. Without it, one person writes a single sentence of Context and another pastes three pages of meeting notes, and both believe they followed the framework. Keep each entry short enough that someone can read the whole dictionary in five minutes. Put it at the top of the wiki page where your templates live, and link to it from every template so reviewers can point at a specific rule instead of arguing.

What each dictionary entry contains

• Field name and one-line purpose.
• Required or optional.
• A good example from your own work.
• A weak example with the reason it fails.
• A length hint, such as “two to five sentences” or “one line.”

Sample entries for Context, Objective, Audience, and Response

Context (required): facts the model cannot know, such as product name, customer tier, prior decisions, and constraints. Good: “Customer on a Pro annual plan asked for refund 45 days after renewal; policy allows 30 days.” Weak: “Customer is upset.” Length: two to five sentences.

Objective (required): one verb-led sentence stating what done looks like. Good: “Write a reply that declines the refund, offers a one-month credit, and keeps the account.” Weak: “Help with this customer.” Length: one line.

Audience (required): who reads the output and what they already know. Good: “Small-business owner, not technical, has emailed twice.” Weak: “Customers.” Length: one line.

Response (required): format, length, and structure. Good: “Email under 120 words, three short paragraphs, no bullet points, sign-off from Support Team.” Weak: “An email.” Length: one line.

The house template you can paste

Once the dictionary is set, the house template is the dictionary with the explanations removed. Copy this CO-STAR-based version and edit the house fields for your team:

• CONTEXT: [facts the model cannot know; two to five sentences].
• OBJECTIVE: [one verb-led sentence stating what done looks like].
• STYLE: [optional; genre such as support email, executive memo, product changelog].
• TONE: [team default is warm and direct; override only when needed].
• AUDIENCE: [who reads this and what they already know].
• RESPONSE: [format, length cap, structure, sign-off].
• SOURCES: [documents or data the model may use; say “only the text above” when it applies].
• AVOID: [banned phrases, unapproved claims, competitor names].

A filled version for a support team might read: CONTEXT: customer on Pro annual plan asked for a refund 45 days after renewal; policy allows 30. OBJECTIVE: decline the refund, offer a one-month credit, keep the account. TONE: warm and direct. AUDIENCE: non-technical small-business owner, second email. RESPONSE: under 120 words, three paragraphs, sign as Support Team. SOURCES: refund policy pasted above. AVOID: “unfortunately,” legal language, promises about future pricing.

Version the template with a date in its title, such as “Support reply template v2026-09,” so people know which rules apply.

Score shared prompts with a two-minute rubric

A rubric turns review from opinion into a checklist. Score each required field 0, 1, or 2, then add a score for the output itself. Reviewers can finish in about two minutes per prompt, which means reviews happen instead of piling up. The rubric also shows patterns: if Audience averages 0.6 across the team, you know where to coach. Keep the scale small. A ten-point scale invites hair-splitting, while a three-point scale forces a clear call. Run reviews on prompts that go into the shared library, not on every quick chat, or people will stop sharing.

The 0 to 2 scale per field

• 0: field missing or filled with filler (“professional,” “help with this”).
• 1: field present but vague; a teammate would need to ask a question.
• 2: field specific enough that a new hire could rerun the prompt and get the same kind of output.

Add one output score: 2 if the model's answer shipped with light edits, 1 if it needed a rewrite of one section, 0 if it was discarded. A prompt needs 2 on every required field plus 2 on output before it enters the library.

Running the review

Pick a fixed slot, such as thirty minutes every other Thursday. Each person brings one prompt they want to share. A reviewer reads the prompt, scores each field, runs it once on the team's default model, and scores the output. Record scores in a simple sheet. Fix the lowest field on the spot, then save the passing version.

Store winners where people look

Keep one wiki page per team, not a folder of scattered docs. Put the field dictionary at the top, then templates grouped by job: support replies, release notes, meeting summaries, research briefs. Each template entry lists its owner, version date, the model it was tested on, and one sample output. For a deeper guide to library structure, read https://promptmake.net/blog/prompt-library-how-to-build.

Link the page from your team channel topic and from onboarding docs. People reuse prompts they can find in two clicks. They rewrite from scratch when the good version sits in someone's private notes.

Onboard new hires in thirty minutes

Teach the framework with the team's own examples. Spend five minutes on the field dictionary. Spend ten minutes on a before and after: a vague prompt from the archive, its weak output, the house-template version, and its better output. Spend ten minutes having the new hire fill the template for a real task from their first week. Use the last five minutes to score their prompt with the rubric together.

Give them a starter set of three templates for their role and the name of the template owner. Check back after two weeks and review one prompt they wrote alone.

Signs the shared fields are sticking

Track three signals each month. First, fill rate: what share of library prompts score 2 on every required field. Second, reuse: how often people copy a library template instead of writing fresh. Third, edit distance: how much people change model outputs before shipping. Rising fill rate and reuse with falling edits means the framework is working.

When a field scores low for two months, fix the dictionary entry or cut the field. When people keep adding the same line to AVOID, promote it to a team default. Treat the template as a product with an owner and a changelog.

Common mistakes when teams adopt a framework

Picking the framework by vote without looking at past prompts leads to fields nobody uses. Audit twenty real prompts first.

Requiring every field for every task makes the template feel like a tax. Keep required fields to four or five.

Skipping the dictionary leaves each person with a private definition of Context. Write the one-pager before the template.

Reviewing every prompt kills sharing. Review only what enters the library.

Confusing adoption with selection wastes the first meeting. If you still need to choose among frameworks, start with https://promptmake.net/blog/prompt-frameworks-compared or the team picker in https://promptmake.net/blog/prompt-engineering-frameworks-guide, which also covers a multi-framework rollout calendar. This page assumes you pick one base and focuses on making its fields stick.

Use PromptMake to draft the first templates

When a teammate has a rough ask and no idea how to fill the fields, paste it into https://promptmake.net/frameworks/costar. The generator returns a structured prompt with Context, Objective, Style, Tone, Audience, and Response sections. Copy the output into your house template, add SOURCES and AVOID, and run it through the rubric.

PromptMake writes prompt text only. It does not store your team library or run your models. As of September 2026, guests get about three runs per day per tool path and free registered accounts about five, so a team can draft its first templates on the free tier.

FAQ

What is an AI prompt framework?

An AI prompt framework is a set of labeled fields you fill in before you send a prompt, such as Context, Objective, Audience, and Response. Popular ones include CO-STAR, CRAFT, RISEN, and RTF. The labels help you remember what the model needs and help reviewers spot gaps. For teams, the main value is a shared language for what a good prompt contains.

Which AI prompt framework is best for teams?

CO-STAR fits most writing-heavy teams because it separates Tone and Audience, which drive most rewrites. CRAFT suits teams that want five fields and a strong format spec. RISEN suits procedure-heavy work with ordered steps. Pick the one that matches the bulk of your recent prompts, then trim it.

How many fields should a team prompt template have?

Aim for four or five required fields and up to three optional ones. More than that and people start skipping boxes or pasting filler. Audit your best recent prompts to see which pieces show up in the winners. Cut any field that always gets the same answer and make that answer a team default.

How do we review prompts without slowing the team down?

Use a 0 to 2 score per required field plus one score for the output, which takes about two minutes per prompt. Review only prompts that go into the shared library. Hold a short fixed session every other week. Fix the lowest-scoring field on the spot and save the passing version.

Where should a team store its prompt templates?

Keep one wiki page per team with the field dictionary at the top and templates grouped by job. List the owner, version date, tested model, and a sample output for each template. Link the page from your team channel and onboarding docs. Scattered private docs lead people to rewrite prompts from scratch.

How do we get people to keep using the framework?

Track fill rate, reuse, and how much people edit outputs before shipping. Fix or cut fields that score low for two months. Give each template an owner and a changelog. Teach new hires with your team's own before and after examples in their first week.

Is there a free tool to build framework prompts?

Yes. PromptMake offers free CO-STAR, CRAFT, and RISEN generators under its /frameworks paths, linked earlier on this page. Guests get about three runs per day per path and registered free accounts about five, as of September 2026. The tool writes prompt text; you store and run the prompts in your own stack.