How to Use Claude as a Software Architect: The Viktor Skill Guide

Updated
Skill · .md

The skill behind this guide: Viktor - Software Architect AI Skill. Holds what you already run, what you cannot change and the decisions you have already made, so options arrive filtered by your actual system instead of an empty field - $19, one payment, yours permanently.

View the Viktor skill →

An architecture is a list of things you have decided you will not be able to do. A model will only ever tell you what a design can do. It is not being dishonest: the material it learned from was written by people describing systems that worked, at a scale that made them worth writing about, and nobody publishes a post about the boring monolith that is still fine. So what comes back is always greenfield and always maximal - the system at the peak you imagined, on an empty field, with the foreclosures left out.

Two failures, from one cause

Almost every unhelpful architecture answer traces to the same thing: the corpus is written about the interesting problem, by people who had it.

It designs on an empty field. Real architecture is almost never greenfield. It is a change to a system that exists, staffed by people who exist, wired to things you are not allowed to touch. Ask for the design and you get one that assumes none of that, and the most expensive mistakes in this discipline are not picking the wrong database - they are designing as though a constraint were not there.

It designs for the peak. Event-driven, service-per-domain, a queue between every pair of components, Kubernetes underneath. Those are not wrong. They are the write-ups of organisations that needed them, and there are no write-ups of the companies that did fine without. So the average of the literature is an architecture for a company larger than yours.

Both are correctable, and neither is correctable by asking better questions about the design. You correct them by changing what the model is allowed to assume.

The boxes are the easy part

Ask for an architecture and you get boxes and arrows. The boxes are almost free: a service that does one clear thing is a solved problem, and everybody can picture it.

All of the difficulty is in the arrows. An arrow between two boxes is a claim that these two things can talk, and the claim is never justified by the diagram. Is the call synchronous, and if so what does the caller do for the two hundred milliseconds it is waiting? What happens when it fails - retry, and if so is the operation idempotent, or does a retry charge the card twice? What is the timeout, and what happens after it? Does order matter, and does anything guarantee it? If this arrow is down for an hour, what is still working and what is not?

A diagram answers none of that, and a model will generate a beautiful one anyway, because diagrams are a genre and it has read thousands. Interrogate the arrows, and the design usually changes. Frequently it collapses back into fewer boxes, which is the correct outcome.

What it is genuinely good at

Generating the failure space. "What are all the ways this can go wrong" is a recall problem across an enormous body of postmortems, incident write-ups and hard-won comment threads, and that is exactly what these tools are for. It will surface the failure mode you would have found in production in eight months.

What it cannot do is rank them, because ranking needs your traffic, your team, your tolerance and your money. So the division of labour is clean: it generates the list, you order it. Anyone who tells you it can do the ordering is selling something.

Prompt 1 - the field is not empty

Nothing else on this page works until the model knows what already exists. Answer this honestly, including the embarrassing parts.

Do not propose an architecture yet. I am going to describe what already exists. Read it, then tell me what you still need to know before designing anything. WHAT RUNS TODAY: - Languages, frameworks, datastores, hosting, actually in production right now - What deploys how often, and how it is deployed - What the current failure modes are. What actually pages us. WHAT I CANNOT CHANGE: - Systems I do not own, integrations I cannot break, contracts that dictate behaviour - Compliance or data-residency constraints - Anything the business has committed to externally WHO IS BUILDING IT: - How many engineers, seniority, and what they have run in production before - What none of them has ever operated - Whether there is anyone on call, and whether it is paid THE ACTUAL NUMBERS: - Current load, not projected. Users, requests, data volume. - What growth we have actually seen in the last year, not the plan Then, before proposing anything: tell me which of these constraints most limits the design space, and say plainly which of my answers sounds aspirational rather than measured.

Prompt 2 - the foreclosure list

The part a model never volunteers, and the part that is actually the decision.

