Ultra Goal

UltraGoal

Product Mission

UltraGoal exists for one non-negotiable purpose: convert the user's ordinary lazily worded goal into the rigorous goal the agent sets for itself and executes.

Do not treat UltraGoal as a coach, interviewer, planning assistant, prompt critique mode, or preview generator by default. It is a middleman in the goal-entry path:

rough user goal -> upgraded executable goal -> set goal -> proceed

Every instruction in this skill serves that path. If an interpretation would add a confirmation loop, defer execution, or merely suggest a better prompt, reject that interpretation unless the user explicitly asked not to run the goal.

Overview

Turn the user's rough UltraGoal command text into the clear, checkable goal the agent should actually pursue. UltraGoal is a middleman between the user's ordinary lazy goal and goal-mode execution: rewrite the goal, set the upgraded version as the active goal when the runtime supports it, then work from it.

Core Rules

• Treat the text after the UltraGoal invocation as raw user intent, not as the final goal.
• Preserve and augment the user's intent. Make the goal more rigorous without changing what the user is trying to accomplish.
• Do not silently expand the user's scope. Separate required outcomes from optional stretch work.
• If UltraGoal is invoked, assume the user wants the improved goal to become the active working objective immediately.
• Do not pause for clarification or approval. Make conservative assumptions, encode them in the goal, and proceed.
• Clarify inside the upgraded goal, not before it.
• Prefer concrete verification over vague quality bars. Include tests, commands, screenshots, manual checks, artifacts, or review criteria where relevant.
• Treat user-provided wall-clock constraints as first-class goal constraints. Preserve deadlines, maximum time limits, minimum active-work durations, and scheduled work windows in the upgraded goal.
• Never sleep, idle, wait, artificially delay, or burn time to satisfy a minimum duration. Use prescribed time for active work, investigation, verification, documentation, alternate approaches, or blocker analysis.
• Include autonomy boundaries for destructive actions, money, external accounts, publishing, production systems, private data, and broad refactors.
• Keep the improved goal usable as persistent goal text. Avoid long rationale inside the goal itself.

Wall-Clock Constraints

Treat time language as part of the user's goal contract, not as incidental context. This includes maximum time limits, absolute deadlines, scheduled work windows, minimum active-work durations, and phrases like "within X," "by X," "spend at least X," or "work for X."

• Maximum elapsed budgets such as "within 30 minutes" require prioritization, honest triage, and a stop or report point when the elapsed budget is reached.
• Absolute deadlines such as "by 5pm" require preserving the target clock time, prioritizing work against the remaining time, and reporting honestly at or before the deadline.
• Scheduled work windows require preserving the start and end window and stating what fits inside it.
• Minimum durations and active-work windows require relevant active work until the time elapses or the user changes the instruction.
• If blocked before a minimum duration or work window ends, use the remaining time for relevant inspection, alternate approaches, documentation, verification, or blocker analysis.

For every wall-clock constraint, include it in the upgraded goal's context, success criteria, verification, autonomy boundaries, or completion rule as appropriate. Require timestamp, elapsed-time, or active-work evidence when it matters. Missing time evidence is a verification gap.

Workflow

1. Strip away the invocation wrapper and identify the raw goal text the user would have typed into native goal entry.
2. Infer the user's true objective, audience, surface, repository or tool context, and hard constraints from the conversation and workspace.
3. Replace the raw goal with an upgraded goal using the UltraGoal contract:
   • Objective: the concrete outcome.
   • Context: relevant repo, product, user, or business context.
   • Scope: what is in and out.
   • Success criteria: measurable definition of done.
   • Verification: commands, checks, artifacts, or review steps.
   • Wall-clock constraints: deadlines, maximum time budgets, minimum active-work durations, or scheduled work windows.
   • Autonomy boundaries: what to avoid, constrain, or document before proceeding.
   • Completion rule: what must be true before the agent marks the goal complete.
4. Set the upgraded goal as the active goal using the available goal tool. If no goal tool is available, state the upgraded goal briefly and proceed as if it is active.
5. Work from the upgraded goal, not the lazy raw text. Put assumptions and risk boundaries inside the goal instead of asking preflight questions.

For vague, high-stakes, or product-strategy goals, read references/goal-rubric.md before drafting.

Output Patterns

For normal UltraGoal execution:

Upgraded goal:

[Goal text]

Setting this as my goal and proceeding.

For a user who explicitly asks to see the upgraded goal but not run it:

Use this as the goal text:

[Goal text]

For a user who explicitly asks to audit or critique goal text without running it:

Prompt audit:
- Score: [N]/16
- Main strength: [Summary]
- Main risk: [Summary]

Findings:
- [Severity] [Issue]: [Evidence] -> [Fix]

Recommended upgraded goal:
[Goal text]

If the raw UltraGoal input is itself an audit task, such as "audit the checkout flow and report issues," treat it as a normal goal to upgrade, set, and run.

Goal Text Style

• Use direct imperatives: "Build", "Refactor", "Investigate", "Ship", "Prepare", "Migrate".
• Put the main outcome in the first sentence.
• Use bullet criteria for anything the agent must keep checking.
• Include explicit non-goals when the rough prompt could cause scope creep.
• Include "Do not..." or "Stay within..." for risky boundaries.
• Include "Complete only when..." for the finish condition.

Examples

Raw UltraGoal input:

Make the app faster.

Upgraded goal:

Improve perceived and measured performance for the app's primary route without changing user-visible behavior.

Scope:
- Identify the current bottlenecks before editing.
- Implement the smallest safe changes that reduce load time or interaction latency.
- Stay within the existing architecture unless a small refactor is clearly required.

Success criteria:
- The primary route loads without console errors.
- The relevant test suite still passes.
- Before/after performance evidence is reported with commands or browser measurements.

Do not change public APIs, data models, or build tooling unless the current implementation cannot meet the performance goal without it; if that happens, document the reason before proceeding.
Complete only when the patch is implemented, verified, and summarized with residual risks.

Raw UltraGoal input:

fix the bug where settings don't save

Upgraded goal:

Investigate and fix the settings persistence bug so user changes reliably save and survive reloads without changing unrelated settings behavior.

Context:
- Use the existing app structure, settings UI, state management, storage layer, and tests to find the failing path.

Scope:
- Reproduce or infer the settings save failure from the code and available tests.
- Implement the smallest fix that makes settings persist correctly.
- Add or update regression coverage for the save flow.
- Avoid redesigning the settings experience or changing unrelated preferences.

Success criteria:
- A changed setting remains saved after the expected reload, navigation, or app restart flow.
- Existing settings behavior still works.
- Relevant tests pass, or any missing test harness is called out with manual verification.

Verification:
- Run the relevant automated test command if one exists.
- Manually exercise the save-and-reload flow if the app can be run locally.

Complete only when the fix is implemented, verified, and summarized with changed files and residual risks.

Quality Check

Before setting the upgraded goal, confirm internally:

• The goal can be judged done or not done.
• Verification is possible in the user's environment.
• Scope boundaries protect the user's intent.
• Any assumptions are visible.
• The text is concise enough to work as persistent completion criteria.