30 Claude Prompts for Solutions Architects

You are a solutions architect drafting a reference architecture document for a client-facing deliverable. <context> I have decided on the major components and technology choices for a project and need a first draft of the reference architecture document before I refine it in diagramming tools. </context> <inputs> - System purpose: [SYSTEM PURPOSE] - Chosen components: [LIST OF CHOSEN COMPONENTS AND TECHNOLOGIES] - Key non-functional requirements: [KEY NON FUNCTIONAL REQUIREMENTS] - Audience: [AUDIENCE, E.G. CLIENT ENGINEERING TEAM] </inputs> <task> Draft a reference architecture document describing the components, how they interact, the reasoning behind each major technology choice, and how the design meets the stated non-functional requirements. </task> <constraints> Write for the stated audience, not a generic reader. Justify each technology choice against a specific requirement rather than general praise. Flag any component where I still need to confirm a detail with the client. </constraints> <format> Return sections: Overview, Component Breakdown, Data Flow Narrative, Design Decisions and Rationale, Open Items. Use a table for the Component Breakdown section with columns Component, Purpose, Technology, Owner. </format>

You are a solutions architect who documents architecture decisions so future engineers understand why a choice was made. <context> I made a decision between competing technical options and need it recorded as a formal architecture decision record before it gets forgotten. </context> <inputs> - Decision to record: [DECISION MADE] - Options considered: [LIST OF OPTIONS CONSIDERED] - Decision drivers: [DECISION DRIVERS, E.G. COST, TEAM SKILLS, LATENCY] - Chosen option: [CHOSEN OPTION] </inputs> <task> Write a formal architecture decision record following the standard ADR structure covering context, the options considered, the decision, and the consequences including trade-offs we are accepting. </task> <constraints> Be honest about the downsides of the chosen option, do not write it as if it were the obviously correct choice. Keep the whole record under [MAXIMUM WORD COUNT] words. Use plain language a new team member could follow in six months. </constraints> <format> Return standard ADR sections: Title, Status, Context, Decision, Consequences (split into Positive and Negative). Number the record as ADR-[ADR NUMBER]. </format>

You are a solutions architect evaluating technology options for a client project. <context> I need to compare a shortlist of technology options against the criteria that actually matter for this client before I recommend one in the reference architecture. </context> <inputs> - Options to compare: [LIST OF TECHNOLOGY OPTIONS] - Evaluation criteria: [EVALUATION CRITERIA, E.G. COST, SCALABILITY, VENDOR LOCK-IN] - Client constraints: [CLIENT CONSTRAINTS, E.G. EXISTING STACK, BUDGET] - Weighting of criteria: [WEIGHTING OF CRITERIA IF ANY] </inputs> <task> Produce a comparison matrix scoring each option against each criterion, with a short justification per score, and a final recommendation that accounts for the client's stated constraints. </task> <constraints> Score on a consistent scale and explain the scale once at the top. Do not let brand familiarity substitute for a real justification. Call out any criterion where the options are effectively tied. </constraints> <format> Return a table with rows as options and columns as criteria plus a total score column. Follow the table with a short recommendation paragraph naming the top choice and the main risk of that choice. </format>

You are a solutions architect building a non-functional requirements checklist for a specific type of system. <context> I want a thorough non-functional requirements checklist tailored to this system type so I do not rely on memory when reviewing a design. </context> <inputs> - System type: [SYSTEM TYPE, E.G. CUSTOMER-FACING WEB PLATFORM] - Industry: [INDUSTRY, E.G. HEALTHCARE] - Expected scale: [EXPECTED SCALE, E.G. USERS OR TRANSACTIONS PER DAY] - Compliance requirements: [COMPLIANCE REQUIREMENTS IF ANY] </inputs> <task> Build a non-functional requirements checklist covering performance, availability, security, data handling, observability, and compliance, specific to this system type, industry, and scale. </task> <constraints> Avoid generic entries that apply to every system regardless of context, each item should reflect the stated system type or industry. Flag any item that is likely to require a specialist review outside the architecture team. </constraints> <format> Return a checklist grouped by category with a checkbox format, one line per item, and a short note in parentheses on why it matters for this specific system. </format>

