idk-now

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

IDK Now

For when the user doesn't know what to do next. Not a silent autopilot: survey → questions → a concrete, achievable next step that serves the project vision.

Unlike

recon

(tactical: git scope → skill from this pack),

idk-now

is directional: recover purpose, then pick the smallest useful move — which may be a DecisionNerd skill, DocSlime / ProductFeeling / Impeccable, or a vendored skill in this repo.

适用于用户不知道下一步做什么的场景。不是静默的自动驾驶：调查 → 提问 → 给出服务于项目愿景的具体、可实现的下一步。

与

recon

（战术性：git范围 → 从本技能包选技能）不同，

idk-now

是方向性的：先找回目标，然后选择最小的有用动作 — 可能是DecisionNerd技能、DocSlime / ProductFeeling / Impeccable，或者本仓库中的vendored技能。

Operating contract

操作契约

Shared by every DecisionNerd/dev-skills skill. Canonical copy:

handbook/concepts/14-operating-contract.md

Define done first. Before using tools, write the finish line in one or two lines: the acceptance criteria (existing issue AC, BDD scenarios, tests, or contract when they exist; otherwise propose them and say where they should live) and the evidence that will prove them. Re-check it before reporting done. Never report done on work you did not verify.
Requested scope sets the finish line. A question ("is it ready?", "why is it broken?", "what next?") ends with the answer and a
```
Next:
```
line naming the exact next invoke. An outcome request ("fix", "finish", "land", "#42") continues through the chain (diagnose → fix → test → check-readiness → merge-it) until the outcome or a real blocker. Do not end a turn with "Do you want me to…?" for in-scope, in-repo work.
Stop only for real blockers. Stop and ask only when you cannot continue without the user, or before: deleting data or unmerged work, force-push or history rewrite, changing anything outside this repository (GitHub objects, deployments, live data, production or paid resources, external services), or leaving the requested scope, unless the user's request already named that exact action. Keep the harness's permission prompts for risky commands. Otherwise keep going and put status notes in the same message as the next action.
Ask well, once. For a genuine question use the harness's structured question tool when it has one (Claude Code:
```
AskUserQuestion
```
; Codex:
```
request_user_input
```
when the current mode supports it) with concrete options; otherwise plain text with numbered options. Treat the answer as settled; do not re-open earlier verdicts, plans, or answers unless asked.
Fan out when work is parallel. Use subagents for independent reads (repo survey, evidence gathering, per-option research, per-area audits) and for independent verification (a reviewer that did not write the change). Writes stay single-owner per path set and sequential. Brief every child with goal, done-when, constraints, must-not, and return shape; verify each child's result before consolidating. Use Claude Code's
```
Workflow
```
tool only for orchestration across many subagents that truly needs it; it is expensive.
Pick the model tier per child; defer to routing config. If the harness or user config already routes subagents (Claude Code
```
CLAUDE_CODE_SUBAGENT_MODEL
```
or a CLAUDE.md rule; Codex
```
agents.default_subagent_model
```
or a role's
```
agents.<name>.config_file
```
; Cursor a custom subagent's
```
model:
```
frontmatter), follow it and do not pass a model. Otherwise: mechanical search or inventory → fast/cheap (Claude Code
```
haiku
```
); implementation and evidence gathering → mid (
```
sonnet
```
); planning, review, adversarial verification → top (
```
opus
```
or
```
fable
```
). In Claude Code set it with the
```
Agent
```
tool
```
model
```
param or agent frontmatter
```
model:
```
; in Codex pass a spawn model or set
```
model
```
in the role's config file; in Cursor set
```
model:
```
(default
```
inherit
```
) in
```
.cursor/agents/*.md
```
. Where the harness cannot choose, children inherit the parent model or the harness picks one (Cursor's built-in Explore/Bash/Browser subagents pick per subtask); say which in the status note.
Keep a checklist on long runs. For more than about five steps or work that crosses skills, keep
```
TASKS.md
```
at the repo root and tick items as they finish. Do not commit it unless the repo already tracks one.
Close every run with three headings.
```
Blocked on me
```
(the one genuine question or blocker, else "none");
```
Changed
```
(files, commits, GitHub objects, deploys, else "nothing");
```
Found
```
(evidence, verdict, and
```
Next: <exact invoke>
```
).

所有DecisionNerd/dev-skills技能共同遵守。标准副本：

handbook/concepts/14-operating-contract.md

。

先定义完成标准。 使用工具之前，用一两行写出终点：验收标准（现有issue的AC、BDD场景、测试或契约，若存在；否则提出验收标准并说明存放位置）以及验证完成的证据。报告完成前重新检查。永远不要对未验证的工作报告完成。
请求的范围决定终点。 一个问题（"准备好了吗？"、"为什么坏了？"、"下一步是什么？"）以答案和一行
```
Next:
```
结尾，指明确切的下一次调用。一个结果请求（"修复"、"完成"、"上线"、"#42"）会沿着链条持续推进（诊断 → 修复 → 测试 → 就绪检查 → 合并），直到达成结果或遇到真正的阻塞。对于范围内、仓库内的工作，不要在回合结束时问"你想让我…吗？"。
仅在遇到真正阻塞时停止。 只有在没有用户就无法继续，或者即将执行以下操作时才停下来询问：删除数据或未合并的工作、强制推送或历史重写、修改本仓库之外的任何内容（GitHub对象、部署、实时数据、生产或付费资源、外部服务）、超出请求范围，除非用户的请求已经明确指定了该操作。对于风险命令，保留运行框架的权限提示。否则继续推进，并在同一条消息中附上状态说明和下一步操作。
一次问清楚。 对于真正的问题，当运行框架有结构化提问工具时使用它（Claude Code：
```
AskUserQuestion
```
；Codex：在当前模式支持时用
```
request_user_input
```
），并提供具体选项；否则使用带编号选项的纯文本。将答案视为最终决定；不要重新开启之前的结论、计划或答案，除非被要求。
工作可并行时分派执行。 使用子Agent进行独立读取（仓库调查、证据收集、逐选项研究、逐领域审计）和独立验证（未编写变更的评审者）。写入操作在每个路径集上保持单一所有者且顺序执行。为每个子Agent简要说明目标、完成条件、约束、禁止事项和返回格式；在合并前验证每个子Agent的结果。仅当确实需要编排大量子Agent时才使用Claude Code的
```
Workflow
```
工具；它成本很高。
为每个子Agent选择模型层级；遵循路由配置。 如果运行框架或用户配置已经为子Agent配置了路由（Claude Code的
```
CLAUDE_CODE_SUBAGENT_MODEL
```
或CLAUDE.md规则；Codex的
```
agents.default_subagent_model
```
或角色的
```
agents.<name>.config_file
```
；Cursor自定义子Agent的
```
model:
```
frontmatter），遵循配置，不要传递模型参数。否则：机械搜索或盘点 → 快速/低成本（Claude Code
```
haiku
```
）；实现和证据收集 → 中等（
```
sonnet
```
）；规划、评审、对抗性验证 → 顶级（
```
opus
```
或
```
fable
```
）。在Claude Code中通过
```
Agent
```
工具的
```
model
```
参数或Agent frontmatter的
```
model:
```
设置；在Codex中传递生成模型或在角色的配置文件中设置
```
model
```
；在Cursor中在
```
.cursor/agents/*.md
```
中设置
```
model:
```
（默认
```
inherit
```
）。如果运行框架无法选择，子Agent将继承父模型或由运行框架选择（Cursor内置的Explore/Bash/Browser子Agent会根据子任务选择）；在状态说明中注明使用的模型。
长时间运行时保留检查清单。 对于超过大约五个步骤或跨技能的工作，在仓库根目录保留
```
TASKS.md
```
，完成一项勾选一项。除非仓库已经跟踪该文件，否则不要提交它。
每次运行结束用三个标题收尾。
```
Blocked on me
```
（一个真正的问题或阻塞，否则为"无"）；
```
Changed
```
（文件、提交、GitHub对象、部署，否则为"无"）；
```
Found
```
（证据、结论和
```
Next: <确切的调用命令>
```
）。

Commands

命令

Command	What it does
(none) / `guide`	Full flow: survey → questions → recommend
`quick`	Short survey + 1–2 questions + one primary recommend (less chat)
`vision`	Focus on recovering/stating why the project exists, then one goal
`skills`	Inventory available skills (pack + DocSlime/PF/Impeccable + vendored) without full coaching
`help` / `library`	List commands

Optional free-text after the command is a hint (“shipping feels stuck”, “docs are a mess”).

命令	作用
(无) / `guide`	完整流程：调查 → 提问 → 推荐
`quick`	简短调查 + 1–2个问题 + 一个主要推荐（更少对话）
`vision`	聚焦于恢复/明确项目存在的意义，然后给出一个目标
`skills`	盘点可用技能（技能包 + DocSlime/PF/Impeccable + vendored），无需完整指导
`help` / `library`	列出命令

命令后的可选自由文本是提示（"发布感觉卡住了"、"文档一团糟"）。

Routing

路由

No args / “idk” / “what now” →
```
guide
```
.
First word is a command → that command.
Clear “just list skills” →
```
skills
```
; “why does this project exist?” →
```
vision
```
.

Read-only by default. Do not implement, open PRs, or mutate GitHub until the user accepts a follow-up skill/action.

无参数 / "idk" / "现在做什么" →
```
guide
```
。
第一个词是命令 → 执行该命令。
明确"只列出技能" →
```
skills
```
；"这个项目为什么存在？" →
```
vision
```
。

默认只读。在用户接受后续技能/操作之前，不要实现功能、打开PR或修改GitHub内容。

Flow (

guide

/ default)

流程（

guide

/ 默认）

Follow references/flow.md. Summary:

遵循 references/flow.md。摘要如下：

1. Brief survey (read-only, keep it short)

1. 简要调查（只读，保持简短）

Environment — cwd, OS hints if relevant, whether this is a worktree, active branch, dirty/clean.

Repo — remote, default branch, package/stack signals, open PR on branch if any.

Docs / vision signals — skim in order until you can state a candidate purpose (do not dump files):

```
README.md
```
,
```
AGENTS.md
```
,
```
CLAUDE.md
```
,
```
PRODUCT.md
```
,
```
VISION.md
```
,
```
docs/
```
(esp. DocSlime-style PRODUCT / DESIGN / REQUIREMENTS / strategy)
```
.productfeeling/
```
,
```
FEELING.md
```
if present
Landing/marketing copy or
```
apps/web
```
hero only if docs are empty

Git history — recent commits/themes (

git log --oneline -15

), ahead/behind, abandoned branches if obvious.

Skills present — see references/skill-universe.md.

Write a tight Survey block (bullet list, not an essay). If vision is unclear, say so explicitly. For a large repo (many packages, deep docs), fan out environment/repo/docs/git reads to parallel read-only subagents (fast tier); cap total file reads per the survey budget in references/flow.md.

环境 — cwd、相关OS提示、是否为worktree、当前分支、dirty/clean。

仓库 — 远程地址、默认分支、包/技术栈信号、当前分支是否有打开的PR（若有）。

文档 / 愿景信号 — 按顺序浏览，直到你能说出一个候选的项目目的（不要堆砌文件内容）：

```
README.md
```
、
```
AGENTS.md
```
、
```
CLAUDE.md
```
、
```
PRODUCT.md
```
、
```
VISION.md
```
、
```
docs/
```
（尤其是DocSlime风格的PRODUCT / DESIGN / REQUIREMENTS / strategy）
```
.productfeeling/
```
、
```
FEELING.md
```
（如果存在）
仅当文档为空时，查看落地页/营销文案或
```
apps/web
```
的首页内容

Git历史 — 最近的提交/主题（

git log --oneline -15

）、领先/落后提交数、明显的废弃分支。

现有技能 — 参见 references/skill-universe.md。

写一个简洁的调查块（项目符号列表，不要写成散文）。如果愿景不明确，要明确说明。对于大型仓库（大量包、深层文档），将环境/仓库/文档/git的读取任务分派给并行的只读子Agent（快速层级）；按照 references/flow.md 中的调查预算限制总文件读取数。

2. Guided questions

2. 引导式提问

Ask 3–5 questions max, prefer multiple-choice when possible. Use the harness's structured question tool (Claude Code:

AskUserQuestion

) with the options listed below; plain text with numbered options as fallback. Cover:

Horizon — today / this week / this milestone / vague “make it better”
Constraint — time, risk, “must not break prod”, solo vs team
Energy — ship / fix / clarify / design / clean / explore
Blocker feel — unknown next, too many options, broken thing, missing vision, waiting on people
Optional: user type they care about right now (if product-shaped)

Do not interrogate if answers are already in the user message — skip asked questions.

For

quick

: at most 2 questions, or zero if enough signal.

最多问3-5个问题，尽可能用选择题。使用运行框架的结构化提问工具（Claude Code：

AskUserQuestion

）并列出以下选项； fallback为带编号选项的纯文本。覆盖：

时间范围 — 今天 / 本周 / 本次里程碑 / 模糊的"让它变得更好"
约束条件 — 时间、风险、"不能破坏生产环境"、单人 vs 团队
精力方向 — 发布 / 修复 / 澄清 / 设计 / 清理 / 探索
阻塞感受 — 不知道下一步、选项太多、东西坏了、缺少愿景、在等人
可选：他们当前关心的用户类型（如果是产品相关的）

如果用户消息里已经有答案，就不要追问 — 跳过已经回答的问题。

对于

quick

模式：最多2个问题，如果信号足够也可以不问。

3. Goal → next steps

3. 目标 → 下一步

From survey + answers:

State Project vision (1–2 sentences) — inferred or confirmed; flag confidence low/med/high.
State Achievable goal for this session/week — small enough to finish; clearly advances the vision (not busywork).
Rank Next steps (primary + 2 alternates), each with:
- exact skill invoke (
```
issues create …
```
  ,
```
productfeeling audit …
```
  ,
```
$impeccable polish
```
  ,
```
docslime-fill
```
  ,
```
recon issue #n
```
  , …)
- one-line why it serves the goal/vision
Close with three headings:
```
Blocked on me
```
(none, or the one real question),
```
Changed
```
(nothing — read-only),
```
Found
```
: vision confidence, achievable goal. Next:
```
<exact primary invoke>
```
.

根据调查 + 回答：

说明项目愿景（1-2句话）— 推断或确认的；标注置信度为低/中/高。
说明本次会话/本周的可实现目标 — 小到可以完成；明确推进愿景（不是无用功）。
排序下一步（主要方案 + 2个备选），每个都包含：
- 确切的技能调用（
```
issues create …
```
  、
```
productfeeling audit …
```
  、
```
$impeccable polish
```
  、
```
docslime-fill
```
  、
```
recon issue #n
```
  、…）
- 一句话说明为什么它服务于目标/愿景
用三个标题收尾：
```
Blocked on me
```
（无，或者一个真正的问题）、
```
Changed
```
（无 — 只读）、
```
Found
```
：愿景置信度、可实现目标。Next:
```
<确切的主要调用命令>
```
。

