Skip to main content

first-principles

Decompose to axioms, challenge inherited assumptions, reconstruct from verified truths. USE WHEN first principles, fundamental, root cause, decompose, deconstruct, challenge assumptions, rebuild from scratch, question everything.

Informações da origem

Repositório
ajbmachon/ajbm-skills
Última atividade na origem
16 de abril de 2026 às 16:14
Idioma detectado do SKILL.md
inglês
Estrelas
7
Forks
2

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Explorador de arquivos
4 arquivos

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
name
first-principles
description
Decompose to axioms, challenge inherited assumptions, reconstruct from verified truths. USE WHEN first principles, fundamental, root cause, decompose, deconstruct, challenge assumptions, rebuild from scratch, question everything.
# First Principles Foundational reasoning methodology based on Elon Musk's physics-based thinking. Deconstructs problems to fundamental truths rather than reasoning by analogy. ## Core Concept **Reasoning by Analogy** (default, often wrong): - "How did we solve something similar?" - "What do others do?" - Copies existing solutions with slight variations **Reasoning from First Principles** (this skill): - "What are the fundamental truths here?" - "What is this actually made of?" - Rebuilds solutions from irreducible facts ## When to Use - Architects: Challenge "is this actually a constraint or just how we've always done it?" - Pentesters: Identify actual attack surfaces vs. assumed security boundaries - Red Team: Sharpen adversarial analysis by deconstructing assumptions - Engineers: When stuck, rebuild from fundamentals - Any task: When inherited assumptions may be limiting the solution space ## Workflow Routing Route to the appropriate workflow based on the request: - Break problem into fundamental parts → `workflows/Deconstruct.md` - Challenge assumptions systematically → `workflows/Challenge.md` - Rebuild solution from fundamentals → `workflows/Reconstruct.md` ## The 3-Step Framework ``` ┌─────────────────────────────────────────────────────────┐ │ STEP 1: DECONSTRUCT │ │ "What is this really made of?" │ │ Break down to constituent parts and fundamental truths │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ STEP 2: CHALLENGE │ │ "Is this a real constraint or an assumption?" │ │ Classify each element as hard/soft constraint │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ STEP 3: RECONSTRUCT │ │ "Given only the truths, what's optimal?" │ │ Build new solution from fundamentals, ignoring form │ └─────────────────────────────────────────────────────────┘ ``` ## Key Questions ### Deconstruction - What is this actually made of? - What are the constituent parts? - What is the actual cost/value of each part? - What would a physicist say about this? ### Challenge - Is this a hard constraint (physics/reality) or soft constraint (policy/choice)? - What if we removed this constraint entirely? - Who decided this was a constraint and why? - What evidence supports this assumption? ### Reconstruction - If we started from scratch with only the fundamental truths, what would we build? - What field has solved an analogous problem differently? - Are we optimizing function or form? - What's the simplest solution that satisfies only the hard constraints? ## Constraint Classification | Type | Definition | Example | Can Change? | |------|------------|---------|-------------| | **Hard** | Physics/reality | "Data can't travel faster than light" | No | | **Soft** | Policy/choice | "We always use REST APIs" | Yes | | **Assumption** | Unvalidated belief | "Users won't accept that UX" | Maybe false | **Rule**: Only hard constraints are truly immutable. Soft constraints and assumptions should be challenged. ## Integration Pattern Other thinking modes invoke First Principles like this: ```markdown ## Before Analysis → Use Challenge on all stated constraints → Classify each as hard/soft/assumption ## When Stuck → Use Deconstruct to break down the problem → Use Reconstruct to rebuild from fundamentals ## For Adversarial Analysis → Red Team uses Challenge to attack assumptions → Pentester uses Deconstruct on security model ``` ## Examples ### Architecture Decision **Problem**: "We need microservices because that's how modern apps are built" **Analysis**: 1. Deconstruct: What does this app actually need? (team size, scale, complexity) 2. Challenge: Is "microservices" a hard constraint? No — it's reasoning by analogy 3. Reconstruct: Given a 3-person team and moderate scale, a modular monolith optimizes for actual constraints ### Security Assessment **Problem**: "The firewall protects the internal network" **Analysis**: 1. Deconstruct: What is the firewall actually doing? (packet filtering on specific ports) 2. Challenge: Does packet filtering = protection? What about authorized ports? Insider threats? 3. Reconstruct: Protection requires defense in depth — firewall is one layer, not "the" protection ### Cost Optimization **Problem**: "Cloud hosting costs $10,000/month — that's just what it costs" **Analysis**: 1. Deconstruct: What are we actually paying for? (compute, storage, bandwidth, managed services) 2. Challenge: Is managed Kubernetes a hard requirement? Is this region required? 3. Reconstruct: Actual compute needs = $2,000. The other $8,000 is convenience we're choosing to pay for ## Output Format ```markdown ## First Principles Analysis: [Topic] ### Deconstruction - **Constituent Parts**: [List fundamental elements] - **Actual Values**: [Real costs/metrics, not market prices] ### Constraint Classification | Constraint | Type | Evidence | Challenge | |------------|------|----------|-----------| | [X] | Hard/Soft/Assumption | [Why] | [What if removed?] | ### Reconstruction - **Fundamental Truths**: [Only the hard constraints] - **Optimal Solution**: [Built from fundamentals] - **Form vs Function**: [Are we optimizing the right thing?] ### Key Insight [One sentence: what assumption was limiting us?] ``` ## Principles 1. **Physics First** — Real constraints come from physics/reality, not convention 2. **Function Over Form** — Optimize what you're trying to accomplish, not how it's traditionally done 3. **Question Everything** — Every assumption is guilty until proven innocent 4. **Cross-Domain Synthesis** — Solutions from unrelated fields often apply 5. **Rebuild, Don't Patch** — When assumptions are wrong, start fresh rather than fixing ## Anti-Patterns - **Reasoning by Analogy**: "Company X does it this way, so should we" - **Accepting Market Prices**: "Batteries cost $600/kWh" without checking material costs - **Form Fixation**: Improving the suitcase instead of inventing wheels - **Soft Constraint Worship**: Treating policies as physics - **Premature Optimization**: Optimizing before understanding fundamentals --- **Attribution**: Framework derived from Elon Musk's first principles methodology as documented by James Clear, Mayo Oshin, and public interviews.
Ver no GitHub