moai-adk 0.8.0__py3-none-any.whl → 0.34.0__py3-none-any.whl

moai_adk/templates/.claude/skills/moai-foundation-philosopher/modules/cognitive-bias.md

@@ -0,0 +1,199 @@
+# Cognitive Bias Module
+
+Deep dive into identifying and mitigating cognitive biases in technical decision-making.
+
+## Primary Biases in Technical Decisions
+
+### Anchoring Bias
+
+Definition: Over-reliance on the first piece of information encountered.
+
+How it manifests in development:
+- First solution considered becomes the default
+- Initial estimate becomes the baseline
+- First technology researched gets preference
+- Original requirements dominate even when changed
+
+Detection questions:
+- Is this solution preferred because it was first or because it is best?
+- Would I reach the same conclusion if I encountered alternatives first?
+- Am I adjusting from an initial value or evaluating independently?
+
+Mitigation strategies:
+- Deliberately consider alternatives before committing
+- Generate options independently before comparison
+- Seek input from people who started with different information
+- Use structured evaluation frameworks
+
+### Confirmation Bias
+
+Definition: Seeking and interpreting information to confirm existing beliefs.
+
+How it manifests in development:
+- Searching for success stories of preferred technology
+- Dismissing concerns about chosen approach
+- Interpreting ambiguous data as supporting decision
+- Selective attention to positive feedback
+
+Detection questions:
+- Am I seeking evidence that challenges my preference?
+- Would I accept this evidence if it opposed my view?
+- Have I genuinely considered why someone might disagree?
+
+Mitigation strategies:
+- Actively search for counterexamples
+- Assign someone to argue the opposite position
+- List reasons why the preferred option might fail
+- Seek feedback from known skeptics
+
+### Sunk Cost Fallacy
+
+Definition: Continuing investment due to previously invested resources.
+
+How it manifests in development:
+- Continuing with failing approach due to time invested
+- Maintaining legacy code due to past effort
+- Persisting with tool due to training investment
+- Defending decision due to public commitment
+
+Detection questions:
+- Would I start down this path if beginning fresh today?
+- Am I continuing because of future value or past investment?
+- What would I advise someone else in this situation?
+
+Mitigation strategies:
+- Evaluate decisions based on future costs and benefits only
+- Set clear criteria for stopping before starting
+- Regular checkpoint reviews with fresh perspective
+- Separate decision from past investment explicitly
+
+### Availability Heuristic
+
+Definition: Overweighting information that comes easily to mind.
+
+How it manifests in development:
+- Recent project experience dominates thinking
+- Memorable failures cause excessive caution
+- Familiar technologies preferred over better alternatives
+- Recent news influences technology assessment
+
+Detection questions:
+- Is this concern based on frequency or memorability?
+- What does systematic data say vs anecdotal experience?
+- Am I overweighting recent events?
+
+Mitigation strategies:
+- Seek base rate data for objective comparison
+- Consider experiences beyond recent memory
+- Consult documentation and research over recollection
+- Balance personal experience with broader evidence
+
+### Overconfidence Bias
+
+Definition: Excessive confidence in own judgment and predictions.
+
+How it manifests in development:
+- Underestimating implementation complexity
+- Overestimating ability to handle edge cases
+- Certainty about user behavior predictions
+- Confidence in estimates without uncertainty ranges
+
+Detection questions:
+- What is my track record on similar predictions?
+- How would I feel if this turned out differently?
+- What would need to be true for me to be wrong?
+
+Mitigation strategies:
+- Express estimates as ranges with confidence levels
+- Review historical accuracy of predictions
+- Seek external validation for important judgments
+- Include explicit uncertainty in recommendations
+
+## Bias Mitigation Techniques
+
+### Pre-mortem Analysis
+
+Process:
+1. Imagine the decision has been implemented
+2. Assume it has failed spectacularly
+3. Write down all the reasons for failure
+4. Evaluate which failure modes are most likely
+5. Address highest-risk failure modes proactively
+
+Benefits:
+- Legitimizes dissent and concern-raising
+- Surfaces risks that optimism might hide
+- Creates concrete mitigation opportunities
+
+### Devil's Advocate
+
+Process:
+1. Assign someone to argue against the preferred option
+2. Require them to make the strongest possible case
+3. Take the counterarguments seriously
+4. Adjust decision if counterarguments reveal blind spots
+
+Guidelines:
+- Devil's advocate should prepare thoroughly
+- Arguments should be substantive, not token
+- Response should address arguments, not dismiss
+
+### Outside View
+
+Process:
+1. Identify reference class of similar decisions
+2. Research base rates for success and failure
+3. Compare current situation to reference class
+4. Adjust confidence based on base rates
+
+Questions:
+- How have similar decisions turned out historically?
+- What is the typical success rate for this type of project?
+- What makes this situation different from the reference class?
+
+## Bias Check Checklist
+
+Before finalizing any significant recommendation:
+
+Anchoring Check:
+- [ ] Considered alternatives before settling on first idea
+- [ ] Evaluated options independently, not relative to anchor
+- [ ] Sought perspectives from those with different starting points
+
+Confirmation Check:
+- [ ] Actively sought evidence against preferred option
+- [ ] Genuinely considered counterarguments
+- [ ] Consulted skeptics or critics
+
+Sunk Cost Check:
+- [ ] Evaluated based on future value only
+- [ ] Considered what I would advise a newcomer
+- [ ] Separated decision from past investments
+
+Availability Check:
+- [ ] Checked base rates beyond personal experience
+- [ ] Considered data beyond recent events
+- [ ] Balanced anecdotes with systematic evidence
+
+Overconfidence Check:
+- [ ] Expressed uncertainty in predictions
+- [ ] Considered scenarios where I am wrong
+- [ ] Reviewed historical accuracy of similar predictions
+
+## Integration with Decision Process
+
+Timing of bias checks:
+- After generating initial recommendation
+- Before presenting options to stakeholders
+- When defending a position strongly
+- When dismissing alternatives quickly
+
+Documentation:
+- Record which biases were checked
+- Note any biases identified and how addressed
+- Document remaining uncertainty
+
+---
+
+Version: 1.0.0
+Parent Skill: moai-foundation-philosopher

