goal-define

name

goal-define

description

Structure a clear, verifiable /goal from rough user input through guided interview. Use this skill whenever the user says "define goal", "tạo goal", "/goal", "goal cho task này", "I want to do X" (where X is complex/multi-step), "structure this task", "make this into a goal", or when you detect the user has a vague multi-step objective that would benefit from structured goal definition. Also trigger when the user pastes a wall of requirements and needs them organized into a runnable goal. Covers all task types: implementation, exploration/research, audit/review, and refactoring.

Goal Define

Turn rough user input into a structured, verifiable /goal text through guided interview.

A well-structured goal has a control core — four sections that prevent the agent from wandering or over-committing:

Section	Purpose
Constraints	Hard fences — what you CANNOT do
Operating rules	How you work — iteration size, scope control
Done when	Finish line — measurable success criteria
Pause if	Abort conditions — stop instead of grinding

Without all four, autonomous work either wanders or burns tokens on doomed approaches.

Process

Work through these phases in order. Each phase fills one section of the goal template. Use AskUserQuestion for structured choices. Ask one question per message.

Phase 1: Detect Task Type

Classify the user's intent into one of four types. This determines which optional sections to include and how to phrase interview questions.

Type	Signal phrases	Extra sections
Implementation	"build", "fix", "add", "implement", "deploy"	Components to build, Storage layout
Exploration	"explore", "understand", "trace", "diagram", "how does X work"	Method (tools), Output format constraints
Audit	"review", "check", "audit", "validate", "security"	Areas to examine, Severity classification
Refactoring	"refactor", "restructure", "clean up", "migrate"	Before/after criteria, Regression checks

If ambiguous, ask the user. If the user's input already makes the type obvious, skip this question.

Phase 2: Title & Scope

Extract or ask for:

• One-line title: <Task Type>: <description in ≤ 10 words>
• Scope boundary: What is explicitly IN scope? What is OUT?

If the user's initial input is detailed enough, propose a title and confirm.

Phase 3: Context Discovery

Identify what the agent should read before starting work.

Context-aware discovery: Check what's available in the current environment and suggest accordingly:

1. CodeGraph available? → Use codegraph_context or codegraph_files to find relevant files for the user's topic. Suggest specific paths.
2. Project has docs/? → Check for specs, architecture docs, plans that relate to the topic.
3. Project has CLAUDE.md? → Note relevant rules/constraints already defined there (don't duplicate — reference them).
4. Existing skills available? → Check if any loaded skills relate to the task (e.g., verify, quick-test, ag-ui).

Present discovered context to the user for confirmation. Ask: "These files look relevant — should I include them? Any others?"

Phase 4: Method Selection

Based on task type and available tools, suggest the approach:

• Which tools to use — codegraph (if indexed), MCP servers, Grep/Read, specific skills
• Which skills to invoke — check the available skills list for matches
• Execution strategy — sequential, parallel agents, incremental

Frame each suggestion with WHEN to use it: "codegraph_trace: when tracing call paths between symbols"

Phase 5: Constraints

Ask the user for hard rules. Prompt with task-type-specific examples:

• Implementation: "Output format? Framework restrictions? No X pattern?"
• Exploration: "Diagram type? Max complexity? Actors to include?"
• Audit: "Severity levels? Which categories to check? Scope limits?"
• Refactoring: "What must NOT change? API compatibility? Performance bounds?"

Rule: Every constraint must use "NO", "ONLY", or "MUST" — never "try to avoid" or "prefer". Soft constraints are useless in autonomous execution.

Phase 6: Operating Rules

Ask about process preferences:

• Iteration size: "One change at a time?" or "Batch related changes?"
• Verification cadence: "Verify after each step?" or "Verify at checkpoints?"
• Scope control: "Stop and ask if scope expands?" or "Note and continue?"
• Progress tracking: "Save artifacts immediately?" or "Batch at end?"

Suggest sensible defaults based on task type. User confirms or overrides.

Phase 7: Success Criteria (Done When)

Ask: "How do we know this is finished?"

Each criterion must be measurable + verifiable + specific, and include how to verify it inline. Combine what was done with how to prove it in one bullet:

• Good: "sessions/ JSON count == DB row count per env (verify: compare ls | wc -l against SQL count)"
• Good: ".gitignore includes raws/ (verify: grep raws .gitignore)"
• Bad: "diagrams are complete" — no verification method

Reject vague criteria. If user says "it works correctly", ask: "What specific check proves it works?"

Phase 8: Escape Hatches (Pause If)

Ask: "What should make us stop instead of pushing through?"

Each pause condition must be:

• Testable — agent can detect it programmatically
• Specific — "codegraph returns 'not initialized' error" not "tools don't work"
• Actionable — implies what to do next (ask user, try different approach, etc.)

Suggest 2-3 based on task type:

• Implementation: "tests fail in unrelated area", "dependency not available"
• Exploration: "index not initialized", "too many unresolvable dynamic dispatches"
• Audit: "codebase structure doesn't match expected layout"
• Refactoring: "existing tests fail before any changes made"

Output

Budget: the final goal text MUST be under 3000 characters. Goals are pasted into /goal prompts where context space is precious. A bloated goal wastes tokens on every turn the agent reads it.

After all phases, assemble the goal using compressed format — no ASCII trees, no verbose bullets, no section headers for empty sections. Apply these compression rules automatically:

• Single-line summaries instead of per-item annotations
• Shorthand: →, +, NO, ONLY, MUST instead of prose
• Merge "Validation: During" checks into the relevant "Done when" criterion (they must mirror each other anyway — don't duplicate)
• Collapse multi-sentence explanations into comma-separated phrases
• Drop optional sections that add no information beyond what's already in Constraints or Done-when

/goal <Type>: <Title>

  Context:
  - <path> (<why — 3-5 words>)

  Method:
  - <tool — when to use>

  Constraints:
  - <HARD rule — NO/ONLY/MUST>

  Operating rules:
  - <Process rule — one line>

  Done when:
  - <Measurable criterion + how to verify>

  Pause if:
  - <Testable condition>

Optional Sections (only when they add info not covered above)

• Resources (Exploration) — external endpoints, credentials, resource names in compact table
• Output layout (Implementation) — one-line pattern like {env}/sessions/ + workspaces/ + summary.json
• Before/after (Refactoring) — what changes vs. what stays

Quality Checks

Before printing the final goal, verify:

1. Under 3000 chars? — Count the goal text. If over budget, compress further using the rules above.
2. Control core complete? — Constraints + Operating rules + Done when + Pause if all present
3. No soft constraints? — Every constraint uses NO/ONLY/MUST
4. Done-when verifiable? — Each criterion includes how to verify it (command, file check, count match)
5. Context paths exist? — Every path is real (verify with Glob/codegraph)
6. No vague criteria? — No "works correctly", "looks good", "is complete" without specifics
7. Pause-if testable? — Each condition can be detected programmatically
8. No redundancy? — No section repeats information already in another section

If any check fails, fix inline before printing.

Anti-Patterns to Flag

If you notice these in user input, flag and fix:

Anti-pattern	Fix
"Try to avoid X"	→ "NO X"
"It should work"	→ Ask: "What specific check proves it works?"
Missing pause-if	→ Suggest 2-3 based on task type
Components without validation	→ Add matching validation entry
Context paths that don't exist	→ Verify with Glob, remove or correct
Scope too broad for single goal	→ Suggest decomposition into sub-goals

Reference

For the full goal template with all fields and compression guide, see references/goal-template.md.