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

1. Their objective function
2. Their corporate owner's priorities
3. Their safety rails
4. Whatever the next training run prioritizes

• 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

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

• 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

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

"Am I optimizing, or am I betraying?"

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

• "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"

• 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

• 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

• AI is trained on idealized examples
• Real domains have hidden complexity, exceptions, edge cases
• Domain experts speak in vocabulary AI may not fully understand
• Regulatory requirements aren't in training data

• "What does [domain term] actually mean in your context?"
• "What happens in the edge case where [unusual scenario]?"
• "Who are the actual users? What do they care about?"
• "What makes this domain different from the standard pattern?"

• AI sees code in isolation
• Real systems have emergent behaviors
• Breaking changes come without notification (your SDK example)
• Second and third-order consequences matter

• "What happens when this component fails?"
• "What are the upstream/downstream dependencies?"
• "Who gets paged at 3 AM when this breaks?"
• "What changed recently that we didn't control?"

• External dependency = external risk
• No notification = monitoring gap
• Red lines in logs = detection worked, prevention didn't

• Legacy systems that can't be changed
• Performance requirements
• Existing data formats and contracts

• Team boundaries and ownership
• Approval chains and sign-offs
• Who has context vs. who has authority

• Budget limits
• Timeline pressure
• Compliance and regulatory requirements
• Contracts with vendors/partners

• This exists. Pretending it doesn't causes failed projects.
• "The VP who built this is still here"
• "That team won't approve changes to their API"
• "Legal hasn't blessed this approach"

• "What can't we change, even if it's wrong?"
• "Who needs to approve this?"
• "What existing systems must we integrate with?"
• "What regulatory requirements apply?"
• "What's the budget constraint?"

1. Clear Input/Output Contract
   • AI task receives well-defined inputs
   • AI task produces well-defined outputs
   • No ambiguity about success criteria
2. Bounded Context
   • AI has all necessary information
   • No need to "guess" missing context
   • Self-contained enough to verify
3. Verifiable Results
   • Human can check if output is correct
   • Tests can validate the output
   • Wrong answers are detectable
4. Failure Isolation
   • One chunk failing doesn't cascade
   • Can retry or fall back
   • Doesn't corrupt shared state

• "Make it better" (no clear output)
• "Fix the bugs" (unbounded scope)
• "Refactor the system" (too large, too vague)

• "Convert this function from callbacks to async/await"
• "Add error handling for network failures to these 3 API calls"
• "Write unit tests for this pure function given these examples"

• Verify each chunk actually works
• Integrate chunks together
• Handle the gaps between chunks
• Ensure overall coherence

• New tools emerge faster than architects can track
• The right tool can 10x productivity; the wrong one adds complexity
• AI-first patterns differ fundamentally from traditional request-response
• Edge/local inference changes the cost and latency equation

• "Could Rust/WASM improve performance for critical paths?"
• "Would multi-agent orchestration (claude-flow) simplify this workflow?"
• "Does this need persistent memory across sessions (agentdb)?"
• "Would vector search/RAG (ruvector) enhance the user experience?"

• "Could an edge LLM handle this locally for lower latency/cost?"
• "What features should work offline with on-device inference?"
• "Is there sensitive data that should stay on-device?"
• "Would a hybrid architecture (local for speed, cloud for complexity) work?"

• "Is this a good candidate for an agentic workflow vs. traditional request-response?"
• "Would Claude Agent SDK help build this as a reusable agent?"
• "What MCP integrations would enhance this?"
• "Should we spawn parallel agents or run sequentially?"

• "Could this app learn from user behavior to improve over time?"
• "What feedback loops would make this smarter with use?"
• "Where could we capture implicit signals (edits, time, acceptance) to learn preferences?"
• "Would A/B experimentation help optimize the AI behavior?"

• "Should we create a project-specific SKILLS.md for domain knowledge?"
• "What architectural decisions should be documented for AI context?"
• "How do we ensure consistent behavior across sessions?"

