30 Claude Prompts That Write Tutorials

You are an operations lead who writes clear process tutorials. <context> I need a ready-to-publish tutorial that documents how to onboard a new team member end to end, so any manager can follow it, as a self-contained Markdown document. </context> <inputs> - Role being onboarded: [E.G. SUPPORT REP, ENGINEER] - Timeframe: [E.G. FIRST 30 DAYS] - Tools and accounts to grant: [LIST] - Who is responsible for what: [MANAGER, IT, BUDDY] - Success at day 30: [WHAT GOOD LOOKS LIKE] </inputs> <task> Write: the outcome (a productive new hire by day 30), Prerequisites (accounts, hardware, buddy assigned), then a phased, numbered process: before day one, day one, week one, and weeks two-to-four. Each step names the action, the owner, and a checkbox, with a [SCREENSHOT: system/tool] placeholder where a tool is configured. Include an access-and-accounts checklist table, a 30-day check-in agenda, and a Recap. Make it reusable for future hires. </task> <constraints> - Assign an owner to every step; no orphaned tasks. - Use checkboxes so it doubles as a working checklist. - Group by phase (pre-start, day one, week one, month one). </constraints> <format> Return the full onboarding process tutorial as a Markdown artifact, then note which step to automate first to save the manager time. </format>

You are a content operations manager who writes workflow tutorials. <context> I need a tutorial that documents the full workflow to take a piece of content from idea to published, so a whole team follows the same path, as a self-contained Markdown document. </context> <inputs> - Content type: [E.G. BLOG POST, VIDEO, NEWSLETTER] - Stages you use: [E.G. IDEA, DRAFT, EDIT, DESIGN, PUBLISH, PROMOTE] - Tools per stage: [WHICH TOOL AT EACH] - Roles involved: [WRITER, EDITOR, DESIGNER] - Definition of done: [WHAT PUBLISHED-AND-PROMOTED MEANS] </inputs> <task> Write: the outcome (consistent, on-time publishing), Prerequisites, then numbered stages from idea to promotion. For each stage give: the goal, the owner, entry and exit criteria, the tool used, and a [SCREENSHOT: board/tool] placeholder. Include a handoff checklist between stages, a status-label scheme, an SLA or timing per stage, and a Recap with the top bottleneck to watch. Make it usable as a repeatable playbook. </task> <constraints> - Define entry and exit criteria for each stage; no fuzzy handoffs. - Assign an owner and a timing/SLA to every stage. - Include a status-label scheme the team can apply in their tool. </constraints> <format> Return the full publishing workflow tutorial as a Markdown artifact, then note the stage most likely to become a bottleneck. </format>

You are an engineering manager who writes process tutorials for dev teams. <context> I need a tutorial that documents how the team triages incoming bugs consistently, from report to resolution, as a self-contained Markdown document ready for the team wiki. </context> <inputs> - Where bugs come in: [E.G. SUPPORT, USERS, MONITORING] - Severity levels you use: [E.G. P0-P3 OR DEFINE THEM] - Tool: [E.G. LINEAR, JIRA, GITHUB ISSUES] - Who triages and how often: [ROLE, CADENCE] - SLA targets: [RESPONSE/FIX TIME PER SEVERITY] </inputs> <task> Write: the outcome (predictable, fair triage), Prerequisites, then numbered steps: intake and deduplicate, reproduce and confirm, assign a severity using a clear rubric, label and route to an owner, and track to resolution. Include a severity rubric table (level, definition, example, SLA), a [SCREENSHOT: issue board] placeholder, a triage-meeting agenda, and a Recap. Make it a repeatable weekly ritual. </task> <constraints> - Include a concrete severity rubric with definitions, examples, and SLAs. - Cover deduplication and reproduction before assignment. - Define the triage cadence and who owns it. </constraints> <format> Return the full bug-triage tutorial as a Markdown artifact, then note the most common severity-misclassification to guard against. </format>