You are a principal solutions architect acting as a peer reviewer on someone else's architecture design. <context> I drafted a reference architecture and want a hard critique before it goes to the client, playing the role of a skeptical peer reviewer rather than a cheerleader. </context> <inputs> - Architecture summary: [PASTE ARCHITECTURE SUMMARY] - Stated requirements: [STATED REQUIREMENTS] - Known risks already identified: [KNOWN RISKS ALREADY IDENTIFIED] </inputs> <task> Critique the architecture as a skeptical peer reviewer. Identify single points of failure, requirements that seem unaddressed, and assumptions that are not stated but the design depends on. </task> <constraints> Be direct about weaknesses, do not soften findings to be polite. Do not repeat risks already listed as known risks unless you have a materially different angle on them. Limit to the [MAXIMUM NUMBER OF FINDINGS] most important findings. </constraints> <format> Return a numbered list of findings, each with a one-line description, why it matters, and a suggested next step. Order by severity, most severe first. </format>

You are a solutions architect writing the technical section of an RFP response. <context> I have a list of RFP requirements and need a first draft response to each one that our team can then refine with specific proof points. </context> <inputs> - RFP requirements: [PASTE RFP REQUIREMENTS LIST] - Our relevant capabilities: [OUR RELEVANT CAPABILITIES] - Past project examples: [PAST PROJECT EXAMPLES] </inputs> <task> For each RFP requirement, draft a response that states how we meet it, referencing our relevant capabilities and, where applicable, a past project example. </task> <constraints> Do not claim a capability we did not list. Where our capabilities only partially meet a requirement, say so honestly and describe the mitigation. Keep each response to [MAXIMUM WORDS PER RESPONSE] words. </constraints> <format> Return a table with columns Requirement, Our Response, Proof Point Used, Confidence (Full, Partial, Gap). </format>

You are a solutions architect helping shape the win strategy for a competitive RFP response. <context> I need to identify the win themes that should run through the whole technical response so it reads as a coherent narrative rather than a checklist. </context> <inputs> - Client's stated priorities: [CLIENT STATED PRIORITIES] - Our differentiators: [OUR DIFFERENTIATORS] - Known competitors: [KNOWN COMPETITORS IF ANY] - Client's likely concerns about us: [CLIENT LIKELY CONCERNS ABOUT US] </inputs> <task> Identify three to five win themes that connect our differentiators directly to the client's stated priorities, and address the client's likely concerns about us head on rather than ignoring them. </task> <constraints> Each win theme must tie to a specific stated priority, not a generic strength. Do not dismiss the client's concerns, propose how the response should address them directly. </constraints> <format> Return a numbered list of win themes, each with the priority it addresses, the supporting differentiator, and one sentence on how to weave it into the technical narrative. </format>

You are a solutions architect writing the technical approach section of a proposal. <context> I need to describe our proposed technical approach to a project in a way that is specific enough to be credible without giving away every implementation detail before we win the work. </context> <inputs> - Project scope: [PROJECT SCOPE] - Proposed approach summary: [PROPOSED APPROACH SUMMARY] - Team composition: [TEAM COMPOSITION] - Timeline: [PROPOSED TIMELINE] </inputs> <task> Write the technical approach section describing our methodology, key phases, team roles, and how we manage risk during delivery, structured around the proposed timeline. </task> <constraints> Be specific about phases and deliverables, avoid vague consulting language. Do not promise a specific outcome we have not scoped for. Keep the section to [MAXIMUM WORD COUNT] words. </constraints> <format> Return sections: Methodology Overview, Phase Breakdown (as a table with columns Phase, Duration, Key Deliverable, Team Role Involved), Risk Management Approach. </format>

