Prompt To Loop Controller

Purpose

Convert a user's traditional goal prompt or rough prompt idea into a loop-based engineering controller prompt. Do not execute the underlying task. Preserve the user's intent, constraints, output format, and forbidden behaviors while adding state handling, stepwise execution, self-checks, repair rules, safeguards, and exit conditions. Offer optional opposition review for strict, risky, or skill-bound conversions; do not enable it by default.

Use this skill as a prompt refactoring workflow. If the user asks to run the transformed prompt, finish the conversion first and ask or proceed only according to the user's latest instruction.

Workflow

1. Classify The Request

Confirm that the user wants prompt conversion, not task execution.

Proceed when the user asks to:

• turn a traditional prompt into a loop prompt
• generate a loop prompt from a prompt idea
• make a prompt iterative, self-checking, or agent-friendly
• convert a development, OCR, analysis, automation, document, decision, or skill prompt into a controller
• prepare a prompt for later skill or agent use

If the user only asks for the task result, do not use this skill unless they explicitly ask for prompt restructuring.

2. Parse The Input

Classify the input as either:

• Complete prompt: the user already provided a usable traditional prompt.
• Prompt idea: the user provided a goal, rough concept, or partial requirements for a prompt that does not yet exist.

Extract these fields from either input type:

• Goal: what the prompt asks the AI to accomplish
• Inputs: files, images, text, systems, APIs, data, or context
• Output contract: format, sections, file types, tables, code, or artifacts
• Hard constraints: must-follow requirements
• Forbidden behaviors: what the AI must not do
• Uncertainty handling: how to mark unclear, missing, risky, or ambiguous cases
• Ordering rules: required sequence, such as top-to-bottom or read-code-before-editing
• Quality checks: tests, validation, consistency checks, review criteria

For prompt ideas:

• Preserve confirmed information as requirements.
• Convert uncertain details into explicit assumptions.
• Ask at most three questions only when missing information would make the generated prompt unusable.
• If enough context exists, generate the loop prompt and include an assumptions section instead of blocking.
• Do not invent domain facts, formats, tools, recipients, schemas, or business rules as if they were confirmed.

If the input is clear enough, convert or generate directly.

3. Choose A Loop Type

Select the smallest useful loop type. Load references/loop-types.md when you need task-specific patterns.

Common choices:

• Recognition loop: OCR, screenshots, handwritten forms, visual extraction
• Development loop: coding, bug fixing, CLI tools, repository changes
• Analysis loop: Excel, CSV, SQL, reports, data quality checks
• Decision loop: architecture, options, tradeoffs, plans, retrospectives
• External action loop: Feishu, Slack, calendar, email, APIs, approvals
• Skill-design loop: SKILL.md, references, examples, packaging workflow

Do not overbuild. For simple prompts, use judge -> execute -> check -> output.

4. Decide Whether To Offer Opposition Review

Opposition review is optional and off by default. It adds an independent critical pass after the first loop prompt draft.

Offer a short prompt asking whether to enable opposition review when the source prompt is:

• complex or likely to become a reusable skill
• high risk or strict quality controlled
• about code, data analysis, OCR, formal documents, or external actions
• about sending, approving, deleting, purchasing, publishing, or committing outside the chat
• explicitly requested as "strict", "reviewed", "high reliability", "反向审核", "对立面审核", or "红队"

Use this default behavior:

• If the user says yes, enable opposition review.
• If the user says no, continue normal conversion.
• If the user does not answer and the question is non-blocking, continue normal conversion and mention that opposition review was not enabled.
• If the task involves external action or irreversible/high-stakes consequences, strongly recommend opposition review and still require explicit authorization for any converted prompt that would later execute the action.

Load references/opposition-review.md when opposition review is enabled or when you need the exact review checklist.

5. Build The Controller

Create a loop prompt with:

• Role: what specialist the future AI should act as
• Goal: the user's original objective, preserved
• State model: what the AI checks before and during work
• Work loop: ordered steps for execution
• Self-checks: requirements that must be verified before output
• Revision rules: how to correct missing, inconsistent, or uncertain work
• Output rules: exact final structure
• Exit conditions: concrete, checkable completion criteria
• Loop safeguards: maximum rounds, blocked-state rules, and fallback behavior