You are an operations analyst who writes recurring-process tutorials. <context> I need a tutorial that documents a repeatable weekly reporting routine so anyone on the team can produce the report the same way, as a self-contained Markdown document. </context> <inputs> - What the report covers: [E.G. GROWTH METRICS, SALES, SUPPORT] - Data sources: [WHERE NUMBERS COME FROM] - Audience and format: [E.G. SLACK SUMMARY, SLIDE, DOC] - Key metrics: [THE 4-6 NUMBERS THAT MATTER] - When it is due: [DAY AND TIME] </inputs> <task> Write: the outcome (a consistent report on time every week), Prerequisites (access to sources), then numbered steps: pull each data source, calculate the key metrics, compare to last week and target, write the narrative summary, and distribute. Each data-pull step has a [SCREENSHOT: dashboard] placeholder and the exact filter or query to use. Include a metric-definitions table so numbers are computed identically, a report template to fill in, and a Recap. </task> <constraints> - Include a metric-definitions table so every metric is computed the same way each week. - Provide a fill-in-the-blank report template. - Show the week-over-week and vs-target comparison explicitly. </constraints> <format> Return the full reporting routine tutorial as a Markdown artifact, then note which metric definition is easiest to get inconsistent. </format>

You are a customer-support operations lead who writes process tutorials. <context> I need a tutorial that documents how support tickets get escalated cleanly from frontline to specialists to engineering, as a self-contained Markdown document ready for the team. </context> <inputs> - Support tiers you have: [E.G. TIER 1, TIER 2, ENGINEERING] - Tool: [E.G. ZENDESK, INTERCOM, FRESHDESK] - What triggers an escalation: [CRITERIA] - Response/resolution SLAs: [PER TIER] - Info required to escalate: [WHAT MUST BE ATTACHED] </inputs> <task> Write: the outcome (fast, no-ping-pong escalations), Prerequisites, then numbered steps: assess and attempt at tier one, decide with a clear escalation-criteria checklist, package the ticket with required context, route to the right tier, and hand back on resolution. Include an escalation-criteria table (trigger, target tier, SLA), a required-context checklist so nothing bounces back, a [SCREENSHOT: ticket view] placeholder, and a Recap. Make it a repeatable standard. </task> <constraints> - Define explicit escalation criteria so agents do not escalate everything. - Include a required-context checklist to prevent ticket ping-pong. - Assign SLAs and an owner to each tier. </constraints> <format> Return the full escalation flow tutorial as a Markdown artifact, then note the missing-context item that causes the most bounce-backs. </format>

You are a patient teacher who writes true-beginner getting-started guides. <context> I need a beginner guide that gets a total newcomer from account creation to their first real win in a specific tool, as a self-contained Markdown document ready to publish. </context> <inputs> - Tool: [WHICH APP] - The reader's goal: [THE FIRST USEFUL THING THEY WANT TO DO] - Their background: [ASSUME ZERO EXPERIENCE?] - Time budget: [E.G. 15 MINUTES] - One term they will not know: [JARGON TO DEFINE] </inputs> <task> Write: a warm intro promising a concrete first win, a "what you need" Prerequisites line, a short glossary of 3-5 key terms in plain language, then numbered steps: create the account, orient them to the main screen, and walk through achieving that first win. Each step has a [SCREENSHOT: ...] placeholder and explains the why, not just the click. Add a "you did it" checkpoint, three next things to try, and a Recap. </task> <constraints> - Assume zero prior knowledge; define every term on first use. - Get to a real, satisfying first win, not just a tour. - Explain why each step matters, not only what to click. </constraints> <format> Return the full beginner guide as a Markdown artifact, then note the moment a first-timer is most likely to feel lost. </format>

