The Staff Architect Skill: Designing Products With AI
Most teams use AI to write code faster. I use it to avoid making bad architectural decisions at 11pm under sprint pressure.
The Staff Architect skill is not a documentation generator. It's a reasoning partner that actively pushes back before letting you move forward.
The problem
Product projects fail not from a shortage of code but from a shortage of rigor in the decisions that precede the code. Vague discovery produces elastic scope. Rushed architecture produces technical debt. Missing ADRs produce circular debates about decisions already made.
The people who suffer are senior engineers and tech leads working on new products without a structured reasoning partner — because the team is small, or because there's no design review culture.
The core problem: the rigor of a Staff Engineer in product and architecture decisions should not depend on having a Staff Engineer available on your team.
Why a skill and not a rule
A rule would be "always use the ten-phase method" — far too heavy for every conversation, including the ones where you're renaming a variable.
A skill is "when designing a product, activate the Staff Architect" — on-demand behavior, with a context cost proportional to the moment it's actually needed.
The method involves sequential phases with gates, active questioning that blocks progress, and decisions separated by reversibility. That is behavior, not passive context.
What each phase produces
Discovery — a problem statement validated with Jobs-to-be-Done, identified personas, and defined success metrics. Not "increase engagement," but "reduce average supplier triage time from three days to four hours."
Definition — a PRD with closed scope, functional and non-functional requirements, measurable acceptance criteria. The skill actively challenges: is this a requirement of the product, or of the solution you already have in mind?
Strategic design — architectural options analyzed with trade-offs, build vs. buy vs. open-source, and the first ADRs.
Architecture — system diagram, data model, API contracts, components and their responsibilities. Every non-obvious decision becomes an ADR.
Execution — a work breakdown with milestones, effort estimates per phase, critical dependencies, mapped risks.
The remaining phases cover access governance, SLIs/SLOs and observability, a STRIDE threat model, technical documentation for users and operators, and a post-MVP evolution roadmap.
The behavioral rules that make it work
It never generates code before the architecture is approved — even when asked "can you just do this one small part quickly?" Today's shortcut is tomorrow's debt.
It never skips phases, even under pressure. Skip discovery and the PRD will be wrong. Skip the PRD and the architecture will solve the wrong problem.
It interrogates where requirements came from: is this problem real, or a solution looking for a problem? Did the requirement come from evidence or from opinion?
And it separates reversible from irreversible decisions, applying rigor proportionally. A variable name is reversible — decide fast. A multi-tenancy model is irreversible — it's worth an afternoon of analysis.
What it is not
Not a pretty-document generator. Any LLM produces a plausible-looking PRD in thirty seconds. This skill doesn't generate documents — it questions you until you have enough clarity for the documentation to be honest.
Not a stack oracle. "Which database should I use?" is not a question it answers for you. It lays out the trade-offs and forces you to decide based on your real constraints: team, scale, operational budget.
Not faster than a senior engineer who already knows the domain. It is useful precisely when that person isn't available, or when you need a structured second pair of eyes.
What came out of it
Running a full compliance SaaS through the method produced ten documented phases, twelve ADRs covering everything from the multi-tenancy model to data retention and observability, a work breakdown of roughly 290 estimated hours, a STRIDE threat model, and a post-MVP evolution plan — before a meaningful line of production code was written.
That last part is the whole point. The expensive mistakes were argued about on paper, where they cost an afternoon instead of a quarter.