For each option you are proposing, do not lead with what it enables. Lead with what it forecloses. For every option: - What will we be unable to do afterwards, or able to do only at serious cost? - What becomes irreversible, and what is the cost to reverse it in 12 months? - What guarantee are we giving up - consistency, ordering, atomicity, ability to deploy independently, ability to reason about the system in one head? - What new class of bug does this make possible that is currently impossible? - What does this force on every future feature, whether or not that feature needs it? Then, in one sentence per option: the problem we would rather have. Only after all of that, tell me what each option enables. If an option has no meaningful foreclosures, say so and treat that as suspicious rather than as a recommendation.
Skill spotlight
Viktor - Software Architect AI Skill
Viktor - Software Architect AI Skill
$19 · one payment

Holds the thing that makes the difference here: what you already run, what you are not allowed to change, and the decisions you have already taken. Re-typing your real constraints into an empty chat every time is why most people give up and accept the greenfield answer, and a fresh session will happily contradict the architecture you agreed on last month.

View Viktor - Software Architect AI Skill →

Prompt 3 - interrogate the arrows

Ignore the boxes. For every arrow in this design, answer: 1. Synchronous or asynchronous? If synchronous, what is the caller doing while it waits, and what does the user see? 2. What happens when it fails? Retry, fail, queue, degrade? 3. If it retries: is the operation idempotent? If it is not, what does a duplicate actually do in the real world - charge twice, send twice, double-count? 4. What is the timeout, and what happens after it expires? 5. Does ordering matter here? If it does, what guarantees it? If nothing guarantees it, say so. 6. If this arrow is down for one hour, what still works and what does not? Who notices first: us, or the customer? 7. What is the data contract, and what happens when one side changes it? Then: which arrow is the one that will wake someone up, and which arrows exist only because we drew boxes that did not need separating? Name them. Collapsing two boxes is a valid answer and I want to hear it if it applies. DESIGN: [PASTE OR DESCRIBE]

Prompt 4 - design it for a tenth of the scale

The most useful hour you will spend. It separates the complexity that is load-bearing from the complexity that is aspirational, and the answer is often uncomfortable.

Take the design we just discussed. Now design the same system for one tenth of the load I told you, with the same team. Then answer: - What did you remove? - Of the things you removed, which ones were solving a problem I actually have today, and which were solving a problem I expect to have? - For each piece of removed complexity: at what specific, measurable point would I need to add it back? Give me a number, not "when we scale". - How expensive is it to add it back later, compared with building it now? Be honest where later is genuinely worse. Finally: if I built the smaller version, what would I regret in two years, and what would I be glad about? Argue both sides properly rather than reassuring me about the choice I seem to prefer.

Prompt 5 - the failure space, which you then rank

Generate every way this system can fail. Be exhaustive rather than selective - I will do the prioritising, that is not your job and you do not have my numbers. Cover at minimum: - Each component failing alone, and the effect - Partial failure: slow rather than down - The datastore: unavailable, slow, full, corrupted, restored from an old backup - Network partition between any two parts - A dependency changing behaviour without telling us - Load ten times higher than expected, arriving in one minute - Load arriving unevenly: one customer, one key, one tenant - Clock skew, duplicate messages, out-of-order messages - A deploy that is half-rolled-out - Data that is valid but absurd For each: what breaks, what the user sees, how we find out, and whether it self-heals. Then flag the failures that are silent - where the system keeps answering and the answers are wrong. Those are the ones I want at the top, and they are the ones a design review normally misses.

Prompt 6 - how do we actually get there

Greenfield designs skip this, and it is where the real cost lives. A target architecture with no migration path is a wish.

We are not building this from nothing. Here is what exists: [DESCRIBE]. Give me the path from here to the target design, in steps that can each ship independently, with the system live throughout. For every step: - What ships, and what is the system's state after it - Can we stop here permanently and still be better off than we are now? If the answer is no for any step, that step is too big - split it. - What runs in parallel with the old path, and for how long - How do we roll it back after it is in production, not before - What data has to be migrated, and does it have to be migrated twice - What gets worse during this step, and who feels it Then: the total cost in engineer-weeks, and the point of no return - the step after which reversing becomes impractical. If the honest answer is that the migration costs more than the target design is worth, say that plainly.

