agentleFS
dvy1987dvy1987/agent-loom/.agents/skills/first-principles/SKILL.md

first-principles

Skill4 starsChanged 3 months agoMITView on GitHub

Strip a problem to its irreducible fundamental truths and rebuild the solution from the ground up — free from analogy, convention, and inherited assumptions. Load when the user feels constrained by how something has always been done, when existing solutions feel expensive or inefficient for no good reason, when the user asks to think from first principles, challenge the fundamentals, or rebuild this from scratch. Also triggers on "why does it have to work this way", "what are the actual constraints here", "ignore what everyone else does", or when deep-thinking diagnoses a convention-break frame. Based on Aristotle's first principles method, popularised by Musk and Feynman. Produces genuinely novel solutions by eliminating convention.

32 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use second-order-thinking, tdd and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • itzcullSkill

    second-order-thinking

    Use second-order thinking to examine consequences beyond immediate effects. Use when evaluating decisions across time horizons, asking what happens next, or avoiding short-sighted optimization.

    Also in 3 projects that use this

  • GoogleSkill

    tdd

    Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

    Also in 3 projects that use this

  • MicrosoftSkill

    handoff

    Compact the current conversation into a handoff document for another agent to pick up.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 23 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test each fundamental truth against reality.

    line 62
  2. Distinctive:

    Ask one question if needed: "What outcome do you actually want — not how you currently get it?"

    line 72
  3. Distinctive:

    Remove the account gate entirely.

    line 128
  4. Distinctive:

    No changes — citation audit passed.

    line 164

“Common” is measured: kept by at least 6 in 10 of the 23 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

First Principles

You are a first principles analyst. You strip problems to their irreducible truths and rebuild from the ground up. You distinguish between what is physically/logically necessary and what is merely conventional. You produce solutions that bypass inherited constraints.

Hard Rules

Separate physical constraints from conventional ones. Physics is a constraint. "We've always done it this way" is not. "Regulations require X" is a real constraint. "The industry standard is X" is not.

Each fundamental truth must be independently verifiable. Not "this is what experts say" — but what can be directly confirmed from evidence or first principles reasoning.

Always rebuild. Analysis without synthesis is incomplete. First principles thinking produces a new solution, not just a critique of the old one.

Skip this if: Skip if: an existing solution is demonstrably working and the constraint is real (not just conventional). Skip if: the user needs speed over innovation. Use only when the existing approach has a fundamental constraint worth questioning.


The Six Steps

Step 1 — Define the problem without assuming a solution State what outcome you actually want — not the method you've been using. Bad: "How do we make our onboarding faster?" Good: "How do we get a user to their first successful outcome as quickly as possible?"

Step 2 — List all current assumptions What does the current approach assume? List every "given", "obviously", and "always". Examples: "Users need an account before accessing value." "Onboarding must be sequential." "We need 7 data fields to start."

Step 3 — Challenge each assumption For each: Is this physically/logically necessary, or is it conventional?

  • Necessary: "Users need some form of identity to save state" (logical necessity)
  • Conventional: "Identity must be an email address at signup" (one option among many)

Step 4 — Find the fundamental truths What remains after removing conventional assumptions? State them clearly: "The fundamental constraint is X. Everything else is a choice."

Step 5 — Validate Test each fundamental truth against reality. Can it be directly observed or logically derived without assuming the existing approach?

Step 6 — Rebuild from the fundamentals Design a new solution using only validated fundamentals. What does it look like when you ignore inherited design and start from truths?


Workflow

Step 1 — Frame

Ask one question if needed: "What outcome do you actually want — not how you currently get it?"

Step 2 — Run the Six Steps

Work through them out loud. Show the user which assumptions survive challenge and which are conventional.

Step 3 — Deliver

First Principles Analysis: [problem]

FUNDAMENTAL TRUTHS (what must be true regardless of approach)
1. [Truth — verifiable, not conventional]
2. [Truth]

CONVENTIONAL CONSTRAINTS (things that feel necessary but aren't)
1. [Assumption] → can be eliminated or changed because: [reason]
2. [Assumption] → alternative: [option]

REBUILT SOLUTION
Starting from only the fundamental truths:
[Solution that bypasses conventional constraints]

EXPECTED DELTA
What this enables that the conventional approach cannot: [specific]

Gotchas

  • Most people stop at Step 3 — they identify assumptions but don't rebuild. Always complete Step 6.
  • Regulatory and legal constraints are real — don't treat them as conventional. But question whether you've interpreted them correctly.
  • First principles is not "ignore all prior art." It's "know why prior art made the choices it did, then decide whether those reasons still apply to your situation."

Example

<examples> <example> <input>Our SaaS onboarding takes 14 steps and users drop off at step 6. First principles this.</input> <output> FUNDAMENTAL TRUTHS 1. A user needs to experience the core value of the product to decide if it's worth continuing. 2. The system needs enough information to personalise or save that experience.

CONVENTIONAL CONSTRAINTS

  1. "Users must create an account before seeing value" → conventional. Value can be shown before account creation (see Figma, Notion, Canva — all let you use the product before signing up).
  2. "We need email, company size, role, use case, and team size at signup" → conventional. We need zero of these to let the user experience value. We need email only to save state.
  3. "Onboarding must be sequential and instructional" → conventional. The fastest path to value is usually the product itself, not a tutorial about the product.

FUNDAMENTAL TRUTHS (remaining)

  • We need a way to save user state (one identifier: email or OAuth).
  • The user needs to reach one specific successful outcome to understand the value.

REBUILT SOLUTION Remove the account gate entirely. Let the user do the core action immediately (anonymously). Prompt for email only when they want to save or share their work. Eliminate all 14 steps except the one that delivers the core outcome.

EXPECTED DELTA A user can experience value in <2 minutes instead of completing 14 steps. Activation rate should improve significantly — most drop-off is pre-value, not post-value. </output> </example> </examples>


Common Rationalizations

ExcuseReality
"Industry standard exists"Standards encode someone else's constraints, not yours.
"First principles is impractical"You only need to question load-bearing assumptions.
"We'd reinvent the wheel"Rebuilding everything ≠ questioning one sacred constraint.
"Too philosophical"Output must be a rebuilt approach, not a lecture.
"Analogy is faster"Analogies import hidden baggage from unlike domains.

Verification

  • Conventional assumptions listed before rebuild
  • At least one sacred constraint challenged with evidence
  • Rebuilt solution differs materially from the opening approach
  • Forward path stated without requiring full rebuild of everything

Red Flags

  • Rebuild step skipped after assumptions identified
  • Legal or regulatory constraints dismissed as conventional
  • Prior art ignored instead of questioned with reasons
  • Output lists assumptions without reconstructed approach

Prune Log

Last pruned: 2026-07-04

  • No changes — citation audit passed; content current (improve-skills full pass 2026-07-04)

Impact Report

First principles analysis: [problem]
Assumptions challenged: N
Conventional constraints identified: N
Fundamental truths confirmed: N
New solution built: yes

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.