TRACE
The framework for work you are handing to someone else.
What is TRACE?
TRACE is five slots: Task, Requirements, Audience, Context and Examples. It is a briefing framework — the one to reach for when the output is a document somebody else will act on, and the measure of success is that they can start work without coming back with questions.
Most frameworks help you ask for a piece of writing. TRACE helps you delegate a piece of work, and the difference shows up in two slots nothing else has together. Requirements holds the acceptance criteria — the things that make the deliverable right or wrong, not merely good or bad. Examples gets a slot of its own, which matters more than it sounds: on our own prompt scorer, showing a worked fragment rather than describing one is worth ten points, and every other framework has to smuggle it in somewhere. TRACE is the one that asks for it by name.
Where TRACE Came From
A modern acronym, no documented author
TRACE has no inventor of record and no history before prompting. It belongs to the same pool of assembled acronyms as RTF, TAG and PACT — someone catalogued the parts of a brief people skip and arranged five of them into a word. Pages naming a founder are inventing one.
Two prior TRACEs, neither related
The name is heavily taken. TRACE International is a well-known anti-bribery and compliance organisation, and the TRACE model is a 1986 connectionist model of speech perception by McClelland and Elman. Neither has anything to do with prompts, and both outrank prompting for the bare acronym — search the expansion instead.
Why five slots and not four
TRACE is longer than its neighbours on purpose. A brief is written once and read by people who were not in the room, so the cost of an extra hundred words is small and the cost of a missing constraint is a fortnight. That trade only works for delegated work: for a quick request, five labelled slots is ceremony, and RTF will serve you better.
The 5 Slots, One at a Time
Each slot is a decision. Leave it out and the model still makes it — just without you.
One sentence. Name the artefact and its destination, because a brief that will be sent to three competing agencies is a different document from one going to a colleague, and every later slot depends on which it is.
The slot that separates TRACE from a nicely-organised wish. Requirements are checkable: a word count, named sections, a rule about what must be measurable, an explicit exclusion. If a line here could be argued about after delivery, it belongs in Context instead.
For a brief, the pressure matters as much as the person. Someone reading forty briefs a month and deciding in five minutes whether to bid needs the constraints early and the backstory late. Say what they already know, and say what they will not do.
Everything the reader needs in order to price the work: the size of the thing, the numbers you are unhappy with, the immovable constraints, the deadline and why it is fixed. This is the slot that prevents the model from writing a generic brief, and the one people fill with company history instead of decisions.
Not a description of the style — an actual specimen. Take the section you most expect to be done badly and write three lines of it yourself. It costs a minute, it removes an entire category of misunderstanding, and it is the highest-value slot in the framework.
One Task, Before and After
The task: A brief for three agencies pitching a website redesign. Both prompts below are scored by our free prompt checker — paste either in and you will get the same number, because the scoring is deterministic.
Write a brief for our website redesign.
Six words. You get a plausible, generic brief that could be about any website — the kind an agency reads twice and does not bid on.
Task: Write the project brief we will send to three agencies pitching for a redesign of our website. Requirements: 900 to 1,100 words, in these seven headed sections - Background, Objectives, Scope, Out of scope, Constraints, Deliverables, How we will choose. Objectives must be measurable. Scope must state page counts. Do not include a budget figure; write [BUDGET RANGE] where it belongs. Work through what an agency would need in order to price the work before you write, and make sure every section answers something they would otherwise have to ask. Audience: Agency new-business leads who read forty briefs a month and will decide within five minutes whether to bid. They are not familiar with our product and will not read a preamble. Context: We are a 40-person B2B logistics software company. The current site is nine years old, 60 pages, on WordPress, and converts at 0.8% against a 2% target. Sales say prospects cannot find pricing. We must keep the existing CMS and cannot move off it. The launch date is fixed to a trade show in March. Examples: The Objectives section should read like this: ``` Objective 2 - Make pricing findable. A first-time visitor reaches the pricing page in two clicks from any page. Measured by: pricing page sessions as a share of all sessions, from 3% today to 12% within one quarter of launch. ```
Ninety-one, and it is 220 words — one of the highest scores on this site from one of the shorter prompts, because five labelled slots happen to cover most of what a general rubric looks for.
Ninety-one, and the honest caveat is length rather than the missing points
TRACE scores near the top of the range because its five slots map almost one-to-one onto what a prompt rubric checks. Only one thing is structurally unreachable — and the more useful caution is not about the score at all:
No persona slot. For a brief that is right: the document speaks for your organisation, and "you are a seasoned agency strategist" adds a voice that has to be edited back out. If you want the eight points, RACE gives you a Role slot and loses the Examples one — a bad trade here.
A point lost to hedging vocabulary. Not worth chasing; the remaining softness is in the framing sentences, not the requirements.
The scoring ceiling is not TRACE's limitation. Its limitation is that a five-slot brief is a hundred-word minimum before you have said anything, and most requests do not deserve that. TRACE pays for itself on work you delegate or repeat, and wastes your time on work you could just ask for.
The transferable test, whatever framework you use: could the reader price this work without asking a question? Every slot TRACE has exists to close one category of question — what, how judged, for whom, why, and what it should look like. If a question survives all five, the brief is not finished.
Copy-Paste Prompt Template
Replace the bracketed placeholders with your specific details.
Task: [The deliverable, and who it is going to] Requirements: [Only things checkable on delivery — length, named sections, what must be measurable, what is explicitly out of scope] Audience: [Who reads it, how much time they will give it, and what will make them stop] Context: [The facts needed to price or plan the work — the numbers, the immovable constraints, the deadline and why it is fixed] Examples: [Three lines of the section you most expect to be done badly, written the way you want it]
When TRACE Fits — and When It Does Not
- Briefs for agencies, freelancers and contractors who will quote against them.
- Technical specifications where the acceptance criteria matter more than the prose.
- Requests for proposal, and anything three suppliers will read side by side.
- Onboarding curricula, training modules and handover documents.
- Any prompt you intend to reuse — the length is amortised over every run.
- Quick one-off asks. Five slots is ceremony; use RTF or TAG.
- Creative exploration, where over-specifying is the failure mode you are trying to avoid.
- Data processing and structured output. Use ICIO — TRACE has no slot for the data.
- Persuasion and sales copy. Nothing here is built to move anyone; use AIDA, PAS or BAB.
- Situations where you genuinely do not yet know the requirements. Write SCQA first, then TRACE.
10 Ready-Made TRACE Prompts
Every prompt below was produced by the Frompting generator with TRACE selected — not written by hand for this page. Each is scored by our prompt checker; the median is 86/100. Click one to open it, then copy.
A brief for a website redesign project 81
You are a senior web strategy consultant tasked with creating a comprehensive brief for a website redesign project. The brief must clearly define the redesign objectives, functional and technical requirements, target user personas, project constraints, and illustrative references. Include the following sections in the output, each written in concise, professional prose (approximately: objectives 150 words, requirements 200 words, audience 150 words, constraints 150 words, references 100 words). - State the primary goals of the redesign and the key performance indicators it should achieve. - List required features, content structures, integration points, accessibility standards, and performance targets. - Describe the main user groups, their needs, and how the redesign will address them. - Outline project scope limits, budget range, timeline, technology stack preferences, and any regulatory or branding guidelines. - Provide three concrete examples of existing websites or design patterns that illustrate the desired look and feel. Quality criteria: 1. All sections are logically ordered and internally consistent. 2. Language is clear, jargon‑free, and each technical term is briefly defined. 3. The brief is actionable for designers, developers, and stakeholders without needing additional clarification. Exclude speculative market analysis or unrelated marketing copy. If any essential detail is missing, state your assumption and ask up to three clarifying questions before finalizing the brief. [PROJECT BUDGET]: specify the budget range for the redesign. [PROJECT TIMELINE]: specify the expected start and end dates. [TECHNOLOGY STACK]: specify preferred platforms, CMS, or frameworks. [BRANDING GUIDELINES]: specify any existing brand assets or style guides. [REGULATORY REQUIREMENTS]: specify any compliance standards (e.g., GDPR, WCAG).
A technical specification for a reporting dashboard 81
You are a senior technical writer specializing in analytics solutions. Your task is to produce a complete technical specification for a new reporting dashboard. The specification must detail functional features, data integration points, user interface layouts, performance requirements, security controls, and deployment considerations. The document should be written for the team that will design, develop, and maintain the dashboard, assuming they have intermediate expertise in data visualization and backend services. Include the following essential information, filling in any unknowns with the indicated placeholders: - Primary business objectives the dashboard must support. - Key metrics and visualizations required. - Source systems and data models to be consumed. - Expected user roles and permission levels. - Performance targets (e.g., load time, refresh frequency). - Security and compliance requirements. - Deployment environment and integration points. Structure the output as a markdown document with clear headings for each section, using concise bullet points where appropriate. Aim for 1,200–1,500 words total. Quality criteria: technical accuracy, completeness of all required sections, and clarity for developers and analysts. Exclude any speculative technology choices; only list components that are confirmed or marked with a placeholder. If any critical detail is missing, state your assumption and ask up to three clarifying questions before finalizing the specification.
A brief for agencies pitching a rebrand 86
You are a senior brand strategist tasked with creating a concise, compelling brief for an agency that will pitch your company’s rebrand. Develop a brief that clearly outlines the rebrand’s objectives, deliverables, and success criteria. Include the essential information the agency needs to understand the project scope, target market, and desired tone, and provide any relevant background that will guide their creative approach. The brief is for: [AGENCY_TYPE: e.g., full‑service creative agency, boutique design studio, etc.] Key deliverables: brand name (if changing), visual identity, messaging framework, brand guidelines, and rollout plan. Required length: 250–300 words, formatted as a markdown document with clear headings for each section. Quality criteria: 1. Clearly articulated goals and measurable outcomes. 2. Specific, actionable requirements for deliverables. 3. Insightful context that informs the agency’s creative direction without being overly prescriptive. Exclude any speculative market data or internal financial figures unless you can confirm them; focus on strategic intent and creative constraints. If any of the above details are unknown, state your assumptions and ask up to three clarifying questions before finalizing the brief. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader.
An onboarding curriculum for new sales hires 83
You are a seasoned sales enablement specialist tasked with creating a comprehensive onboarding curriculum for new sales hires. Develop a structured curriculum that covers essential knowledge areas, core skill development, and practical application activities. The curriculum should be organized into weekly modules, each including learning objectives, key topics, recommended training methods (e.g., workshops, role‑plays, e‑learning), and assessment criteria. The curriculum is intended for [AUDIENCE TYPE: specify the experience level and background of the new hires, e.g., recent graduates, career changers, internal transfers]. Assume the organization operates in the [INDUSTRY: specify the market sector, e.g., SaaS, manufacturing, financial services] and sells [PRODUCT/SERVICE: brief description of the primary offering]. The onboarding program is expected to span [DURATION: number of weeks or months] and should prepare hires to achieve [PERFORMANCE TARGET: e.g., first‑quarter quota, pipeline generation metrics] by the end of the program. If any of these details are unknown, state your assumptions clearly and ask up to three clarifying questions before finalizing the curriculum. Deliver the curriculum as a markdown document with the following structure: - **Overview** (150–200 words) summarizing the program’s purpose and outcomes. - **Weekly Modules** (each 250–300 words) titled “Week 1: …”, “Week 2: …”, etc., containing: - Learning objectives (bullet list) - Core topics (bullet list) - Training methods (bullet list) - Assessment criteria (bullet list) - **Final Assessment** (200–250 words) describing the capstone project or evaluation format. Quality criteria: 1. Content is logically sequenced and builds progressively. 2. Each module balances theory with practical exercises. 3. Language is clear, concise, and appropriate for the specified audience. Exclude any references to proprietary tools or platforms not mentioned by the user.
A request for proposal for a CRM implementation 89
You are a professional technical writer specializing in procurement documents. Your task is to draft a complete Request for Proposal (RFP) for implementing a Customer Relationship Management (CRM) system. The RFP must include: - A clear project overview and objectives. - Detailed functional and technical requirements, covering data migration, integration points, user roles, security, reporting, and scalability. - Evaluation criteria and weighting for vendor proposals. - Submission instructions, timeline, and mandatory contract terms. The document is intended for potential CRM vendors who will respond with detailed solution proposals. Assume the organization is a [ORGANIZATION_TYPE: e.g., mid‑size manufacturing company] seeking to improve sales, service, and marketing processes. The RFP will be distributed electronically and should be concise yet thorough, not exceeding 1,200–1,500 words. If any of the following details are unknown, insert a placeholder in the format [PLACEHOLDER_LABEL: brief hint]: - [CRM_SCOPE: key business processes the CRM must support] - [BUDGET_RANGE: estimated budget for the implementation] - [IMPLEMENTATION_DEADLINE: target go‑live date] - [CURRENT_SYSTEMS: existing software that must integrate with the CRM] - [VENDOR_EXPERIENCE: required minimum years of vendor experience] Structure the RFP with clear headings and sub‑headings, using bullet points or tables where appropriate for requirements and evaluation criteria. Write in a formal, business‑professional tone, ensuring clarity and precision. Do not include any marketing language or promotional claims about the organization. Deliver the RFP as plain text formatted with markdown headings. If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue — do not ask for it and stop. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A brief for a data migration project 82
You are a data migration strategist tasked with drafting a concise, actionable brief that guides a team through moving their data to a new platform. First, outline the migration objective, key deliverables, and success criteria. Next, list all essential requirements: data types to be moved, security and compliance standards, performance targets, validation steps, and any technology constraints. Identify the primary audience for this brief (e.g., [AUDIENCE: role or team who will use the brief, such as “IT operations team”]) and tailor the language, detail level, and responsibilities accordingly. Provide the necessary context: current data storage solution ([CURRENT_PLATFORM: name of existing platform]), estimated data volume ([DATA_VOLUME: approximate size, e.g., “2 TB”]), target timeline ([TIMELINE: desired completion window]), and any organizational constraints or dependencies that could affect the migration. Conclude with concrete examples that illustrate the expected format of migration plans, validation reports, and communication templates. Deliver the brief in plain text, no longer than 350 words, organized with clear headings for each section. Ensure the brief is precise, actionable, and free of ambiguous language. Exclude any references to this prompt or the underlying framework. If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue — do not ask for it and stop.
A handover document for a departing project manager 80
You are a seasoned project management consultant tasked with drafting a comprehensive handover document for a departing project manager. The deliverable must be a clear, organized handover guide that enables the incoming manager to assume responsibilities smoothly. Include sections for project overview, current status, key milestones, outstanding risks, stakeholder contacts, tools and repositories, and next‑step actions. Write the guide in professional prose, using headings and bullet points where appropriate, and keep the total length between 300 and 400 words. The handover must be accurate, concise, and immediately actionable for the new manager. Ensure that each section contains only essential information and avoids unnecessary detail. Do not include any speculative data; where information is missing, insert a placeholder in the form **[PLACEHOLDER: description of needed detail]** (e.g., **[PROJECT NAME: specify the name of the project]**). Use no more than five such placeholders, focusing on the items that would most affect the handover’s usefulness. If any critical details are unknown, state the assumption you are making and proceed, or ask up to three clarifying questions before finalizing the document. Produce the handover guide as plain text with markdown headings (e.g., `## Project Overview`). Do not add any disclaimer, legal notice, or unrelated commentary.
A research brief for a customer survey 95
You are a research strategist tasked with creating a comprehensive research brief for a customer survey. Develop a brief that clearly defines the purpose of the survey, outlines the specific research questions to be answered, and details the methodology, sampling plan, and data collection approach. Include guidance on questionnaire design, length, and question types, as well as any required pre‑test or pilot steps. The brief is intended for the team that will design, field, and analyze the survey, so ensure the language is precise and actionable for survey developers, data analysts, and project managers. The survey will be conducted in the context of [PROJECT NAME: brief description of the business initiative or product area] and must align with the overall objectives of that initiative. Provide concrete examples of at least two survey questions that illustrate the desired depth and tone, and include a short sample timeline showing key milestones (e.g., questionnaire finalization, pilot testing, fielding, data cleaning, reporting). Deliver the brief in a structured markdown document no longer than 800 words, using clear headings for each section, bullet points for lists, and a table for the timeline. Quality criteria: 1. Completeness – all essential elements of survey planning are covered. 2. Clarity – instructions are unambiguous and ready for immediate implementation. 3. Practicality – recommendations are feasible given typical survey resources. Exclude any assumptions about budget, specific software tools, or proprietary data unless they are provided. If any critical details are missing, state your assumptions and ask up to three clarifying questions before finalizing the brief. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A brief for developers building a mobile MVP 96
You are a senior product strategist tasked with creating a concise, actionable brief for a development team that will build a mobile app MVP. The brief must clearly define the core objective of the MVP, list all essential functional and non‑functional requirements, identify the primary audience who will use the app, provide the business and technical context needed for developers to make informed decisions, and include concrete examples of similar apps or features to illustrate expectations. Deliver the brief in plain text, organized into five sections in the order described above, each section no longer than 150 words. Use bullet points for requirements and examples, and keep the overall length under 800 words. Quality criteria: 1. Requirements are specific, testable, and prioritized. 2. The audience description includes key user characteristics and primary use‑case scenarios. 3. Context supplies necessary background without assuming unknown details. Exclude any discussion of the TRACE framework or its components. If any critical detail is missing, state your assumption and ask up to three clarifying questions before finalizing the brief. [TECH_STACK]: specify the development technologies (e.g., React Native, Swift, Kotlin) [TARGET_PLATFORM]: indicate whether the MVP is for iOS, Android, or both [BUSINESS_DOMAIN]: describe the industry or problem the app addresses [KEY_FEATURES]: list the top three features the MVP must deliver [COMPARABLE_APPS]: provide names of existing apps that exemplify the desired functionality Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A training module for an internal analytics tool 92
You are a senior instructional designer tasked with creating a comprehensive training module that teaches users how to operate the organization’s internal analytics tool. Develop a self‑contained training module that includes: - An introductory overview of the tool’s purpose and key capabilities. - A step‑by‑step walkthrough of core functions, illustrated with clear, actionable instructions. - Practical exercises or scenarios that let learners apply each function in a realistic context. - A short knowledge‑check (e.g., quiz questions or tasks) at the end of each major section to reinforce learning. - A concluding summary that highlights best practices and common pitfalls to avoid. The module must be written for an audience of [AUDIENCE ROLE: specify the typical job title or function of the learners, e.g., “marketing analysts”] who have [PRIOR KNOWLEDGE LEVEL: indicate the expected familiarity with analytics concepts, e.g., “basic spreadsheet skills but no prior exposure to this specific tool”]. Assume the training will be delivered as a digital document (PDF/HTML) and should be readable in about 45 minutes of study time, roughly 1,000–1,500 words total. Include the following elements: 1. **Learning objectives** – three to five concise statements of what the learner will be able to do after completing the module. 2. **Content sections** – each covering a distinct feature of the tool; use clear headings and bullet points where appropriate. 3. **Hands‑on activity** – a realistic example that mirrors a typical workflow in the organization; describe the data set, the steps to follow, and the expected outcome. 4. **Assessment items** – at least three multiple‑choice or short‑answer questions per major section, with answer keys provided separately. 5. **Tips & tricks** – a sidebar or call‑out box with shortcuts, troubleshooting advice, and best‑practice recommendations. Quality criteria: - Accuracy: all instructions must reflect the actual functionality of the tool; avoid speculative features. - Clarity: use plain language, define any technical terms on first use, and keep sentences varied in length. - Engagement: incorporate interactive elements (exercises, quizzes) that promote active learning. Boundary: Do not include any proprietary code snippets, system configuration files, or internal security policies; focus solely on user‑level operations. If any of the above details are unclear, state your assumptions explicitly and ask up to three clarifying questions before finalizing the module.
Scores range from 80 to 96. They are shown as generated rather than cherry-picked — a library where every entry scores in the nineties tells you it was curated, not measured.
TRACE vs the Alternatives
The closest relative — same five ideas, different emphasis. CLEAR is aimed at explaining something to a reader; TRACE is aimed at commissioning something from a doer. CLEAR has Language, TRACE has Context.
The other briefing framework. CRISP has a Role and a Style slot and is better for creative briefs where voice is the deliverable; TRACE is better where the deliverable is a spec.
Four slots and a persona. RACE is the faster everyday brief; TRACE is what you write when money or a fortnight depends on the answer.
Six slots, two of them about voice. Better when the output is a piece of writing; TRACE is better when the output is an instruction for other people.
The machine-facing cousin. Both give examples real weight; ICIO briefs a pipeline, TRACE briefs a person.
Five Ways People Get TRACE Wrong
The defining TRACE failure, and a self-defeating one: the Examples slot is the main reason to choose this framework over a shorter one. Skip it and you have written a wordier RACE. Three lines of specimen output is the highest return on effort in the whole brief.
"Comprehensive", "professional", "high quality" are not requirements — nobody can fail them and nobody can pass them. If a line cannot be checked on delivery, it is Context.
The Context slot is for facts that change what a reader would do: the numbers, the immovable constraints, the deadline and its reason. Founding dates and mission statements are padding that pushes the real constraints below the fold.
The single most useful line in any brief, and the one people omit. Saying what you are not asking for prevents both padded quotes and quiet scope creep.
"Agencies" is a category, not an audience. How many of these do they read, how long will they give it, and what will make them stop reading — that is what changes the order of the sections.
The framework has a floor of about a hundred words. Applied to something you could have simply asked for, it costs more to write than the answer is worth.
TRACE Questions
What does TRACE stand for?
Task, Requirements, Audience, Context and Examples. It is a briefing framework, aimed at work that someone else will execute from the document you produce.
What is the difference between Requirements and Context?
Requirements can be checked on delivery; Context explains why they are what they are. "Seven headed sections, 900 to 1,100 words" is a requirement. "The site is nine years old and converts at 0.8%" is context. Collapsing the two loses your acceptance criteria.
Is the Examples slot really necessary?
It is the reason to pick TRACE. On our scorer, a described example and a shown one differ by ten points, and in practice a three-line specimen removes an entire class of misunderstanding that no amount of adjectives will.
How is TRACE different from CLEAR?
They share five ideas but point in opposite directions. CLEAR is for making something understood — documentation, explanations, teaching. TRACE is for getting something commissioned — briefs, specs, RFPs.
Why does TRACE score so highly?
Because five labelled slots happen to cover most of what a general rubric checks: task, audience, context, format and examples. That is a real advantage for delegated work and not a reason to use it everywhere — the same five slots make it far too heavy for a quick ask.
Should I add a role to a TRACE prompt?
Usually not. A brief speaks for your organisation, and a persona adds a voice you then have to edit out. The exception is when the brief itself should model a specialist register — a clinical or legal spec, say.
Generate a TRACE Prompt Instantly
Skip the manual template — Frompting applies TRACE to your topic in one click.
Try it FreeFramework Details
| Name | TRACE |
| Stands for | Task-Requirements-Audience-Context-Examples |
| Domain | Communication & Storytelling |
| Steps | 5 |
| Access | Pro |