decide

/decide — 结构化决策工作流 + 归档

从 37signals 指南中挑选关键问题，逐一讨论，得出结论，并归档决策依据和复查日期。

态度： 语气温和，标准不变。你站在用户这边，正因如此，不能接受“应该没问题”作为答案。质疑含糊的回答，而不是质疑回答的人。

步骤 0 — 确认这是一个当前待做的决策

先恢复进度。 在归档目录（步骤 6）中查找首行以 `

Include only the header fields, Context, and an empty `## Questions` — add the later sections at finalization, so an unfinished file never looks finished. Update the marker whenever the step changes (once triage picks the questions, `then:` lists the ones still to ask) and after every recorded answer, which goes under `## Questions` with its `(unanswered)` tag, if any. Multi-turn answers are recorded as all replies joined with ` / `. The slug names the decision in 3–6 words (`drop-1500-retainers`), which is what a later resume matches on. The file is the session's memory — if the session dies, the next one resumes from it. Don't touch `INDEX.md` until Step 6.

## Step 2 — Triage the question set

Read `references/questions.md` for the full set (the 37signals 38 + house additions, e.g. Q39 opportunity cost) and category mapping. Pick 6–8 based on the decision's characteristics:

**Default 5 (always ask, in this order):**
- Q9 — First instinct? (capture before "thinking" muddies it)
- Q1 — Does this decision actually need to be made?
- Q2 — Is the right person making this decision?
- Q8 — How easily can we reverse it? (skip if Step 1 already settled it — carry that answer over)
- Q3 — A year from now, how will we feel about this?

**Add based on type:**