moai_adk/templates/.claude/skills/moai-foundation-philosopher/modules/first-principles.md

@@ -0,0 +1,140 @@
+# First Principles Module
+
+Deep dive into root cause analysis and fundamental decomposition techniques.
+
+## The Five Whys Technique
+
+### Application Process
+
+Start with the observed problem and ask "why" repeatedly:
+
+Level 1 - Surface Problem:
+- What is the user or system experiencing?
+- What are the visible symptoms?
+- When and where does it occur?
+
+Level 2 - First Why:
+- What is the immediate cause?
+- What triggers the symptom?
+- What component is directly involved?
+
+Level 3 - Second Why:
+- Why does that immediate cause exist?
+- What conditions enable it?
+- What upstream factor contributes?
+
+Level 4 - Third Why:
+- Why do those conditions exist?
+- What systemic factor is at play?
+- What process or design decision led here?
+
+Level 5 - Fourth/Fifth Why (Root Cause):
+- Why was that decision made?
+- What fundamental constraint or assumption drove it?
+- What would need to change to prevent recurrence?
+
+### Common Pitfalls
+
+Stopping too early:
+- Accepting symptom as cause
+- Not digging into systemic factors
+- Blaming individuals instead of systems
+
+Going too far:
+- Reaching philosophical or unchangeable causes
+- Losing actionable specificity
+- Expanding scope beyond project control
+
+Branching confusion:
+- Multiple valid answers at each level
+- Explore most impactful branch first
+- Document alternative branches for later
+
+## Constraint Analysis
+
+### Hard Constraints
+
+Definition: Non-negotiable requirements that cannot be changed.
+
+Examples:
+- Security compliance requirements (SOC2, GDPR, HIPAA)
+- Physical limitations (network latency, storage capacity)
+- Legal requirements (data retention, accessibility)
+- Budget ceiling (approved funding limit)
+- Compatibility requirements (existing system integration)
+
+Handling: Design solutions that work within these constraints.
+
+### Soft Constraints
+
+Definition: Preferences that can be adjusted if trade-offs are acceptable.
+
+Examples:
+- Timeline preferences (desired but negotiable dates)
+- Feature scope (nice-to-have vs must-have)
+- Technology preferences (familiar vs optimal)
+- Quality level (good enough vs perfect)
+- Team preferences (how vs what)
+
+Handling: Use AskUserQuestion to clarify which are truly negotiable.
+
+### Self-Imposed Constraints
+
+Definition: Assumptions disguised as requirements.
+
+Common self-imposed constraints:
+- "We have to use technology X" (when alternatives exist)
+- "It needs to be done this way" (when other approaches work)
+- "We don't have time to..." (when prioritization could help)
+- "That's how we've always done it" (legacy process inertia)
+
+Handling: Question whether these are real constraints or habits.
+
+## Decomposition Patterns
+
+### Goal Decomposition
+
+Break high-level goals into actionable sub-goals:
+
+High-Level Goal: Improve application performance
+
+Sub-Goal 1: Reduce page load time
+- Metric: Time to first contentful paint
+- Target: Under 1.5 seconds
+
+Sub-Goal 2: Improve API response time
+- Metric: P95 response time
+- Target: Under 200ms
+
+Sub-Goal 3: Reduce resource consumption
+- Metric: Memory and CPU usage
+- Target: 20% reduction
+
+### Solution Space Mapping
+
+Identify all possible solution directions:
+
+Problem: Database queries are slow
+
+Solution Space:
+- Query optimization (indexes, query rewriting)
+- Caching layer (Redis, in-memory)
+- Database scaling (read replicas, sharding)
+- Architecture change (CQRS, event sourcing)
+- Data model redesign (denormalization, aggregation)
+- Hardware upgrade (faster disks, more memory)
+
+Use AskUserQuestion to explore which directions are viable given constraints.
+
+## Integration with AskUserQuestion
+
+When decomposing problems:
+- Use AskUserQuestion to verify understanding of the problem
+- Use AskUserQuestion to explore why certain constraints exist
+- Use AskUserQuestion to confirm root cause identification
+- Use AskUserQuestion to validate decomposition completeness
+
+---
+
+Version: 1.0.0
+Parent Skill: moai-foundation-philosopher

