Goal

/goal — Goal Prompt Design Coach (Goal Prompt 設計引導器)

Turns a vague "I want to do X" into a precise goal prompt that satisfies the five-element framework, and for subjective tasks also builds a rubric (評分標準) following the 6-step SOP from the source talk.

把「我想做某件事」這種模糊念頭，透過引導式問答轉化成符合五元素框架的精確 goal prompt。主觀類任務（設計、寫作、行銷）會額外引導建立 rubric（評分標準）。

Five elements (五個元素)

• Outcome — what "done" looks like / 完成定義
• Verification — how to prove it's done / 驗證方式
• Constraint — what must not be touched / 限制條件
• Iteration policy — what to record each round / 疊代政策
• Error handling — when to pause and report / 錯誤處理

Usage

/goal      # full Q&A from scratch
/goal --use                     # load saved goal at ~/.claude/goals//goal.md
/goal --resume            # resume an interrupted Q&A from handoff.md

Also triggered by natural language — phrases like "I want to design a goal", "help me write a goal prompt", "我要設計一個 goal", "幫我寫個 goal prompt" should fire this skill.

⚠️ No-argument /goal is intentionally unsupported — users must provide at least one sentence so the skill has a starting point.

When NOT this skill — outbound routing (對外讓位)

Check intent before starting the Q&A. Two cases are NOT this skill's job:

| User intent looks like | Route to | Why | |---|---|---| | A full software product — multiple features, deployed, used by others ("I want to build an app / platform / 我想做一個系統") | idea-to-spec (if installed) | That's product-requirement convergence (multi-round dark-zone Q&A), not a single-task goal prompt. Not installed → continue here, but warn the user this is product-scale and one goal prompt covers only a slice. | | A finished spec to split into dependency-ordered execution units ("decompose this spec", "把規格拆成 goal 圖") | goal-decomposer (if installed) | This skill's "goal" = ONE task's five-element prompt. goal-decomposer's "goal" = a node (G1/G2…) in a dependency graph compiled from a spec — same five-element format, different granularity. Not installed → continue here one module at a time. |

(The breadth sibling rule already exists: the same check across many independent units → workflow-shaper.)

What /goal is for

The source talk (transcript in examples/source-transcript.md if included) analyzes why Claude Code, OpenAI Codex, and Manus Agent simultaneously shipped a /goal feature in 2026: LLMs suffer from context anxiety — when the context window approaches full, they shortcut to a wrap-up and stop. /goal fights this by pairing an implementer (執行者) with a reviewer (評審) that re-evaluates the goal after each round.

But the feature only works if "done" is defined precisely. A vague prompt like "make this project better" lets the AI choose its own definition of "better" and quit in three minutes. A precise one — like "drop checkout page response time below 0.2s, verified by speed test tool, without touching other modules" — keeps it iterating for hours.

**Writing the rubric is ostensibly for the AI. The real value is that it forces you to put into words the taste that previously only lived in your head.**

This skill automates that forcing function.

Core principles (核心原則 — read before invoking)

