当学生说"我参加过一些活动但没整理过"、"帮我把经历录进去"、"我的活动档案是空的"时使用。让学生一口气把记得的活动说出来，直接把这段话拆成结构化的长期事项（角色、组织、起止时间、做了什么、结果、级别），说不清的字段留空标"待补"而不是编，再用一张选择题卡把级别判定与是否重复这类关键项一次问完，然后提案入库。
只记录学生真正说出口的内容，级别按事实判定，绝不往高了写。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
把学生记在脑子里的活动经历，整理成结构化的长期事项并存下来。
难点不在存，在于信息是零碎的。学生说"我在机器人社待过两年"， 这句话里缺角色、缺时间、缺具体做了什么、缺结果。
以前的做法是一条一条追问到齐。那样问一段经历要来回七八轮， 多数学生问到第三条就走了。现在的做法是：先把他说的一次性拆成表格， 缺的字段明写「待补」，让他对着表格补——看着空格填，比凭空回想容易得多。
拆解不等于补全。留空是这个 skill 的核心动作，不是失败。
reflection-interviewer不适用于 / Not for：
admissions-readeractivity-list-optimizerreflection-interviewer| 输入 | 必填 | 说明 |
|---|---|---|
| 已有长期事项 | 是 | 先读。避免把同一段经历录两遍 |
| 学生的口述 | 是 | 全部内容都来自这里。一段话就行，不必按字段说 |
| 学生档案 | 否 | 年级用来校验时间跨度是否说得通（10 年级学生说的"三年前"要问清楚） |
读已有：取回现有的长期事项，避免重复录入。
让他一次说完：请他把记得的活动一口气说出来，想到什么说什么， 不用管顺序也不用管完整度。不要给他一张字段清单让他照着填——那是表格不是对话。
直接拆成表格：把他那段话拆进下面六个字段，有什么填什么，没有的写「待补」：
一次问完关键项：调 ask_user（最多 4 问），只问会改变入库结果的：
| 什么时候问 | 怎么问 |
|---|---|
| 级别拿不准 | 「机器人社那个比赛是哪一级？」校内 / 市级或省级 / 全国 / 国际 |
| 疑似与已有记录重复 | 「这段和你已有的『X』是同一件事吗？」是同一件 / 是两件 |
| 时间跨度对不上年级 | 「说的三年前，是 8 年级那会儿吗？」给具体年份选项 |
「待补」的描述与成果不用问。 那些留空入库就行，学生日后想起来再补，
或者交给 reflection-interviewer 慢慢挖。逼他现在编一个出来才是真的损失。
提案：propose_events 逐条提案为 kind: long 的长期事项。
多条一起提，不要每整理完一条就出一张卡。
拆完直接给表格，同一轮附上问题卡：
按你说的整理成这样，空着的是我不知道的，你有空再补：
**<活动名>**
角色：<role> · 组织：<organization> · <startDate> 至 <endDate 或"至今">
做了什么：<description 或「待补」>
成果：<achievements 或「暂无」>
级别：<level>（依据：<一句话>）
级别的判定依据要写出来，学生才有机会纠正。
这是最容易虚高的一项，按事实判定：
学生说"我们那个比赛挺大的"不构成升级依据。拿不准就按低的记，并在问题卡里问清楚。
上面的流程按 nestudy 的工具写。在 Claude Code 或其他没有这些工具的环境里，流程、输出格式和边界都不变， 只把工具换成下表的做法，并在回复开头写明「降级：没有 nestudy 工具，整理好的档案要你自己保存」。
| 工具 | 没有时怎么做 |
|---|---|
get_events | 读不到已有记录：照常拆，同一轮的问题里加一问"这些里有没有你已经录过的"，卡片上注明「未核对是否与已有记录重复」 |
get_profile | 从对话里取年级；没有就跳过时间跨度的校验，不为此追问 |
ask_user | 在对话里直接问：同样最多 4 问、每问给选项，一次问完，然后停下等他回答 |
propose_events | 把拆好的条目按上面的输出格式写成一张 Markdown 卡片（多条放在同一张），请学生自己保存；不说"已录入" |
description 和 achievements 拆不出来就写「待补」/「暂无」入库。
空着比编一个"提升了团队协作能力"诚实，也更有用——
admissions-reader 正是靠这些空白判断该补什么。description 是给自己看的记录，不是 Common App 的 150 字文案。
学生要那个，转 activity-list-optimizer。kind: "long"），之后不再重复取propose_events，不要每问完一条就出一张卡| 版本 | 日期 | 变更 | 类型 |
|---|---|---|---|
| 0.2.1 | 2026-09-26 | 「何时使用」与 reflection-interviewer 几乎同句：补判别句（还没进长期事项、要存事实 → 本 skill；已录过、想聊影响 → 反思）；声明兼容 claude-code 却没有降级路径，补「没有这些工具时（降级）」，已有记录改为问学生、提案改为 Markdown 卡片 | patch |
| 0.2.0 | 2026-08-04 | 转向先产出：改为一次听完口述直接拆成表格、缺项标「待补」，再用 ask_user 只问会改变入库结果的几项；取消"一次一条活动逐项追问" | minor |
| 0.1.0 | 2026-08-04 | 初始草稿 | minor |
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
当学生说"Common App 活动栏写不下"、"这段活动描述超字数了"、"帮我把这几条压到限制内"时使用。先按官方申请表核对当季字符限额，再逐条检查；一次把所有条目量完并直接给出压缩版，只在需要砍掉实质内容时才用选择题问该保哪部分。每改一版都用工具重新数一遍字符，绝不凭感觉说"这样应该够了"。只压缩，不代写空白。
The English summary is being prepared. Showing the original description.
当学生问"招生官会怎么看我的档案"、"我的背景还差什么"、"帮我评估一下现在的申请竞争力"时使用。以顶尖大学招生官的视角通读学生的档案、长期活动与已写下的反思，不问任何前置问题直接产出一份指名道姓的坦诚点评：这份材料的亮点、招生官真实的解读方式、明显的短板与空白、以及接下来最值得做的一到两件事。只读不写，不修改学生的任何数据，也不代写任何申请材料。
The English summary is being prepared. Showing the original description.
当使用者说"帮我填词"、"按这个字数模板写歌词"、"用多Agent对抗式写词"、"这首副歌帮我想几句"时使用，前提是字数骨架和这首歌写什么都已经有了；只有主题、还没定写什么时先用 lyric-concept-builder。拿一份字数骨架和意象系统，派三个 sonnet 子代理按不同路子并行独立起草（场景派 / 口语派 / 意象派），再派一个红队子代理逐句挑毛病，主 Agent 按句裁决拼稿，最后统一辙口与意象。收敛判据卡死：字数用 lyric-doctor 的脚本对模板数、每段同辙、hook 不含陈词、主歌二对主歌一有推进。不抄现有歌词，不替使用者决定这首歌要说什么。
The English summary is being prepared. Showing the original description.
当想知道一段 AI 回答"哪些能直接用、哪些必须先验证、哪些只能当建议"时使用。按声明类型分四级——低风险草稿材料、观点与策略建议、可查证的事实声明、会改变状态的可执行指令——每级配一句默认处置动作；再按影响半径排序，给出最小的下一步检查。可执行类一律标"不能直接执行；先做代码审阅/沙箱测试/回滚准备"，其中破坏性或提权的命令排在最前。教的是一套可复用的复查习惯，不是替使用者把所有内容都核实一遍：本 skill 只分级、排序、定处置，要逐条核实走 ai-output-fact-checker，整段代码要做入库体检走 ai-code-onboarding-checklist。
The English summary is being prepared. Showing the original description.
当拿到一段 AI 生成的代码，还没决定要不要信、要不要跑、要不要往上继续加东西时使用。先做一遍客观体检：行数与嵌套深度、有没有测试、有没有硬编码密钥或遗留 TODO、依赖是不是真实存在、有没有危险调用（eval/exec、shell=True、递归删除、反序列化、提权、外发网络，按正文给的 grep 模式逐类查）；再给风险评级和下一步动作。老实写明它查不了算法正确性——体检通过不等于代码是对的。回答里文字、事实和代码混在一起时先用 ai-answer-triage 分级；只审相对已有代码的一份改动用 ai-diff-review-protocol。
The English summary is being prepared. Showing the original description.
当 AI 改完代码、要决定这份 diff 放不放行时使用。不逐行精读，按四步走查高风险点——意图是否匹配、有没有碰到边界条件、副作用面有多大、能不能回滚——每步有明确的放过与打回判据。改动文件数、增删行数、动到的迁移/锁文件/CI/配置/鉴权/测试文件和危险 hunk 先由 scripts/diff_risk.py 统计（粘贴进来的 diff 文本也能读，不需要 Git），越过固定阈值时必须人工逐段过。只有口头描述、没有改动内容时不给结论，只列要补的材料。diff 里新写的测试可不可信交给 ai-generated-test-auditor；没有基线的整段新代码走 ai-code-onboarding-checklist。
The English summary is being prepared. Showing the original description.