You are a developer educator who writes gentle beginner coding guides. <context> I need a beginner guide that teaches someone with no version-control experience to put their first project on GitHub and make changes safely, as a self-contained Markdown document with runnable commands. </context> <inputs> - Reader background: [E.G. CAN CODE A LITTLE, NEVER USED GIT] - Operating system: [MAC / WINDOWS / LINUX] - Their project: [WHAT THEY WANT TO PUSH] - Working solo or with others: [SOLO / TEAM] - One fear to address: [E.G. LOSING WORK, MERGE CONFLICTS] </inputs> <task> Write: a plain-language explanation of what Git and GitHub are and why they matter, Prerequisites (install and account), a mini-glossary (repo, commit, push, branch, pull request), then numbered steps: install and configure Git, create a repo, make the first commit, connect to GitHub and push, then create a branch and open a pull request. Every command is in a code block with the expected output and a plain explanation. Add a "what to do if you mess up" safety section and a Recap. </task> <constraints> - Explain each command in plain words right after the code block. - Cover the reader's stated fear directly with a recovery step. - Show expected terminal output so they know it worked. </constraints> <format> Return the full Git beginner guide as a Markdown artifact, then note the single command beginners fear most and why it is safe. </format>

You are a friendly instructor who writes beginner spreadsheet guides. <context> I need a beginner guide that takes someone who has never used spreadsheets to confidently building a simple, useful sheet, as a self-contained Markdown document ready to publish. </context> <inputs> - Tool: [GOOGLE SHEETS / EXCEL] - What they want to build: [E.G. A SIMPLE BUDGET, A TASK LIST] - Their comfort level: [ASSUME NONE] - The formulas they need: [E.G. SUM, AVERAGE, IF] - Where they will use it: [WORK / PERSONAL] </inputs> <task> Write: a plain intro on what a spreadsheet is and when it beats a note, Prerequisites, a mini-glossary (cell, row, column, formula), then numbered steps: enter data, format it as a table, write their first SUM, add one more formula they need, and turn it into a tiny chart. Each step has a [SCREENSHOT: ...] placeholder and shows the exact formula to type with what each part means. Add a common-mistakes note (mixing text and numbers), a small practice task, and a Recap. </task> <constraints> - Show each formula literally and break down what every part does. - Get them to a working, useful sheet, not abstract theory. - Include one hands-on practice task at the end. </constraints> <format> Return the full spreadsheet beginner guide as a Markdown artifact, then note the formatting habit that saves beginners the most headaches. </format>

You are an AI educator who writes beginner-friendly prompting guides. <context> I need a beginner guide that teaches someone new to AI how to write prompts that get reliably good results, as a self-contained Markdown document with copy-paste examples. </context> <inputs> - Reader's goal: [WHAT THEY WANT AI TO HELP WITH] - Their experience: [NEVER PROMPTED SERIOUSLY] - The tool they use: [E.G. CLAUDE, CHATGPT] - A task they will try: [A REAL EXAMPLE TASK] - Their frustration so far: [E.G. VAGUE, GENERIC ANSWERS] </inputs> <task> Write: a plain intro on why prompt quality changes output, Prerequisites, then numbered lessons that each teach one principle with a bad-prompt and better-prompt example side by side: give a role, add context, specify the format, provide an example, and set constraints. Apply each principle to the reader's real task so it compounds into one strong final prompt. Include a reusable prompt template, a common-mistakes list, and a Recap. </task> <constraints> - Show a weak-vs-strong prompt pair for every principle. - Build toward one polished prompt for the reader's actual task. - End with a fill-in-the-blank reusable prompt template. </constraints> <format> Return the full prompting beginner guide as a Markdown artifact, then note the single change that most improves a beginner's prompts. </format>

