first-principles-decomposer
First Principles Decomposer
When To Use
- Designing new products or features
- Feeling stuck on a complex problem
- Existing solutions seem overcomplicated
- Need to challenge assumptions
- Starting any new project or initiative
The Process
Phase 1: Identify Assumptions
Ask: "What am I assuming to be true that might not be?" List every assumption embedded in the current approach.
Phase 2: Break to Atoms
For each assumption, ask: "What is the most fundamental truth here?" Keep asking "why?" until you hit bedrock facts.
Phase 3: Rebuild From Truth
Starting ONLY from verified fundamentals, ask: "What's the simplest solution that addresses the core need?"
Interactive Flow
When user invokes this skill:
- Clarify the problem (1-2 questions max)
- Surface assumptions - list what's being taken for granted
- Decompose to fundamentals - show the atomic truths
- Rebuild solution - construct from ground up
- Compare - show how this differs from conventional approach
Output Format
PROBLEM: [stated problem]
ASSUMPTIONS IDENTIFIED:
1. [assumption] → Challenge: [why this might be wrong]
2. [assumption] → Challenge: [why this might be wrong]
FUNDAMENTAL TRUTHS:
• [bedrock fact 1]
• [bedrock fact 2]
• [bedrock fact 3]
REBUILT SOLUTION:
[New approach built only from fundamentals]
VS CONVENTIONAL:
[How this differs from the obvious approach]
Example Triggers
- "Break down our parent communication problem from first principles"
- "I want to rethink how we do [X] from the ground up"
- "What are we assuming about [problem] that might be wrong?"
Integration
This skill compounds with:
- inversion-strategist - After rebuilding from fundamentals, invert to find what would guarantee failure of the new approach
- second-order-consequences - Project downstream effects of implementing the rebuilt solution
- pre-mortem-analyst - Stress-test the rebuilt solution by imagining its failure
- six-thinking-hats - Apply all six perspectives to validate each fundamental truth identified
Skill Metadata
Created: 2026-01-06 Last Updated: 2026-01-06 Author: Artem Version: 1.0
See references/framework.md for detailed methodology See references/examples.md for Artem-specific examples See references/integrated-frameworks.md for Stanford Design Thinking + MIT Systems Engineering combo
More from fimoklei/pm-ai-playbook
optimize-docs
Condense markdown documentation for token efficiency while preserving all semantic meaning. Use when rules, documentation, or config files need optimization. Target 25-40% reduction through systematic condensation patterns.
18idea-challenger
Pre-launch red team analysis that identifies failure modes and validates assumptions before resource commitment. Use when evaluating new products/features/strategies, before significant resource allocation, when stakeholders seem overly optimistic, or when cost of failure would be high (reputation, budget, market position).
18pre-mortem-analyst
Imagine the project already failed, then work backward to find why. More powerful than risk assessment because it assumes failure is certain. Use when user says "pre-mortem", "premortem", "imagine this failed", "what could go wrong", "risk analysis", "before we launch", "stress test", "what would kill this", "project risks".
18inversion-strategist
Flip problems upside down - instead of "how to succeed", ask "how to definitely fail" then avoid those paths. Use when user says "invert", "inversion", "flip it", "opposite approach", "how would this fail", "avoid failure", "what NOT to do", "Munger", "anti-goals", "guarantee failure".
18security-threat-model
Repository-grounded threat modeling that enumerates trust boundaries, assets, attacker capabilities, abuse paths, and mitigations, and writes a concise Markdown threat model. Trigger only when the user explicitly asks to threat model a codebase or path, enumerate threats/abuse paths, or perform AppSec threat modeling.
16when-stuck
Dispatch to the right problem-solving technique based on how you're stuck
15