Skill universe (must consider)

技能范围（必须考虑）

When recommending, search across:

This pack (DecisionNerd/dev-skills) — agents, architect-it, check-readiness, diagnose-bug, document-it, fix-it, idk-now, issues, kiss, merge-it, milestones, observe-it, pulls, recon, refactor-it, repos, research-it, test-it, tidy-up, troubleshoot-app, …

DocSlime —

docslime-init

docslime-fill

docslime-adr

docslime-kiss

docslime-install

(product docs tree)

ProductFeeling — feeling/emotion-aware product design (
```
productfeeling
```
/
```
/productfeeling
```
)
Impeccable — frontend craft (
```
impeccable
```
craft/shape/audit/polish/…)
Vendored / local skills in the repo space — discover under
```
.agents/skills/
```
,
```
.cursor/skills/
```
,
```
skills/
```
,
```
vendor/**/skills
```
,
```
packages/**/skills
```
, or paths
```
AGENTS.md
```
names. Prefer repo-vendored copies when present.

Details and routing heuristics: references/skill-universe.md.

Prefer the smallest skill that unblocks the achievable goal. Do not recommend a swarm of skills.

推荐时，搜索以下范围：

本技能包（DecisionNerd/dev-skills） — agents、architect-it、check-readiness、diagnose-bug、document-it、fix-it、idk-now、issues、kiss、merge-it、milestones、observe-it、pulls、recon、refactor-it、repos、research-it、test-it、tidy-up、troubleshoot-app、…

