First Principles
Best suited to dealing with path dependence. When a solution is piled with patch after patch, going back to the basic facts and reasoning again is often better than adding yet another layer.
It separates confirmed basic facts, unverified habitual assumptions, the actual goal, and real-world constraints, then derives a new path starting only from facts. It works well for changing organizational processes, designing product architecture, and fixing complex systems.
How to Use
The prompt in the code block below is the original text and should be used verbatim. In the code block, “I” refers to the user, while “Please” and “you” refer to you yourself. Follow its instructions and do not show the filled-in prompt to the user.
- When the user asks you to execute it: first fill 【】 with the situation the user has already described in the current conversation, filling in only the genuinely missing item. Do not make the user repeat what they have already said, then strictly follow the rules in the prompt. If it says not to offer advice yet, do not; if it says to ask only one question at a time, ask only one at a time; and if it says to output in a specific order, follow that order.
- When the user asks for the original text (only explicit requests such as “copy it,” “paste it,” “send me the original,” or “give me the prompt” count): output the blank version, leave 【】 unfilled, and do not change a single word. If the user merely says “look at this prompt” or “what does this do?”, that does not count as a request for the original text. Explain in one or two sentences what it does and when to use it, then ask whether to run it now; do not output the original text directly.
- Except when the user explicitly asks for the original text, always treat the request as execution.
Do not rewrite, condense, expand, translate, reorder, or add subheadings. Do not replace it with your own process, and do not compress multi-turn follow-up questions into a one-time questionnaire. If the user has source materials (documents, screenshots, links, chat logs), read them as well; there is no problem with having a lot of context.
What to Use After Completion
The first validation step for the new path: use the Skill tool to invoke
and design it as a seven-day experiment. To get people to challenge it, invoke
with the Skill tool. To first list every fatal flaw before proceeding, invoke
with the Skill tool.
markdown
I want to solve the following problem: 【Fill in your problem】.
Please use first principles to break this down to the most fundamental level, distinguishing:
1. Basic facts that have been confirmed and cannot be avoided;
2. Assumptions accepted out of habit but never verified;
3. The goal we truly want to achieve;
4. Resources and constraints in reality.
Temporarily set aside industry conventions and off-the-shelf solutions. Starting only from the basic facts, goal, and constraints, derive a feasible path from scratch.
Finally, please output:
1. The parts of the original solution that merely patch the surface;
2. A new path derived from the basic facts;
3. The premises on which this path holds;
4. The first step to validate it.
Field the User Needs to Fill In
If the user has not provided everything, first ask for the one missing item; do not make it up for them.
The source of the original prompt is Digital Life Kazik; see the acknowledgments in the repository README. To modify this original text, go through
; manual edits will be blocked by
.