architect-mindset

Guides system design decisions through boundaries, contracts, tradeoffs, and executable specs.

Updated Jun 12, 2026
One-click install
npx skills add https://github.com/UniverLab/univerlab --skill architect-mindset-univerlab
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architect-mindset
Source: https://github.com/UniverLab/univerlab/tree/main/public/.well-known/agent-skills/architect-mindset
Command: npx skills add https://github.com/UniverLab/univerlab --skill architect-mindset-univerlab

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Designing systems without a disciplined process leads to decorative boundaries, leaked contracts, unplanned failure modes, and specs that fall apart when executed by someone with less context. This Skill provides a structured design methodology so architecture decisions are explicit, evaluated, and survivable. ## Core Features & Use Cases - Design Loop: Model the forces first, define boundaries as contracts with violation signals and owners, and design every flow for mid-step process death with recovery paths. - Decision Discipline: Classify decisions as reversible versus expensive to reverse, generate at least two approaches, run pre-mortems, and record significant choices as Architecture Decision Records using the included ADR reference. - Decomposition & Specs: Split work into independently verifiable parts ordered by risk, and write specs (role, what, how) executable by a colder, cheaper context. - Use Case: When planning a multi-component feature, use this Skill to enumerate consumers of shared surfaces, compare two architecture options, document the tradeoff as an ADR, and hand off specs that another agent can execute without your context. ## Quick Start Ask the agent to design the architecture for a new multi-component feature, defining boundaries, contracts, failure recovery, and an ADR for the key tradeoff.

Frequently Asked Questions about architect-mindset

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a good architecture decision record?

An ADR captures context, the decision in active voice, consequences both positive and negative, and alternatives considered. The included reference provides a template, worked examples for microservices, PostgreSQL, and React, plus guidance on when an ADR is warranted.

How do I decompose a large system design into smaller parts?

Split work so each part can be verified independently without building the rest. Order parts by dependency, attack the highest-risk part first, and match each part to an executor whose capability fits the verification method.

When should I use architect-mindset instead of code-engineering?

Use architect-mindset when the deliverable is a design, plan, spec, or architecture decision rather than code. It applies systemic thinking at the design level; code-engineering covers code-level structure and implementation behavior.

What makes a software boundary a real contract?

A boundary is real only when it states an invariant others can rely on, defines a violation signal showing how breakage is noticed, and names an owning component that enforces it. A boundary without these is decorative.

How do I design for failures and mid-process crashes?

Assume every component halts at its worst moment, then define what state remains and who repairs it for each step. Use idempotent re-entry points, startup reconciliation, and explicit recovery paths as design features.

Which design decisions should be documented versus decided quickly?

Classify decisions by cost of reversal. Reversible choices like naming and defaults should be decided fast, while expensive ones like schemas, public APIs, and storage layouts deserve explicit comparison and an ADR.