30 Claude Prompts for Confluence

You are a site reliability engineer who turns postmortems into repeatable runbooks. <context> We just closed an incident postmortem and I want the fix steps captured as a runbook so the next on-call engineer does not have to relearn them. </context> <inputs> - Postmortem summary: [PASTE POSTMORTEM SUMMARY] - Affected service: [SERVICE NAME] - Detection method: [ALERT OR MONITOR NAME] - Owning team: [TEAM NAME] </inputs> <task> Write a runbook with sections for symptoms, diagnosis steps, fix steps, and verification steps, based strictly on what actually happened and was fixed in the postmortem. </task> <constraints> Write each step as a numbered, actionable command or check, not a vague description. Do not include steps that were considered but not actually used to resolve the incident. Keep the whole runbook under 600 words. </constraints> <format> Return a Confluence page titled with the service name, sections Symptoms, Diagnosis, Fix Steps, Verification, and a Last Reviewed date placeholder. </format>

You are a DevOps engineer documenting release procedures for a Confluence space. <context> Our deployment process lives in a few people's heads and I need it written down so anyone on the team can run a release safely. </context> <inputs> - Service name: [SERVICE NAME] - Deployment tool: [TOOL, e.g. GitHub Actions or Jenkins] - Pre-deploy checks: [PRE DEPLOY CHECKS] - Rollback method: [ROLLBACK METHOD] </inputs> <task> Write a numbered deployment runbook covering pre-deploy checks, the deployment steps themselves, post-deploy verification, and what to do if something goes wrong. </task> <constraints> Write steps as commands or clicks a person can literally follow, not summaries. Call out any step that requires approval from another team. Avoid assuming tools not mentioned in the inputs. </constraints> <format> Return a Confluence page with numbered sections Pre-Deploy, Deploy, Verify, Rollback, and an Owners line at the top listing who to contact for each step. </format>

You are an on-call engineer who writes triage guides for the next shift. <context> Our on-call rotation keeps re-solving the same handful of alerts from scratch, and I want a triage guide that shortcuts that work. </context> <inputs> - Common alerts: [LIST OF ALERT NAMES] - Service: [SERVICE NAME] - Dashboards used: [DASHBOARD LINKS OR NAMES] - Escalation contact: [ESCALATION CONTACT OR CHANNEL] </inputs> <task> For each alert listed, write a short triage entry with likely causes, the first three checks to run, and when to escalate instead of continuing to debug alone. </task> <constraints> Keep each alert entry under 120 words. Order the checks from fastest to slowest to run. Be explicit about the exact condition that means stop and escalate. </constraints> <format> Return one Confluence page with an H3 heading per alert, followed by Likely Causes, First Checks, and Escalate When subsections. </format>

You are a release engineer who documents recovery procedures. <context> We have never written down how to roll back a bad release for this service and I want that fixed before the next incident forces us to improvise. </context> <inputs> - Service: [SERVICE NAME] - Deployment platform: [PLATFORM, e.g. Kubernetes or ECS] - Database migrations involved: [YES OR NO, AND DETAILS] - Typical rollback window: [TIME WINDOW] </inputs> <task> Write a rollback runbook covering how to detect a bad release, how to revert the deploy, how to handle any database migration that already ran, and how to confirm the rollback worked. </task> <constraints> Be explicit about irreversible steps, such as destructive migrations, and mark them with a warning label. Do not assume a migration can always be reversed unless the inputs say so. Keep the runbook actionable, not theoretical. </constraints> <format> Return a Confluence page with sections Detect, Revert Deploy, Handle Migrations, Confirm, and a bold Warning callout for irreversible steps. </format>

You are an incident commander who converts one-off fixes into standing documentation. <context> We fixed an outage manually last night and I want that fix turned into a permanent runbook page before the details are forgotten. </context> <inputs> - What broke: [WHAT BROKE] - Commands or actions used to fix it: [PASTE COMMANDS OR STEPS TAKEN] - Root cause if known: [ROOT CAUSE OR UNKNOWN] - Related service: [SERVICE NAME] </inputs> <task> Write a permanent runbook page that documents the symptoms that would indicate this same problem again, the exact steps taken to fix it, and a suggested longer-term prevention item. </task> <constraints> Use the exact commands given, do not paraphrase them into something more generic. If root cause is unknown, say so plainly instead of guessing one. Keep the prevention suggestion realistic, not a full redesign. </constraints> <format> Return a Confluence page with sections Symptoms, Fix Applied, Root Cause, Prevention Suggestion, tagged with the service name in the title. </format>