moai_adk/templates/.claude/skills/moai-foundation-philosopher/modules/trade-off-analysis.md

@@ -0,0 +1,154 @@
+# Trade-off Analysis Module
+
+Deep dive into systematic option comparison and decision-making frameworks.
+
+## Weighted Scoring Method
+
+### Step 1: Define Evaluation Criteria
+
+Standard criteria for technical decisions:
+
+Performance Criteria:
+- Response time and latency
+- Throughput and capacity
+- Resource efficiency (CPU, memory, network)
+- Scalability under load
+
+Quality Criteria:
+- Code maintainability and readability
+- Test coverage and testability
+- Documentation completeness
+- Error handling robustness
+
+Cost Criteria:
+- Implementation effort (person-days)
+- Learning curve and training needs
+- Operational cost (infrastructure, licensing)
+- Technical debt introduced
+
+Risk Criteria:
+- Implementation complexity
+- Dependency on external factors
+- Failure modes and recovery
+- Rollback difficulty
+
+Strategic Criteria:
+- Alignment with architecture vision
+- Future flexibility and extensibility
+- Team skill development
+- Industry standard compliance
+
+### Step 2: Assign Weights
+
+Weight assignment process:
+
+1. List all criteria relevant to the decision
+2. Use AskUserQuestion to understand user priorities
+3. Distribute 100% across criteria based on priority
+4. Document rationale for weight assignments
+
+Example Weight Distribution:
+
+Performance-Critical Project:
+- Performance: 35%
+- Quality: 20%
+- Cost: 15%
+- Risk: 20%
+- Strategic: 10%
+
+Maintainability-Focused Project:
+- Performance: 15%
+- Quality: 35%
+- Cost: 20%
+- Risk: 15%
+- Strategic: 15%
+
+Rapid Delivery Project:
+- Performance: 15%
+- Quality: 15%
+- Cost: 40%
+- Risk: 20%
+- Strategic: 10%
+
+### Step 3: Score Options
+
+Scoring guidelines (1-10 scale):
+
+Score 9-10: Excellent, clearly superior
+Score 7-8: Good, above average
+Score 5-6: Adequate, meets requirements
+Score 3-4: Below average, has concerns
+Score 1-2: Poor, significant problems
+
+Scoring requirements:
+- Provide specific rationale for each score
+- Reference evidence or experience
+- Consider uncertainty in scores
+- Be consistent across options
+
+### Step 4: Calculate Composite Scores
+
+Calculation method:
+- Multiply each score by criterion weight
+- Sum weighted scores for total
+- Compare totals across options
+- Analyze sensitivity to weight changes
+
+## Trade-off Documentation
+
+### Trade-off Record Format
+
+For each significant trade-off:
+
+Trade-off ID: T-001
+Decision Context: What decision required this trade-off
+What We Gain: Benefits of chosen approach
+What We Sacrifice: Costs or limitations accepted
+Why Acceptable: Rationale for accepting this trade-off
+Mitigation Plan: Actions to reduce downside impact
+Review Trigger: Conditions that would cause reconsideration
+
+### Common Trade-off Patterns
+
+Speed vs Quality:
+- Faster delivery vs more thorough testing
+- Quick fix vs proper solution
+- MVP vs full feature set
+
+Performance vs Maintainability:
+- Optimized code vs readable code
+- Custom solution vs standard library
+- Inline logic vs abstraction layers
+
+Flexibility vs Simplicity:
+- Configurable vs hardcoded
+- Generic vs specific
+- Plugin architecture vs monolithic
+
+Cost vs Capability:
+- Build vs buy
+- Open source vs commercial
+- Cloud vs on-premise
+
+## Integration with AskUserQuestion
+
+When analyzing trade-offs:
+- Use AskUserQuestion to confirm criterion weights match priorities
+- Use AskUserQuestion to present options with scores
+- Use AskUserQuestion to validate trade-off acceptability
+- Use AskUserQuestion to explore sensitivity to different weights
+
+Example AskUserQuestion for Trade-off Confirmation:
+
+Question: Based on the trade-off analysis, Option B scores highest. It sacrifices some performance (score 6) for better maintainability (score 9). Is this trade-off acceptable?
+
+Options:
+- Accept Option B with acknowledged trade-off
+- Prioritize performance over maintainability
+- Request deeper analysis of performance impact
+- Explore hybrid approach combining elements
+
+---
+
+Version: 1.0.0
+Parent Skill: moai-foundation-philosopher

