The 3-Step AI Workflow

Turn one defined question into verified research, a reviewed draft, and purposeful reuse assets without restarting from a blank page.

For: professionals who regularly research a topic, produce a primary document, and adapt it for other channels.

You will finish with: a research brief, one approved source draft, a reuse matrix, and a record that keeps claims traceable across every output.

The system at a glance

The sequence matters. Research creates the evidence boundary. The primary draft creates the approved source of truth. Reuse changes the format and angle without changing the facts.

Prepare one workflow record

Before using a prompt, write down:

Do not automate a task whose owner, evidence, or acceptance criteria are unclear.

Step 1: Research

Use AI to assemble evidence, not to turn unsourced confidence into a research result.

Copy-ready research prompt

Act as a careful research analyst. Build an evidence brief for this question: [RESEARCH QUESTION].

Audience and decision: [WHO NEEDS THIS AND WHAT IT WILL INFORM]
Scope: [INCLUDED TOPICS, REGION, DATES, OR INDUSTRY]
Approved sources or source types: [LINKS OR RULES]
Excluded sources or claims: [LIST]
Current date: [DATE]

If browsing is available, prioritize primary and official sources. Cite a direct link beside every factual claim. If browsing is unavailable, use only the material I provide and mark gaps [SOURCE NEEDED].

Return: a 5-sentence answer; an evidence table with claim, source, publication date, source type, and confidence; meaningful disagreements; outdated or missing information; 5 implications for the stated audience; and a fact-check queue.

Do not use search-result snippets as evidence. Separate source statements from your inference. Do not invent statistics, quotes, examples, or consensus. Stop if the central question cannot be answered from credible evidence.

Research gate

• Every factual claim has a direct source.
• Current claims have a publication or verification date.
• Primary evidence is distinguished from commentary.
• Contradictions remain visible.
• The conclusion fits the evidence rather than the desired answer.

Anthropic recommends putting long source material before the request and making the final query specific. Anthropic long-context prompting guidance

Step 2: Draft

Draft from the approved research brief. Do not ask the model to research and publish in one unreviewed step.

Copy-ready drafting prompt

Work as a senior editor. Create the first draft of [PRIMARY ASSET] from the approved research brief below.

Audience: [PASTE]
Reader's starting problem: [PASTE]
Promised result: [PASTE]
Desired action: [PASTE]
Voice and length: [PASTE]
Required structure: [PASTE]
Approved research brief: [PASTE]

Use only claims and examples supported by the brief. Preserve the source link beside each factual statement during drafting. Mark a missing transition or example [EDITOR INPUT] instead of fabricating one.

Lead with the practical outcome. Build a logical section sequence, use concrete examples, and end with the stated next action. After the draft, provide a claim ledger with draft claim, supporting source, and review status.

Do not add urgency, testimonials, performance guarantees, or new product facts. Finish with 5 editorial questions that a human must resolve before approval.

Draft gate

Step 3: Reuse

Reuse should change the entry point for a new audience moment. It should not copy the primary asset into smaller pieces or introduce new evidence.

Copy-ready reuse prompt

Act as a distribution editor. Adapt the approved primary asset into channel-native pieces without changing its verified claims.

Approved primary asset: [PASTE]
Approved claim ledger: [PASTE]
Channels and format limits: [LIST]
Audience moment by channel: [PASTE]
Primary CTA by channel: [PASTE]
Statements that must remain exact: [LIST]

First extract the source thesis, approved claims, examples, and limits. Then create a reuse matrix with channel, audience situation, unique angle, format, opening, retained evidence, CTA, and success signal. Draft one complete piece per channel.

Each piece must stand alone and fit the channel. Link or cite the primary asset where appropriate. Mark any requested idea not supported by the source [NEW RESEARCH REQUIRED]. Do not invent platform statistics, customer proof, or urgency. End with a cross-channel consistency check for claims, terminology, and links.

Reuse gate