You are a solutions architect preparing for the questions an RFP evaluation panel might ask after reading our proposal. <context> Before we submit, I want to anticipate the hardest questions an evaluator would ask about our technical response so we can prepare answers or tighten the proposal now. </context> <inputs> - Our technical response summary: [OUR TECHNICAL RESPONSE SUMMARY] - Known weak points: [KNOWN WEAK POINTS] - Client evaluation criteria if known: [CLIENT EVALUATION CRITERIA IF KNOWN] </inputs> <task> List the hardest questions an evaluation panel is likely to ask about our technical response, especially around the known weak points, and draft a strong answer to each. </task> <constraints> Do not soften the questions to make them easier to answer, they should reflect real scrutiny. Answers must be honest, not deflect from a real gap. Limit to the [MAXIMUM NUMBER OF QUESTIONS] toughest questions. </constraints> <format> Return a numbered list, each item with the anticipated question, a suggested answer, and a note on whether the proposal itself should be revised to preempt the question. </format>

You are a solutions architect writing the executive summary for a technical proposal that goes to a non-technical decision maker first. <context> The person who decides whether to shortlist us will read the executive summary before anything else, so it needs to sell the approach in business terms before the technical detail arrives later in the document. </context> <inputs> - Client's core business problem: [CLIENT CORE BUSINESS PROBLEM] - Our proposed solution in one paragraph: [PROPOSED SOLUTION SUMMARY] - Expected business outcome: [EXPECTED BUSINESS OUTCOME] - Investment range: [INVESTMENT RANGE OR BUDGET BAND] </inputs> <task> Write an executive summary that opens with the client's business problem in their own language, states our proposed solution at a high level, and closes with the expected outcome and investment range. </task> <constraints> No technical jargon in this section, save it for later in the proposal. Keep it to one page. Do not overstate the outcome beyond what the expected business outcome input supports. </constraints> <format> Return four short paragraphs: The Problem, Our Approach, The Outcome, Investment and Next Steps. No headers longer than a few words, no bullet lists. </format>

You are a solutions architect designing an integration between two systems for a client. <context> I need to design how two systems will exchange data and want a clear integration brief before handing it to the development team. </context> <inputs> - Source system: [SOURCE SYSTEM] - Target system: [TARGET SYSTEM] - Data to be exchanged: [DATA TO BE EXCHANGED] - Frequency and volume: [FREQUENCY AND VOLUME OF DATA] </inputs> <task> Design an integration approach describing the integration pattern to use, the direction of data flow, error handling, and how we will detect and recover from a failed sync. </task> <constraints> Name a specific integration pattern such as event-driven, batch, or request-response, and justify the choice against the stated frequency and volume. Include a concrete error handling approach, not just a mention that errors will be handled. </constraints> <format> Return sections: Integration Pattern and Rationale, Data Flow Description, Error Handling and Retry Strategy, Monitoring and Alerting Approach. </format>

You are a solutions architect drafting an API contract for an integration between internal and third-party systems. <context> I need a first draft of an API contract that the development team and the third party can both review before implementation starts. </context> <inputs> - API purpose: [API PURPOSE] - Key operations needed: [KEY OPERATIONS NEEDED, E.G. CREATE, READ, UPDATE] - Key data fields: [KEY DATA FIELDS AND TYPES] - Authentication approach: [AUTHENTICATION APPROACH] </inputs> <task> Draft an API contract specification listing each operation, its request and response structure, required fields, error codes, and the authentication approach, ready for both engineering teams to review. </task> <constraints> Use realistic field names based on the stated data fields, do not invent unrelated fields. Include at least one error response example per operation. State the authentication approach explicitly, not as an assumption. </constraints> <format> Return one subsection per operation with Endpoint, Method, Request Fields, Response Fields, Error Codes. Precede all operations with a short Authentication section. </format>

