Role-Specific Use Cases Basics

9 examples to get you started with role-specific use cases - 6 basic and 3 intermediate.

Prerequisites

• A Claude.ai account, with Projects available on paid plans (check your workspace's plan if you do not see a Projects option in the sidebar).
• No installation or setup beyond a normal login. Everything below happens in the browser or desktop app.
• Some familiarity with plain chat conversations is helpful, since these examples build on top of that.

Basic Examples

1. Identify Your Role's Recurring Task

Before setting anything up, name the one task you do most often in your job that involves writing, summarizing, or reviewing text.

• A writer might name "drafting chapter outlines," an analyst might name "turning a spreadsheet into a summary," a marketer might name "writing campaign copy variations."
• If you cannot name a recurring task, you likely only need plain chat for now, not a dedicated setup.
• Write this task down in one sentence - it becomes the scope for the Project you build in the next example.
• The goal is specificity: "write emails" is too broad, "draft first-reply emails for billing disputes" is usable.

Related: How Claude Adapts to Different Job Functions - why the same features serve every role differently.

2. Build a Role-Specific Project

Create a Project scoped to the recurring task you just named, and add the context that task always needs.

• Name the Project after the task, not your job title, such as "Billing Dispute Replies" rather than "Support Work."
• Add custom instructions describing tone, audience, and any rules specific to that task.
• Upload one or two files that task always references, such as a style guide, a template, or a policy document.
• Keep the scope narrow at first; you can always expand it once you see what the Project is missing.

Related: Choosing Projects vs Artifacts by Role - when a Project earns its setup cost for your role.

3. Match Your Prompt to Your Role's Voice

Ask Claude for output in the register your job actually requires, rather than a generic answer.

• Specify the audience explicitly: "for a client email" reads differently than "for an internal Slack message."
• Name the format you need, such as "three bullet points" or "a short paragraph," instead of leaving it open-ended.
• If your role has house style rules, such as never using exclamation points in support replies, state that rule directly in the prompt or the Project instructions.
• Compare the first draft against what you would have written yourself, and adjust the prompt, not just the output, next time.

Related: Role-Based Prompt Checklist by Job Function - ready-made prompt patterns organized by role.

4. Choose an Artifact for a Deliverable, Not a Quick Answer

Notice the difference between a question you want answered once and a document you expect to revise.

• A one-line question, like "what's a synonym for this word," belongs in plain chat.
• A campaign brief, a report summary, or a draft chapter belongs in an Artifact, since you will likely ask for changes.
• Ask directly for the deliverable, such as "write this as a document I can revise," if Claude does not open an Artifact on its own.
• Once the Artifact exists, describe changes in plain language rather than re-explaining the whole task from scratch.

Related: When to Use an Artifact Instead of a Chat Reply - the decision rule behind this example.

5. Borrow a Prompt Pattern From an Adjacent Role

Read how a neighboring role uses Claude, even if it is not your own, since many patterns transfer.

• A marketer's habit of asking for "three variations, ranked by tone" works just as well for a support agent drafting a difficult reply.
• An analyst's habit of asking Claude to state its assumptions before summarizing works well for anyone reviewing a document for accuracy.
• Skim one or two of the role-specific articles in this section even if they do not match your title.
• Keep a short personal list of patterns that worked well, regardless of which role they came from originally.

Related: Claude for Customer Support: Drafting Responses and Summarizing Tickets - one example of a role-specific pattern set.

6. Know When Plain Chat Is Still Enough

Resist the urge to build a Project for every single task, and recognize genuinely one-off work.

• If a task will not repeat this month, a Project is setup cost with no payoff.
• Plain chat still benefits from a clear, specific prompt, even without persistent context.
• Revisit the decision only once a "one-off" task turns out to recur - that is the actual signal to build a Project.
• Most people over time end up with a small number of active Projects, not one for every possible task.

Intermediate Examples

7. Hand Off Work Between Two Roles in One Workflow

Practice a workflow where one role's output becomes another role's input, such as an analyst's summary feeding a marketer's campaign brief.

• Keep the two tasks in separate Projects, since they have different audiences and voice rules, even though the content flows between them.
• Copy the finished Artifact's key points into the next Project's conversation rather than trying to merge the two Projects.
• Ask the second Project to explicitly restate its understanding of the handed-off material before it starts drafting, as a quick accuracy check.
• This pattern mirrors how cross-functional work actually happens on a team, one role's output becoming the next role's starting point.

Related: Claude for Business Analysts: Summarizing Data and Reports - the analyst side of a hand-off like this.

8. Audit a Project for Role Drift

Review a Project you have used for a few weeks and check whether its scope still matches the task it was built for.

• Read back through the custom instructions and ask whether they still describe how you actually use this Project today.
• Check the uploaded files for anything outdated, such as a superseded style guide or a policy document from a prior quarter.
• If you notice the Project now covers two unrelated tasks, consider splitting it into two narrower Projects.
• A short quarterly check like this keeps a Project's answers sharp instead of gradually drifting off-topic.

Related: Role-Specific Use Cases Best Practices - habits for keeping role-based setups working well over time.

9. Scale a Working Pattern Across a Team

Once a Project setup works well for you individually, adapt it so a teammate in the same role can use it too.

• Write the custom instructions so they describe the task and the rules, not personal shorthand only you would understand.
• Share the Project's file list as a starting checklist for a teammate building their own version, rather than assuming shared access.
• Ask a teammate to try the same recurring task and compare their draft outputs against yours to spot instruction gaps.
• Treat the first shared version as a draft standard, expecting to refine it once more than one person is relying on it.

Related: Claude for Marketers: Campaign Ideation and Content at Scale - a role where scaling a pattern across a team is especially common.

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.