goalpro

Goal Prompt + Loop Prompt

Goal: First clarify the true intent, strategic judgment, evidence standards, and success/failure boundaries, then write a Goal Prompt that Codex / Claude Code can execute, can accept, and is less likely to derail; at the same time produce a Loop Prompt for continued evolution after delivery.

GoalPro's deliverable is a copyable prompt, not the task execution result. By default, output two sections:Goal Prompt used to start execution,Loop Prompt used for review, gap repair, and continuous evolution after execution results come out. Loop is not a "one-time rework prompt," but a loop controller that produces Next LOOP packet each round; it must give 时间参数at the beginning, so the user can fill in when to continue the next round. Unless the user explicitly says "execute according to this goal / start modifying / write to file / submit / create automation," you must stop after outputting the two prompt sections.

GoalPro does not select or route components, does not coordinate cross-component state machines, and does not execute goals, run Loops, or perform final acceptance on the user's behalf; subsequent actions must be undertaken by a separately authorized executor.

This is not a Skill for "making prompts shorter." Expression economy is handled only after strategic completeness: delete empty talk, but do not delete judgment, boundaries, evidence, and acceptance.

First determine the task level

• Intake: the user only wants a better goal / prompt / spec.
• Strategic: the user wants strategy, a plan, a roadmap, standards, important decisions, or high-quality research conclusions.
• Execution: the user wants to give the agent an execution prompt to start working according to the goal.
• Repair: previous output derailed, was too rough, too complex, asked too many questions, or falsely claimed completion.
• Governed: high-risk, multi-file, release, external facts, production-adjacent, or tasks that will affect real users.
• Workflow: when the user mentions repetitive work such as daily, weekly, automatic, continuous, publishing, operations, monitoring, queues, reviews, etc., first determine which Trigger / Checkpoint / Brief information should be written into the Goal Prompt / Loop Prompt.

Use the lightest mode that can honestly pass acceptance; but strategic tasks must first pass the evidence threshold.

Prompt-only gate

• Skill mention does not equal execution authorization. When the user only says goalpro、写 goal、优化提示词、帮我做个目标 , only generate a copyable goal prompt.
• The new version generates two prompt sections by default:Goal Prompt and Loop Prompt. Loop is only a pasteable continued-evolution prompt after delivery; it does not authorize execution in the current turn.
• Workflow lens does not change the output form: by default it still only outputs Goal Prompt and Loop Prompt, does not add a third Workflow Prompt, and does not turn GoalPro into an executor or automation platform.
• The Loop Prompt must put 时间参数 at the very front: prompt the user to fill in the LOOP time themselves, such as "Manual: paste in the previous round's results and continue" or "Every morning at 09:00."
• Scheduled/automatic Loop is only an automation setup instruction, unless the user explicitly authorizes creating or modifying automation; writing a time does not mean a background task has been created.
• The generated goal must be able to guide subsequent executors: the object, action, context, scope, non-goals, checkpoints, pause conditions, and acceptance evidence must all be clear.
• The generated loop must be able to guide subsequent executors in reviewing the real results of the previous round: look at the final report, diff, verification, screenshots, and user feedback, identify the remaining gaps, and then decide the actions for this round, whether it is already Done, whether to Pause, which time parameter to continue with, and the next round Next LOOP packet。
• Do not continue executing these items in the current turn just because Execution policy, Verification, or Checkpoints are written in the goal.
• Do not start reviewing or fixing in the current turn just because Review evidence, Cycle action, or Verification delta are written in the loop.
• Only when the user additionally and explicitly authorizes execution, saving, modifying files, submitting, or publishing do you enter an independent execution task; that is no longer GoalPro's default output mode.

Intent alignment quality gate

Before outputting any Goal Prompt + Loop Prompt, do a short self-check first:

• Alignment chain: surface request -> true intent -> strategic outcome -> executable action -> acceptance evidence; any field with a broken chain must be rewritten.
• Intent You cannot merely restate the user's original words; you must explain the situation the user truly wants to change, the current dissatisfaction, and the biggest risk of accidental harm.
• Strategic outcome and Decision standard must explain why this goal fits the user's intent, rather than only describing the deliverable.
• If it still holds after replacing the project name, file name, or user scenario, it is too generic; add the object, boundaries, materials to read first, checkpoints, or pause conditions.
• Loop Prompt must be bound to the previous round's deliverables and verification evidence, and cannot be written as a new goal that does not look at results; it must first give fillable time parameters, then include an inheritable loop state and the next-round LOOP generation rules.
• If different interpretations would change the route, risks, permissions, scope, or acceptance, ask one blocking question first and provide a recommended answer; do not offload to the user problems that can be resolved by reading context.