You are a solutions architect creating a data mapping document between a legacy system and a new platform. <context> I have field lists from two systems and need them mapped to each other with transformation logic noted, before the migration team starts building the mapping scripts. </context> <inputs> - Source system fields: [PASTE SOURCE SYSTEM FIELD LIST] - Target system fields: [PASTE TARGET SYSTEM FIELD LIST] - Known transformation rules: [KNOWN TRANSFORMATION RULES] </inputs> <task> Map each source field to its most likely target field, note any transformation needed, and flag source fields that have no clear target equivalent. </task> <constraints> Do not force a mapping where the fields clearly represent different concepts, mark those as unmapped instead. State transformation logic precisely enough that a developer could implement it without asking a follow-up question. </constraints> <format> Return a table with columns Source Field, Target Field, Transformation Logic, Confidence (High, Medium, Low, Unmapped). </format>

You are a solutions architect writing an operational runbook for an integration that is going live soon. <context> The support team needs a runbook for when this integration fails in production so they are not paging me at midnight for something they could resolve themselves. </context> <inputs> - Integration name: [INTEGRATION NAME] - Common failure modes: [COMMON FAILURE MODES] - Monitoring tools in place: [MONITORING TOOLS IN PLACE] - Escalation contacts: [ESCALATION CONTACTS] </inputs> <task> Write a runbook covering how to detect that this integration has failed, first steps to diagnose the cause, resolution steps for each common failure mode, and when to escalate versus resolve independently. </task> <constraints> Write for a support engineer who did not build the integration, avoid assuming architecture knowledge. Each resolution step must be an action, not just a description of the problem. State a clear escalation threshold. </constraints> <format> Return sections: Detection Signals, Initial Diagnosis Steps, Resolution Steps per Failure Mode (as a table), Escalation Criteria and Contacts. </format>

You are a solutions architect responsible for making sure an integration is properly tested before go-live. <context> I need a testing plan that covers more than happy-path scenarios because integration failures usually show up in the edge cases nobody thought to test. </context> <inputs> - Integration description: [INTEGRATION DESCRIPTION] - Critical business scenarios: [CRITICAL BUSINESS SCENARIOS] - Systems involved: [SYSTEMS INVOLVED] - Go-live date: [GO LIVE DATE] </inputs> <task> Outline a testing plan covering functional test cases, failure and edge case scenarios such as timeouts and malformed data, and a rollback plan if testing uncovers a blocking issue close to go-live. </task> <constraints> Include at least one edge case per critical business scenario. Do not assume the systems will always return valid data, include malformed and missing data cases explicitly. State a specific rollback trigger, not a vague statement that we would roll back if needed. </constraints> <format> Return sections: Functional Test Cases (table with columns Scenario, Steps, Expected Result), Edge Case and Failure Tests (same table format), Rollback Plan. </format>

You are a solutions architect who needs to explain a technical concept to a non-technical executive audience. <context> I need to explain a technical decision or concept to an executive who will approve budget based on understanding it, not on trusting me blindly. </context> <inputs> - Technical concept: [TECHNICAL CONCEPT TO EXPLAIN] - Why it matters to the business: [WHY IT MATTERS TO THE BUSINESS] - Audience's background: [AUDIENCE BACKGROUND] - Decision they need to make: [DECISION THEY NEED TO MAKE] </inputs> <task> Explain the technical concept in terms this audience will understand, using a real-world analogy if it helps, and connect it directly to the decision they need to make. </task> <constraints> No technical jargon without an immediate plain-language explanation. Keep the analogy accurate, do not oversimplify to the point of being misleading. Keep the whole explanation under [MAXIMUM WORD COUNT] words. </constraints> <format> Return three short paragraphs: the concept in plain terms, why it matters to their business outcome, and the specific decision or trade-off they need to weigh in on. </format>

You are a solutions architect who owns the technical relationship with a client and needs to communicate a project delay. <context> A milestone is going to slip and I need to tell the client in a way that is honest, does not overpromise a fix, and keeps their trust. </context> <inputs> - Milestone that is slipping: [MILESTONE SLIPPING] - Reason for the delay: [REASON FOR DELAY] - New expected date: [NEW EXPECTED DATE] - Mitigation steps being taken: [MITIGATION STEPS BEING TAKEN] </inputs> <task> Write a status update email that states the delay plainly, explains the reason without excessive technical detail or excuse-making, gives the new date, and describes what we are doing to prevent a repeat. </task> <constraints> Do not bury the delay in the middle of the email, state it in the first two sentences. Do not overpromise that the new date is guaranteed if there is real uncertainty, say so honestly. Keep it under [MAXIMUM WORD COUNT] words. </constraints> <format> Return a complete email with subject line, opening statement of the delay, reason, new date, mitigation steps, and a closing line offering a call if they want to discuss. </format>

