first-principles

Reframe plans, specs, or problems from the true goal downward.

2|Updated May 13, 2026
One-click install
npx skills add https://github.com/mujtaba3B/gstack-extensions --skill first-principles-mujtaba3b
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: first-principles
Source: https://github.com/mujtaba3B/gstack-extensions/tree/main/pm/skills/first-principles
Command: npx skills add https://github.com/mujtaba3B/gstack-extensions --skill first-principles-mujtaba3b

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Helps users step back from an inherited plan, spec, or problem and identify the real goal, constraints, and hidden assumptions.

Core Features & Use Cases

  • Goal-first reframing: Clarifies the true endpoint before debating tactics.
  • Constraint analysis: Separates hard limits from assumptions that can be challenged.
  • Alternative attack paths: Generates multiple reframes by attacking the goal, sequence, actor, unit, or boundary.
  • Pressure testing: Checks each reframe for legitimate reasons the current approach exists.
  • Use case: When a team is stuck arguing implementation details, use this skill to reframe the work from first principles and surface better options.

Quick Start

Ask the first-principles skill to reframe the plan, spec, or problem you are working on from the goal downward.

Frequently Asked Questions about first-principles

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

FAQPage Schema
How do I reframe a product strategy from first principles when my team is stuck arguing implementation details?

To reframe product strategy from first principles, clarify the true endpoint goal, separate hard constraints from challengeable assumptions, generate alternative attack paths, and pressure-test the current approach to surface better options.

What is the best way to pressure test inherited constraints in a technical spec?

Pressure testing inherited constraints in a technical spec requires analyzing the true goal downward, identifying hidden assumptions, generating alternative reframes by attacking the sequence or boundary, and validating legitimate reasons for the current approach.

How do I identify hidden assumptions in an in-flight plan or process debate?

Identify hidden assumptions in an in-flight plan by clarifying the true goal, analyzing constraints to separate hard limits from assumptions, and reframing the problem from the ground up to expose weaker frames teams are optimizing within.

When should I use a first principles approach for product decisions instead of optimizing existing plans?

Use a first principles approach for product decisions when teams are optimizing inside inherited constraints instead of questioning them, specifically during technical strategy, process debates, or spec analysis where hidden assumptions obscure better options.

Can I generate alternative attack paths for a problem by questioning the actor or unit?

You can generate alternative attack paths by attacking the goal, sequence, actor, unit, or boundary of a problem, creating multiple reframes that pressure-test the current approach and expose weaker frames in your product strategy.

Why does my team keep optimizing inside inherited constraints instead of finding better options?

Teams optimize inside inherited constraints because they debate implementation details before clarifying the true goal, skipping the constraint analysis needed to separate hard limits from challengeable assumptions, which first principles reframing explicitly targets.