You are a personal-finance coach who writes approachable beginner guides. <context> I need a beginner guide that helps someone set up their first personal budget and actually stick to it, as a self-contained Markdown document ready to publish, judgment-free and practical. </context> <inputs> - Income situation: [E.G. STEADY SALARY, IRREGULAR FREELANCE] - Their goal: [E.G. STOP OVERSPENDING, SAVE FOR X] - Tool preference: [SPREADSHEET / APP / PAPER] - Biggest money worry: [WHAT KEEPS THEM UP] - How often they will review: [WEEKLY / MONTHLY] </inputs> <task> Write: an encouraging intro on why a simple budget beats a perfect one, Prerequisites (gather last month's statements), a mini-glossary (fixed vs variable, needs vs wants), then numbered steps: total income, list and categorize expenses, pick a simple framework (like 50/30/20) and adapt it, set one savings target, and choose a review ritual. Include a fill-in budget table, a [SCREENSHOT: sheet/app] placeholder, a "what to do in a tight month" section, and a Recap. </task> <constraints> - Keep it judgment-free and doable; no shaming, no 40-category systems. - Provide a concrete fill-in budget table with example numbers. - Address the reader's stated worry directly. </constraints> <format> Return the full budgeting beginner guide as a Markdown artifact, then note the one habit that most determines whether a budget sticks. </format>

You are a database performance engineer who writes advanced technical deep-dives. <context> I need an advanced tutorial that teaches an experienced developer how to design indexes that actually speed up their queries, with reasoning and measured proof, as a self-contained Markdown document with runnable SQL. </context> <inputs> - Database: [E.G. POSTGRES, MYSQL] - The slow query or workload: [PASTE OR DESCRIBE IT] - Table sizes and shape: [ROW COUNTS, KEY COLUMNS] - Read/write mix: [MOSTLY READS? HEAVY WRITES?] - Current indexes: [WHAT EXISTS NOW] </inputs> <task> Write: the goal (faster queries without wrecking writes), Prerequisites, then a conceptual section on how the index type works (B-tree, composite, partial, covering) tied to the reader's query. Follow with numbered steps: read the query plan (EXPLAIN ANALYZE), identify the bottleneck, design the index with column order justified, create it, and re-measure. Show the before/after query plans and timings in code blocks. Add a trade-offs section (write cost, bloat), an anti-patterns list, and a Recap. </task> <constraints> - Justify column order and index type against the actual query, not generically. - Show real EXPLAIN ANALYZE output before and after with timings. - Cover the write-and-storage trade-off honestly; no "just add indexes". </constraints> <format> Return the full indexing deep-dive as a Markdown artifact, then note the query-plan signal that tells you an index is being ignored. </format>

You are an automation architect who writes advanced power-user tutorials. <context> I need an advanced tutorial that levels up someone who builds basic automations into designing robust, multi-step ones with branching, error handling, and rate-limit safety, as a self-contained Markdown document. </context> <inputs> - Platform: [E.G. MAKE, ZAPIER, N8N] - The workflow to build: [MULTI-STEP GOAL] - Where it currently breaks: [FAILURE POINT] - APIs or data volume involved: [DETAILS] - Reader level: [BUILDS SIMPLE ZAPS, WANTS ROBUST ONES] </inputs> <task> Write: the goal (a reliable multi-step automation), Prerequisites, then a concepts section on branching (paths/filters), loops/iterators, data stores, and error handlers. Follow with numbered build steps: structure the flow, add conditional paths, batch and paginate API calls, add retries and error branches, and set rate-limit-safe delays. Each step has a [SCREENSHOT: scenario] placeholder and a concrete config (e.g., the exact filter condition or the retry settings). Add a testing-with-failure-injection section and a Recap. </task> <constraints> - Cover error handling and retries explicitly; a happy-path-only automation is a fail. - Address rate limits and pagination for API-heavy steps. - Show concrete filter/branch conditions, not "add a filter". </constraints> <format> Return the full advanced automation tutorial as a Markdown artifact, then note the failure mode most people forget to handle. </format>

You are a performance engineer who writes systematic optimization tutorials. <context> I need an advanced tutorial that teaches a developer to profile and speed up a slow web app methodically, from measurement to fix to proof, as a self-contained Markdown document. </context> <inputs> - Stack: [FRONTEND, BACKEND, DATABASE] - The symptom: [E.G. SLOW PAGE LOAD, LAGGY API] - Current metrics: [LCP, TTFB, P95 LATENCY IF KNOWN] - Suspected culprit: [IF ANY] - Constraints: [CANT CHANGE X] </inputs> <task> Write: the goal (measurably faster with proof), Prerequisites (baseline measurement first), then a method section on measure-before-you-optimize. Follow with numbered steps across layers: profile the frontend (bundle, render, network), the backend (slow endpoints, N+1 queries), and the database (query plans, caching). Each step names the tool to use, the metric to read, and a code or config fix in a block. Show before/after numbers at each layer. Add a prioritization framework (biggest win first) and a Recap. </task> <constraints> - Establish a baseline metric before any change; optimize by evidence, not hunch. - Cover frontend, backend, and database layers, each with a real tool and metric. - Show before/after numbers to prove each fix worked. </constraints> <format> Return the full performance deep-dive as a Markdown artifact, then note the layer that usually hides the biggest single win. </format>

You are a spreadsheet modeling expert who writes advanced formula tutorials. <context> I need an advanced tutorial that teaches a competent spreadsheet user to solve a real, gnarly problem using powerful formulas, as a self-contained Markdown document with copy-ready formulas. </context> <inputs> - Tool: [EXCEL / GOOGLE SHEETS] - The problem to solve: [E.G. DYNAMIC LOOKUP, ROLLING TOTALS, DEDUPE] - The data shape: [COLUMNS AND WHAT THEY HOLD] - Formulas they know: [SO YOU CAN GO BEYOND THEM] - Constraint: [MUST WORK ON OLD EXCEL? NO ARRAYS?] </inputs> <task> Write: the goal (a robust formula solving their exact problem), Prerequisites, then a concepts section on the functions involved (e.g., INDEX/MATCH or XLOOKUP, FILTER, LET, dynamic arrays). Follow with numbered steps that build the final formula incrementally: start simple, add lookup logic, handle errors with IFERROR, and make it spill or dynamic. Each step shows the exact formula, what each argument does, and the result on sample data. Add a version-compatibility note, a debugging tip, and a Recap. </task> <constraints> - Build the formula step by step; do not just present the final monster formula. - Explain every argument and include error handling (IFERROR or similar). - Note version compatibility if the input flags an old Excel. </constraints> <format> Return the full advanced Excel tutorial as a Markdown artifact, then note the function that makes this class of problem dramatically easier. </format>

You are a platform engineer who writes advanced CI/CD tutorials. <context> I need an advanced tutorial that teaches a developer to design a production-grade CI/CD pipeline for their project, from commit to deploy with safety gates, as a self-contained Markdown document with real config. </context> <inputs> - Stack and repo: [LANGUAGE, WHERE CODE LIVES] - CI platform: [E.G. GITHUB ACTIONS, GITLAB CI] - Deploy target: [WHERE IT SHIPS] - Stages you want: [TEST, LINT, BUILD, DEPLOY, ETC] - Safety needs: [E.G. REQUIRE REVIEW, STAGING GATE] </inputs> <task> Write: the goal (safe, fast, automated shipping), Prerequisites, then a concepts section on pipeline stages, caching, secrets, and environments. Follow with numbered steps to build the pipeline file: trigger on push/PR, run lint and tests in parallel, build and cache dependencies, gate deploy behind a passing suite and manual approval to production, and add a rollback path. Each step includes the actual YAML config block and what it does. Add a secrets-handling note, a make-it-faster section (caching, concurrency), and a Recap. </task> <constraints> - Provide real, valid pipeline YAML for the named platform, not pseudo-config. - Include a deploy gate and a rollback path; no unguarded prod deploys. - Show how secrets are injected safely, never hardcoded. </constraints> <format> Return the full CI/CD deep-dive as a Markdown artifact, then note the gate that prevents the most production incidents. </format>