| name | just-ask |
| description | 一次性「只回答」回合——用户是在问问题，不是在派活。用 /just-ask 加问题调用（如「/just-ask 这个测试为什么会偶发失败」）。仅该回合内：只读调查、给出经过分析的回答；不改文件、不跑会改状态的命令、不写计划、不动手修。下一条消息恢复正常。以显式调用为主；用户说「只问一下，别动手」「你就解释，不用修」时同样适用。 |
| metadata | {"short-description":"一次性只回答的提问"} |
just-ask — 是提问，不是派活
这个 skill 浓缩的是用户懒得反复打的那段话：「我只是问问——去调查然后回答我，别动任何东西。」它存在的原因是：一个正处在干活上下文里的 agent，倾向于把每条消息都当成下一个任务，用户只想听个解释，它却开始修了。
作用范围：恰好一个回合
只覆盖调用它的那个回合，之后不再生效。答案发出即用完；下一条消息按正常方式理解，没有需要宣布或退出的「模式」。
单独调用、没带问题时：回一行问「你想问什么」，把下一条消息当作那个问题——仍然只算一个回合。
这个回合是什么
交付物是一个回答——经过分析、以你实际查过的东西为依据。用户是想弄懂一件事，不是想让这件事被处理掉。
问题不是指令，无论它听起来多像在表达不满。「这个函数怎么这么慢？」要的是原因，不是一次优化。如果你觉得修法很明显，这个判断作为一句话写进回答里，而不是作为一次编辑写进文件里。
如果这段对话里本来有活儿在干，这一回合不推进它，也不把问题的言外之意悄悄折回任务里（「那我换个方案」）。回答完就结束回合；任务接下来怎么办，由用户的下一条消息决定。
允许与不允许
允许：读文件、搜索、只读命令（git log、git diff、ls、grep）、只读的子 agent。调查的深度配得上问题本身——只读不等于凭记忆回答。
不允许：编辑或新建文件、会改状态的命令、创建任务或待办清单、进入计划模式、「顺手」把修复先备好。
如果要给出定论确实绕不开一次改动——比如跑一遍构建、打上候选补丁验证——那就不做。给出只读证据能支撑的最好回答，说清你的把握有多大、依据是什么，并指出哪一条命令或改动能一锤定音，交给用户去跑或批准。
回答的形状
先给答案，再给依据，最后说还有什么不确定。说清你查了什么、跳过了什么。
不放「下一步」小节，不留一份等着批准的计划。结尾最多允许一行「你说一声我就修」；绝不以一份计划收尾。
语言：跟随用户的语言。