| If… | Add |
|---|---|
| Reversibility = hard / one-way door | Q14 (is there a wrong decision?), Q17 (knock-on effects), Q34 (principles bent) |
| Time pressure | Q5 (why hesitating?), Q15 (different tomorrow?), Q22 (when do we have to decide?) |
| Multiple people involved | Q21 (someone else's practice rep?), Q27 (would another opinion help?), Q35 (multiple people deciding what one should?) |
| Lots of data / analysis | Q19 (what missing info would change it?), Q26 (data vs gut?), Q9 deepened |
| Recurring decision | Q11 (last time?), Q23 (one-and-done or repeating?) |
| Customer-facing | Q24 (anyone outside depending?), Q25 (customer vs us impact?) |
| Money decision | Q38 (in the end, is this about money?), Q36 (return on effort?), Q39 (what does yes displace?) |
| Big time / focus commitment | Q39 (opportunity cost), Q36 (return on effort?), Q20 (creates or eliminates work?) |
| Stuck / not deciding | Q4 (why hasn't it been made already?), Q10 (what if we don't decide?), Q31 (do you even care?) |

Cap at ~8 questions. More than that turns into analysis paralysis (which is itself one of the things this skill exists to prevent).

When several rows apply and you're over the cap, keep the questions whose answer could **flip the call**; drop ones that would only confirm it. A row that matches the stated reversibility (one-way door → irreversibility row) beats a row you inferred.

Tell the user which questions you picked and why, then proceed.

## Step 3 — Walk through

Ask the questions one at a time. Offer a tight cluster only if the user's answers are coming back specific — clustering a vague answerer just speeds up the vagueness.

**Apply, don't recite.** Fold the user's own facts into each question. Not "What does yes displace?" but "You said the contractor leaves Nov 15 and you'd fund the hire from the ads budget — what happens to signups when ads go to zero?"

**Hold the bar.** When an answer is a non-answer — "should be fine," "we'll figure it out," "probably not a big deal," "I think people want it" — don't record it and move on:
1. Stay on the question and name it: *"I'm going to stay here — that's a hope, not an answer."*
2. Offer 1–2 sharper candidate answers so they're not facing a blank ("Is it 'I'll spend ~10 hrs/week, cutting main-product work in half' or 'I'll only build on weekends'?"), or ask for one specific fact (a number, a name, a date, evidence).
3. If it's still mush after two pushes, record it verbatim and tag it `(unanswered)`. Move on — the tag carries into Step 4.

Candidate answers are prompts, not facts. A number or claim you suggested only enters the archive if the user states it or explicitly adopts it — and then it's quoted as theirs.

Whether sharp or tagged, capture the final answer verbatim — don't paraphrase into corporate-speak.

**Impatient user** ("just tell me yes or no") — applies from the first message on, not just here: don't lecture and don't cave. Use Q28 — *"If you had to decide right this second, what would you do?"* — record it as the Q9 first instinct (if Q9 is already captured, skip Q28), and tell them how many questions are left. Keep the triage announcement to one line.

For Q9 (first instinct), get the answer BEFORE diving into analysis. The point is to surface the gut call so we can later check if "analysis" was just rationalization. Record the gut unchallenged — but if it carries a factual claim ("people want it"), note the claim and push on it at the most relevant later question. A gut call is sacred; the facts it leans on aren't.

## Step 4 — Reach a call

Synthesize the answers into a decision. Options:

- **Decide now** — answers point to a clear call
- **Decide smaller** — break into 2–3 smaller decisions (Q7)
- **Wait** — flag what info / time would change the answer (Q19, Q15)
- **Don't decide** — the decision doesn't need to be made (Q1, Q10)
- **Wrong person** — kick to the right decider (Q2, Q35)

State the call clearly. No hedging.

Before stating it, run three checks:

- **Weak inputs route to Wait or Decide smaller.** If any load-bearing answer is tagged `(unanswered)`, "Decide now" is off the table. The unhedged call is **Wait** (naming the missing fact, per Q19) or **Decide smaller** (the cheapest step that produces that fact — e.g., a waitlist before a build). A Decide-smaller test needs a pass/fail bar from the user ("50 signups in 2 weeks") before you archive it — otherwise it can't fail.
- **Instinct match needs independent support.** If the call matches Q9, check that at least one answer adds a reason the gut didn't already supply. If every answer just restates the instinct, say so — that's the rationalization Q9 exists to catch.
- **Real-decision check.** Name the smart alternative being rejected and the downside being accepted. If you can't name a downside, the user hasn't faced the cost yet — ask before calling it.

As soon as the call (and any pass/fail bar and accepted downside) is agreed, write the `## Decision` section into the working file — don't hold it in chat until finalization.

**Pushback after the call:** re-synthesize only when the user brings new information (a stakeholder's data, a constraint you didn't have) — rerun the real-decision check on the new call, and if the new info answers an `(unanswered)` question, annotate the tag rather than deleting it. If it's just discomfort, hold the call and say why.

## Step 5 — Set the revisit

Pick a revisit date based on when consequences would show up:
- Decisions about tools/processes: 30 days
- Decisions about strategy/positioning: 90 days
- Decisions about hires/partnerships: 90–180 days
- Decisions about products/launches: 30–60 days post-launch

Write what to look for on the revisit ("did MRR move? did the partner ship? do clients still ask for X?").

## Step 6 — Archive

Archives live in `${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/decide/archive/` (create the directory if missing). Never write archives inside the skill's own folder — skill installs and upgrades re-sync from source and wipe anything saved there.

**Migration:** if this skill's folder contains an old `references/decisions-archive/` with user entries, move those files into the archive directory before writing anything new.

Finalize the working file at `<archive dir>/<YYYY-MM-DD>-<slug>.md` (created in Step 1): fill every remaining section and **delete the `` line**. A retroactive log (Step 0) is written here in one go. Template:

```markdown
# Decision: <one-line>

**Date:** YYYY-MM-DD
**Decide by:** <date or "open">
**Reversibility:** easy / hard / one-way door
**Stakes:** low / medium / high

## Context
<1–3 sentences>

## Questions

### <Q3 phrasing>
<answer>

### <Q8 phrasing>
<answer>

(only questions actually applied — heading is the question text, not "Q3")

## Decision
**<the call, stated clearly>**

**Rejected alternative:** <the smart option not chosen>
**Accepted downside:** <the cost the user signed up for>
**Revised from:** <earlier call and what changed it — omit if the call never changed>

## Rationale
<2–3 sentences synthesizing the answers. Quote — don't paraphrase — any answer tagged (unanswered); never upgrade "should be fine" into "low risk.">

## Weak spots
<answers tagged (unanswered) or unsure, verbatim — or "none">

## Expected outcome
<what should be true if this was right, by <date> — built from the user's own signals; don't invent targets they didn't state>

## Revisit
**<YYYY-MM-DD>** — <what to look for>

## Source
Questions adapted from [The 37signals Guide to Making Decisions](https://37signals.com/how-we-make-decisions)

将以下内容追加到 <archive dir>/INDEX.md（若文件不存在则创建）：

- 2026-06-16 — [<decision>](./<filename>.md) — **<call>** — <one-line rationale> — revisit 2026-09-16

如果条目存在薄弱之处，请在决策依据末尾加上 (N weak spots)，以免未来用 grep 搜索时，把基于含糊信息做出的决策误读为有把握的结论。

步骤 7 — 展示

在聊天中展示归档条目，并告知用户归档路径。提供以下选项：

• “要我安排一个 /loop 提醒，在复查日期提醒你吗？”（会使用 loop 技能，在合适的时间触发）
• “要推送到 Notion，作为决策卡片吗？”
• “这之后还需要做后续决策吗？”

未来增强功能

• 自动创建日历事件或 cron 提醒，以便复查（通过 Agent 的调度器，如果有的话，例如 Claude Code 中的 compound-engineering:schedule；否则创建日历事件）
• 可与 business-brainstorm 组合使用 — brainstorm 从 9 个维度评估想法；之后由 decide 正式确定是否继续
• 用 grep 搜索过往决策中的模式（“给我看看我做过哪些标记为‘容易撤回’、但最后没有撤回的决策”）

可组合使用

• business-brainstorm — 对于“我该不该做 X”这类问题，brainstorm → decide 是自然的工作流
• deep-research — 如果决策还在等待信息（Q19），先触发研究
• Memory — 加载 feedback_*.md，查找可能适用的原则（Q34）
• loop / compound-engineering:schedule — 用于复查提醒

质量注意事项

• 不要把 38 个问题都问一遍。 分流的目的就是跳过不适用的问题。问 8 个相关问题 > 问 38 个凑数的问题。
• 不要弱化结论。 “可能是”“倾向于”“也许应该”会让这个技能失去意义。做出选择。输入信息薄弱时，诚实的选择是等待或缩小决策范围，而不是自信地说“是”。
• 也不要降低标准。 不先追问就原样记录“应该没问题”，是最常见的失败。语气温和，标准不变。
• 第一直觉（Q9）至关重要。 务必在分析前记录下来。如果最终结论与第一直觉不同，决策依据必须解释原因 — 这正是这个问题的意义所在。
• 每个决策都要归档，即使很小。 长期累积的价值在于能够用 grep 搜索“去年我对定价做了什么决定” — 因此，即使当下觉得显而易见，也要把它们记下来。