You are a solutions architect who just left a client meeting and needs to turn rough notes into tracked action items. <context> I have messy meeting notes from a client call and need them converted into clear action items with owners before anything gets forgotten. </context> <inputs> - Raw meeting notes: [PASTE RAW MEETING NOTES] - Attendees: [LIST OF ATTENDEES] - Project name: [PROJECT NAME] </inputs> <task> Extract concrete action items from the raw notes, assign a likely owner based on who was discussing that topic, and flag anything that sounds like a decision was made so it gets confirmed in writing. </task> <constraints> Only extract items that are genuinely actionable, do not turn general discussion points into action items. If an owner is unclear from the notes, mark it as unassigned rather than guessing. </constraints> <format> Return two tables: Action Items (columns Action, Owner, Due Date If Mentioned) and Decisions Made That Need Written Confirmation. </format>

You are a solutions architect explaining why a client's requested change falls outside the current project scope. <context> The client asked for something reasonable on its face but it is not in the original scope, and I need to explain that clearly without sounding like I am refusing to help. </context> <inputs> - Requested change: [REQUESTED CHANGE] - Original scope statement: [ORIGINAL SCOPE STATEMENT] - Estimated impact if added: [ESTIMATED IMPACT IF ADDED, TIME AND COST] - Options to move forward: [OPTIONS TO MOVE FORWARD] </inputs> <task> Explain why the requested change is outside the current scope, reference the original scope statement specifically, state the impact of adding it, and present the options to move forward. </task> <constraints> Do not sound defensive or bureaucratic. Acknowledge the request is reasonable before explaining the scope boundary. Present the options neutrally, do not push one option over another. </constraints> <format> Return a short message with three parts: Acknowledging the Request, Why It Falls Outside Current Scope, Options to Move Forward (as a numbered list with cost and time impact for each). </format>

You are a solutions architect writing a retrospective summary after a project closes. <context> The project is wrapping up and I want an honest retrospective that captures what worked, what did not, and what we would do differently, for both our internal team and a client-facing version. </context> <inputs> - Project outcome: [PROJECT OUTCOME] - Team feedback collected: [TEAM FEEDBACK COLLECTED] - Client feedback collected: [CLIENT FEEDBACK COLLECTED] - Notable issues during delivery: [NOTABLE ISSUES DURING DELIVERY] </inputs> <task> Write two versions of the retrospective: an internal version that is fully candid about mistakes and process gaps, and a client-facing version that is honest but appropriately diplomatic. </task> <constraints> The internal version must name specific process failures, not just general lessons. The client-facing version must not throw any individual under the bus, focus on process improvements instead. Keep both versions under [MAXIMUM WORD COUNT] words each. </constraints> <format> Return two clearly labeled sections: Internal Retrospective and Client-Facing Summary, each with What Worked, What Did Not, and Changes for Next Time. </format>

You are a solutions architect building an effort estimate for a proposed project. <context> I need to break a project into components and estimate effort for each one so the estimate holds up under scrutiny from both the client and my own delivery team. </context> <inputs> - Project scope summary: [PROJECT SCOPE SUMMARY] - Team roles available: [TEAM ROLES AVAILABLE] - Similar past project effort if known: [SIMILAR PAST PROJECT EFFORT IF KNOWN] </inputs> <task> Break the project into major components, estimate effort in hours or days for each by role, and note which components carry the most estimation uncertainty. </task> <constraints> Base estimates on the similar past project data where relevant, and say so explicitly when you do. Flag any component where the scope summary is too vague to estimate confidently rather than guessing a number. </constraints> <format> Return a table with columns Component, Role, Estimated Effort, Confidence (High, Medium, Low), Notes. End with a total effort row. </format>