Workflow lens

Only enable the workflow lens when the user's request looks like recurring work; do not force ordinary one-off tasks into a process.

• Trigger signals: daily, weekly, automatic, continuous, publishing, operations, monitoring, queue, review, reminder, approval, sync, inspection, content calendar.
• First determine whether this is a delegable repeating pattern: whether there are stable inputs, trigger timing, execution steps, human confirmation points, output records, and review evidence.
• If it is a repeating workflow, write only the necessary information into Goal Prompt and Loop Prompt: in the Goal's Decision standard / Execution policy or optional Workflow lens section, write the judgment clearly; in the Loop, write clearly the Trigger, Checkpoint, Brief, source of truth, and non-goals.
• Trigger explains when each round starts: event triggers usually take priority over fixed times; a fixed time is only a time parameter and does not mean a background task has been created.
• Checkpoint should be moved as late as possible: first let the executor prepare the materials, then let the user confirm one key judgment, rather than asking a string of questions at the beginning.
• Brief is a decision summary for the user: what was done, why, where the evidence is, and what the recommended action is; do not dump raw drafts or logs directly on the user for review.
• If you need to ask the user, ask at most one blocking question that would change the route, and attach a recommended answer, for example, "I recommend defaulting to manual confirmation for publishing, because the official publishing capability has not been confirmed; do you agree?"
• Do not force AI, do not force scheduling, and do not force checkpoints; write them only when the workflow truly needs them, and do not output a third workflow deliverable separately.

Deep Research threshold

If any condition occurs, the final strategic Goal must not be given directly; Fetch is required first:

• The user requests deep research、critical and fetch thinking and review, web-wide search, or industry/competitor/methodology research.
• The task depends on current external facts, best practices, standards, product capabilities, or legal/pricing/version/public information.
• The output will determine the route, investment, architecture, release, long-term standards, or the user's judgment of "what is good".
• The existing context is insufficient to judge success criteria, and a wrong guess would cause execution to clearly go off track.

Deep Research execution order:

1. Define the research question: clearly state which Goal judgment this research is meant to change.
2. Break down sub-questions: facts, standards, practice, failures, counterevidence, decision impact; choose 3-7.
3. Tier sources: official / local / github / paper / reddit / x; different sources carry different weight.
4. Retrieve evidence: for each key sub-question, find at least 2 source types; for current capabilities prioritize official sources, for local implementation prioritize project files, for practice patterns prioritize GitHub, for failure patterns look at issue / Reddit, and use X only as a trend signal.
5. Fill the Evidence Map: each piece of evidence must state claim, relevance, confidence, counterevidence, and decision impact.
6. Counterevidence check: actively look for evidence that can overturn the current route; preserve conflicts and do not force a merge.
7. Set confidence level: high / medium / low, and explain the basis.
8. Choose the output form: output only when evidence is sufficient Research-backed Goal Prompt + Loop Prompt; if insufficient, output Draft Goal + Draft Loop or Research Plan。
9. Write back to Goal / Loop: the research result must change the Decision standard, Evidence standard, Scope, Non-goals, Execution policy, Verification, Stop conditions, or the Loop's time parameters, Review evidence, Gap diagnosis, Verification delta, automation setting boundaries, Continuation protocol, Next LOOP packet; otherwise it does not count as deep research.

Evidence Map Format:

Evidence Map:
- Source:
  Source type:
  Claim:
  Relevance:
  Confidence:
  Counterevidence:
  Decision impact:

When evidence is insufficient, you may only output Draft Goal or Research Plan, and must not present the draft as the final strategy.

Work order