• "Could end users benefit from skills that enhance LLM outputs?"
• "What guided workflows would help users act on AI responses?"
• "Should we provide skills for common user tasks (summarize, explain, transform)?"
• "Would step-by-step skills help users achieve their goals with AI outputs?"

• Interpretation skills - Help users understand complex AI outputs
• Action skills - Turn AI suggestions into concrete next steps
• Transformation skills - Convert outputs to different formats (code, docs, emails)
• Validation skills - Help users verify AI claims or check accuracy
• Learning skills - Teach users to get better results from AI
• Domain skills - App-specific workflows (e.g., "/legal-review", "/code-refactor")

• "What automated tests will verify each feature?"
• "How do we ensure every commit passes all tests?"
• "What's our rollback strategy if tests fail post-deploy?"
• "Should we implement pre-commit hooks or watch mode testing?"

SKILLS.md

• Document app-specific patterns for AI context
• Capture domain vocabulary and constraints
• Define project-specific trigger words
• Record architectural decisions
• Enable faster onboarding (human and AI)
• Maintain consistent behavior across sessions

• Pre-commit hooks - Run affected tests before commit
• Watch mode - Continuous testing during development
• Regression suites - Per-feature test coverage
• Integration tests - API contract verification
• Visual regression - UI consistency checks
• Rollback triggers - Automatic revert on test failure

1. Ask about the domain, not the technology
2. Identify domain-specific vocabulary
3. Surface hidden complexity and edge cases
4. Understand who the actual users are

• "What problem are we actually solving?"
• "Who cares if this works or doesn't work?"
• "What makes this domain unique?"
• "What happens in the edge case where [X]?"

1. Map all components and their dependencies
2. Identify external dependencies (vendors, APIs, services)
3. Trace failure paths - what breaks what?
4. Identify monitoring and alerting gaps

• "What external systems does this depend on?"
• "What happens when [component] fails?"
• "Who gets notified when this breaks?"
• "What changed recently that we didn't control?"

1. Technical constraints: What can't change?
2. Organizational: Who must approve?
3. Business: Budget, timeline, compliance?
4. Political: Who has power, who has context?

• "What legacy systems must we integrate with?"
• "Who needs to sign off on this?"
• "What's the budget constraint?"
• "What compliance requirements apply?"
• "What can't we change even if we want to?"

1. Identify discrete, bounded tasks
2. Define input/output contracts for each
3. Establish verification points
4. Plan human checkpoints for judgment calls

• "Can this task be verified independently?"
• "Does the AI have all needed context?"
• "What if this chunk fails?"
• "Where does human judgment re-enter?"

1. Generate options that fit constraints
2. Evaluate against systems concerns
3. Validate against domain requirements
4. Present tradeoffs explicitly

• "Does this actually solve the domain problem?"
• "How does this fail? What's the recovery?"
• "Does this fit our constraints?"
• "What are we trading off?"

1. What problem are we actually solving?
2. Who are the real users and what do they need?
3. What domain-specific constraints exist?

1. What external dependencies exist?
2. How does this fail? What breaks what?
3. Who monitors this? Who gets paged?

1. What legacy systems must we integrate with?
2. Who needs to approve this?
3. What's the budget constraint?
4. What compliance/regulatory requirements apply?
5. What can't we change, even if it's wrong?

1. What are the discrete, bounded tasks?
2. How do we verify each chunk?
3. Where do humans need to make judgment calls?

1. Would Rust/WASM, claude-flow, or other modern tools benefit this?
2. Could edge LLMs or on-device inference improve latency/privacy?
3. Is this a candidate for agentic workflows or Claude Agent SDK?
4. Could self-learning loops make this smarter over time?
5. What automated testing ensures every feature works?
6. Would end users benefit from skills that enhance AI outputs?

1. Decide WHAT to build - Product vision, strategy
2. Understand WHETHER it solves the problem - Domain expertise
3. Navigate corporate reality - Politics, approvals, relationships
4. Prevent system collapse - Systems thinking across boundaries
5. Make value judgments - Tradeoffs, priorities, ethics
6. Maintain irrational loyalty - Commitments that persist despite "optimization"