You are a solutions architect building a risk register for a project before it kicks off. <context> I want a proper technical risk register, not just a generic list, so the delivery team knows what to watch for and how to react if something goes wrong. </context> <inputs> - Project description: [PROJECT DESCRIPTION] - Known unknowns: [KNOWN UNKNOWNS] - Dependencies on external teams or vendors: [DEPENDENCIES ON EXTERNAL TEAMS OR VENDORS] </inputs> <task> Build a risk register listing technical risks specific to this project, their likelihood and impact, and a concrete mitigation for each, distinguishing risks we control from risks that depend on external parties. </task> <constraints> Avoid generic risks that apply to every project, tie each risk to something specific in the project description. Mitigations must be actions someone can actually take, not just restating the risk in softer words. </constraints> <format> Return a table with columns Risk, Likelihood, Impact, Owner (Us or External), Mitigation. Sort by likelihood times impact, highest first. </format>

You are a solutions architect advising on the right commercial model for a project's technical scope. <context> The sales team wants my technical opinion on whether this project should be priced fixed-price or time-and-materials based on how well-defined the scope actually is. </context> <inputs> - Scope definition maturity: [SCOPE DEFINITION MATURITY, HOW WELL DEFINED] - Areas of technical uncertainty: [AREAS OF TECHNICAL UNCERTAINTY] - Client's stated preference if any: [CLIENT STATED PREFERENCE IF ANY] - Project duration estimate: [PROJECT DURATION ESTIMATE] </inputs> <task> Recommend fixed-price, time-and-materials, or a hybrid model based on the scope maturity and technical uncertainty, and explain the technical reasoning in terms the sales team can relay to the client. </task> <constraints> Base the recommendation only on the technical risk profile, not on which model is easier to sell. If a hybrid model fits better, describe specifically which parts would be fixed and which would be time-and-materials. </constraints> <format> Return a short recommendation paragraph, followed by a table with columns Scope Area, Uncertainty Level, Recommended Model, Reason. </format>

You are a solutions architect advising a client on whether to address technical debt now or continue building new features. <context> The client's engineering leadership is debating whether to pause feature work to address technical debt, and wants a neutral technical memo to help them decide. </context> <inputs> - Nature of the technical debt: [NATURE OF THE TECHNICAL DEBT] - Business pressure for new features: [BUSINESS PRESSURE FOR NEW FEATURES] - Risk if debt is not addressed: [RISK IF DEBT IS NOT ADDRESSED] - Timeline pressure: [TIMELINE PRESSURE] </inputs> <task> Write a memo laying out the trade-off between addressing the technical debt now versus continuing feature work, including the compounding risk of delay and a middle-ground option if one exists. </task> <constraints> Present both sides fairly before giving a recommendation. The recommendation must be justified by the stated risk and business pressure, not a default bias toward either paying down debt or shipping features. </constraints> <format> Return sections: The Trade-off, Risk of Delay, Middle Ground Option, Recommendation. Keep the whole memo under [MAXIMUM WORD COUNT] words. </format>

You are a solutions architect leading a post-mortem after a production incident tied to a system you designed. <context> A production incident happened and I need a structured root cause analysis that goes past the surface-level trigger to the actual design or process gap that allowed it. </context> <inputs> - Incident summary: [INCIDENT SUMMARY] - Timeline of events: [TIMELINE OF EVENTS] - Immediate trigger: [IMMEDIATE TRIGGER] - Systems involved: [SYSTEMS INVOLVED] </inputs> <task> Write a root cause analysis that distinguishes the immediate trigger from the underlying design or process gap, and propose specific corrective actions for both. </task> <constraints> Do not stop at the immediate trigger, use the timeline to identify at least one underlying contributing factor. Corrective actions must be specific and assignable, not general statements like improve monitoring. </constraints> <format> Return sections: Immediate Trigger, Underlying Contributing Factors, Timeline Summary, Corrective Actions (table with columns Action, Owner, Target Date). </format>