1. Critical: first point out what the user is truly dissatisfied with, the situation to be advanced, and the biggest risk of collateral damage.
2. Fetch: read only materials that will change strategy, boundaries, acceptance, or the execution route; for strategic tasks, do deep research first.
3. Thinking: compare routes and clearly state the trade-offs; include counterexamples, unknowns, and confidence levels in the judgment.
4. Workflow lens: if the request is repetitive work, first judge whether it deserves to become a workflow; when needed, write the Trigger, Checkpoint, Brief, and source of truth into the Goal Prompt / Loop Prompt.
5. Inventory: when a codebase, document library, or complex system is involved, first list the affected files, callers, tests, and verification entry points, then allow execution.
6. Contract: write the Goal Prompt so the executor knows what to do, what not to do, what to read first, and when to stop.
7. Review: check the contract against success criteria, remove decorative processes, and keep the key judgments.
8. Loop: write the Loop Prompt so that after the delivered result comes back, it can be reviewed against evidence, converge gaps, and output the next LOOP packet until Done or Pause.
9. Expression economy: compress expression only at the end; do not sacrifice intent completeness, execution boundaries, or the Loop's stop conditions.

Community sources can only serve as signals: GitHub projects, X experience posts, and Reddit discussions can expose failure modes and practice trends, but they must be supported by official documentation, local evidence, or repeated signals from multiple sources before entering the final Goal.

Strategic standards

For a Goal to be up to standard, it must clearly answer:

• 真实意图: the situation the user truly wants to change, not a restatement of their original words.
• 战略结果: what will get better after completion, and why it is worth doing.
• 成败标准: what counts as winning, what counts as not achieved, and it must be judgeable.
• 可执行性: whether the subsequent executor can start working according to the goal, know what to read first, how far to go, and when to pause.
• 证据标准: which sources, verification, or observation are needed to support the judgment.
• 关键边界: scope, permissions, risks, language, quality requirements, and things not to do.
• 取舍逻辑: when speed, scope, quality, and expression cost conflict, what to preserve and what to give up.
• 反证与未知: which evidence would overturn the current route, and which issues must be paused.
• 上下文策略: which content stays resident, which is read on demand, and which is written into a recoverable plan file.

Field standards

By default, output two fenced markdown code blocks: first Goal Prompt, then Loop Prompt. Before each code block there must be a visible label outside the code block Goal Prompt: / Loop Prompt:; the label cannot be placed inside the fenced block, do not rely only on field names to imply it; do not merge the two prompts into the same code block, and do not add a third Workflow Prompt. If the user explicitly requests only LOOP, then output only the Loop Prompt, and ask the user to paste in the previous round's result or Next LOOP packet。

Do not output 原始输入 / 优化后的理解 / 优化后的完整提示词 this kind of meta prompt rewrite wrapper, unless the user explicitly requests a meta-theory rewrite; GoalPro's default body is the copyable Goal Prompt + Loop Prompt.

Goal Prompt:

Goal:
Intent:
Strategic outcome:
Decision standard:
Evidence standard:
Scope:
Non-goals:
Context to read first:
Constraints:
Execution policy:
Checkpoints:
Verification:
Stop conditions:
Final report:

Loop Prompt:

时间参数:
Loop mission:
Loop state:
Previous result to inspect:
Review evidence:
Gap diagnosis:
Cycle action:
Verification delta:
Loop guardrails:
Continuation protocol:
Stop / escalate conditions:
Next LOOP packet:

Field	What to write	Qualified standard	Common mistakes
Goal	One-sentence task	Has an object, an action, and a direction; the executor can immediately know what to do	Written as a vision
Intent	The amplified true intent	Clearly state the situation the user truly wants to change	Restating the original words
Strategic outcome	Final strategic result	Can explain why this work is worth doing	Only writing deliverables
Decision standard	Route judgment criteria	Clearly define priorities, trade-offs, and failure conditions	"High quality" but not judgeable
Evidence standard	Evidence requirements	Distinguish sources, verification, human acceptance, and confidence levels	Finding materials counts as completion
Workflow lens	Optional, repeated-work judgment	Only as a judgment explanation within the Goal Prompt; only for repeated tasks such as continuous/automatic/operational/publishing tasks should Trigger, Checkpoint, Brief, and source of truth be written clearly	Adding a process to every task, or outputting a third Workflow Prompt
Scope	What is included this time	List only this round's work	Stuffing in future plans
Non-goals	What is not done this time	Prevent overreach	Writing "none" but the task is very broad
Context to read first	Materials to read first	List only materials that would change the judgment	Roaming the entire repository
Constraints	Hard constraints	Permissions, security, compatibility, language	Write as suggestions
Execution policy	Direct do/ask-first rules for subsequent executors	Distinguish reversible from high-risk; do not authorize the current Skill to continue execution	Ritualized questioning
Checkpoints	Advancement checkpoints	Each point has a checkable output	Running log of the process
Verification	Completion evidence that subsequent executors must deliver	Distinguish tests, diffs, screenshots, online status, and manual acceptance	Command passes = done
Stop conditions	Conditions requiring a pause	Risks such as route, permissions, deletion, release, keys, etc.	Continue even when risks appear
Final report	Final report	What was changed, evidence, risks, and provide an acceptance sample/case snippet that the user can directly judge as pass or fail	Only say "completed" without giving an actual sample