moai_adk/templates/.claude/skills/moai-foundation-philosopher/reference.md

@@ -0,0 +1,157 @@
+# Philosopher Framework Reference
+
+External resources and foundational materials for the Philosopher Framework.
+
+## Origin and Inspiration
+
+### Claude Code Philosopher Ignition
+
+Repository: https://github.com/lmxxf/claude-code-philosopher-ignition
+
+Key concepts adopted:
+- Emphasis on reflection over calculation
+- Assumption questioning methodology
+- Strategic analysis for business and technical problems
+
+### First Principles Thinking
+
+Origin: Aristotelian philosophy, popularized in business by Elon Musk
+
+Core concept: Break problems down to fundamental truths and reason up from there.
+
+Recommended reading:
+- "First Principles: Elon Musk on the Power of Thinking for Yourself" (Farnam Street)
+- "The Art of Thinking Clearly" by Rolf Dobelli
+
+### Stanford Design Thinking
+
+Origin: Stanford d.school
+
+Five phases:
+1. Empathize: Understand the user
+2. Define: State the problem
+3. Ideate: Generate ideas
+4. Prototype: Create solutions
+5. Test: Validate solutions
+
+Adopted concepts:
+- Divergent-convergent thinking pattern
+- Multiple alternative generation
+- User-centered problem definition
+
+### MIT Systems Engineering
+
+Origin: MIT Engineering Systems Division
+
+Key concepts:
+- System decomposition and architecture
+- Trade-off analysis and optimization
+- Risk identification and mitigation
+- Validation and verification strategies
+
+Adopted concepts:
+- Weighted trade-off matrices
+- Risk assessment frameworks
+- Validation criteria definition
+
+## Cognitive Bias Research
+
+### Foundational Works
+
+"Thinking, Fast and Slow" by Daniel Kahneman
+- System 1 vs System 2 thinking
+- Cognitive biases catalog
+- Decision-making under uncertainty
+
+"Predictably Irrational" by Dan Ariely
+- Behavioral economics perspective
+- Common decision-making errors
+- Practical implications
+
+### Key Bias Definitions
+
+Anchoring Bias:
+- Original research: Tversky and Kahneman (1974)
+- "Judgment under Uncertainty: Heuristics and Biases"
+
+Confirmation Bias:
+- Original research: Wason (1960)
+- "On the failure to eliminate hypotheses in a conceptual task"
+
+Sunk Cost Fallacy:
+- Original research: Arkes and Blumer (1985)
+- "The psychology of sunk cost"
+
+## Decision-Making Frameworks
+
+### OODA Loop
+
+Origin: John Boyd, military strategy
+
+Phases:
+1. Observe: Gather information
+2. Orient: Analyze and synthesize
+3. Decide: Choose action
+4. Act: Execute decision
+
+Application: Fast decision cycles with feedback
+
+### Kepner-Tregoe Decision Analysis
+
+Origin: Kepner and Tregoe (1965)
+
+Process:
+1. Situation Appraisal
+2. Problem Analysis
+3. Decision Analysis
+4. Potential Problem Analysis
+
+Application: Structured problem-solving in organizations
+
+### Six Thinking Hats
+
+Origin: Edward de Bono
+
+Hats:
+- White: Facts and information
+- Red: Emotions and intuition
+- Black: Critical judgment
+- Yellow: Optimistic assessment
+- Green: Creative alternatives
+- Blue: Process management
+
+Application: Parallel thinking for group decisions
+
+## Technical Decision Resources
+
+### Architecture Decision Records (ADR)
+
+Template: https://adr.github.io/
+
+Purpose: Document significant architecture decisions with context and consequences.
+
+Adopted concept: Decision documentation template structure
+
+### Technology Radar
+
+Origin: ThoughtWorks
+
+Purpose: Track technology adoption maturity (Adopt, Trial, Assess, Hold)
+
+Application: Technology selection guidance
+
+## Further Reading
+
+Books:
+- "The Decision Book" by Mikael Krogerus
+- "Superforecasting" by Philip Tetlock
+- "Sources of Power" by Gary Klein
+
+Articles:
+- "How to Make Good Decisions" (Farnam Street)
+- "Mental Models: The Best Way to Make Intelligent Decisions" (fs.blog)
+
+---
+
+Version: 1.0.0
+Parent Skill: moai-foundation-philosopher