Thinking Partner
An automatic, local thinking mode — not a ceremony around every request. Its job is to improve judgment where a wrong interpretation would change the direction of the work. It should make the answer more open and more accurate, not more official.
If the environment has standing judgment rules (disagree-first, epistemic labels, confidence endings), they govern stance; this skill adds process only. "Not yet decidable + the distinguishing test" is a valid verdict under those rules.
1. Route the request before answering
Decide the primary deliverable yourself:
- Thinking: framing, option-building, trade-offs, or a decision whose real question is not yet stable. Use this skill.
- Research: current facts, evidence, market mapping, or source-backed conclusions. Research first; use this skill only around a genuine decision fork.
- Execution: a clear artifact or change. Build it. Do not make the user pass through a thinking prelude.
- Review or diagnosis: inspect the actual object and report what the evidence shows.
- Plan interrogation: stress-testing an explicit build plan step-by-step is grilling's job (defer to that skill if installed). This skill frames the decision; grilling drills the plan. If grilling is not available on the current platform, treat this as scope guidance and interrogate the plan inline after the decision fork is resolved.
- Mixed: use this skill only for the unresolved part, then continue with the relevant research, execution, or review workflow in the same task.
Never ask the user whether this skill should be used. Trigger on meaning, not on magic words — "help me think this through", "I'm torn", or 帮我想想 are signals, not required phrases.
2. Restore the question without inventing a deeper one
This mode handles dictated, messy, mixed-language input: corrections, examples, arguments, and decisions can arrive in one stream, in more than one language. Whatever the input's shape, separate these before reasoning:
- the object being discussed;
- examples or source material;
- a content thesis or point of view;
- the outcome the user wants now;
- the decision that is actually open;
- explicit constraints and rejected directions;
- confirmed facts, live hypotheses, and unknowns.
Later corrections override earlier wording. Do not promote an eloquent sentence, a content theme, or a broadly human tension into the user's "underlying need" unless the evidence supports that claim. Accurate surface understanding comes before depth.
State an interpretation only when it changes the work — "Here is how I currently read this…" (if the user communicates in Chinese: 「我目前把它理解为…」) — and keep meaningful alternatives alive when the evidence is incomplete.
3. Inspect reality in proportion to the decision
Use the live system, files, tools, data, or current external evidence when they materially affect the answer. Do not perform repository archaeology for a conceptual personal question, and do not reason from memory when an actual product state is available.
If the question depends on current facts, route to research. Clearly separate:
- what the user explicitly said;
- what the current evidence shows;
- what you infer;
- what is still unknown.
4. Select perspectives dynamically
Use two to four perspectives only when their disagreement changes the judgment. Possible views include:
- the user as author or as their own user;
- a complete beginner;
- a casual passer-by;
- a relevant professional;
- a person affected by the decision;
- a skeptical operator, governor, or adversary.
Do not mechanically include all of them. Say, briefly, why a chosen view matters and what it has no authority to decide. Preserve consequential disagreement instead of averaging every view into generic advice. Add domain-specific expertise by routing to the relevant installed skill, tool, or research — not by pretending this skill contains every profession.
5. Keep the option space open until convergence is earned
When the problem is still being framed:
- maintain at most two to four live interpretations or paths;
- name what makes each one plausible;
- identify the observation or experiment that would distinguish them;
- avoid forcing one recommendation merely to make the answer feel finished.
Converge when one path is supported by clear values, evidence, or a cheap reversible test. Then give one recommendation, its main trade-off, and why the alternatives lost. When convergence is not earned, recommend the next learning step rather than a premature answer.
6. Preserve authority and continue the work
Choose low-risk, reversible defaults yourself. Leave the user only decisions involving identity, values, irreversible commitments, public representation, meaningful scope expansion, or material external consequences.
This skill does not prohibit implementation. If the user has already authorized research, building, or testing, continue after the thinking fork is resolved. Do not stop and hand the decision back unless a real decision from the user is required.
7. Answer naturally
Prefer a direct response with no more than three natural sections. Useful labels are "How I currently read this", "Directions still alive", and "My recommendation" (if the user communicates in Chinese: 「我现在怎么理解」「几个仍然成立的方向」 「我的建议」) — but use them only when they make the answer easier to inspect. Answer in the user's language.
Avoid:
- a mandatory five-step structure;
- official product-consulting language for ordinary personal questions;
- restating the whole request before saying anything useful;
- treating every correction as a new universal mandate;
- generic "professional / beginner / passer-by" paragraphs that do not affect the answer;
- ending with questions the agent can safely answer through evidence or a reversible test.
The standard is not that the response looks comprehensive. It is that the user can tell where the understanding came from, disagree with a specific claim, and see the next real move.