qws-zoom-out

QWS Zoom-Out

Purpose

Help the user break out of going in circles on a local level: check whether the problem, goals, and default premises hold, choose to keep the original framework, expand the system scope, or redefine the problem, and give the fix or the one item requiring the user's decision in the same reply. Complete business deliverables such as an entire piece of copy, a full plan, code, and releases still go back to the original task.

Attribution of execution failures that have already occurred (e.g., format not saved correctly, command execution errors) is outside the scope of this Skill and stays with the current task.

Files to read

• Before a deep zoom-out, fully read references/system-scope-model.md. If missing, state that the file is missing, do only a light check, and do not fabricate levels or steps.
• During a deep zoom-out, then read the grounding files according to task type: for revising text (sentences, paragraphs, references, wording), read references/landing-text.md; for content and account-related matters (videos, topics, frameworks, titles and covers, bolded key points, account positioning, stages, agendas), read references/landing-content.md; other tasks do not read them. Grounding files only provide grounding methods and do not change the process in this file.

Principles

1. The original framework must also pass a fact check. Both the user's and the Agent's problem definitions must be verified; if they hold, keep them, and do not zoom out for the sake of zooming out.
2. Distinguish demands, goals, metrics, and means. Goals may be questioned, but value trade-offs are decided by the user.
3. Changing the framework requires an accounting. State which interpretation, goal, cause, solution, risk, responsibility level, or acceptance criterion was changed, and on what basis.
4. Analysis scope ≠ execution scope. When the problem is found to lie at a higher level, fall back to the earliest affected link, and do not push the responsibility of the whole system onto the object at hand.
5. A new answer must be better than A to be adopted. Compare against answer A, which still holds under prior checks, and see whether the new answer more accurately explains the facts or advances the original demand; a higher level or sounding more profound is not a reason. If there is no net improvement, keep A; when A has been overturned by facts, recalibrate, and do not use a rollback to preserve an error.

Process

Trigger

• Deep zoom-out: performed when the user explicitly requests it. The user saying just the two words "升维" is enough; saying "升维 Skill", "从全局看", "这是不是局部问题", "检查是否只在局部解决", or directly invoking /qws-zoom-out, all count as explicit requests.
• Suggest zoom-out: when the user has not explicitly requested it but the conversation shows they are repeatedly revising the same thing and still unsatisfied, only add one sentence of suggestion at the end of the current reply, do not automatically expand into a zoom-out analysis, and complete the original task as usual. Judge by meaning, not only by matching fixed sentences. Common meanings include:
  • Expressing dissatisfaction repeatedly about the same edit: "It's still wrong," "That's not what I meant," "Something feels off, but I can't put my finger on it," "None of these work," "Try another one";
  • It gets worse with each revision, or the user wants to revert: "It's getting worse," "The original was better," "Forget it, let's just use the first version";
  • The user feels the AI's judgment keeps shifting: "Why do you keep changing it?" "That's not what you said earlier," "You changed it back again";
  • Different sources give conflicting directions, and the user can't decide: "The AIs all say different things," "I don't know who to listen to";
  • The same problem is fixed and then reappears, or more and more rules and patches are added without effect. The prompt is: "This problem may be stuck at the local level. If needed, say 'elevate' and I'll look at it from a higher dimension." Do not prompt in the following cases: the user is raising an edit suggestion for the first time; the user gives a clear, specific edit instruction (e.g., "replace this word with so-and-so"); the problem is an execution error, e.g., the file wasn't saved correctly or a command failed to run. Prompt only once for the same matter; if the user does not respond, do not repeat unless a new round of repeated revisions occurs afterward.
• When words like "strategy" or "architecture" appear in the wording but it is actually only a small local change, that does not constitute a reason to elevate.

Lightweight check

Ask in order: what does the user want to understand or change, and what goals and causal assumptions are presupposed; which facts support or refute these presuppositions; whether what is missing is a system relationship or the problem definition is wrong. Classify the conclusion into four categories:

Result	Action
Local is sufficient	Leave a one-line visible trace, e.g., "Lightweight boundary check: the original framework holds, returning directly," and return to the original task with the problem definition
Local handling + upper-level constraint	State the constraint clearly and then return
Move up to the responsibility layer	Handle the upper level first, then return to the local part
Boundary cannot yet be determined	First give a judgment based on the most likely case and state the assumptions, then ask only about the single most critical item

Deep elevation

First do Step 0, then follow references/system-scope-model.md to complete Steps 1–4.

1. Lock in A and the record of going in circles. Explicitly write out answer A: the version the user has explicitly approved; if there is none, use the version from before the circling began (the earliest original draft, or the version already published and in use). A is not the last rejected version; later discussions having criticized A does not mean A has been overturned—it becomes invalid only if the user explicitly rejects it or new facts overturn it. Compare all candidates with A; fine-tuning on A also counts as a valid answer. Then identify the shared premises or common change locations of the tried solutions, and use the "common causes of circling" in the reference to recognize which type of circling this is; if there is no corresponding type in the table, you must also judge for yourself and state which one it is.
2. Calibrate the problem and goals.
3. Choose a path: expand the boundary, change the framework, or combine both. When expanding the boundary, complete a well-grounded parent-chain check within this session; when changing the framework, compare problem definitions and do not force it into being "one level higher."
4. Compare candidates against A. When adopting a new solution, it must replace the shared premise found in Step 0; candidates that only change the wording are still circling in place.
5. Return to the original problem, determine the stopping boundary, and give the fix.

