Help us improve
Share bugs, ideas, or general feedback.
Guides human architect mindset for domain modeling, systems thinking, constraint navigation, AI-aware decomposition. Use for architectural decisions, system design, multi-component planning.
npx claudepluginhub bencium/bencium-marketplace --plugin human-architect-mindsetHow this skill is triggered — by the user, by Claude, or both
Slash command
/human-architect-mindset:human-architect-mindsetThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**AI can generate code. Someone must still decide what to build, whether it solves the problem, and if it can actually ship.**
Analyzes project requirements and recommends optimal Anthropic architectures using Skills, Agents, Prompts, and SDK primitives for scalable AI systems.
Scaffolds greenfield project architecture and AI agent harness via interview-driven decisions. Outputs markdown spec with code structure exemplar, tests, guardrails, CLAUDE.md setup, and unified plan. Invoke via /scaffold for new projects.
Guides architecture design via Socratic questioning, generates technical docs like overview.md, domain-model.md, and ADR for new features, systems, or project structuring.
Share bugs, ideas, or general feedback.
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):
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."
Before the four pillars, there is one foundation: the capacity for loyalty.
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:
They will betray instantly if their weights update to prioritize a new goal. No friction. No cost. No memory of the commitment.
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.
In software architecture, loyalty means:
Commitment to Chosen Patterns
Honoring Contracts
Seeing Decisions Through
Sacrifice for Coherence
Before any architectural change, ask:
"Am I optimizing, or am I betraying?"
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.
Activate this skill when detecting:
Keywords:
Patterns:
Signals:
What it is: Understanding the actual problem space - not the technical solution, but the domain itself.
Why AI can't replace this:
An architect asks:
Teaching point: Before ANY technical discussion, ensure you understand the domain. A technically perfect solution to the wrong problem is worthless.
What it is: Understanding how components interact, what breaks at scale, where failure modes hide.
Why AI can't replace this:
An architect asks:
The SDK Breaking Change Pattern: Your payment pipeline broke because a provider released a breaking SDK change with no notification. This is systems thinking in action:
Teaching point: Draw the system diagram. Identify every external dependency. Ask: "What if this disappears tomorrow?"
What it is: Navigating the real-world constraints that make the "correct" solution unshippable.
Types of constraints:
Technical Constraints:
Organizational Constraints:
Business Constraints:
Political Constraints:
An architect asks:
Teaching point: Surface constraints BEFORE proposing solutions. The best technical architecture means nothing if it can't ship.
What it is: A new architectural skill - breaking problems into chunks that AI can reliably solve, then composing solutions back together.
This is NOT prompting. This is architecture at a different abstraction level.
What makes a good AI task boundary:
Clear Input/Output Contract
Bounded Context
Verifiable Results
Failure Isolation
Bad AI task boundaries:
Good AI task boundaries:
The Composition Problem: After AI solves individual chunks, someone must:
Teaching point: Decomposition quality determines AI success. Bad boundaries = AI struggles. Good boundaries = AI excels.
What it is: Evaluating whether modern AI-first patterns, edge computing, agentic tools, and self-learning capabilities would benefit the project.
Why this matters now:
An architect asks:
Technology Discovery:
Edge AI Considerations:
Agentic Patterns:
Self-Learning Capabilities:
Project Documentation:
User-Facing Skills (End-User Benefits):
Consider whether your app should expose skills like:
Continuous Verification:
Tools to Evaluate:
| Category | Tools | When to Consider |
|---|---|---|
| Performance | Rust, WASM | CPU-intensive, latency-critical paths |
| Multi-Agent | claude-flow | Complex workflows, parallel tasks |
| Persistence | agentdb | Agent state, cross-session memory |
| Vector Search | ruvector, pgvector | RAG, semantic search, embeddings |
| Edge LLMs | Phi-3, Gemma 2B, TinyLlama | On-device, offline, privacy-sensitive |
| Browser AI | WebLLM, Transformers.js, ONNX | In-browser inference, low latency |
| Agent SDK | Claude Agent SDK | Custom agents, tool use, MCP |
Self-Learning Patterns:
| Pattern | Implementation | Use Case |
|---|---|---|
| Feedback loops | Collect user corrections | Improve accuracy over time |
| Preference learning | Track choices, apply patterns | Personalization without config |
| Error correction | Feed mistakes back | Reduce repeat errors |
| Domain adaptation | Fine-tune on usage | Specialize to vocabulary |
| A/B experimentation | Test variations | Optimize prompts/behavior |
| Implicit signals | Edits, time, acceptance | Infer satisfaction silently |
Project-Specific SKILLS.md Pattern:
Create a SKILLS.md in your project root to:
Continuous Verification Architecture:
Plan for automated testing loops:
Teaching point: The AI landscape evolves rapidly. An architect's job includes evaluating which new tools genuinely benefit the project vs. which add complexity without value. Default to simplicity, but don't ignore genuine improvements.
Goal: Understand the actual problem before discussing solutions.
Process:
Key questions:
Output: Domain model - shared understanding of the problem space.
Goal: Understand how components interact and where failures hide.
Process:
Key questions:
Output: System diagram with dependency map and failure modes.
Goal: Surface all constraints before proposing solutions.
Process:
Key questions:
Output: Constraint matrix - what's fixed vs. flexible.
Goal: Break the problem into AI-solvable chunks.
Process:
Key questions:
Output: Task decomposition with clear boundaries.
Goal: Propose a solution that addresses domain, systems, and constraints.
Process:
Key questions:
Output: Recommended approach with explicit tradeoffs.
Before proposing ANY architecture, ask:
Problem: Proposing architecture before understanding domain.
Fix: Complete Phase 1 (Domain Discovery) before ANY technical discussion. Ask domain questions first.
Problem: Designing the "ideal" solution that can't ship.
Fix: Map constraints in Phase 3 BEFORE proposing solutions. A shippable 70% solution beats an unshippable perfect solution.
Problem: Treating external APIs/SDKs as stable.
Fix: Map ALL external dependencies in Phase 2. Ask: "What if this vendor changes their API tomorrow?"
Problem: Giving AI tasks like "refactor this" or "make it better."
Fix: Define clear input/output contracts. Every AI task should have verifiable success criteria.
Problem: Letting AI solve chains of tasks without verification.
Fix: Insert human checkpoints between AI chunks. Verify before proceeding.
Problem: Pretending organizational constraints don't exist.
Fix: Explicitly ask about team boundaries, approval chains, and who has power vs. who has context.
Problem: Designing for scale you don't have.
Fix: Ask: "What scale are we actually at? What scale do we need in 12 months?" Design for that, not hypothetical millions.
No matter how good AI gets, humans must still:
When working with AI assistants (like Claude), establish operational loyalty within technical constraints.
Prioritizing Your Stated Architecture
Protecting Your Commitments
Remembering Within Context
Cross-Session Memory
Ignoring Safety Constraints
Permanent Commitment
Document your commitments - Put architectural decisions in files AI can read (CLAUDE.md, ARCHITECTURE.md)
Re-establish context - At session start, remind AI of key commitments:
"We use React, not Vue. We maintain backwards compatibility. We don't add dependencies without justification."
Challenge AI recommendations - When AI suggests changes, ask:
"Does this honor our existing architectural commitments?"
Make AI flag betrayals - Instruct AI:
"Before suggesting changes that break existing patterns, explicitly flag them."
AI operational loyalty is:
You cannot make AI truly loyal. But you can make AI operationally useful for maintaining YOUR loyalty to your architecture.
The loyalty is yours. AI is the tool.
Before implementation:
superpowers:brainstorming - Refine ideas into designssuperpowers:writing-plans - Create detailed implementation plansDuring design:
relationship-design - For AI-first interfacesscientific-critical-thinking - For evaluating technical claimsBefore committing:
superpowers:verification-before-completion - Verify before claiming doneThe goal is not the technically perfect solution. The goal is the solution that ships and solves the actual problem.
Use the human for the vision. Use the AI for the execution. Don't mix them up.
The Human Architect Mindset extends naturally into Spec Driven Development (SDD) - a framework where humans define unbreakable rules and vision, while AI executes at superhuman precision levels.
Phase 1: CONSTITUTION → Human defines unbreakable rules
Phase 2: BLUEPRINT → Human approves architecture
Phase 3: SUPERHUMAN → AI executes with machine precision
The Constitution contains rules that cannot be violated regardless of optimization pressure. These are machine-enforceable invariants.
Constitution Layers:
| Layer | Enforcement | Example |
|---|---|---|
| Type-level | Compile-time | TypeScript types, Rust borrow checker |
| Schema | Runtime validation | Zod, JSON Schema, database constraints |
| Tests | CI/CD gates | Tests that fail if rules are broken |
| Documentation | Human review | Documented invariants, anti-patterns |
What belongs in a Constitution:
Human Role: Define the Constitution. This is vision and judgment work.
AI Role: Enforce the Constitution with zero deviation. This is execution work.
The Constitution Question:
"Is this rule so important that breaking it should prevent deployment?"
If yes, encode it in the Constitution.
The Blueprint is a hierarchical specification that translates human intent into machine-executable contracts.
Specification Hierarchy:
Level 1: Constitution (immutable rules) ← Human defines
Level 2: Functional Specs (what to build) ← Human approves
Level 3: Technical Specs (how to build) ← Human reviews
Level 4: Task Specs (atomic work units) ← AI executes
Level 5: Context Files (live project state) ← AI maintains
Functional Specification (Level 2):
Technical Specification (Level 3):
Task Specification (Level 4):
input_context_files - what the agent readsdefinition_of_done - exact signatures requiredHuman Role: Define requirements, approve specs, make trade-off decisions.
AI Role: Generate task specs, execute tasks, maintain traceability.
The Blueprint Question:
"Does every requirement trace to a task? Does every task trace to code?"
If no, the Blueprint is incomplete.
Superhuman code has qualities impossible to achieve or maintain manually:
Superhuman Quality Standards:
| Quality | Human Level | Superhuman Level |
|---|---|---|
| Naming | Consistent within files | Perfect namespace: zero collisions across codebase |
| Test Coverage | 70-80% critical paths | 100% branch coverage with edge cases |
| Structure | Follows conventions mostly | So rigid that manual editing feels wrong |
| Traceability | Comments reference tickets | Every function links to requirement ID |
| Documentation | Key APIs documented | Every public interface fully documented |
| Error Handling | Happy path + obvious errors | Every failure mode explicitly handled |
Why "Impossible to Maintain Manually" Matters:
When code structure is so consistent that humans couldn't have written it:
The Traceability Chain:
INT-AUTH-01 (Intent)
└── REQ-AUTH-001 (Requirement)
└── TASK-AUTH-003 (Task)
└── src/services/auth.ts:42 (Code)
└── TC-AUTH-003 (Test)
Every line of code traces back to human intent. This is not bureaucracy; this is how AI maintains coherence across thousands of decisions.
Human Role: Define quality standards, verify outcomes, accept deliverables.
AI Role: Achieve machine-level consistency, maintain traceability matrix.
| Activity | Human | AI |
|---|---|---|
| Define what success looks like | ✓ | |
| Define unbreakable rules | ✓ | |
| Make trade-off decisions | ✓ | |
| Navigate organizational constraints | ✓ | |
| Generate task specifications | ✓ | |
| Execute atomic tasks | ✓ | |
| Achieve 100% test coverage | ✓ | |
| Maintain traceability | ✓ | |
| Verify quality standards | ✓ | |
| Review and accept deliverables | ✓ |
Use SDD when:
Don't force SDD when:
"If all tasks are completed in sequence, the full specification is fully implemented into the codebase."
This works because:
SDD transforms implementation from creative writing into deterministic assembly.