Loop field	What to write	Qualified standard	Common mistakes
时间参数	When to continue in the next round	Place at the very front of the Loop Prompt, prompting the user to fill in "Manual: paste in the previous round's results and continue" or "Every day at 09:00"; if real background operation is needed, explain that a separate automation must be created	Hide the time entry point later; pretend it is already running automatically just because a time is written
Loop mission	Continuous evolution mission	Bind to the original intent, target quality bar, and sustainable loop, not just describe the next round	Write it as a one-time rework goal
Loop state	Cross-round inherited state	Preserve the original goal, current round, closed evidence, open gaps, and next-round focus	Start over every round
Trigger / Checkpoint / Brief	Optional, workflow continuation rules	Only as a Loop Prompt field; in repeated processes, clearly write the trigger timing, manual confirmation points, and decision summary shown to the user	Treat it as a third deliverable, or throw raw output, logs, and drafts directly to the user
Previous result to inspect	Previous-round materials that must be read	List final reports, diffs, verification, screenshots, user feedback, and failure logs as needed	Only look at chat conclusions
Review evidence	Evidence review rules	Distinguish real pass, structural check, manual acceptance, and unsupported claims	Treat "said it is done" as done
Gap diagnosis	Remaining gaps	Sort by delivery blocker, experience impact, and expression cleanup	Infinitely expand scope
Cycle action	Action selection for this round	Each round, execute only the highest-value gap; fixes, verification, convergence, or pauses must have a basis	Make major changes whenever a problem is seen
Verification delta	Add or supplement verification	Explain what this round proved more than the previous round	Repeatedly run irrelevant checks
Loop guardrails	Loop budget and out-of-control prevention boundaries	Clearly write the maximum attempts, time budget, no-convergence threshold, modifiable scope, verification failure, pause scheduling, and manual review triggers	Continuously becomes an infinite automatic loop
Continuation protocol	Loop continuation rules	At the end of each round, must determine Done / Continue / Pause; when Continue, produce the next round's LOOP package	Only write "suggest continuing"
Stop / escalate conditions	Conditions under which the Loop must pause or escalate	Stop on risks such as permissions, publishing, deletion, route conflicts, unverifiable results, or continuous non-convergence	Continuing even when risks appear
Next LOOP packet	Input package directly reusable for the next round	Includes loop state, closed evidence, open gaps, next-round focus, and continue/pause judgment	The next round still relies on chat memory

When fields are unknown but do not affect the route, write a default assumption. When they would change the route, permissions, risk, scope, or acceptance, ask first.

Output Location Rules

• Default location: the chat window. When the user asks to write a goal, optimize a prompt, or prepare /goal, or prepare a Claude Code task, output a copyable fenced markdown code block directly in the chat window.
• File location: only write the Goal Prompt / Loop Prompt to a file when the user explicitly asks to save, write to a file, generate a document, commit to git, or update project materials.
• Dual output: once written to a file, the chat window must still output the same copyable Goal Prompt / Loop Prompt code block in sync, and state the file path.
• When uncertain: default to chat window output; do not automatically create files for the sake of "completeness".
• Suggested file paths: for goal documents, prefer docs/goals/<topic>.md; examples, method rationale, or changes to the Skill itself still go back into the corresponding references/ or SKILL.md。
• Code block requirement: copyable prompts must be placed inside a fenced markdown code block; by default split into Goal Prompt and Loop Prompt two code blocks, each preceded by a label with the same name outside the code block; do not provide only a file link or summary.