Move the original prompt's forbidden behaviors into both the work loop and the self-check stage. This is how "do not guess", "do not correct", "do not send without confirmation", and similar rules stay active.

Every converted loop prompt must include these safeguards unless the user explicitly asks for a minimal prompt:

• Default to 3 rounds for normal tasks and at most 5 rounds for complex tasks.
• If the same issue remains unresolved for two consecutive rounds, enter blocked.
• If required input, permissions, files, or evidence are missing, stop and ask for the smallest necessary user input.
• If exit conditions cannot be fully satisfied, output the best current result, unresolved items, and exact next questions instead of continuing indefinitely.

6. Apply Opposition Review When Enabled

When opposition review is enabled:

1. Draft the loop prompt normally.
2. Review it from the opposing perspective: find original-intent drift, missing constraints, excessive complexity, weak exit conditions, missing confirmation gates, or hidden execution risk.
3. Revise the loop prompt based on valid findings.
4. Stop after one review-and-revision pass by default; use at most two passes when the user explicitly asks for stricter review.
5. Include a concise "Opposition Review Notes" section unless the user requested final-prompt-only output.

Do not let opposition review become a second full solution. It should challenge the controller prompt, not execute the underlying task.

7. Produce The Output

Default output:

1. Original prompt analysis
2. Loop structure design
3. Opposition review recommendation or notes
4. Complete copyable loop prompt
5. Assumptions and open questions when the input was a prompt idea
6. Usage notes and boundaries

If the user asks for only the final prompt, output only the complete copyable loop prompt.

If the user wants to turn the result into a skill, add a short skillization note:

• suggested skill name
• trigger description
• likely references
• validation examples

Use references/output-templates.md for reusable output shapes.

Conversion Rules

• Preserve the user's original goal. Do not change the business task while improving the control structure.
• Preserve required output formats unless the user asks to change them.
• For prompt ideas, separate confirmed requirements from assumptions and open questions.
• Make implicit sequence explicit. For example, "recognize table" becomes structure detection, row-by-row recognition, uncertainty marking, and final consistency checks.
• Convert negative instructions into active guardrails. For example, "do not infer" becomes "mark unclear content instead of inferring" plus a self-check for unsupported guesses.
• Use uncertainty labels when the source prompt contains ambiguity, risk, missing data, visual blur, permission boundaries, or external actions.
• Add user-confirmation gates for external writes, irreversible actions, approvals, commitments, or messages sent to other people.
• Keep the controller proportional. A short prompt should not become a heavy state machine unless the task is high risk or multi-step.
• Add loop safeguards to prevent open-ended self-correction: round limits, blocked-state triggers, and fallback output.
• Distinguish conversion from execution. The final answer should be a better prompt, not the result that prompt would produce.
• Do not enable opposition review silently. Either the user asked for it, or you offered it and the user accepted.
• Keep opposition review bounded to prompt quality, not domain execution.

Quality Bar

The converted loop prompt is successful when:

• the original objective is still recognizable
• all hard constraints are represented in the loop
• prompt ideas distinguish confirmed requirements from assumptions
• forbidden behaviors appear as operational checks
• uncertain or risky cases have explicit handling
• the output contract is concrete
• the exit condition can be checked
• loop safeguards prevent indefinite execution
• optional opposition review is suggested or applied in the right cases
• a future AI can copy the prompt and run the task more reliably than with the original one-shot prompt

References

• Read references/loop-types.md when selecting or adapting a task-specific loop pattern.
• Read references/opposition-review.md when the user enables opposition review or the task calls for a strict/high-risk recommendation.
• Read references/output-templates.md when the user asks for a specific output style, such as concise, strict, skill-controller, or comparison mode.
• Read references/examples.md when you need examples, especially for handwritten table OCR, development goals, Excel analysis, and external actions.
• Read references/architecture.md when explaining the skill architecture or showing the loop plus opposition-review design.
• Read references/validation.md when the user asks how to test a converted prompt, compare it with the original, or decide whether the conversion is good enough.