first-principles

Guides structured problem framing, building, and stress-testing for hard or ambiguous engineering problems.

Updated Jun 20, 2026
One-click install
npx skills add https://github.com/tiendungchs/PersonalWiki --skill first-principles-tiendungchs
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: first-principles
Source: https://github.com/tiendungchs/PersonalWiki/tree/main/.claude/skills/first-principles
Command: npx skills add https://github.com/tiendungchs/PersonalWiki --skill first-principles-tiendungchs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Hard or ambiguous problems often get attacked with mechanism before the problem is precisely stated, producing over-parameterized code that solves the wrong problem. This Skill forces the framing questions that make the real problem collapse before any implementation starts. ## Core Features & Use Cases - Three-stage method: Frame (concrete scenario, kill the naive approach with numbers, define desired behavior, borrow structure from solved problems), Build (toy version, minimal working version, one delta at a time), and Stress (state limits, measure what distinguishes, verify against unfitted cases). - Anti-pattern detection: Flags mechanism-before-motivation, unlabeled simplifications, vague failure claims, and complexity with no chain back to a simple working design. - Compressed checklist: A scannable Frame/Build/Stress checklist for design reviews and architecture decisions. - Use Case: Before committing to a new caching architecture, use this Skill to state the concrete scenario, quantify why the naive approach fails, and define the metric that separates a sound design from a memorized one. ## Quick Start Use the first-principles skill to help me frame and stress-test my proposed design for the dashboard caching layer before I write any code.

Frequently Asked Questions about first-principles

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I solve ambiguous software design problems from first principles?▼

Start by stating one concrete scenario instead of a category, then write down the naive solution and kill it with a specific number. Define desired behavior on three or four hand-checkable cases before discussing any architecture or mechanism.

How to validate a system architecture before writing code?▼

State the hard limit, the early degradation mode, and the assumptions that make the design correct. Then verify the design against a case nobody built it for, since confirming intended behavior alone is not verification.

When should I use first-principles reasoning instead of a standard pattern?▼

Use it when the path forward is unclear, a bug resists the quick fix, or a design is growing more parts than the problem has. If the naive approach survives quantified scrutiny, ship it instead of designing further.

Why does my design keep getting more complex than the problem requires?▼

This usually comes from reaching for mechanism before the problem is stated precisely. Factor the design into independently varying parts, and check that the complex version is reachable as a short chain of single changes from a simple working version.

What are the limitations of first-principles problem solving?▼

It costs upfront framing time, so it is wasteful on routine tasks with known solutions. It also depends on honest quantification; vague failure claims like 'won't scale' undermine the entire method.