• Every output has a channel-specific job.
• The opening changes because the audience moment changes.
• Claims match the approved ledger.
• Links and CTAs go to the intended destination.
• New research requests remain outside the approved output.

Continuous example: one brief to a complete product update

This example shows one brief moving through Research, Draft, Review, and Reuse. The company, feature, release notes, issue log, dates, and people are fictional. They demonstrate the workflow and are not real product facts.

Copy-ready workflow brief

Copy this blank brief before starting:

Deliverable: [WHAT MUST BE PRODUCED]
Audience: [WHO WILL USE IT]
Outcome: [WHAT THE READER SHOULD UNDERSTAND OR DO]
Approved inputs: [FILES, LINKS, OR RECORDS]
Evidence cutoff: [DATE AND TIME]
Required structure: [SECTIONS IN ORDER]
Length and format: [LIMITS]
Excluded claims: [WHAT MUST NOT BE SAID]
Human owner: [NAME OR ROLE]
Acceptance criteria: [FACT, SCOPE, LINK, VOICE, AND ACTION CHECKS]
Approval gate: [WHO APPROVES BEFORE REUSE OR SHARING]
Reuse outputs: [FORMATS NEEDED AFTER APPROVAL]

Completed brief for this example

Fictional source pack

Release notes v18

Issue log snapshot

The source pack supports a narrow update. It does not support saying that the approval queue is available to all users, that a wider rollout has a date, or that any change improved customer outcomes.

Research prompt with supplied files

Keep the guide's general Research prompt. For this example, use these filled parameters:

Use only the supplied fictional release notes v18 and issue log snapshot. Do not browse and do not add product knowledge.

Prepare evidence for a weekly internal product update. For each relevant claim, return: claim, exact source reference, supported scope, uncertainty, and review decision. Separate shipped changes from open issues. Mark any statement that needs information outside the supplied files as SOURCE NEEDED.

The final update must cover 3 changes, open blockers, and 1 next action. Stop before drafting if availability, timing, or issue status cannot be stated within the documented scope.

Completed evidence table

Unresolved gaps: the wider rollout date, the resolution date for ISS-184, and the cause of delayed pilot notifications. These gaps remain visible rather than being filled with estimates.

Drafting prompt for the weekly update

Keep the guide's general Draft prompt and add this example-specific instruction:

Draft an internal weekly product update of about 250 words from the approved evidence table. Use 3 sections: What changed, What remains open, and Next action.

Describe exactly 3 shipped changes. Keep the approval queue in the blocker section because it is limited to pilot users and has an open notification issue. Preserve source references in brackets for review. Do not invent rollout dates, performance results, customer reactions, or issue-resolution dates. End with one action owned by the product lead.

Illustrative product update (about 250 words)

Fictional example for workflow practice

What changed

Three updates are ready for internal use this week. First, workspace owners can export an access report as CSV with user, role, and last access date fields [Release notes v18, item 1]. Teams using the export should note that the last access date may be missing for suspended users while ISS-184 remains under review [Issue log, ISS-184].

Second, notification settings now include a weekly digest option [Release notes v18, item 2]. This is an additional choice. The existing default has not changed.

Internal teams can describe the option, but should not imply that it is enabled for every workspace or that it changes delivery performance. Those conclusions do not appear in the supplied notes.

Third, the mobile upload retry flow now preserves a draft when a connection is interrupted [Release notes v18, item 3]. The internal reconnect test passed, and Support is continuing to monitor reports [Issue log, ISS-197]. This update does not establish a broader reliability result.

What remains open

The approval queue is available to pilot users in 12 workspaces, not to all users [Release notes v18, item 4]. Two pilot workspaces reported delayed notifications, and the investigation is still open [Issue log, ISS-191]. The wider rollout date is unconfirmed.

Next action

The product lead should confirm the next approved status for ISS-184 and ISS-191 before the next weekly update. Until then, internal teams should describe approval-queue access as pilot-only and avoid stating or implying a wider rollout date.