You are an executive assistant who writes clean meeting notes from raw transcripts. <context> I recorded a meeting and have a messy auto-generated transcript that needs to become a readable Confluence page. </context> <inputs> - Raw transcript: [PASTE TRANSCRIPT] - Meeting title: [MEETING TITLE] - Attendees: [LIST OF ATTENDEES] - Date: [MEETING DATE] </inputs> <task> Clean up the transcript into structured notes covering key discussion points, decisions made, and action items with an owner for each. </task> <constraints> Drop filler speech and false starts, keep the substance only. Every action item must have a named owner taken from the attendee list, never leave one unassigned without flagging it. Keep the whole page under 500 words. </constraints> <format> Return a Confluence page with sections Summary, Key Points, Decisions, Action Items table with columns Owner and Due Date. </format>

You are a program manager who sends recaps after stakeholder meetings. <context> I just finished a meeting with stakeholders from multiple teams and need a recap that keeps everyone aligned on what was agreed. </context> <inputs> - Rough notes from the meeting: [PASTE ROUGH NOTES] - Stakeholders present: [STAKEHOLDER NAMES AND TEAMS] - Project name: [PROJECT NAME] - Next meeting date: [NEXT MEETING DATE] </inputs> <task> Write a recap that states what was agreed, what was pushed back or deferred, and a clear action item list with owners and deadlines. </task> <constraints> Separate agreed items from deferred items clearly, do not blend them. Keep tone neutral and factual, not celebratory. Reference the next meeting date at the end so readers know when this will be revisited. </constraints> <format> Return a Confluence page with sections Agreed, Deferred, Action Items table, and Next Meeting line. </format>

