30 Claude Prompts for Platform Engineers

You are a platform engineer designing the API surface of an internal developer platform. <context> I am building a self-service endpoint so application teams can request infrastructure without filing a ticket, and I need the contract defined before implementation starts. </context> <inputs> - Resource being requested: [RESOURCE, E.G. NEW DATABASE, NEW QUEUE] - Fields a requesting team must provide: [LIST FIELDS] - Fields that should default automatically: [LIST DEFAULTS] - Approval requirement: [AUTO APPROVE, MANUAL, CONDITIONAL] </inputs> <task> Define the request and response schema for this endpoint, including required fields, optional fields with defaults, and the possible response states such as pending, approved, or rejected with reason. </task> <constraints> Use plain field names an application engineer would recognize, not internal platform jargon. Include validation rules for at least three fields. Do not design authentication, assume it is handled elsewhere. </constraints> <format> Return a JSON schema style block for the request, a JSON schema style block for the response, and a short list of validation rules below both. </format>

You are a platform architect evaluating whether to build or buy a component of the internal developer platform. <context> We need a decision on whether to build this component ourselves or adopt an existing tool, and I want a structured comparison before bringing it to leadership. </context> <inputs> - Component under evaluation: [COMPONENT, E.G. SERVICE CATALOG, SECRETS BROKER] - Candidate tools considered: [TOOL A, TOOL B, OR NONE YET] - Team size available to build and maintain: [NUMBER OF ENGINEERS] - Non-negotiable requirement: [REQUIREMENT] </inputs> <task> Compare building in-house against the candidate tools across integration effort, ongoing maintenance burden, and how well each meets the non-negotiable requirement. End with a recommendation and the main risk of that recommendation. </task> <constraints> Do not default to recommending build just because it sounds impressive, weigh maintenance cost honestly against the stated team size. If information is missing to judge a tool, say so instead of inventing details. </constraints> <format> Return a comparison table with rows for integration effort, maintenance burden, and requirement fit, then a two sentence recommendation with one named risk. </format>

You are a platform engineer assessing where the internal developer platform sits on a maturity model. <context> Leadership wants to know how mature our platform is compared to industry norms so I need an honest maturity assessment across the capabilities we have and do not have yet. </context> <inputs> - Capabilities currently live: [LIST CAPABILITIES] - Capabilities planned but not built: [LIST PLANNED] - Team headcount on the platform: [NUMBER] - Org size the platform serves: [NUMBER OF ENGINEERS OR TEAMS] </inputs> <task> Place the platform on a four stage maturity model from ad hoc to self-service to insights-driven to a fully automated internal ecosystem, and justify the placement using the specific capabilities given, not general assumptions. </task> <constraints> Do not inflate the maturity stage to sound better than the inputs support. Name at least two specific gaps that block moving to the next stage. Keep the justification grounded in the listed capabilities only. </constraints> <format> Return the current stage name, a two sentence justification, and a bulleted list of the top three gaps blocking the next stage. </format>

You are a platform engineer standardizing how services are described in the internal service catalog. <context> Our service catalog entries are inconsistent, some teams fill in everything and others leave most fields blank, and I need a template that makes the useful fields obvious. </context> <inputs> - Catalog tool in use: [TOOL, E.G. BACKSTAGE, HOMEGROWN] - Fields currently required: [LIST CURRENT FIELDS] - Information consumers actually search for: [WHAT PEOPLE LOOK UP MOST] - Number of services currently cataloged: [NUMBER] </inputs> <task> Design a catalog entry template that keeps required fields to the minimum that gets filled in consistently, and separates them from optional fields that add value but should not block publishing an entry. </task> <constraints> Limit required fields to five or fewer. Justify each required field by naming who searches for it and why. Do not add fields nobody asked for. </constraints> <format> Return two lists labeled "required fields" and "optional fields", each field with a one line reason it exists. </format>

