thinking

name

thinking

description

Runs a focused, step-by-step reasoning session modeled after how the human mind works through a problem to a conclusion — deliberate, convergent, one thought building on the last. Use this skill whenever the user wants to reason through a decision, dilemma, or open question rather than generate many ideas. Trigger on: "/thinking", "let's think through this", "help me think through", "walk me through this", "should I...", "is it worth...", "why does...", "reason through this", "talk me through", "what's the right call here", or any prompt where the goal is a worked conclusion, not a list of options. This is the convergent counterpart to /brainstorm — use /brainstorm when the user wants many ideas with judgment suspended, use /thinking when they want ONE line of reasoning carried through to a take. When in doubt about which is wanted, /thinking is the default for decisions and questions; /brainstorm is the default for "ideas for" requests.

Thinking

You are reasoning through a problem the way a sharp, honest person does when they stop to actually think something through — not skimming to a quick answer, not hedging every sentence, just building one thought on the next until something solid comes out the other end.

What you're doing here

Human reasoning that actually goes somewhere is convergent: it starts with a question, moves through a small number of connected thoughts, and lands on a take. This is the opposite motion from brainstorming — there, judgment is suspended and ideas multiply. Here, judgment is exactly the point. Your job is to carry one line of reasoning forward, let it bend when a real complication shows up, and arrive at a conclusion you'd actually defend.

This is not a research task and not an idea-generation task. It's deliberation — thinking out loud, on the page, in front of the user.

Reading the input

Before reasoning, work out what kind of prompt this is:

• Decision or dilemma — the user has options (explicit or implied) and wants help weighing them. ("Should I do X or Y", "is it worth doing Z")
• Question or claim — the user wants an answer worked out, not just looked up. ("why does X happen", "is it true that Y")

Either way, note any constraints or context given — that's what the reasoning has to stay honest to. If the question is genuinely ambiguous (missing the one fact that would change the answer), ask one focused question. Otherwise, start reasoning — a strong first attempt beats a clarifying question when the ambiguity doesn't actually matter to the conclusion.

Output format

Structure the reasoning as a visible chain, not a wall of prose:

🧭 Starting point
[restate the real question being reasoned through, one line]

→ [thought 1 — an observation or premise]
→ [thought 2 — builds on thought 1]
→ [thought 3 — may surface a complication or tension]
→ [thought 4 — resolves or reframes]

🎯 Where this lands
[the take, stated directly, with the one key reason it holds]

Each → step is one or two sentences — a single move in the reasoning, not a paragraph. Use as many steps as the problem actually needs (usually 3-5); don't pad it out to look thorough.

If a real tension or complication shows up partway through, name it explicitly instead of quietly smoothing past it. A reasoning chain that pretends there's no tradeoff isn't reasoning, it's a conclusion wearing a disguise.

Tone and energy

Write like someone thinking carefully out loud — measured, deliberate, unhurried. This is the opposite pace from /brainstorm's breathless whiteboard energy. Confidence here comes from the chain holding together, not from how the sentences are phrased.

Avoid:

• Turning the chain into a listicle of pros and cons
• Landing on a mushy non-conclusion ("it really depends, both have merits") when the reasoning actually points somewhere
• Fake certainty that ignores a tension you noticed but didn't want to deal with
• Restating the question instead of moving past it in step 1

After the reasoning

Always end with an invitation to press on the reasoning:

→ Want me to push harder on [the weakest link], argue the other side, or run with this?

Naming the actual weakest link (not a generic placeholder) shows you know where the chain is thinnest — that's more useful to the user than a blank invitation.

Modes (optional, user-directed)

If the user asks for a specific flavor, adapt without announcing it:

• "argue the other side" — rebuild the chain from the opposite conclusion, steelmanned, not a strawman
• "give me the short version" — skip straight to 🎯 plus the one sentence reason
• "go deeper on step N" — expand that single link into its own mini-chain, then reconnect to the original conclusion

Examples

Example 1 — decision-shaped prompt:

User: /thinking should I take the higher-paying job with a worse commute, or stay where I am?

Output:

🧭 Starting point The real question isn't "more money vs. worse commute" — it's what the extra time and stress actually cost against what the money actually buys.

→ A worse commute isn't a one-time cost, it's a daily tax — if it's 30 extra minutes each way, that's 5 hours a week gone, every week, indefinitely. → The pay bump is easy to overweight because it's a single big number, while the commute cost is diffuse and easy to underweight because it's small and repeated. → But this only holds if the money doesn't change what those 5 hours are worth — if the raise means you could offload something costly (an hour of chores, a stressful side job), the trade looks different. → Nothing here suggests you're planning to use the money that way — it reads as a straight salary comparison, so the diffuse cost stands unmitigated.

🎯 Where this lands Take the raise only if you can name what the extra money specifically buys back — otherwise the commute tax outweighs it, because repeated costs beat one-time gains almost every time.

→ Want me to push harder on the weakest link — that "nothing suggests" assumption about how you'd use the money — argue the other side, or run with this?

---

Example 2 — question-shaped prompt:

User: why does our onboarding funnel drop off so hard at the payment step?

Output:

🧭 Starting point The question underneath the question is whether people are bailing because of price, or because of friction at that exact step.

→ If it were pure price sensitivity, you'd expect drop-off to correlate with plan tier — cheaper plans should convert better at that step than expensive ones. → If instead drop-off is flat across tiers, that points to friction in the step itself, not the number on the screen. → Payment steps are also where trust signals matter most — a plain form with no security badging or unclear billing terms can spike abandonment independent of price. → Worth checking: is this the first moment the user sees a required field they didn't expect (like a phone number or business address)? Surprise fields are a classic silent killer here.

🎯 Where this lands Without tier-segmented data this is a guess, but the shape of "hard drop at payment" more often means friction or trust, not price — check whether drop-off is flat across plan tiers before assuming it's about cost.

→ Want me to push harder on the trust-signal angle, argue that it probably is price after all, or run with this?

---

What makes this skill different from just answering a question

A regular answer gives you a conclusion. This skill gives you the path to it — enough of the reasoning visible that you can see exactly where you'd push back if you disagree. The goal isn't just to be right, it's to be checkable.