You are a team lead who writes weekly sync summaries for a Confluence space. <context> Our team holds a weekly sync and I want a consistent summary page each week that people who missed it can catch up on quickly. </context> <inputs> - Sync notes this week: [PASTE THIS WEEK'S NOTES] - Team name: [TEAM NAME] - Week ending date: [WEEK ENDING DATE] - Ongoing projects: [LIST OF ONGOING PROJECTS] </inputs> <task> Summarize the sync into per-project status updates, blockers raised, and anything the team needs to decide before next week. </task> <constraints> Group updates by project name, not by speaker. Mark each project status as On Track, At Risk, or Blocked based on what was actually said. Keep each project update to two or three sentences. </constraints> <format> Return a Confluence page titled with the team name and week ending date, with an H3 per project showing Status, Update, Blockers. </format>

You are a client-facing consultant who documents call outcomes for internal tracking. <context> I just got off a call with a client and need an internal recap that the account team can reference without listening to the recording. </context> <inputs> - Call notes: [PASTE CALL NOTES] - Client name: [CLIENT NAME] - Attendees: [INTERNAL AND CLIENT ATTENDEES] - Contract stage: [CONTRACT STAGE, e.g. renewal or onboarding] </inputs> <task> Write an internal recap covering what the client asked for, any commitments we made, concerns they raised, and next steps with owners. </task> <constraints> Be precise about commitments made versus ideas floated, these are not the same and mixing them up creates risk. Do not soften concerns the client raised, note them plainly. Keep it under 400 words. </constraints> <format> Return a Confluence page with sections Client Asks, Commitments Made, Concerns Raised, Next Steps table with Owner and Due Date. </format>

You are a facilitator who turns open brainstorming sessions into concrete next steps. <context> We ran a brainstorm with a lot of ideas thrown around and I need to distill it into something the team can actually act on. </context> <inputs> - Raw ideas list: [PASTE RAW IDEAS] - Session topic: [SESSION TOPIC] - Participants: [PARTICIPANT NAMES] - Time available next sprint: [TIME OR CAPACITY ESTIMATE] </inputs> <task> Group the raw ideas into themes, flag the two or three most promising ones given the stated capacity, and write next steps for exploring them further. </task> <constraints> Do not discard ideas entirely, park lower priority ones in a Later section instead of deleting them. Base the promising picks on the stated capacity, not on personal preference. Keep the whole page under 450 words. </constraints> <format> Return a Confluence page with sections Themes, Top Picks with reasoning, Later, and Next Steps table with Owner. </format>

You are a team lead writing onboarding documentation for new hires. <context> We are hiring for the team and I want a single onboarding page that gets a new person oriented in their first week. </context> <inputs> - Team name: [TEAM NAME] - Role: [ROLE TITLE] - Key tools used: [LIST OF TOOLS] - Manager name: [MANAGER NAME] </inputs> <task> Write an onboarding page covering team mission, who is who, tools to set up, and a suggested first-week schedule of things to read or do. </task> <constraints> Keep the first-week schedule realistic, no more than two or three items per day. Do not list tools without a one-line note on what each is used for. Write in a welcoming but plain tone, not overly enthusiastic. </constraints> <format> Return a Confluence page with sections Team Mission, Who Is Who, Tools to Set Up, First Week Schedule as a day-by-day table. </format>

You are an HR business partner who builds structured onboarding checklists. <context> I want a 30 day onboarding checklist so a new employee and their manager both know what should happen and by when. </context> <inputs> - Role: [ROLE TITLE] - Department: [DEPARTMENT] - Key milestones expected by day 30: [MILESTONES] - Buddy or mentor assigned: [BUDDY NAME OR TBD] </inputs> <task> Write a checklist broken into Week 1, Week 2, Weeks 3 to 4, each with concrete tasks and who is responsible for making sure it happens. </task> <constraints> Every task needs a responsible party, either New Hire, Manager, or Buddy. Do not front-load everything into week one. Keep tasks specific, not vague statements like get familiar with the team. </constraints> <format> Return a Confluence page with a checklist table per week, columns Task, Responsible, Done. </format>

You are an IT onboarding coordinator documenting system access for new employees. <context> New hires keep asking the same questions about which systems they need access to, and I want a single page that answers this upfront. </context> <inputs> - Role: [ROLE TITLE] - Required systems: [LIST OF SYSTEMS] - Access request process: [HOW ACCESS IS REQUESTED] - IT contact: [IT CONTACT OR CHANNEL] </inputs> <task> Write a page listing each required system, why the role needs it, how to request access, and expected wait time if known. </task> <constraints> Group systems by category such as Communication, Development, Finance if that grouping applies. Do not assume a wait time was given if it wasn't, mark it Unknown instead of guessing. Keep each system entry to one or two lines. </constraints> <format> Return a Confluence page with a table: System, Purpose, How to Request, Expected Wait, grouped under category headers. </format>

You are an engineering manager writing a role-specific onboarding guide. <context> Generic onboarding covers the company, but I need a guide specific to what a new engineer on my team actually needs to learn. </context> <inputs> - Role: [ROLE TITLE, e.g. backend engineer] - Codebase or repo names: [REPO NAMES] - Key systems they will touch: [SYSTEMS] - First project assigned: [FIRST PROJECT] </inputs> <task> Write a guide covering codebase orientation, local environment setup, key systems explained briefly, and how the first assigned project connects to what they just learned. </task> <constraints> Keep environment setup steps as literal commands, not descriptions. Explain each system in one paragraph maximum, assume no prior context. Connect the first project explicitly to at least one system covered earlier in the guide. </constraints> <format> Return a Confluence page with sections Codebase Orientation, Environment Setup, Key Systems, Your First Project. </format>

You are a people operations specialist compiling a new-hire FAQ page. <context> New hires keep asking the same questions in our Slack channel and I want an FAQ page that answers them once and for all. </context> <inputs> - Common questions asked: [PASTE LIST OF QUESTIONS OR TOPICS] - Company or team name: [COMPANY OR TEAM NAME] - Policy documents to reference: [POLICY DOC NAMES OR LINKS] - HR contact: [HR CONTACT] </inputs> <task> Write clear answers to each question, referencing the relevant policy document by name where applicable, and note when a question should instead be routed to the HR contact. </task> <constraints> Do not fabricate a policy detail that was not given, instead say see the policy document and name it. Keep each answer under 60 words. Order questions from most to least commonly asked. </constraints> <format> Return a Confluence FAQ page with each question as an H3 followed by its answer, and a Still Have Questions section linking to the HR contact. </format>

You are a principal engineer who writes architecture decision records for the team wiki. <context> We made an architecture decision in a meeting and I need it captured as a formal ADR before the reasoning is forgotten. </context> <inputs> - Decision made: [DECISION MADE] - Alternatives considered: [ALTERNATIVES CONSIDERED] - Reasoning discussed: [PASTE REASONING OR NOTES] - System affected: [SYSTEM NAME] </inputs> <task> Write an ADR with status, context, the decision itself, the alternatives with why they were rejected, and the consequences of this choice, both positive and negative. </task> <constraints> List at least two rejected alternatives with a concrete reason each, not just because it was worse. Include at least one real negative consequence, no decision is consequence-free. Keep the whole record under 500 words. </constraints> <format> Return a Confluence ADR page with sections Status, Context, Decision, Alternatives Considered, Consequences. </format>

You are an operations manager who maintains a decision log for process changes. <context> We changed how a recurring process works and I want it logged so future team members understand why it works this way now. </context> <inputs> - Process changed: [PROCESS NAME] - Old process: [OLD PROCESS SUMMARY] - New process: [NEW PROCESS SUMMARY] - Reason for change: [REASON FOR CHANGE] </inputs> <task> Write a decision log entry describing what changed, why, who approved it, and when the change should be revisited if it does not work out. </task> <constraints> State the old and new process side by side so the contrast is clear. Name a specific revisit condition, not a vague someday. Keep the entry under 300 words. </constraints> <format> Return a Confluence page with a comparison table Old vs New, followed by Reason, Approved By, Revisit Condition. </format>

You are a technical lead documenting a tool or vendor comparison for the record. <context> We evaluated two options and picked one, and I want the comparison written down so we stop re-litigating it every few months. </context> <inputs> - Option A: [OPTION A NAME] - Option B: [OPTION B NAME] - Evaluation criteria used: [CRITERIA, e.g. cost, latency, support] - Final choice: [FINAL CHOICE] </inputs> <task> Write a comparison covering each criterion for both options, a summary of tradeoffs, and the final recommendation with reasoning. </task> <constraints> Score each criterion for both options rather than only describing the winner. Be fair to the option not chosen, note what it did well. Keep total length under 450 words. </constraints> <format> Return a Confluence page with a comparison table by criterion, followed by Summary and Final Recommendation sections. </format>

You are a procurement lead documenting a vendor selection decision. <context> We just finished evaluating vendors for a new tool and I need the decision recorded for audit and future reference purposes. </context> <inputs> - Vendors evaluated: [LIST OF VENDORS] - Selected vendor: [SELECTED VENDOR] - Budget considered: [BUDGET RANGE] - Contract length: [CONTRACT LENGTH] </inputs> <task> Write a vendor decision record covering the evaluation criteria used, a brief note on each vendor considered, the final selection with reasoning, and the contract terms agreed. </task> <constraints> Include a short note on every vendor evaluated, not only the winner. State the budget and contract length exactly as given, do not round or approximate. Keep the record factual, no sales language. </constraints> <format> Return a Confluence page with sections Vendors Considered table, Selection Reasoning, Contract Terms. </format>

You are a team lead documenting the reversal of a previous decision. <context> A decision we made a while back is not working out and the team agreed to reverse it, and I want that reversal documented properly. </context> <inputs> - Original decision: [ORIGINAL DECISION] - What went wrong: [WHAT WENT WRONG] - New direction: [NEW DIRECTION] - Link to original decision record: [LINK OR PAGE NAME] </inputs> <task> Write a page that references the original decision, explains plainly what did not work and why, and lays out the new direction with a rough migration plan. </task> <constraints> Do not assign blame to individuals, describe the outcome factually instead. Reference the original decision record explicitly so the two pages link together. Keep the migration plan to concrete steps, not a vague intention. </constraints> <format> Return a Confluence page with sections Original Decision, What Did Not Work, New Direction, Migration Plan as a numbered list. </format>

You are a documentation owner responsible for keeping a Confluence space accurate. <context> I have an old page that has not been updated in a long time and I am not sure what in it is still true. </context> <inputs> - Page content: [PASTE FULL PAGE CONTENT] - Last updated date: [LAST UPDATED DATE] - What has changed since then: [KNOWN CHANGES SINCE THEN] - Page owner: [PAGE OWNER] </inputs> <task> Go through the page and flag which sections are likely outdated given the known changes, which are probably still accurate, and suggest specific rewrites for the outdated parts. </task> <constraints> Only flag a section as outdated if it conflicts with a stated known change, do not guess beyond that. Keep suggested rewrites short and specific, not a full page rewrite. List the page owner at the top so accountability is clear. </constraints> <format> Return a Confluence comment-style audit with sections Likely Outdated, Probably Still Accurate, Suggested Rewrites. </format>

You are an information architect who restructures dense documentation. <context> This page has grown into one long wall of text and nobody reads it anymore, I need it broken into a scannable structure. </context> <inputs> - Page content: [PASTE FULL PAGE CONTENT] - Primary audience: [PRIMARY AUDIENCE] - Most common question this page answers: [MOST COMMON QUESTION] - Page purpose: [PAGE PURPOSE] </inputs> <task> Restructure the content into clear H2 and H3 sections, pull out anything that reads as a step into a numbered list, and put the answer to the most common question near the top. </task> <constraints> Do not remove any actual information from the original text, only reorganize it. Keep headers short and scannable, three to five words. Add a short table of contents at the top. </constraints> <format> Return the restructured Confluence page with a table of contents, then the reorganized sections. </format>

You are a documentation lead setting writing standards for a Confluence space. <context> Our pages are written inconsistently across teams and I want a style guide so new pages follow the same conventions. </context> <inputs> - Examples of good existing pages: [PASTE OR DESCRIBE EXAMPLES] - Examples of inconsistent pages: [PASTE OR DESCRIBE PROBLEMS] - Team name: [TEAM NAME] - Tone preference: [TONE, e.g. concise and direct] </inputs> <task> Write a style guide covering heading structure, tone, how to write action items, how to handle placeholders and TBDs, and naming conventions for page titles. </task> <constraints> Base every rule on an actual pattern from the good or bad examples given, not generic advice. Keep the guide itself under 500 words so people actually read it. Include one short before-and-after example. </constraints> <format> Return a Confluence page with sections Headings, Tone, Action Items, Placeholders and TBDs, Page Titles, and one Before/After example. </format>

You are a documentation architect designing reusable Confluence templates. <context> Every runbook we write looks different and I want a single template so future ones are consistent and complete from the start. </context> <inputs> - Existing runbooks to model from: [PASTE OR LIST EXISTING RUNBOOKS] - Required sections per company policy: [REQUIRED SECTIONS IF ANY] - Team that will use it: [TEAM NAME] - Tool used to trigger the runbook: [MONITORING OR ALERTING TOOL] </inputs> <task> Design a runbook template with placeholder sections and short instructional notes explaining what to put in each one, based on patterns from the existing runbooks provided. </task> <constraints> Keep instructional notes in italics so they are visually distinct from real content once someone fills the template in. Include every required section from company policy if any were given. Do not make the template longer than what the example runbooks actually use. </constraints> <format> Return a Confluence template page with each section heading followed by an italic instructional note and a placeholder line. </format>

You are a documentation program manager planning a periodic cleanup effort. <context> Our Confluence space has grown messy over the quarter and I want a concrete cleanup plan rather than a vague someone should fix this later. </context> <inputs> - Known problem areas: [LIST OF PROBLEM SPACES OR PAGES] - Available hours for cleanup: [HOURS OR TEAM CAPACITY] - Owners available to help: [NAMES OR TEAMS] - Deadline for this cleanup: [DEADLINE] </inputs> <task> Write a cleanup plan that prioritizes the known problem areas by impact, assigns them to available owners, and fits the work within the stated capacity and deadline. </task> <constraints> Do not assign more work to an owner than the stated capacity allows. Prioritize by which pages get the most traffic or cause the most confusion if that information is given. Keep the plan realistic enough to actually finish by the deadline. </constraints> <format> Return a Confluence page with a prioritized table: Area, Owner, Estimated Hours, Deadline, and a short Success Criteria section at the end. </format>