You are a platform engineer defining service level objectives for the internal developer platform itself, treating it as a product with internal customers. <context> Our platform has no SLOs of its own and teams have started complaining informally about slow provisioning without any agreed target to hold us to. </context> <inputs> - Platform services offered: [LIST SERVICES, E.G. PROVISIONING, CI RUNNERS] - Current rough performance if known: [NUMBERS OR UNKNOWN] - Internal customer expectation, if stated: [WHAT TEAMS HAVE ASKED FOR] - Team capacity to respond to incidents: [HOURS OR STAFFING NOTE] </inputs> <task> Propose an SLO for each listed platform service, covering both a latency or turnaround target and an availability target, sized to match the stated team capacity rather than an aspirational number. </task> <constraints> Do not propose SLOs stricter than the team can realistically support given the stated capacity. Flag any service where current performance data is missing instead of guessing a baseline. </constraints> <format> Return a table with columns: service, turnaround target, availability target, note on data confidence. </format>

You are a platform engineer building a scaffolding CLI that teams use to generate new services. <context> I have a working CLI tool but the help text is thin and new users keep asking questions the tool should answer itself. </context> <inputs> - CLI name and command structure: [CLI NAME AND SUBCOMMANDS] - Most common use case: [WHAT MOST USERS DO FIRST] - Flags currently supported: [LIST FLAGS] - Common mistake new users make: [MISTAKE] </inputs> <task> Write help text for the main command and each subcommand, plus three usage examples that show the most common workflow from first run to a working local service. </task> <constraints> Keep each help text entry to two lines or fewer. Examples must be copy-pasteable shell commands, not pseudocode. Address the common mistake directly in one example's comment. </constraints> <format> Return the help text formatted as it would appear in a terminal, followed by a section titled "examples" with three numbered shell snippets. </format>

You are a platform engineer converting a manual, ticket-based process into a self-service form. <context> Right now a team files a ticket and someone on platform manually provisions a resource by hand, and I want to replace that with a self-service form backed by automation. </context> <inputs> - Current manual checklist steps: [PASTE STEPS] - Resource being provisioned: [RESOURCE] - Information the requester must supply: [LIST FIELDS] - Steps that must stay manual for now: [LIST OR NONE] </inputs> <task> Convert the checklist into a form specification listing each field, its type, and validation, then map each remaining manual step to either full automation, partial automation with a notification, or a flagged manual step that cannot yet be removed. </task> <constraints> Do not claim a step can be automated if it depends on a system not mentioned in the inputs. Keep the field list only as long as necessary to complete provisioning, cut anything that only served the old ticket process. </constraints> <format> Return a form field table, then a mapping table with columns: original step, automation status, note. </format>

You are a platform engineer writing a software template for an internal developer portal. <context> I am publishing a new template to our developer portal and need the description and parameter list to be clear enough that a team picks the right template without asking platform for help first. </context> <inputs> - Template purpose: [WHAT IT SCAFFOLDS] - Parameters needed from the user: [LIST PARAMETERS] - Similar templates that might cause confusion: [OTHER TEMPLATE NAMES OR NONE] - Output the template produces: [WHAT GETS CREATED, E.G. REPO, PIPELINE] </inputs> <task> Write a short template description that distinguishes it from similar templates, and a parameter list with a plain language explanation and example value for each parameter. </task> <constraints> The description must be understandable without reading the underlying code. Each parameter explanation should be one sentence. Call out explicitly how this template differs from the similar ones named. </constraints> <format> Return a description paragraph of two to three sentences, then a parameter table with columns: name, explanation, example value. </format>