1. Bilingual terminology / 術語雙語化: First mention of any technical term writes it as English (中文) or 中文 (English). Examples: baseline (基準輸出), rubric (評分標準), overfitting (過擬合), outcome (完成定義).
2. Match user's language / 配合使用者語言: Detect what language the user opens with. If Chinese, conduct the Q&A in Chinese with English term parentheticals. If English, conduct in English with Chinese term parentheticals. Bilingual terms either way.
3. Smart skipping / 智慧跳問: Before each round, scan everything the user has already said + any Phase 0b scan results. Mark elements as already-known and skip them.
4. Interrogate vague answers / 追問模糊回答: When the user says "better / smoother / more professional / 好一點 / 比較順", you must follow up for a measurable or visible standard. Accepting vague answers = skill failure.
5. 1–3 questions per round — but loop, never collapse / 寧可多輪，禁止塌成文字: Use AskUserQuestion progressively. Long lists make users abandon — BUT when real decisions exceed one round (or AskUserQuestion's 4-question cap), fire multiple rounds. Never dump several decisions into a prose list + 「全照建議 / all recommended」to save clicks — that silently strips the forcing function and reverts to the informal「聊一聊就開寫」mode this skill exists to fix. Each genuine fork gets its own AskUserQuestion option set with the recommended choice first.
6. Cite examples to seed thinking: Offer source-talk examples like "e.g. response time under 0.2s", but tell users not to copy verbatim.
7. Subjective tasks require a rubric: No rubric = the reviewer agent has nothing to judge against = wasted tokens.
8. Context window health above all: Phase 0a is a gatekeeper. If the user's context is unhealthy, advise restart. Do not push through to "finish the skill".
9. KICK-OFF is a self-cue, not a user-facing plan / KICK-OFF 是寫給自己的 self-cue，不是給使用者看的藍圖: After printing the KICK-OFF block (Steps 7 / 11), you must immediately make a tool call in the same turn to begin step 1 (Read / Glob / TodoWrite etc.). Do not end the turn, do not yield to the user. Text instructions pull an LLM far weaker than its default "print and stop" behavior — only an actual same-turn tool call (demonstration / 示範) reliably starts the agent loop. Symptom of violating this: the user has to type "continue" / "請接續完成" before anything happens.

---

What You Must Do When Invoked

Step 1 — Parse trigger arguments

| Trigger | Branch | |---|---| | /goal --use | Jump to Step 7 — --use direct load | | /goal --resume | Jump to Step 8 — --resume handoff | | /goal or natural-language trigger | Continue to Step 2 |

Step 2 — Phase 0a: Context Window Health Check (REQUIRED, FIRST)

Before asking any task-related question, ask about context state with AskUserQuestion:

question: "⚠️ Heads up: this skill's Q&A plus the subsequent /goal run will eat a meaningful chunk of context window. When context fills up, LLMs hit context anxiety (上下文焦慮) → premature wrap-up, quality drops. What's your current state?"
header: "Context status"
options:
  - { label: "Clean / just started",       description: "Continue the skill" }
  - { label: "Pack a handoff for new session", description: "Skill saves draft + gives handoff instructions" }
  - { label: "Aware but continue anyway",  description: "Continue with condensed responses" }

• Clean → continue to Step 3
• Pack handoff → jump to Step 9 — Handoff packaging
• Aware but continue → continue to Step 3; throughout the rest of the flow, condense replies, skip non-essential follow-ups

Step 3 — Phase 0b: Codebase Scan (optional for greenfield — REQUIRED for mutation tasks / 改既有檔必跑)

First, detect mutation intent (先偵測「改既有檔」意圖): does the task description / outcome say it will modify / extend / add to an existing file or module (改／擴展／加到某個既有檔案或模組)?

• Mutation task (改既有檔) → the scan is REQUIRED, not optional. Skip the yes/no ask (or still present it but flag「改既有檔強烈建議掃描」), and the Explore subagent must return the target file's real data contract (真實資料契約) — see the 4th Return item below. This is the exact gap that lets a goal guess at fields / signatures that don't exist: the fix is to read the source, not its output / log.
• Greenfield (新建檔) / pure copy-editing (純文案／設定) → scan stays optional (別把所有 goal 都逼 scan → 過度). Ask as normal below.

Ask if user wants a scan of the working directory:

question: "Should I scan the current project codebase first to find relevant context for your task?"
header: "Codebase scan"
options:
  - { label: "Yes, scan",  description: "I'll search the working directory for relevant files/functions/patterns and weave them into later questions" }
  - { label: "No, skip",   description: "Treat this as a context-free greenfield task" }

If scan (always run this for mutation tasks):

1. Extract keywords from the user's initial description (filenames / function names / tech stack mentions) as search seeds
2. Spawn an Explore subagent to isolate the scan from the main conversation context:

``` Agent( description: "Codebase scan for goal design", subagent_type: "Explore", prompt: "User is designing a goal prompt. Task description: ''. Scan the current working directory for 3-5 key findings:

• Files/modules semantically related to the task (Grep + Glob)
• Existing test framework / verification tools (check package.json / pyproject.toml / Cargo.toml)
• Likely constraints (same-name functions, version pins on dependencies)

Return:

• 3-5 relevant files/functions with paths
• Detected test tools (if any)
• Any important existing implementation patterns
• If this goal will mutate a file / module X: return X's REAL data contract (真實資料契約) — key data structures, function signatures, input / output shape, AND the gap between X's external interface / output and its internal implementation. Don't just say 'X is relevant'; open the file and read it. This item defends against inferring X's internals from its output / log (改既有檔時本項必答).

Under 300 words." ) ```

1. Save returned summary to ~/.claude/goals//scan-summary.md
2. Briefly recap to the user: "Here's what I found — I'll reference these in later questions"
3. This summary MUST be referenced in Step 5 (Phase B) questions, e.g.:

• On Constraint: "I saw validatePayment in src/checkout/ — keep it untouched?"
• On Verification: "I saw vitest configured — use the existing test runner?"

1. Mutation tasks — write the returned data contract into goal.md's Codebase Context section (Step 10). Discipline (鐵律): any field name / function signature the later Outcome or SBE table cites must come from this verified contract — never guessed. If you're about to name a field / signature you haven't actually read from source → stop, read it first.

If skip: jump straight to Step 4.

Step 3.5 — Phase 0c: Goal-Eligibility Check (任務可執行性檢查, REQUIRED)

Before task classification, decide whether this task is even appropriate for /goal execution. /goal works when "AI can move forward armed with tools." It does NOT work for:

• Tasks requiring external credentials (API keys / OAuth / SSH keys / cloud account auth)
• Tasks with severe info gaps (no data source, no I/O examples, no domain documents)
• Tasks whose core IS a human decision (business strategy, UX trade-off, product direction)
• Tasks blocked on external dependencies (waiting on approval, contract, someone's reply)

Evaluation logic:

1. From Phase 0b scan + user's initial description + collected answers, infer risk on the four dimensions
2. Identify clear yellow/red signals (examples):

• Task mentions "integrate Stripe / Twilio / OpenAI API" but scan didn't find .env / config files → External credentials YELLOW
• Task mentions "analyze customer data" but no data path/source given → Information completeness YELLOW
• Task contains "decide / trade-off / should I / which is better" → Human-only decision RED suspect
• Task mentions "after X replies / after approval" → External blocking RED

1. Use AskUserQuestion to confirm all detected risks at once:

``` question: "Final feasibility check before running /goal. From your description + scan, I see these risks. Please confirm each:" header: "Feasibility confirm" multiSelect, list detected concerns, e.g.:

• "Needs Stripe API key (no .env found in project)"
• "Needs customer data source (description didn't say where data lives)"
• "Needs decision: 'cut feature A or rebuild B' (business judgment)"
• "None apply, continue"

```

1. Based on user's selections, determine status:

• 🟢 Green (all clear or user picked "none apply") → continue to Step 4
• 🟡 Yellow (solvable prerequisites): list them and ask via AskUserQuestion:
• "I'll handle it now, continue" → continue to Step 4
• "I'll handle it later, pack handoff" → jump to Step 9 Handoff packaging, and add a ## Prerequisites section to handoff.md listing the blockers
• 🔴 Red (task is not /goal-shaped): tell user clearly, suggest alternatives:

``` ⛔ This task isn't a good fit for /goal direct execution. Reasons:

Alternative paths:

• If business decision → resolve with stakeholders / yourself first, come back with the decision as outcome
• If "waiting on external" → /goal after the reply arrives
• If pure research/exploration → Plan mode is better suited
• If you want /goal for the "uncertain → certain" stretch → rewrite as "gather X/Y/Z info and produce comparison report" — that makes outcome concrete

``` Skill ends here. Do not produce goal.md.

Principles:

• Any single red flag = overall red (conservative)
• Yellow prerequisites must be immediately actionable — write "create .env in project root with STRIPE_API_KEY=..." not "configure environment variables"
• Never demote red to yellow. Better to make the user rethink the task than ship a goal.md that's doomed to fail.

Step 4 — Phase A: Task classification

question: "What kind of task is this? Affects the questions I'll ask."
header: "Task type"
options:
  - { label: "Objective (客觀類)",  description: "Performance, bug fix, data pipeline, API integration — measurable" }
  - { label: "Subjective (主觀類)", description: "Design, writing, marketing copy, video editing — taste-driven" }

Remember the result. Objective → only Step 5. Subjective → Step 5 + Step 6.

Step 5 — Phase B: Five-element guidance (both task types)

Before asking each question, scan what's already known (user's initial description + Phase 0b scan summary). Skip already-answered elements.

In order, ask unknown elements (1–3 per round):

5.1 Outcome (完成定義)

question: "What does 'done' look like, concretely?"

• Vague answer ("better / smoother") → must follow up: "What's the specific standard? Measurable metric or visible difference?"
• Cite example: "e.g. 'response time under 0.2s' or 'all buttons not truncated at 375px mobile width'"

5.2 Verification (驗證方式)

question: "How do you prove it's done? What tool or check confirms it?"

• If Phase 0b found a test framework (vitest, pytest, jest), proactively suggest: "I saw X — use it?"
• "Eyeball it" → follow up: "Which specific screens / metrics?"

SBE 例證化驗收（分支 / 數值 / 資格 / 狀態類任務必做）：任務含任何分支、數值、資格、狀態邏輯（定價 / 贈金 / 折扣 / 等級閘 / 庫存門檻 / 狀態轉移）時，抽象的「計算正確 / 測試通過」不可接受——評審 agent（與下游 specmit scorecard 棘輪）拿不到可重跑的具體標準。逼出 SBE 表：≥3 列「情境 × 具體輸入 → 預期輸出」、用真實數字、至少含 1 正常 + 1 邊界 + 1 fallback。追問：「給我 3 個以上『情境 × 具體輸入 → 預期輸出』的例子（真實數字）。」純展示 / 文件 / 無分支任務可略過、用上面的一般驗證即可。

5.3 Constraint (限制條件)

question: "What files / modules / features absolutely cannot be touched? What styles / techniques are off-limits?"

• Prompt common categories: file scope, tech choices, external deps, style limits
• If Phase 0b scanned files, list them as checkboxes: "Of these scanned files, which are off-limits?"

5.4 Iteration policy (疊代政策)

question: "What should each round record? This feeds the reviewer agent's iteration decisions."

• Default offer from source talk: "Typical: 'what changed, what's the result, what's the next thing worth trying.' Use this or customize?"

5.5 Error handling (錯誤處理)

question: "When stuck / hitting a wall — pause and report, or keep trying? What should the report include?"

• Default offer: "Typical: 'what was tried, what's blocking, what info would unblock.' Use this or customize?"

5.6 Blocked / negative states (UI 或「動作型」任務必問)

**Only for tasks that render UI

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: dragon375014
• Source: dragon375014/goal-workflow-designer
• License: MIT

Install and usage instructions live in the source repository linked above.