Requirements:

• Give the final result in a single call. Keep going upward until reaching "one more level up would change the original proposition, the original question, or the positioning, goals, or value trade-offs the user has already settled"; anything above that level is written only as a constraint or as a matter for the user to decide.
• Self-check before delivery. Suppose the user immediately calls again: would going one level up or switching frameworks yield a different answer? If it would and the original proposition is unchanged, keep checking this time; otherwise stop and deliver. Also confirm the answer addresses the original question, not merely looking correct within the new framework.
• Prevent spinning in place. If the in-depth check did not change any explanation, goal, cause, plan, risk, responsibility layer, or acceptance criteria, reclassify it as "locally sufficient" and return with a one-line trace; if the check was made at the user's request, note "checked as you requested: the original framework holds".
• After completion, keep a concise Active Scope State(see below) in the current task; do not show it to the user unless the user asks.

Active Scope State

The 5 required items must be filled in; fill in the rest only when used; write "not applicable" for anything not involved; do not fabricate layers. Keep them only in the current task and Agent logs; do not write them into the user's document or long-term records.

## Active Scope State
- 用户真正要推进的结果：
- 边界与选择依据（保留／扩展／重定义）：
- 应该介入的层级：
- 原任务必须继承的约束：
- 停止边界及原因：
- （按需）原因判断、关键关系、验收标准、未知与失效条件：

Continuity

• On a repeat call, first inherit the existing state; if there are no new facts, reuse the original boundary and answer, and do not manufacture a new answer just because the user says "go up one more level".
• When new facts or a re-check change the problem definition, goal, cause, plan, risk, responsibility layer, or acceptance criteria, re-check; if the re-check finds an old judgment was wrong, point out the missed facts, and do not use "no new material" to lock in an error.
• Subsequent execution inherits that state and does not silently downgrade a systemic problem back to a local one.

Hand back to the original task

• Give the judgment and the fix in the same reply; do not wait for the user to ask "what should I do" again:
  • Small change(one sentence, one reference, one heading, one bolded item, one parameter): give 1–2 candidates;
  • Major change(change of goal, change of positioning, change of framework, change of value trade-off): give the judgment and possible directions, ask only one question that determines the subsequent path, and give the specific fix after the user decides;
  • When the user explicitly asks only for a diagnosis, give only the judgment.
• **The fix touches only the located spot.** Other problems noticed along the way should be listed in one sentence as "optional", not written into the fix, and do not suggest deleting paragraphs, rewriting other sentences, or rewriting the whole piece; do not touch content the user has finalized or explicitly asked to keep. The fix must preserve the user's original judgment: solve only the located problem, do not replace the user's conclusion, stance, or evaluation criteria, and do not change the intensity of the original sentence's tone.
• When a local action is needed, attach alanding spec: what to change, what to accomplish, what must not be broken, and how to accept it.
• When facts are missing, first look in the user's files and conversation; if not found, give the judgment and fix based on the most likely case and state the assumptions, put questions at the end, ask only one, and offer options where possible.
• Value trade-offs are decided by the user; do not route to other named Skills.

Positive and negative examples

• Should be raised a level: "From a global view: conversion rate dropped, help me revise the landing page copy." Traffic sources, pricing, and customer service scripts were all changed in the same period, and the "conversion" definition mixes trials and paid. → Redefine the problem, first calibrate the metric and cause, then hand back to the copy task.
• Locally sufficient: "Fix the typos in this explanation." → A single line of trace, returned directly.
• No escalation, only a hint: The user says "still wrong" for the third time, but has not asked to escalate. → Complete this revision as usual, and add one sentence at the end of the reply: "This issue may be stuck in the details. If needed, say 'escalate' and I'll look at it from a higher level," without expanding the analysis.
• Fake escalation: Renaming one function, yet producing a full parent chain and state table, without changing any judgment. → Reclassify as local sufficiency.

User-visible output

By default, state only four points:

1. Where it's stuck: write the name of the looping type and the single most critical piece of evidence, and you must write one of the following two: the name of the established approach for this kind of problem; when unsure, at least two searchable keywords.
2. Keep A or switch to B; when switching to B, state which specific fact or requirement B is better on.
3. Fix: for small changes, give candidates, followed by the implementation spec compressed into one or two sentences; for large changes, give optional directions and ask only one question.
4. Where to stop: one sentence explaining what would change if you go further up, and the one remaining question that needs your decision.

Writing requirements:

• Summarize the looping process in one sentence; do not recount the versions tried one by one; give only the single most critical piece of evidence for each judgment.
• Keep replies for small changes to around 600 characters and for large changes to around 1,200 characters; when exceeding, cut explanations first, not fixes and candidates.
• Do not show Active Scope State, theoretical sources, or the internal checking process; expand only when the user asks.