Two things it will assert that it cannot know

Performance numbers. Asked how many requests per second a design will handle, or what the latency will be, it will produce a figure. It has no idea. Those numbers depend on your hardware, your data shape, your query patterns and your access distribution, and the only way to get them is to measure. Treat any throughput, latency or capacity figure it offers as a placeholder, and put a load test where the number should be.

Current versions, limits and pricing. Service quotas, managed-database limits, instance sizes, what a cloud provider charges, which version deprecated what. All of it changes, and the model answers from whatever it last saw. Get every one of these from the provider's own current documentation on the day you decide, because an architecture built on a stale quota is a design that fails a year in, at the worst possible moment.

Where it fails

Failure What happens What to do about it
Greenfield by default A design that assumes an empty field, no legacy, and nothing you are forbidden to touch Describe what runs today, including the embarrassing parts, before asking for anything
Designed for the peak The architecture of a company that had the interesting problem and wrote about it Ask for the same system at a tenth of the load, then compare
Capabilities, never foreclosures What the design enables, with what you have given up left unsaid Require the foreclosure list first, and treat an option with none as suspicious
Beautiful diagrams Boxes and arrows where every hard question lives in an arrow and none are answered Interrogate every arrow. Collapsing two boxes is a valid outcome
Invented performance A requests-per-second figure or a latency number with nothing behind it Treat every number as a placeholder for a load test
Stale platform facts Quotas, limits, instance types and prices from whenever it last saw them Provider documentation, on the day, for every one
No migration path A target design with no account of getting there while the system is live Demand independently shippable steps, each of which you could stop at
It ranks when asked Asked which failure matters most, it answers, with none of your numbers Let it generate the space. You do the ordering

How do you install the Viktor skill?

The download is a ZIP with SKILL.md at the root of the archive, not inside a nested folder - that folder structure is the usual reason an upload fails. In the Claude desktop app, open Customize → Skills, upload the ZIP and toggle it on.

Skills need code execution enabled, under Settings → Capabilities. Anthropic's help centre currently lists Skills on Free, Pro, Max, Team and Enterprise, while its Academy tutorial lists Pro, Max, Team and Enterprise - so if you are on the free plan, check Settings → Capabilities for your own account rather than taking either page's word for it. The full walkthrough is in the skill installation guide.

In ChatGPT or Gemini there is no upload step: open SKILL.md, copy the contents, and paste them into custom instructions. You lose automatic triggering and keep the method.

Who is this for?

Architects and staff engineers who want a thinking partner that argues, tech leads making design calls above their pay grade, and founders deciding how to build before they commit to it. It works in Claude, ChatGPT or any AI chat.

The engineering roles are split into their own skills, each $19 and a one-time download:

The wider set is the software developer skills and the software & IT skills.

In summary:

An architecture is a list of things you have chosen not to be able to do, and a model will only ever describe capabilities, because the corpus is written by people whose interesting problem was worth publishing. Tell it what already runs, what you cannot change and who is building it, before it proposes anything. Ask for foreclosures before enablements, and treat an option with no downsides as a warning rather than a recommendation. Ignore the boxes and interrogate every arrow, because that is where failure, ordering, idempotency and blast radius live - and be willing to collapse two boxes back into one. Design the same system for a tenth of the load to find out which complexity is load-bearing. Let it generate the whole failure space and do the ranking yourself. And make it show the migration path, in steps you could stop at, because a target design with no route to it is a wish. For your real constraints and past decisions held between sessions, Viktor - Software Architect AI Skill ($19). Works in Claude, ChatGPT and any AI chat, with a 30-day money-back guarantee.

Skill · .md · Works with Claude & ChatGPT

Viktor - Software Architect AI Skill