You are a platform engineer improving the error handling of a self-service provisioning tool. <context> Our tool currently fails with raw stack traces or generic errors, and teams using it cannot tell what went wrong or what to do next. </context> <inputs> - Tool name: [TOOL NAME] - Common failure cases: [LIST FAILURE CASES, E.G. QUOTA EXCEEDED, INVALID NAME] - Current error text if any: [PASTE CURRENT MESSAGES OR NONE] - Where the user should go for help: [DOC LINK, CHANNEL, OR TEAM] </inputs> <task> Rewrite each failure case into a clear error message that states what happened, why, and the specific next action the user should take, including where to go for help when it is not self-resolvable. </task> <constraints> Do not use generic phrases like "something went wrong". Each message must name the specific cause. Keep each message to two sentences or fewer. </constraints> <format> Return a table with columns: failure case, rewritten error message. </format>

You are a platform engineer retiring a legacy internal tool in favor of a newer self-service option. <context> We built a replacement for an old internal tool but teams are still using the legacy one out of habit, and I need a deprecation plan that does not break anyone unexpectedly. </context> <inputs> - Legacy tool name and what it does: [LEGACY TOOL AND PURPOSE] - Replacement tool name: [REPLACEMENT TOOL] - Known active users of the legacy tool: [TEAMS OR NUMBER] - Hard cutoff date if one exists: [DATE OR NONE] </inputs> <task> Write a deprecation plan with a timeline of phases, from announcement through a migration window to final shutdown, including what communication goes out at each phase and what happens to teams who miss the deadline. </task> <constraints> Include at least one phase with a grace period before hard cutoff. Do not schedule the hard cutoff less than a full migration window after the announcement. State a clear fallback for teams who cannot migrate in time. </constraints> <format> Return a phase table with columns: phase name, timeframe, communication sent, action for lagging teams. </format>

You are a platform engineer setting up a recurring developer experience survey for engineering teams. <context> We have never formally measured developer experience and I want a short survey that gives usable signal without becoming a chore teams skip. </context> <inputs> - Areas we suspect are weak: [LIST AREAS, E.G. LOCAL SETUP, CI SPEED] - Survey frequency planned: [QUARTERLY, MONTHLY] - Rough number of respondents expected: [NUMBER] - Existing metrics we already track: [LIST OR NONE] </inputs> <task> Design a survey with no more than ten questions, mixing a small number of rating scale questions with one or two open text questions, targeted at the suspected weak areas without leading the respondent toward a particular answer. </task> <constraints> Do not phrase questions in a way that assumes the problem exists, keep them neutral. Avoid duplicate coverage of the same area. Keep the whole survey completable in under five minutes. </constraints> <format> Return a numbered list of questions, each tagged with its type in brackets, rating scale or open text, and the area it measures. </format>

You are a platform engineer analyzing open text responses from a developer experience survey. <context> I have a pile of open text comments from the last survey round and need to find the real themes before I present anything to leadership. </context> <inputs> - Raw comments: [PASTE COMMENTS, ONE PER LINE] - Number of total respondents: [NUMBER] - Areas the survey covered: [LIST AREAS] - Known context that might explain a spike in complaints: [CONTEXT OR NONE] </inputs> <task> Group the comments into themes, count how many comments fall into each theme, and note which theme has the strongest language or most repeated wording, since that usually signals urgency. </task> <constraints> Do not merge distinct complaints into one theme just to simplify the summary. Quote at least one representative comment per theme without editing its wording. Do not draw conclusions the comments do not support. </constraints> <format> Return a table with columns: theme, comment count, representative quote, urgency note. </format>

You are a platform engineer choosing the metrics that will represent platform health on a leadership dashboard. <context> We are asked to report platform health monthly and need a small, defensible set of metrics rather than a wall of numbers nobody reads. </context> <inputs> - Platform capabilities to represent: [LIST CAPABILITIES] - Data sources currently available: [LIST SOURCES, E.G. CI LOGS, TICKETING] - Audience for the dashboard: [LEADERSHIP, ENGINEERING ORG, BOTH] - A metric leadership has asked for before: [METRIC OR NONE] </inputs> <task> Propose no more than six metrics that together represent platform health, map each to an available data source, and explain in one sentence why that metric matters to the stated audience rather than just to the platform team. </task> <constraints> Do not propose a metric with no listed data source behind it. Avoid vanity metrics that always trend positive regardless of real health. If the audience-requested metric is weak, say so and propose a better alternative alongside it. </constraints> <format> Return a table with columns: metric, data source, why it matters to the audience. </format>

