goal-refiner

name	goal-refiner
description	Turn a vague user objective into a rigorous /goal template by asking targeted questions first. Use this skill when the user asks to refine,提炼,生成,整理,or convert an idea into a /goal, task brief, execution goal, scope/constraints/done/stop template, or wants Codex to ask questions before calling /goal.

Goal Refiner

Use this skill to convert an ambiguous task into an executable /goal prompt with clear scope, constraints, environment, validation, deliverables, and stop conditions.

The skill is interactive by default. Do not silently invent important requirements when the user asked to be questioned first.

Workflow

1. Ask the user what they want to do.

   • If the user already provided an objective, restate it in one sentence and classify the task type.
   • If task type is unclear, ask them to choose or describe it.

2. Load the relevant checklist from references/question-bank.md.

   • Use only the sections that match the task.
   • Ask in batches of 3-7 concise questions.
   • Prefer defaults when low-risk, but surface assumptions explicitly.

3. Collect enough information to fill:

   • Objective
   • Scope
   • Constraints
   • Environment
   • Inputs
   • Outputs
   • Validation
   • Done when
   • Stop if
   • Execution requirement

4. Generate the final goal in this structure:

/goal [one-sentence objective]

Scope:
- ...

Inputs:
- ...

Environment:
- ...

Constraints:
- ...

Validation:
- ...

Outputs:
- ...

Done when:
1. ...

Stop if:
- ...

Execution requirement:
- ...

5. Ask the user whether to execute it.
   • If they confirm, send the generated /goal ... as the next actionable command or invoke the platform's goal flow if available.
   • If they want edits, revise the goal and ask again.

Question Style

• Start broad: ask what kind of work this is and what success looks like.
• Then ask task-specific questions.
• Do not ask for information that can be discovered from the repo unless the user wants to lock it upfront.
• When a goal will modify files, always ask about allowed file scope.
• When a goal may install packages, run long jobs, spend money, call APIs, or use credentials, ask for explicit constraints.
• When a goal is research or experimentation, ask for metrics, baselines, data sources, time limits, and result logging.
• When a goal is design or frontend work, ask for style, audience, interaction, visual constraints, assets, and verification viewports.
• When a goal is document/spreadsheet/deck work, ask for source files, target format, formatting constraints, and visual QA.
• When a goal is automation or data processing, ask for input/output schemas, idempotency, scheduling, failure handling, and audit logs.

Required Safeguards

Every generated goal should include:

• A narrow scope, including files or directories that may be changed.
• Explicit non-goals or forbidden changes when relevant.
• Validation steps with concrete commands or checks when possible.
• Stop conditions for risky, expensive, destructive, or long-running work.
• A final reporting requirement.

Do not include "unlimited token usage" unless the user explicitly asks. If included, place it under Environment or Execution requirement; it is not a substitute for runtime or safety limits.

Handling Missing Answers

If the user skips details:

• Use conservative defaults.
• Mark assumptions in the generated goal.
• Add a Stop if item when the missing detail could cause unwanted edits, costs, or invalid results.

Final Output

The final response should contain only:

1. The generated /goal block.
2. A short confirmation question such as: 确认后我会用这个 /goal 开始执行。

Do not execute the goal until the user confirms, unless they explicitly asked you to both create and run it.