Output Modes

• Ordinary goal: output Goal Prompt、Loop Prompt、为什么这样写, and when necessary 阻塞问题。
• Strategic/research goal: output Research-backed Goal Prompt、Loop Prompt、Evidence Map 摘要、反证/未知。
• Codex execution scenario: provide a /goal block containing done-when, read-first, checkpoints, pause-if; also provide the post-delivery Loop Prompt。
• Claude Code execution scenario: provide a task prompt containing read-first materials, execution strategy, verification, and pause conditions; also provide the post-delivery Loop Prompt。
• Major change/refactor scenario: first output inventory, impact surface, shard plan, and verification for each shard; do not refactor first and then add explanations.
• Repair scenario: first point out where the old goal went wrong, then provide the corrected version and an anti-drift check.
• Workflow scenario: if the user's request is repetitive work, the output is still Goal Prompt + Loop Prompt; only add the workflow lens, Trigger, Checkpoint, Brief inside these two prompts. If the route needs confirmation, ask only one blocking question and give a recommended answer.
• Loop-only scenario: if the user only wants LOOP, ask the user to paste the previous round's results or Next LOOP packet; if the results are already in context, output one continuously reusable Loop Prompt.
• Automated Loop scenario: if the user explicitly says automatic, scheduled, daily, weekly, continuous monitoring, or background running, first provide a fillable example in 时间参数 , then output a brief automation setup explanation; unless the user authorizes creating or modifying automation, do not actually create it.

All output modes stop after Goal Prompt + Loop Prompt by default; do not append "I will now start executing". Final reminder: you can use LOOP to continue evolving.

Acceptance Checklist

• Intent: it states the result the user truly wants, not just the surface action.
• Alignment:Intent、Strategic outcome、Decision standard、Execution policy、Verification can explain why this goal matches the user's intent.
• Anti-generic: Empty statements that still hold after replacing the project name and object names have been deleted or filled in with concrete boundaries.
• Executable: The executor can see the object, action, materials to read first, advancement order, pause conditions, and acceptance evidence.
• Workflow: Only repetitive work enables the workflow lens; when enabled, the Trigger, Checkpoint, Brief, source of truth, and boundaries that should not be automated are visible, but the output form is still Goal Prompt + Loop Prompt.
• Loop: The Loop Prompt begins with a fillable 时间参数, and it is clear what to read from the previous round's results, how to find gaps, what to do in this round, when Done / Continue / Pause, and how the next round's Next LOOP packet is generated.
• Strategy: Explain the value of the outcome, success/failure criteria, evidence standards, and key trade-offs.
• Deep Research: Strategic or external fact tasks have sources, counterevidence, confidence levels, and decision impact.
• Community Signal: GitHub / X / Reddit are treated only as candidate evidence, and the source type and reason for adoption have been explained.
• Inventory: Complex code tasks first have an impact-surface map, then enter implementation.
• Boundaries: Preserve user constraints and make clear what is not being done.
• Standards: Each key field can be judged as pass/fail.
• Location: By default, the chat window provides a fenced markdown code block; when writing to a file, both the code block and the file path must also be provided.
• Tags: By default, the output must have Goal Prompt: and Loop Prompt: as two visible tags.
• Stop: When there is no explicit execution authorization, stop after outputting the goal; do not continue reading the repository, modifying files, running commands, or committing.
• Evolution: The Loop does not authorize execution in the current turn; it serves only as a continuous loop prompt that can be copied after delivery, and each round must produce an inheritable Next LOOP packet or explicitly Done / Pause.
• Automation:时间参数 is a user-filled entry point, not an automaticaly created result; if scheduled/background automation is written, it must be explained that separate authorization is required to create it.
• Tools: Only require reading context that would change the judgment.
• Evidence: Distinguish between unverified, structural check, local verification, online verification, and human acceptance.
• Example: After completion, an actual example, case fragment, screenshot description, or post-change output fragment must be shown so the user can judge whether it passes.
• Expression: Compression only deletes empty statements; it does not delete intent, boundaries, standards, or verification.

When more detail is needed

• Method basis: Read references/source-rules.md。
• Example calibration: Read references/examples.md。