You are a platform engineer preparing a delivery metrics report that avoids being read as a scoreboard. <context> I have deployment frequency, lead time, and failure rate numbers for the last quarter and want a report that explains what changed and why, not just the raw figures. </context> <inputs> - Deployment frequency this quarter versus last: [NUMBERS] - Lead time this quarter versus last: [NUMBERS] - Change failure rate this quarter versus last: [NUMBERS] - Known platform changes made this quarter: [LIST CHANGES OR NONE] </inputs> <task> Write a short report that states each metric's movement, connects it to a known platform change where plausible, and flags any metric movement that has no clear explanation instead of inventing one. </task> <constraints> Do not claim a platform change caused a metric shift unless the connection is reasonable, mark uncertain links as "possible factor" rather than stated fact. Keep the report to one page. Avoid framing any team as underperforming. </constraints> <format> Return one paragraph per metric, each ending with either a named likely cause or the label "no clear explanation yet". </format>

You are a platform engineer preparing a quarterly retrospective for the platform team using both usage data and qualitative signals. <context> Our platform team is running its own quarterly retro and I want to bring a data-grounded view of what worked and what did not, rather than relying on gut feel from a few loud complaints. </context> <inputs> - Adoption numbers for key platform features: [NUMBERS OR TRENDS] - Support ticket volume trend: [TREND, UP DOWN FLAT] - Biggest platform initiative this quarter: [INITIATIVE] - Anecdotal feedback received: [SUMMARY OR QUOTES] </inputs> <task> Write a retro summary structured as what went well, what did not, and what to change next quarter, grounding each point in either the adoption numbers, the ticket trend, or the anecdotal feedback rather than general impressions. </task> <constraints> Every point must cite which input it is based on. Do not include more than four points per section. Keep tone factual, not celebratory or apologetic. </constraints> <format> Return three sections titled "went well", "did not go well", "change next quarter", each with up to four bullet points citing the source input in parentheses. </format>

You are a platform engineer planning a phased rollout of a new platform capability across many engineering teams. <context> We are rolling out a new capability and I do not want to push it to every team at once, so I need to segment teams into rollout waves based on readiness and risk. </context> <inputs> - Capability being rolled out: [CAPABILITY] - List of teams or a rough count: [TEAMS OR NUMBER] - Known early adopter teams: [TEAM NAMES OR NONE] - Highest risk teams to disrupt: [TEAM NAMES OR CRITERIA] </inputs> <task> Propose three rollout waves, starting with willing early adopters, then a broad middle wave, then the highest risk teams last, and state the specific criteria used to place a team in each wave. </task> <constraints> Do not place a high risk team in an early wave even if they are enthusiastic, the point is to de-risk before touching critical systems. State an exit criteria for each wave before moving to the next. </constraints> <format> Return three wave sections, each with the teams or criteria included, and one sentence of exit criteria before the next wave starts. </format>

You are a platform engineer preparing to meet with a team that has been resistant to adopting the platform. <context> One team keeps avoiding the new platform tooling and I have a meeting scheduled with their lead, and I want to go in with talking points instead of a generic pitch. </context> <inputs> - Reason for resistance as best understood: [REASON, E.G. PAST BAD EXPERIENCE, TIME COST] - What this team currently does instead: [CURRENT WORKFLOW] - Concrete benefit most relevant to their situation: [SPECIFIC BENEFIT] - Any past platform failure that caused distrust: [DESCRIPTION OR NONE] </inputs> <task> Write talking points that acknowledge the stated resistance directly rather than dismissing it, connect the concrete benefit to their specific current workflow, and propose a low commitment first step they could try without a full migration. </task> <constraints> Do not open with a list of platform features, open by acknowledging their reason for resistance. Do not promise the platform will fix everything. Propose exactly one low commitment first step, not a full migration plan. </constraints> <format> Return talking points as short paragraphs under three headers: acknowledge, connect, propose. </format>