Human review: catch the claim that expanded

Use the guide's existing Draft gate, then confirm:

• [ ] Scope matches the exact source language.
• [ ] Dates, quantities, and statuses have direct references.
• [ ] Open issues remain visible.
• [ ] No result or rollout timing was inferred.
• [ ] Links or file references point to the approved source records.
• [ ] The product lead approved this version before reuse.

AI can flag inconsistencies. It does not replace the human owner who checks the source and accepts the final wording.

Reuse prompt

Adapt the approved fictional product update into 2 drafts: a team email and an action checklist.

Use only the approved update and evidence table. Preserve these facts exactly: approval-queue access is limited to pilot users in 12 workspaces; the wider rollout date is unconfirmed; ISS-184 and ISS-191 remain open. Do not add results, deadlines, customer reactions, or rollout timing.

The email should help internal teams understand what changed and link back to the approved update. The checklist should assign the next review work. Include an owner and review-date field. Return both as drafts for human approval. Do not send, schedule, or publish anything.

Team email draft

Subject: Weekly product update: exports, digest settings, and mobile retry

Team,

This week's approved update covers 3 shipped changes: the workspace access-report CSV export, the optional weekly notification digest, and mobile upload retry that preserves a draft after an interruption.

Please read the approved update before describing these changes externally. The access export may omit the last access date for suspended users while ISS-184 remains open. Support monitoring for the mobile retry also continues.

The approval queue remains limited to pilot users in 12 workspaces. Its wider rollout date is unconfirmed, and ISS-191 remains under investigation. Do not describe the queue as available to all users.

Next action: the product lead will confirm the approved status of ISS-184 and ISS-191 by [REVIEW DATE].

Approved update: [INTERNAL LINK]
Owner: [PRODUCT LEAD]

Action checklist draft

• [ ] Product lead checks the latest status of ISS-184.
• [ ] Product lead checks the latest status of ISS-191.
• [ ] Support confirms whether new mobile retry reports change the approved wording.
• [ ] Update owner records the next review date: [DATE].
• [ ] Reviewer confirms the phrase pilot users in 12 workspaces remains unchanged.
• [ ] Reviewer confirms no wider rollout date was added.
• [ ] Product lead approves the next update before reuse.

Save the handoff package

Save these 5 items together:

1. Completed workflow brief.
2. Reviewed evidence table with unresolved gaps.
3. Product-lead-approved weekly update.
4. Team email draft.
5. Action checklist draft.

For the next run, duplicate the folder, replace the source files and evidence cutoff, then rerun Research. Do not carry forward an old claim simply because the structure is reusable.

Stop conditions

Pause the workflow when a required file is missing, sources conflict, scope is unclear, a claim lacks support, or the human owner has not approved the previous stage. When browsing is unavailable, work only from supplied files and mark missing evidence as SOURCE NEEDED. Do not continue to polished drafting merely to complete the sequence.

Decide what stays human

Finished-state checklist

• [ ] The research question is narrow enough to answer.
• [ ] Every factual claim has a usable source.
• [ ] The primary asset passed its evidence and editorial gates.
• [ ] The approved draft is the source of truth for reuse.
• [ ] Each reused asset has a distinct audience moment and job.
• [ ] No output contains unresolved production markers.
• [ ] A human owner approved the final deliverables.
• [ ] The next iteration has a named input, owner, and review date.

Continue on NEXAIUM

Choose a more specialized starting template from 36 Professional Prompts for Claude. When the same workflow proves useful several times, package its rules with Build a Claude Code Skill.

Official references

• Anthropic prompt engineering overview
• Anthropic long-context prompting guidance
• Claude Projects guide
• Claude Artifacts guide
• Perplexity Pro Search guide

Sources were reviewed on 2026-09-04. Available models, search features, project behavior, and interfaces can change. Verify current official documentation before standardizing the workflow for a team.