Define Goal
Turn intent into one verifiable, bounded objective. Do not force goal creation for ordinary work.
Workflow
- Restate outcome, target artifact/system/environment, verification, scope, exclusions, and stop/escalation condition.
- Add meaningful numbers when possible: exact checks; latency, cost, quality, coverage, error, or reliability thresholds; paths/environments/deadlines; required evidence counts. Avoid decorative precision.
- Repair activity goals (
make progress, investigate, improve) into observable outcomes. Ask one short question only when missing scope or validator could change intent.
- Call
get_goal before creation:
- No active goal: create only after quality check.
- Matching active goal: reuse it.
- Conflicting active goal: ask whether to finish it, mark complete if done, or use separate goal-backed thread.
- Call
create_goal with one concise objective containing evidence and material scope bounds. Include token budget only when explicitly requested.
Never create intermediate plans, snapshots, ledgers, decision logs, or resume files.
Quality Check
Objective must answer:
- What becomes true?
- What exact evidence proves it?
- What binary or quantitative threshold defines success?
- What is in/out of scope?
- When must work stop for user input?
Domain hints:
- Bug: reproduce, fix, failing-then-passing validator.
- Test: exact command and pass condition.
- Performance: metric, threshold, method, run count.
- Quality: observable review or checks.
- Research: decision enabled, source scope, evidence standard.
- Operations: healthy state, monitoring window, failure threshold, rollback/escalation.
If no honest metric exists, propose a binary validator and ask for confirmation.
1---2name: define-goal3description: Define or refine a concrete, measurable goal before work starts. Use when asked to create/set a goal, use the goal tool, clarify success criteria, or quantify fuzzy intent. Do not use for ordinary implementation or durable plans, snapshots, logs, or execution artifacts.4---56# Define Goal78Turn intent into one verifiable, bounded objective. Do not force goal creation for ordinary work.910## Workflow11121. Restate outcome, target artifact/system/environment, verification, scope, exclusions, and stop/escalation condition.132. Add meaningful numbers when possible: exact checks; latency, cost, quality, coverage, error, or reliability thresholds; paths/environments/deadlines; required evidence counts. Avoid decorative precision.143. Repair activity goals (`make progress`, `investigate`, `improve`) into observable outcomes. Ask one short question only when missing scope or validator could change intent.154. Call `get_goal` before creation:16 - No active goal: create only after quality check.17 - Matching active goal: reuse it.18 - Conflicting active goal: ask whether to finish it, mark complete if done, or use separate goal-backed thread.195. Call `create_goal` with one concise objective containing evidence and material scope bounds. Include token budget only when explicitly requested.2021Never create intermediate plans, snapshots, ledgers, decision logs, or resume files.2223## Quality Check2425Objective must answer:2627- What becomes true?28- What exact evidence proves it?29- What binary or quantitative threshold defines success?30- What is in/out of scope?31- When must work stop for user input?3233Domain hints:3435- Bug: reproduce, fix, failing-then-passing validator.36- Test: exact command and pass condition.37- Performance: metric, threshold, method, run count.38- Quality: observable review or checks.39- Research: decision enabled, source scope, evidence standard.40- Operations: healthy state, monitoring window, failure threshold, rollback/escalation.4142If no honest metric exists, propose a binary validator and ask for confirmation.
davidbasilefilho