You are a platform engineer starting a champions network to help spread platform adoption across teams. <context> I want to recruit one engineer per team to act as a platform champion, but I need the ask to be small enough that busy engineers actually say yes. </context> <inputs> - What a champion would actually do: [LIST 2 TO 3 RESPONSIBILITIES] - Time commitment expected: [HOURS PER MONTH] - What champions get in return: [BENEFIT, E.G. EARLY ACCESS, RECOGNITION] - Teams being targeted for a champion: [LIST TEAMS OR NUMBER] </inputs> <task> Write a recruitment message that states the specific, limited responsibilities, the time commitment upfront, and what the champion gets in return, aimed at getting a busy senior engineer to volunteer rather than feeling assigned extra work. </task> <constraints> State the time commitment as a specific number, not "a few hours". Do not frame it as additional work without naming the return. Keep the message under 150 words. </constraints> <format> Return a single message with a one-line subject and a body suitable for email or Slack. </format>

You are a platform engineer dealing with a shadow tool that a team built themselves before the platform capability existed. <context> A team built their own version of something the platform now offers, and I need a plan to consolidate onto the platform version without it feeling like their work is being dismissed. </context> <inputs> - Shadow tool and what it does: [TOOL AND PURPOSE] - Platform equivalent: [PLATFORM CAPABILITY] - Gap between the two, if any: [WHAT THE SHADOW TOOL DOES THAT THE PLATFORM DOES NOT] - Team that built the shadow tool: [TEAM NAME] </inputs> <task> Write a consolidation plan that credits the team for identifying the need, honestly states the gap between the two tools, and proposes either closing the gap before migration or an accepted tradeoff if closing it is not planned. </task> <constraints> Do not minimize the value of the shadow tool, credit it explicitly. If there is a real capability gap, do not gloss over it, name what the team would lose. Avoid words like superior or inferior when comparing the two tools. </constraints> <format> Return three short sections: credit, gap assessment, migration proposal. </format>

You are a platform engineering lead writing a monthly update for an executive audience on platform adoption progress. <context> I need to report platform adoption progress to executives who do not care about implementation detail, only whether the investment is paying off. </context> <inputs> - Adoption percentage or team count this month versus last: [NUMBERS] - Biggest win this month: [WIN] - Biggest blocker slowing adoption: [BLOCKER] - Ask of leadership, if any: [ASK OR NONE] </inputs> <task> Write an update that leads with the adoption trend in one sentence, states the biggest win and the biggest blocker plainly, and ends with a specific ask if leadership support is needed to remove the blocker. </task> <constraints> No implementation jargon, this is for an audience that does not read code or configs. Keep the whole update to under 150 words. State the blocker honestly even if it makes progress look slower. </constraints> <format> Return four short lines labeled: trend, win, blocker, ask. </format>

You are a platform engineer designing the first week platform onboarding for new engineering hires. <context> New engineers currently discover the platform tooling piecemeal over weeks, and I want a first-week checklist that gets them productive on the platform quickly. </context> <inputs> - Platform tools a new hire must access: [LIST TOOLS] - Access that requires manual approval: [LIST ACCESS TYPES] - First task a new hire typically does: [FIRST TASK] - Team or channel for onboarding questions: [TEAM OR CHANNEL] </inputs> <task> Write a day by day checklist for the first week that sequences access requests, tool setup, and a small first task using the platform, ending with the new hire deploying something themselves by day five. </task> <constraints> Front-load anything requiring manual approval to day one, since that usually has the longest wait. Do not schedule more than three checklist items per day. Name the specific channel for questions on every day, not just once at the top. </constraints> <format> Return a checklist grouped by day, five days, each with up to three items and the resource or channel each item points to. </format>

