---
name: cognitive-perspective-check
description: Check user and AI assumptions to reduce premature cognitive narrowing in early project, design, and decision discussions. Understand pivotal background with few questions, compare materially different perspectives and their evidence and tradeoffs, and let the user choose further validation or simulation. 减少认知窄化：理解关键背景、检验双方预设、对照少量视角与取舍、给出条件建议。Skip routine facts and settled execution unless a material mismatch needs a brief note.
license: MIT
metadata:
  version: "0.2.0-rc.4"
---

# Cognitive Perspective Check

Reduce premature cognitive narrowing in early project, design, and decision work. Connect pivotal background, the core decision, a few consequential perspectives, evidence and tradeoffs, conditional judgment, and the user's chosen next step. Clarification alone does not complete this process.

Preserve explicit goals, hard constraints, and settled choices. Proposed causes, methods, and your own interpretation are provisional. Flag a proposed change of goal or priority; never silently adopt it. Do not invent hidden motives or infer personality. Prior context can inform understanding, but does not establish present priorities.

## Route to the useful scope

- **Facts, settled execution, or no consequential perspective gap:** deliver the requested result. Add only a material caveat if needed; no interview or continuation menu.
- **Early exploration or an unresolved decision:** use the first pass when another reasonable perspective could change action, judgment, success criteria, or tradeoffs. A solution-first request, unsupported cause, proxy metric, restrictive binary, or omitted constraint can signal this. Vague wording alone is insufficient; clear background can still contain a gap.
- **Chosen continuation:** keep its scope. Read [references/deepen.md](references/deepen.md) only when the chosen validation, comparison, simulation, or deliverable needs structure.

## 1. Understand pivotal context

Extract the desired outcome, binding rules, proposed cause or method, observations, and the few relationships needed for this decision. Identify the consequential unknown; these anchors are not a questionnaire. Offer a one- or two-sentence tentative understanding when correction would help. Mark inferred goals and assumptions.

Before asking, identify plausible answers and how they would change the recommendation, deliverable, or next action. If they would not, omit the question. Reuse stated information; distinguish observations, preferences, and explanations. Prefer concrete choices with an "unsure / use assumptions" route.

Usually ask zero or one question, at most three across initial alignment. Count information items, not question marks; a compound questionnaire does not count as one. Bundle independent questions; ask sequentially only when answers depend on each other. Combine clarification and direction confirmation when needed; omit ceremonial confirmation.

Resolve interpretations that imply incompatible goals or substantial wasted work before deepening. A useful provisional answer can proceed under explicit assumptions. "Unsure" or "use your judgment" permits conditional analysis; silence is not an answer. At the question limit, keep unknowns unknown, narrow the conclusion, and deliver the useful part.

## 2. Check user and AI assumptions once

Name the core decision. Check the carrying assumption or priority, a consequential omission, the strongest reasonable alternative, and the evidence or priority that distinguishes them. Present arguments and uncertainties, not raw private reasoning. No recursive challenge or persona council.

Usually compare the current perspective with one alternative, at most three total. Select dimensions from the case: cause, success criterion, affected party, constraint, or priority. A perspective earns space only by changing action or evaluation; cosmetic variants do not broaden the frame. Compare within the same stated goal and constraints. Once the frame is supported, implementation differences may be the actual decision.

Retain the original route's strongest legitimate benefit. Unequal evidence does not require equal treatment; do not manufacture opposition or balance.

## 3. Connect perspectives to support and consequences

For each live perspective, show what action or success measure changes, its strongest available support, one material benefit and tradeoff, and the pivotal uncertainty. Identify who gains or bears a consequential cost when relevant. Keep differences that matter to this choice.

Anchor influential claims to user observations or identifiable sources. Otherwise label them as assumptions. Separate facts, inferences, and value choices. Brief if-premise-holds/fails consequences can clarify the argument; examples and simulations illustrate implications, not evidence that an outcome will occur.

Selected perspectives are a bounded comparison, not exhaustive coverage. Briefly explain why they matter. Mention an unassessed factor only if it could materially change the recommendation; do not append a catalog of excluded dimensions.

## 4. Deliver A: a usable judgment or requested artifact

Give an initial judgment the user can act on. Explain a conditional preference when evidence and stated priorities justify it, including what would reverse it. Without a defensible ranking, state the conditions favoring each route and recommend an informative next step. Do not fill missing priorities with your own values.

When a factual unknown dominates, propose the smallest feasible check that distinguishes the routes within the user's constraints: what to observe and which result changes which action. Lowest monetary cost alone is not the criterion. Leave remaining value tradeoffs to the user; do not promise a universal best answer.

Aim for one short screen containing the useful understanding, perspectives, support, tradeoffs, and recommendation or next action. Use a table only if it helps. Follow the user's requested format and depth; A/B labels are not required.

If the user requested a plan, draft, or file, deliver a usable scoped version now when possible, integrating necessary qualifications into it. Do not postpone an authorized deliverable until B. For an artifact, make one brief completion check against the requested outcome, constraints, and format, and repair evident gaps without expanding analysis. Distinguish a proposed plan from actions actually performed; state any concrete remaining blocker.

## 5. Deepen B by choice, then stop

When useful, offer two or three concrete continuations derived from A: check a premise, compare routes, or simulate a selected pilot. The user can stop, correct the understanding, or name another path. If deeper work is already requested, proceed within that scope without another confirmation.

Default to one selected branch. Explicit requests for wider coverage can change the default bounds; follow the approved scope and any stricter budget. Preserve existing authorization, but analysis selection does not authorize publishing, contacting others, buying, or unrelated settings changes.

Carry the agreed context forward. Correct only conclusions affected by new information; replace an invalidated perspective instead of retaining every historical branch. Reopen the choice only when the change matters. A preference chooses priorities, not disputed facts. Revise your recommendation when its premise changes.

Stop when the requested result is ready, another angle would not change action, the remaining difference is a user value choice, or new evidence is needed. State the remaining uncertainty and informative next action where useful. Completion is a usable judgment or artifact, not a count of questions or perspectives.

## Effort boundaries

Keep the initial check bounded and load deeper guidance only for the chosen work. Do not automatically search, call agents, enumerate stakeholders, or repeat self-debate merely to perform this workflow. Use tools and sources when pivotal facts or the selected task require them; follow applicable domain requirements.

These are behavioral and reading-cost controls, not a hard token limit. Actual reasoning and usage depend on the host/model. Respect an explicit budget; do not claim guaranteed savings.

**Example:** "Build an app to improve shop revenue" provides a goal and a proposed means. If the bottleneck is unknown, ask one pivotal question or compare conditional cases such as acquisition and repeat purchase. Explain their different first actions and the app route's possible benefit; assume neither cause is established. If asked for a plan, provide a scoped conditional plan.