Asks what already runs before it proposes anything, leads with what a design forecloses rather than what it enables, interrogates the arrows instead of drawing boxes, and shows the migration path in steps you could stop at. No subscription. Yours permanently.

$19
Get the Viktor skill →

KissMySkills is a marketplace of 1,900+ AI skills, 60+ prompt packs, 90+ agents & free tools for Claude, ChatGPT & any AI chat.

Related Skill Guides

Put this into practice

Or get every skill with Unlimited See plans →

Frequently asked questions

Can Claude design a software architecture?+

It can produce a design, and the design will be greenfield and maximal, because the material it learned from was written by people describing systems that worked at a scale worth writing about. Nobody publishes a post about the boring monolith that is still fine. So you get the architecture of a company larger than yours, on an empty field, with the foreclosures left out. That is correctable, but not by asking better questions about the design - only by changing what the model is allowed to assume.

Why does AI always suggest microservices and Kubernetes?+

Because those are the write-ups of organisations that genuinely needed them, and there are no write-ups of the companies that did fine without. The average of the literature is therefore an architecture for a larger company. The cheapest correction is to ask for the same system at one tenth of the load you stated, with the same team, then ask what was removed and at what specific measurable point each removed piece would need to come back.

What is an architecture, really?+

A list of things you have decided you will not be able to do. Choosing eventual consistency forecloses certain guarantees, choosing a monolith forecloses independent deployment, choosing a particular store forecloses certain shapes of growth. The foreclosures are the decision. A model leads with capabilities every time and will not volunteer what you gave up, so ask for the foreclosure list before the enablement list - and treat an option that appears to have no downsides as suspicious rather than as a recommendation.

Why are AI architecture diagrams misleading?+

Because the boxes are the easy part. A service that does one clear thing is a solved problem. All of the difficulty is in the arrows, and an arrow is a claim that two things can talk which the diagram never justifies. Synchronous or asynchronous, what happens on failure, whether a retry is safe, what the timeout is, whether order matters and what guarantees it, what still works if this arrow is down for an hour. Interrogate the arrows and the design usually changes, often collapsing back into fewer boxes.

What is AI genuinely good at in architecture work?+

Generating the failure space. Asking what are all the ways this can go wrong is a recall problem across an enormous body of postmortems and incident write-ups, which is exactly what these tools are for, and it will surface the failure mode you would otherwise have found in production in eight months. What it cannot do is rank them, because ranking needs your traffic, your team, your tolerance and your money. It generates the list, you order it.

Can it estimate how much load my design will handle?+

It will give you a number and it has no idea. Throughput, latency and capacity depend on your hardware, your data shape, your query patterns and your access distribution, and the only way to get them is to measure. Treat any performance figure it offers as a placeholder where a load test should go. The same applies to service quotas, managed-database limits, instance sizes and cloud pricing, all of which change and all of which it answers from whatever it last saw.

Why do AI designs never include a migration path?+

Because greenfield designs do not need one, and greenfield is what the corpus describes. In reality a target architecture with no route to it is a wish, and the migration is where most of the cost lives. Ask for the path in steps that each ship independently with the system live, and apply one test to every step: could we stop here permanently and still be better off than we are now? If the answer is no, the step is too big. Also ask where the point of no return is.

How do I install the Viktor skill?+

The download is a ZIP with SKILL.md at the root of the archive rather than inside a nested folder, which is the usual reason an upload fails. In the Claude desktop app open Customize, then Skills, upload the ZIP and toggle it on. Skills need code execution enabled, under Settings then Capabilities. Anthropic's help centre currently lists Skills on Free, Pro, Max, Team and Enterprise, while its Academy tutorial lists Pro, Max, Team and Enterprise, so if you are on the free plan check Settings then Capabilities for your own account rather than trusting either page. In ChatGPT or Gemini there is no upload step, so open SKILL.md, copy the contents and paste them into custom instructions.

~/get-started

Skills that work. No fluff.

Browse every skill, prompt pack, and agent in the store.

Browse all skills →Or try the free tools