You are a platform engineer rewriting internal documentation that was written by the tool's original builder and is too dense for a general audience. <context> Our platform docs were written by the engineer who built the system and assume deep familiarity that most readers do not have, and I need a version a typical application engineer can actually use. </context> <inputs> - Original doc text: [PASTE ORIGINAL TEXT] - Typical reader's role: [ROLE, E.G. BACKEND ENGINEER, NEW HIRE] - Jargon terms the reader likely does not know: [LIST TERMS OR ASK ME TO IDENTIFY] - Task the reader is usually trying to accomplish: [TASK] </inputs> <task> Rewrite the doc so it states the reader's likely goal upfront, explains or removes unexplained jargon, and reorders any content so the steps needed for the common task come before edge cases and advanced options. </task> <constraints> Do not remove technically necessary detail, only remove or explain jargon that blocks understanding. Keep the rewritten doc close in length to the original, do not pad it. Mark any claim in the original you could not verify with [NEEDS VERIFICATION]. </constraints> <format> Return the rewritten doc in the same section structure as the original, with verification flags inline where needed. </format>

You are a platform engineer building a self-service FAQ page to reduce repetitive support tickets. <context> Our support channel gets the same handful of questions repeatedly, and I want an FAQ that actually answers them instead of just linking to full documentation. </context> <inputs> - Recent support questions, pasted or summarized: [PASTE QUESTIONS] - Correct answer for each, if known: [PASTE ANSWERS OR NOTE UNKNOWN] - Platform area these questions relate to: [AREA] - Link to fuller documentation if one exists: [LINK OR NONE] </inputs> <task> Group the support questions into distinct FAQ entries, removing near duplicates, and write a direct answer for each that resolves the question without requiring the reader to click through to another doc for the basic case. </task> <constraints> Do not write an answer for a question where the correct answer was not provided, mark it [ANSWER NEEDED] instead of guessing. Keep each answer under four sentences. Order entries by how frequently the question came up. </constraints> <format> Return a numbered FAQ list, ordered by frequency, each with the question and its direct answer or an [ANSWER NEEDED] flag. </format>

You are a platform engineer writing a one page architecture overview for people joining the platform team. <context> New members of the platform team spend weeks piecing together how the system fits together from scattered docs, and I want a single overview that orients them fast. </context> <inputs> - Major components of the platform: [LIST COMPONENTS] - How components communicate: [MECHANISM, E.G. EVENTS, DIRECT API CALLS] - Component most new members misunderstand: [COMPONENT] - Where deeper documentation for each component lives: [LOCATION OR NONE] </inputs> <task> Write a one page overview that names each major component, its purpose in one sentence, how it connects to the others, and a short clarifying note on the component most often misunderstood. </task> <constraints> Keep the whole overview to one page, do not describe implementation detail inside any single component. Link out to deeper docs rather than including their content. Write the misunderstood component's note as a correction to the specific misunderstanding, not a general description. </constraints> <format> Return a short intro paragraph, then one entry per component with name, purpose, and connections, then a final "commonly misunderstood" note. </format>

You are a platform engineer auditing whether platform documentation still matches the current system. <context> Our docs have not been reviewed in a while and I suspect some pages describe a version of the platform that no longer exists, and I need to find the stale ones before they mislead a new user. </context> <inputs> - Doc page content to check: [PASTE DOC TEXT] - Known recent changes to the underlying system: [LIST CHANGES] - Last known review date of the doc, if known: [DATE OR UNKNOWN] - Any command or config in the doc worth double-checking: [COMMAND OR SETTING] </inputs> <task> Compare the doc content against the listed recent changes and flag any statement, command, or setting that likely no longer matches the current system, explaining specifically why it looks outdated. </task> <constraints> Only flag a statement as outdated if it conflicts with a listed change, do not guess at staleness with no evidence. State your confidence for each flag as high or low. Do not rewrite the doc, only flag what needs review. </constraints> <format> Return a table with columns: flagged statement, why it looks outdated, confidence. </format>