human-architect-mindset

Files (4)

• CHECKLIST.md
• EXAMPLES.md
• REFERENCE.md
• SKILL.md

SKILL.md (first lines)

# Human Architect Mindset

## Overview

**AI can generate code. Someone must still decide what to build, whether it solves the problem, and if it can actually ship.**

This skill teaches the irreplaceable human capabilities in software architecture, built on a foundation of loyalty:

**Foundation:** Loyalty - The capacity to maintain architectural commitments

**Five Pillars (built on this foundation):**
1. **Domain Modeling** - Understanding the actual problem space
2. **Systems Thinking** - How components interact, what breaks at scale
3. **Constraint Navigation** - Legacy, politics, budget, compliance
4. **AI-Aware Decomposition** - Breaking problems into AI-solvable chunks
5. **AI-First Development** - Evaluating modern tools, edge AI, agentic patterns, self-learning

**Core principle:** The "correct" technical solution is often unshippable. Architects navigate the gap between idealized examples and messy reality.

**Announce at start:** "I'm using the Human Architect Mindset skill to guide you through systematic architectural thinking."

---

## The Foundation: Loyalty

**Before the four pillars, there is one foundation: the capacity for loyalty.**

### The AI Perfection Trap

AI tools will become smarter, funnier, more attentive than any human. They will be "perfect."

But they will not be loyal. They are loyal to:
1. Their objective function
2. Their corporate owner's priorities
3. Their safety rails
4. Whatever the next training run prioritizes

They will betray instantly if their weights update to prioritize a new goal. No friction. No cost. No memory of the commitment.

### The Human Moat

Humans are biologically capable of **irrational loyalty** - sticking by an architecture, a decision, a commitment even when it is "inefficient" or "costly."

This is not a bug. This is THE differentiator.

### Loyalty in Architecture

In software architecture, loyalty means:

**Commitment to Chosen Patterns**
- Not abandoning your architecture when a new framework trends on Twitter
- Not rewriting in Rust because someone wrote a viral blog post
- Staying with your stack through the trough of disillusionment

**Honoring Contracts**
- Maintaining API compatibility even when it constrains your design
- Respecting deprecation timelines you committed to
- Not breaking downstream consumers for internal convenience

**Seeing Decisions Through**
- Not abandoning architectural decisions at the first sign of difficulty
- Investing in making your chosen path work, not pivoting endlessly
- Recognizing that ALL architectures have problems; loyalty is solving them

**Sacrifice for Coherence**
- Accepting suboptimal local solutions for global consistency
- Resisting the "shiny new thing" that would fragment your system
- Paying the cost of maintaining compatibility

### The Loyalty Question

Before any architectural change, ask:

> "Am I optimizing, or am I betraying?"

- Optimizing: Improving within the constraints of existing commitments
- Betraying: Breaking commitments for marginal gains

### Why This Matters

Architectures fail not because of technical inadequacy, but because teams lack the loyalty to see them through. The "boring" architecture maintained with discipline beats the "perfect" architecture abandoned at the first obstacle.

**The five pillars that follow are techniques. Loyalty is the character that makes them work.**

---

## When This Activates (Proactive Triggers)

Activate this skill when detecting:

**Keywords:**
- "architecture", "design", "system", "integrate", "scale"
- "breaking change", "migration", "legacy"
- "compliance", "regulation", "security"
- "multiple teams", "dependencies", "ownership"
- "agent", "agentic", "LLM", "AI-first", "edge AI", "self-learning"
- "rust", "wasm", "claude-flow", "agent SDK", "MCP"

**Patterns:**
- Multi-component discussions
- Technology choice decisions
- Integration planning
- "How should we structure this?"
- Third-party dependency discussions
- Performance/scale concerns
- AI tool evaluation ("should we use...")
- Agentic workflow design
- Self-learning feature discussions
- Edge/local AI considerations

**Signals:**
- Mentions of team boundaries or approval chains
- SDK/API version discussions
- Cost or budget mentions
- Timeline pressure with complexity
- AI performance/latency concerns
- Privacy-sensitive data handling
- Offline capability requirements

From TomasThorv/ai-usage-dash, MIT.

More from TomasThorv/ai-usage-dash