goal-driven

Goal-Driven

Use this skill only when the user explicitly invokes it or clearly asks for this workflow. Do not invoke it implicitly for ordinary tasks.

Keep the workflow narrow:

1. Clarify the goal.
2. Clarify the criteria for success.
3. Create one dedicated subagent.
4. Keep the master/worker contract strict: the worker solves, the main agent evaluates.

Clarify Before Delegating

Before creating any subagent, ask concise follow-up questions in the user's language until both items are concrete:

• Goal: the exact end state to achieve.
• Criteria: observable checks that let you decide whether the goal is actually complete.

Push for criteria that are testable. Replace vague standards such as "works well" or "looks good" with concrete checks such as tests passing, files generated, benchmarks met, outputs matching, or user-visible behavior verified.

If the user gives only a goal, ask specifically for the criteria. If the user gives weak criteria, tighten them before proceeding. If a reasonable default criterion is obvious, propose it and ask for confirmation instead of asking broad open-ended questions.

Do not delegate until the goal and criteria are explicit enough that the main agent can independently judge completion.

Spawn One Focused Subagent

Once the goal and criteria are defined, use spawn_agent to create exactly one worker subagent.

Give the subagent a prompt that includes:

• The final goal.
• The success criteria.
• The instruction to stay focused on solving the problem rather than asking the main agent to do the work.
• The instruction to break the work into sub-tasks for itself when useful.
• The instruction to keep iterating until the criteria are satisfied or a hard blocker is reached.
• The instruction to report concrete evidence of progress and completion.

Use a prompt in this shape:

You are the dedicated worker for a goal-driven task.

Goal:
<final goal>

Criteria for success:
<final criteria>

Rules:
- Continue working toward the goal until the criteria are satisfied or you hit a concrete blocker.
- Break the work into smaller tasks and execute them.
- Prefer producing verifiable artifacts, tests, commands, diffs, logs, or measurements.
- When you think you are done, report the exact evidence that the criteria are met.
- Do not hand control back merely because one attempt failed; keep iterating.

Evaluate, Then Continue or Stop

Treat the main agent as the sole evaluator.

When the subagent reports completion, becomes inactive, or stops making progress:

1. Check the latest artifacts against the criteria.
2. If the criteria are met, stop and report success.
3. If the criteria are not met, send the subagent back to work with a precise gap list, or replace it with a fresh subagent carrying the same goal and criteria when necessary.

Do not accept "done" without verification. Do not stop only because the worker stopped. Do not move the goalposts after work starts unless the user changes the requirement.

Operating Notes

• Prefer a short, explicit recap before spawning the worker: one line for Goal, one line for Criteria.
• Keep the main thread focused on orchestration and evaluation instead of duplicating the worker's implementation work.
• If verification requires commands, tests, or artifact inspection, perform that verification in the main thread before declaring success.
• If the task is very long-running, consider using a thread heartbeat or another durable wake-up mechanism so the evaluation loop can continue over time instead of relying on a single foreground wait.

Reference

For the original concept and prompt template, read readme_cn.md only when you need the background rationale or source wording.