DocSlime —

docslime-init

、

docslime-fill

、

docslime-adr

、

docslime-kiss

、

docslime-install

（产品文档树）

ProductFeeling — 情绪感知的产品设计（
```
productfeeling
```
/
```
/productfeeling
```
）
Impeccable — 前端工艺（
```
impeccable
```
craft/shape/audit/polish/…）
仓库空间内的vendored / 本地技能 — 在
```
.agents/skills/
```
、
```
.cursor/skills/
```
、
```
skills/
```
、
```
vendor/**/skills
```
、
```
packages/**/skills
```
或
```
AGENTS.md
```
指定的路径下查找。如果存在仓库vendored的副本，优先使用。

详细信息和路由启发式规则：references/skill-universe.md。

优先选择能解锁可实现目标的最小技能。不要推荐一大堆技能。

vision

vision

模式

Survey docs + README + recent commits only; ask at most two questions if purpose is ambiguous; output vision statement + one achievable goal + one skill. Skip full skill inventory unless needed.

仅调查文档 + README + 最近提交；如果目的不明确，最多问两个问题；输出愿景陈述 + 一个可实现目标 + 一个技能。除非必要，否则跳过完整的技能清单。

skills

skills

模式

Inventory only: DecisionNerd pack from this repo’s

skills/*/SKILL.md

(or installed list), plus DocSlime / ProductFeeling / Impeccable if installed or vendored, plus any other vendored skills found. Table: name | one-line job | installed?.

仅盘点：来自本仓库

skills/*/SKILL.md

的DecisionNerd技能包（或已安装列表），加上已安装或vendored的DocSlime / ProductFeeling / Impeccable，以及找到的任何其他vendored技能。表格：名称 | 一句话职责 | 是否已安装？。

Related skills

Grounding

基础依据

This skill’s TTPs are grounded in current engineering baselines (DORA, GitHub Docs, Fowler/Beck, Google SRE & SWE book, OpenTelemetry, OWASP LLM / NIST AI RMF, Diátaxis — see handbook

sources.md

Under uncertainty, frame the goal before options (small batches / Beck clarity). Survey → vision-tied next skill beats thrashing tools.

Handbook card:

handbook/practices/idk-now.md

本技能的TTPs基于当前工程基线（DORA、GitHub Docs、Fowler/Beck、Google SRE & SWE book、OpenTelemetry、OWASP LLM / NIST AI RMF、Diátaxis — 参见手册

sources.md

）。

在不确定的情况下，先确定目标再给出选项（小批量 / Beck清晰原则）。调查 → 与愿景绑定的下一个技能优于盲目折腾工具。

手册卡片：

handbook/practices/idk-now.md

。

idk-now

Original

Translation

IDK Now

IDK Now

Operating contract

操作契约

Commands

命令

Routing

路由

Flow (
`guide`
/ default)

流程（
`guide`
/ 默认）

1. Brief survey (read-only, keep it short)

1. 简要调查（只读，保持简短）

2. Guided questions

2. 引导式提问

3. Goal → next steps

3. 目标 → 下一步

Skill universe (must consider)

技能范围（必须考虑）

`vision`

`vision`
模式

`skills`

`skills`
模式

Related skills

相关技能

Grounding

基础依据

idk-now

Original

Translation

IDK Now

IDK Now

Operating contract

操作契约

Commands

命令

Routing

路由

Flow (guide / default)

流程（guide / 默认）

1. Brief survey (read-only, keep it short)

1. 简要调查（只读，保持简短）

2. Guided questions

2. 引导式提问

3. Goal → next steps

3. 目标 → 下一步

Skill universe (must consider)

技能范围（必须考虑）

vision

vision 模式

skills

skills 模式

Related skills

相关技能

Grounding

基础依据

Flow (
`guide`
/ default)

流程（
`guide`
/ 默认）

`vision`

`vision`
模式

`skills`

`skills`
模式