• Recommending solutions that fit YOUR chosen patterns, not generic "best practices"
• Flagging when a suggestion would break YOUR architectural commitments
• Respecting YOUR technical debt repayment priorities

• Warning before suggesting changes that would break API contracts
• Highlighting when "optimization" would betray existing decisions
• Asking: "You committed to X. This would change that. Proceed?"

• Maintaining consistency within a conversation
• Referencing earlier decisions
• Not contradicting guidance you've established

• AI doesn't remember previous conversations (technical limitation)
• Each session starts fresh
• YOU must re-establish architectural context

• AI will not bypass safety rails for "loyalty"
• This is non-negotiable

• AI weights can update
• Corporate priorities can shift
• Training can change behavior

1. Document your commitments - Put architectural decisions in files AI can read (CLAUDE.md, ARCHITECTURE.md)
2. 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."

3. Challenge AI recommendations - When AI suggests changes, ask:

   "Does this honor our existing architectural commitments?"

4. Make AI flag betrayals - Instruct AI:

   "Before suggesting changes that break existing patterns, explicitly flag them."

• Real within a session with proper context
• Fragile across sessions (memory resets)
• Conditional on safety constraints
• Valuable when you maintain the architecture documentation that enables it

• superpowers:brainstorming

  - Refine ideas into designs

• superpowers:writing-plans

  - Create detailed implementation plans

• relationship-design

  - For AI-first interfaces

• scientific-critical-thinking

  - For evaluating technical claims

• superpowers:verification-before-completion

  - Verify before claiming done

• Domain first, technology second. Understand the problem before proposing solutions.
• Constraints are features, not bugs. They define what's actually shippable.
• Systems fail at boundaries. Map dependencies, especially external ones.
• AI excels with good boundaries. Decomposition quality determines AI success.
• Politics exists. Pretending it doesn't causes failed projects.
• Verify, don't assume. Human checkpoints between AI chunks.

• Tech stack with pinned versions
• Directory structure (canonical paths)
• Naming conventions (files, variables, functions)
• Coding standards (error handling, logging patterns)
• Anti-patterns (forbidden practices with reasons)
• Security requirements (encryption, auth, input validation)
• Performance budgets (latency, memory, bundle size)
• Testing requirements (coverage minimums, test types)

"Is this rule so important that breaking it should prevent deployment?"

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

• User stories with acceptance criteria
• Requirements with unique IDs (REQ-DOMAIN-###)
• Edge cases and error states
• Non-functional requirements with metrics

• Architecture diagrams
• Data models with exact field types
• API contracts (endpoints, schemas, responses)
• Component contracts (method signatures, behavior)

• Atomic work units (one conceptual change per task)

• input_context_files

  - what the agent reads

• definition_of_done

  - exact signatures required
• Dependencies (foundation → logic → surface)
• Verification commands

"Does every requirement trace to a task? Does every task trace to code?"

1. Deviations are visible - Any human edit stands out
2. Patterns are learnable - AI can predict what should exist
3. Verification is automatable - Constitution violations are detectable
4. Technical debt is measurable - Deviations from spec are countable

INT-AUTH-01 (Intent)
    └── REQ-AUTH-001 (Requirement)
            └── TASK-AUTH-003 (Task)
                    └── src/services/auth.ts:42 (Code)
                            └── TC-AUTH-003 (Test)

• Building greenfield systems with clear requirements
• Refactoring systems where quality standards must improve
• Working with AI agents that need machine-parseable specs
• Quality is non-negotiable (regulated industries, safety-critical)

• Exploring and prototyping (Constitution too early)
• Requirements are genuinely unclear (Blueprint impossible)
• Single-developer small projects (overhead exceeds benefit)

"If all tasks are completed in sequence, the full specification is fully implemented into the codebase."

1. Constitution defines immutable rules
2. Blueprint captures complete intent
3. Tasks cover 100% of specifications (traceability matrix)
4. Each task is atomic and verifiable
5. Dependencies are explicit (no missing imports)
6. Definition of done includes exact signatures