/new-mission — Mission Brief
The standard flow before starting a new task: ask the right questions first, then give a plan, get it reviewed, get the user's approval, and only then act. Along the way, produce a reusable task prompt; after execution, deliver a closing report that maps back to the plan.
🤖 R2-D2 moment: R2 projects the Death Star schematics, the rebels gather around the hologram, study the attack route, confirm the trench is flyable, and only then do the X-wings launch. Nobody takes off before reviewing the schematics.
Why this is needed
Claude's default behavior when receiving a task is to start doing it immediately. Halfway through, it discovers three things, and each one requires redoing the work:
- Someone is already working on this, or there is already a card, a file, or an owner. Starting a new effort doesn't just duplicate work; it creates two contradictory sources of truth.
- The scope is misunderstood. A single user sentence can be read three ways; Claude picks the most convenient one and only gets rejected after finishing. The shorter the instruction, the more room for interpretation—and Claude usually doesn't notice which interpretation it chose.
- The output lands somewhere no one can find. The analysis is done and good enough, but it only lives in the conversation; three months later, the person who needs it has no idea where to look.
Most of these three problems can be prevented with a single question before starting. This skill pins down 'which questions to ask', 'what to do after asking', and 'when action is allowed' in a fixed sequence.
When not to use this
If the cost of doing it wrong is less than the cost of a round of questions, just do it. Criterion: if the task is one or two steps, reversible, and redoing it after a mistake costs only a few minutes, don't run this skill. If it has more than three steps, will write to shared files, will message other people, or will change rules, run it.
Actions
0. Open with triage, then investigate first — don't ask empty questions
⏰ Put the time in the first line of your opening reply: whether the next step is triage, investigation, or giving the plan directly, the first line of the reply is always:
⏰ <YYYY-MM-DD（週幾）HH:MM> <IANA 時區>
— e.g.
⏰ 2026-03-09（一）10:12 Europe/Berlin
-
The timezone is mandatory. When the human and the machine are not in the same timezone, or the user is traveling, a time without a timezone doesn't tell anyone what time it is where. Print the machine's timezone; don't pretend to know where the user is.
-
Read it from the machine; don't assemble it from memory. Dependency-free way (works on macOS/Linux, no python needed):
bash
set -- $(date '+%Y-%m-%d %u %H:%M')
case $2 in 1) w=一;; 2) w=二;; 3) w=三;; 4) w=四;; 5) w=五;; 6) w=六;; 7) w=日;; *) w=;; esac
tz=${TZ:-$(readlink -f /etc/localtime 2>/dev/null || readlink /etc/localtime 2>/dev/null)}
tz=${tz#:}; tz=${tz##*/zoneinfo/}
[ -f "/usr/share/zoneinfo/$tz" ] || [ -f "/var/db/timezone/zoneinfo/$tz" ] || tz="$(date +%Z)（非 IANA 名稱）"
[ -n "$1" ] && [ -n "$w" ] && printf '⏰ %s（%s）%s %s\n' "$1" "$w" "$3" "$tz" || echo '時間取不到完整值'
-
Three things to not cut corners on: ① Use the
(1–7) lookup table for the weekday —
gives a locale-dependent
/
, neither of which is the
required by the spec. ②
Get all fields in a single call — separate calls can stitch together a 'new date + old weekday' error across midnight that looks plausible. ③
The final validation line is the core of the whole block: take the extracted name and check it back against the timezone database; if it doesn't match, fall back to the
abbreviation and mark it 'non-IANA'. Every path that 'looks valid but is actually wrong' is caught here — multi-level symlink targets, links pointing to non-timezone files, POSIX-style values in
like
/
. 🚫 Better to label it 'non-IANA' than to print a guessed name.
-
If the reply language is not Chinese, write the weekday in the customary form of that language (e.g.
⏰ 2026-03-09（Mon）10:12 Europe/Berlin
); what cannot be omitted is the timezone, not the Chinese-looking format.
-
Environments where shell cannot run (web version, no terminal): use the time provided by the system in the current turn and add the timezone label yourself; if you can't even get the full value, write directly 'time could not be fully retrieved'. 🚫 Don't package it into a time line that looks valid.
Triage first: if the user hasn't yet said what the task is (only typed a trigger phrase), the first message only asks the following. Do not scan the environment or pre-search — verification only means something when there is a target; scanning empty-handed first is the most expensive guessing game:
What task are we kicking off this time?
- Reply with a one-sentence task description
- Pick from todos — I'll list the important ones for you to choose from
Only if they reply 2 do you dig into the todos/handover records visible in this project (for task-system integrations, see the Advanced section), pick at most five of the most important items, and list them with numbers; when the user replies with a number, use that item as the task description. If the trigger already came with a task description, skip this question and move on.
Then investigate first: before asking the user, spend one round checking what can be checked: this directory, related projects, todo system, recent handover records. Scope box: at most one round, indexed by keywords from the task description; cite the conclusion and source, don't paste the full text — the point of checking is to ask one fewer question, not to show how much you read. Use what you found to confirm, not to ask. 'I found that X already has a card in progress — do you want to continue or open a new one?' saves the user half the effort compared with 'Has this been done before?' and it doesn't make them feel you read nothing.
1. Ask — one question at a time, at most five questions
Ask each question only when you can't find the answer yourself. If an answer is vague, follow up once, not twice (the follow-up counts as the same question and doesn't take another slot); converging within three questions is best. Default to one question at a time; only when the user explicitly says 'ask them all at once' do you list them together (still max five, and still only one follow-up for vagueness).
Give numbered candidates whenever possible: turn what you found in step 0 directly into options (e.g. 'Landing spot: 1 = attach to existing X / 2 = create a new file / 3 = deliver in chat'), so the user can just reply with a number and type as little as possible; only ask open-ended when you can't generate reasonable candidates. If the user replies 'skip' or 'any is fine' to any question, adopt the most reasonable default and write that default into the 【假設】 cell in step 2 — skipping a question does not remove a risk; the risk just surfaces through the assumptions list.
- What do you want: 'After this is done, what do you have in hand that you didn't have before?' If it can't be explained in one sentence, it's usually two things — split it first.
- What you don't want: 'What is out of scope this time?' Boundaries are guessed wrong more often than goals.
- Existing: bring out what you found in step 0 and confirm: 'X already exists — continue from it or start a new one?' If you couldn't find anything, say clearly 'I checked A, B, and C and found nothing', so the user knows where you looked.
- Landing spot: 'Where does the output go, and who will see it?' Criterion for asking this: if someone needs to find this thing three months from now, where would they look? Is it there? Always include a concrete file-path option in the candidates (e.g. '2 = save to
<workdir>/mission-reports/<date>-<task>.md
- Completion criteria: 'What counts as done? How do we verify it?' The answer goes into the plan verbatim and is used to check against after execution.
⚠️ If the user says 'I remember we set up X before': verify first, then respond. If you can't find it, say you can't find it; don't just go along. Their memory may be right (then it's a real gap and needs to be created) or wrong (then one thing is saved); either outcome is better than going along.
2. First-version plan, no implementation
Fixed skeleton; every cell must be filled. If you can't fill one, write 'unknown, needs confirmation' instead of leaving it blank:
【目標】一句話
【範圍】內：…／外：…
【既有】接續 X／另開，理由
【步驟】每一步配一個驗證方式（怎麼知道這步真的做完了）
【假設】每一條假設都是一個要被使用者看見的風險
【產出】形式／落點；收尾報告放哪也在這格先寫明（沒指定就寫預設 `<工作目錄>/mission-reports/…`；無檔案系統的純聊天環境才寫「對話交付」）
【完成判準】照第 1 步第 5 題的答案
🚫 This step does not touch anything. No creating files, no editing files, no sending messages, no writing into shared systems. The plan itself may live in a scratch area.
Proportionality (same rule as step 7): for small tasks close to the lower bound of 'When not to use this', compress each plan cell to one line and each step-3 self-review/review item to one line. Don't delete cells; keep lines short and readable on one screen. ⚠️ The optimized prompt in step 5 is not subject to compression — it exists to be copied, pasted, and reused, so it must always be shown in full as a template block; if it's compressed to one line, users won't recognize it as a prompt, which kills its function (learned from actual behavior).
3. Submit for review
The plan goes through a review round before it is given to the user. The dependency-free version is self-review; external review tools are covered in the Advanced section.
Five self-review questions, answered one by one, one to two sentences each:
- Does this plan solve the thing the user asked about, or something I happened to want to do?
- Is a verification method written for each step? Who decides what 'done' means?
- Which step is most expensive to get wrong? Does the plan put it earlier or set a stopping point?
- Which assumption, if wrong, would force the whole plan to restart?
- Does this plan bypass any 'don't' the user just said?
(These five review the
plan; the other set of five for reviewing
results after wrap-up is in
— one reviews the start and one the end, and the two sets don't overlap.)
Discipline for handling review comments: accept the diagnosis, but judge the prescription yourself. Reviewers are often right that there is a problem, but the fix they suggest is a generic average and may not fit this particular case. Label each comment 'accepted / not accepted + reason'; keep the rejected ones too, so the user can see what you declined.
4. Give it to the user for review and wait for an explicit 'go'
Present three things: the integrated plan, the review-comment disposition table, and the optimized prompt from the next section. End with fixed numbered options, then stop:
- Start executing 2. Needs changes (tell me what to change) 3. Put it aside for now
🔴 Don't act without explicit confirmation. 'Looks okay' or 'should be fine' is not confirmation; only explicit words like 'reply 1', 'do it', 'start', or 'go' count, and they must be a direct reply to the current plan — mentioning these words while quoting, asking a question, or discussing rules doesn't count. Don't move until you get it, even if the plan looks completely safe.
If the user changes a section of the plan: report the change points, not just the new version. A sentence like 'I moved step 3 to step 1 and brought X from out of scope into scope' lets them reject it at a glance; if you hand back the whole rewritten plan, they have to reread everything to see whether you understood correctly.
5. Output the optimized task prompt
Fill this template with what was gathered in steps 1 through 4. It exists for the next time the same thing comes up, or when this work is interrupted and restarted — paste it in and start from the right place without another round of questions:
【任務】<第 1 題的答案，一句話>
【範圍】內：<…>／外：<第 2 題>
【既有】<接續哪張卡／哪份檔，或「查過 A、B、C 皆無，全新」>
【產出】形式：<…>／落點：<第 4 題>
【完成判準】<第 5 題，原話>
【已確認的假設】<第 2 步假設清單裡使用者點頭的那些>
【不要做的事】<使用者在過程中說過的每一個「不要」>
【驗證要求】每一步做完要能指出證據在哪；憑印象的標「未驗證」；掃不到的明說「掃不到」，不靜默跳過
【收尾】做完交收尾報告（見第 7 步）：計畫／執行過程／成果對照／誠實帳／落點五格，明講什麼沒做、什麼沒驗、什麼是猜的
📝 This prompt is presented together with the plan in step 4 (preview); it is only saved to the user-specified landing spot along with the plan after getting the 'go' — during the briefing phase, do not write the plan or prompt into the user's landing spot/shared systems (the step-2 scratch drafts and the advanced review staging files do not count as landing).
6. Execute after confirmation
Start only after an explicit 'go'. If execution encounters out-of-plan conditions that affect scope, risk, or completion criteria (new findings, new blockers, scope changes), stop and report; don't unilaterally expand or shrink the work. At the end of each completed step, write one line on the spot recording 'what was done, where the evidence is' — the 【執行過程】 in step 7 grows from this record, not from memory.
7. Closing report
After execution ends — whether it was finished, stopped halfway, or ended in failure — deliver a full report, not a one-line 'done'. Fixed skeleton, filled cell by cell against the step-2 plan; cells with no content should say 'none', not be deleted:
【計畫】使用者核可的最終版；中途改過的列改動點，不重貼全文。第 5 步的優化 prompt **全文**附在本格末——prompt 是這件事可重跑的濃縮版，少了它報告就當不了下次的起點；照第 2 步的規矩不壓行
【執行過程】逐步對照計畫：每步一行「做了什麼 → 證據在哪」（指令輸出、檔案路徑、連結）；計畫外狀況單獨列：發生什麼、當時怎麼裁決、有沒有停下來回報
【成果】完成判準逐條對照：過的附證據，沒過的講差在哪
【誠實帳】沒做：略過或降級的步驟＋原因／沒驗：做了但沒驗證的＋驗證等級（看起來對 ≠ 驗過 ≠ 實際跑過）／猜的：哪些結論是推論不是證據
【落點】產出實際放在哪；與計畫落點不一致要明講原因
Where the report goes follows the closing-report landing spot written in the step-2 【產出】 cell: once the plan is approved, the report is saved to that landing spot; if the landing spot is an existing carrier (card, thread), append to it; if the plan didn't specify one but the environment has a filesystem (every environment that can install this skill does), save to the default path
<workdir>/mission-reports/<date>-<task>.md
and state that in the report; only
pure-chat environments with no filesystem (the lite scenario) deliver in chat and explicitly say 'report not saved to disk' — this is not a downgrade or failure.
Proportionality: for small tasks near the lower bound of 'When not to use this', compress each of the five cells to one line and still deliver all of them; if any completion criterion was not met, or there were out-of-plan situations, compression is not allowed.
(Another set of five self-review questions exists before wrap-up, see
— in environments where it's installed, you can run the five questions first and feed the results into 【誠實帳】; if it's not installed, that's fine, the five cells are self-sufficient and the absence of the sibling skill does not degrade the report.)
🚦 Iron rules
- 🔴 Don't act without an explicit 'go'. No matter how safe the plan looks; this is the reason the skill exists.
- ⏰ Report the time on the first line, including the IANA timezone; take it from the machine, don't assemble it from memory, and if you can't get it, say so.
- 🚫 Don't ask empty questions. Check what can be checked first, use findings to confirm, and clearly state where you looked if you found nothing. The only exception is an empty trigger: ask what the task is first, then start checking.
- 📝 One question at a time, max five. Follow up on vagueness once, not twice; give numbered candidates whenever possible, so the user can reply with a number.
- ⚠️ Every assumption in the plan must be visible to the user. An assumption kept in your head, when wrong, no one will know.
- 📝 Accept review diagnoses, judge prescriptions yourself. Mark each item as accepted or not, and keep reasons for rejections.
- 📝 When the plan is changed, report the change points, not just the new version. The shorter the instruction, the more necessary this is.
- ✅ Write completion criteria before starting work and check against them after execution; don't define what 'done' means only after finishing.
- 📝 The optimized prompt must land where the user specifies (saved after getting the 'go'), not just live in the conversation.
- 📝 Wrap up with a report, not a one-line 'done' — plan, execution log, results, honest account, and landing spot: all five cells must be present; even a small task compressed to five lines must have all five. Landing on disk beats evaporating: if a filesystem exists, don't let the report live only in the conversation.
Advanced: hook up your own review tool
The file-based five self-review questions are the dependency-free lowest common denominator, not the ceiling. If you have a cross-model review tool, send the plan for review at step 3 and handle the returned feedback with the same 'accept the diagnosis, judge the prescription yourself' discipline. If this package's
is available: save the plan to a scratch file,
call it with the full path (don't use a bare command name)
<ai-review skill 目錄>/scripts/ai-review.sh <計畫檔> --rubric research --context "<這個任務要解什麼>"
; if it returns
/
, fall back to the usual self-review and state clearly 'self-review only this time'.
⚠️ Think about data boundaries before sending for review: the plan often carries names, client names, internal paths, and card numbers. De-identify before sending to an external model (replace with placeholders like 〔角色〕/〔專案〕); paths and filenames are also data, so don't assume sending only the content is safe. State clearly in the report what was sent.
If there is a task system (todos, kanban, cards), use it for the step-0 'investigate first' and for 'pick from todos' when triggered empty-handed; the step-5 prompt can also be attached directly to that card, so the next person who picks it up opens the card and the full text is there.