当学生说"我参加过一些活动但没整理过"、"帮我把经历录进去"、"我的活动档案是空的"时使用。让学生一口气把记得的活动说出来,直接把这段话拆成结构化的长期事项(角色、组织、起止时间、做了什么、结果、级别),说不清的字段留空标"待补"而不是编,再用一张选择题卡把级别判定与是否重复这类关键项一次问完,然后提案入库。只记录学生真正说出口的内容,级别按事实判定,绝不往高了写。
日本語の概要は準備中です。原文の説明を表示しています。
当学生说"Common App 活动栏写不下"、"这段活动描述超字数了"、"帮我把这几条压到限制内"时使用。先按官方申请表核对当季字符限额,再逐条检查;一次把所有条目量完并直接给出压缩版,只在需要砍掉实质内容时才用选择题问该保哪部分。每改一版都用工具重新数一遍字符,绝不凭感觉说"这样应该够了"。
只压缩,不代写空白。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
把学生写好的活动描述压进 Common App 的字符限额,并保住其中真正有信息量的部分。
两件事必须分清楚:
把学生已经写出来的内容压短,是编辑。在空白处替他写,是代写。 这个 skill 做前者,不做后者。
不适用于 / Not for:
activity-profile-builder 建档admissions-reader| 输入 | 必填 | 说明 |
|---|---|---|
| 学生写的原文 | 是 | 职位 / 组织 / 描述三栏中要处理的那些。没有原文就没有可压缩的东西 |
| 已有长期事项 | 否 | 学生说"就用我系统里那几条"时读出来当原料 |
学生只给了活动名字、没有描述时:不要替他写第一版。 让他先用大白话说清楚做了什么,哪怕三百字也行——压缩需要有东西可压。 这是本 skill 唯一必须停下来等的情况,因为缺的不是偏好而是原料。
| 栏位 | 上限 |
|---|---|
| Position/Leadership description | 50 字符 |
| Organization Name | 100 字符 |
| Please describe this activity | 150 字符 |
| 活动条数 | 10 条 |
易变规则:上表最后核对于 2026-08-21。权威来源是 Common App 官方申请表 https://apply.commonapp.org/(需登录;以申请人当季界面显示的
maxlength和条目上限为准)。 每个申请季首次使用本 skill 时,以及用户界面与上表不一致时,都要重新核对;不得把这里的历史值当成永久规则。 同时确认check_activity_limits使用的上限与当季表单一致。若工具仍是旧值,明确报告配置过期, 在更新工具前不要声称文案已满足当季限制。待核实(2026-09-26 记):有二手资料称 2026-27 申请季活动栏的栏位是否必填、栏位与版块名称有调整, 还没有对照官方表单核实,所以上表没改。下次核对时逐项确认这几点,确认后再改表并更新核对日期; 核实之前不要把这些说法当成已确定的事实告诉学生。
是字符不是词。 表单按 UTF-16 计(同 HTML 的 maxlength),
所以 emoji 一个通常占 2 格——学生肉眼数出来 149,表单可能判 152。
有 check_activity_limits 就由它算;没有时跑下文「没有这些工具时(降级)」里的命令,结果标「降级计算」。
哪种情况都不要凭眼睛数。
拿原文:学生贴进来,或从长期事项里读出来。
一次量完:把所有条目一起传给 check_activity_limits,看每条超了多少、哪一栏超。
不要一条一调,也不要量一条改一条再问一句。
直接给出全部压缩版,按这个优先级砍:
Responsible for、Worked to、Helped to、In charge of 直接删,动词开头very、successfully、significant 几乎都不承载信息18 人、从 12 提到 34、三所学校 —— 这些是最贵的字符,最后才动砍虚词和形容词不需要问,直接做,在"砍掉了"那一行写明。
改完重量:再调一次 check_activity_limits。
每一版都要重新量。 你数不准字符数,这不是谨慎是事实。
只有砍到实质内容时才问:虚词形容词砍完还超,说明装不下的是信息本身。
这时用 ask_user 一次问完(每条一问,最多 4 条一批):
「机器人社这条砍完虚词还差 22 格,下面哪个可以不要?」 拿奖那句 / 带了几个新人那句 / 具体做的技术那句
别自己挑一个砍掉再告诉他。这是他的材料,取舍是他的。
(可选)存回去:学生要求把压缩版写回长期事项时,用 propose_events 出确认卡。
不主动做这一步——活动栏文案和系统里的记录用途不同,多数学生会想分开。
条数超过 10 时,把这件事单独提出来:列出哪几条最弱、为什么,
用 ask_user 多选让学生自己决定砍哪几条。
## <活动名>
**描述**(原 <N> 字符 → 现 <M> 字符,限 150)
原文:<原文>
压缩:<压缩版>
砍掉了:<具体砍了什么,一句话>
全部处理完给一个总览:几条、几条还超、还差几格。
上面的流程按 nestudy 的工具写。在 Claude Code 或其他没有这些工具的环境里,流程、输出格式和边界都不变, 只把工具换成下表的做法,并在回复开头写明「降级:没有 nestudy 工具,字符数由本地命令计算」。
| 工具 | 没有时怎么做 |
|---|---|
check_activity_limits | 跑下面的命令,每一栏跑一次,同一栏的所有条目一次量完。流程里每一处"调 check_activity_limits"都换成它,改完之后的重量也一样;报出的数字标「降级计算」 |
get_events | 请学生把原文直接贴进来,不假装读到了他系统里的记录 |
ask_user | 在对话里直接问:同样攒成一条消息、每问给选项,然后停下等他回答 |
propose_events | 把要存回去的压缩版写成一张 Markdown 卡片(活动名、压缩后的描述),请学生自己保存,不说"已存入" |
一行一条,末尾的参数是这一栏的上限(按上面「限额」表,并先照「易变规则」确认当季值)。 命令先去掉首尾空白,再按 UTF-16 码元计数,与表单同一口径;"码点"是逐个字符数出来的个数, 普通文字和单个 emoji 跟肉眼数一致,两个数不相等就是有占 2 格的字符。
python3 -c 'import sys
lim = int(sys.argv[1])
rows = [s.strip() for s in sys.stdin.read().splitlines() if s.strip()]
for i, s in enumerate(rows, 1):
n = len(s.encode("utf-16-le")) // 2
print(f"{i}: 表单计 {n} / 码点 {len(s)} / 限 {lim} / " + (f"超 {n - lim}" if n > lim else f"剩 {lim - n}"))
print(f"共 {len(rows)} 条" + (",超过 10 条槽位" if len(rows) > 10 else ""))' 150 <<'EOF'
<第一条原文>
<第二条原文>
EOF
一条 149 个字符、结尾带 3 个 emoji 的描述,输出是 1: 表单计 152 / 码点 149 / 限 150 / 超 2。
连命令也跑不了时,把这条命令交给学生在自己电脑上跑,或者请他看表单上的计数器。 拿到数字之前不说"已在限制内",也不凭眼睛估一个数给他。
check_activity_limits(没有这个工具就跑降级命令)。说"这样应该在限制内了"就是失职。ask_user 让他选,不要替他决定。check_activity_limits,不要一条一调| 版本 | 日期 | 变更 | 类型 |
|---|---|---|---|
| 0.2.2 | 2026-09-26 | 声明兼容 claude-code 却没有降级路径:补「没有这些工具时(降级)」,无 check_activity_limits 时用 python3 -c 按 UTF-16 码元计数并标「降级计算」,"不要自己数"改为有工具用工具、无工具跑命令;记下 2026-27 季栏位变化待核实;补配置过期与降级两个用例 | patch |
| 0.2.1 | 2026-09-11 | 为 Common App 易变限额补充核对日期、官方来源与每申请季复核要求;上游限额变化时发布 PATCH | patch |
| 0.2.0 | 2026-08-04 | 转向先产出:一次量完所有条目并直接给出全部压缩版;砍实质内容改用 ask_user 一批问完,不再逐条来回 | minor |
| 0.1.0 | 2026-08-04 | 初始草稿 | minor |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
当学生说"我参加过一些活动但没整理过"、"帮我把经历录进去"、"我的活动档案是空的"时使用。让学生一口气把记得的活动说出来,直接把这段话拆成结构化的长期事项(角色、组织、起止时间、做了什么、结果、级别),说不清的字段留空标"待补"而不是编,再用一张选择题卡把级别判定与是否重复这类关键项一次问完,然后提案入库。只记录学生真正说出口的内容,级别按事实判定,绝不往高了写。
日本語の概要は準備中です。原文の説明を表示しています。
当学生问"招生官会怎么看我的档案"、"我的背景还差什么"、"帮我评估一下现在的申请竞争力"时使用。以顶尖大学招生官的视角通读学生的档案、长期活动与已写下的反思,不问任何前置问题直接产出一份指名道姓的坦诚点评:这份材料的亮点、招生官真实的解读方式、明显的短板与空白、以及接下来最值得做的一到两件事。只读不写,不修改学生的任何数据,也不代写任何申请材料。
日本語の概要は準備中です。原文の説明を表示しています。
当使用者说"帮我填词"、"按这个字数模板写歌词"、"用多Agent对抗式写词"、"这首副歌帮我想几句"时使用,前提是字数骨架和这首歌写什么都已经有了;只有主题、还没定写什么时先用 lyric-concept-builder。拿一份字数骨架和意象系统,派三个 sonnet 子代理按不同路子并行独立起草(场景派 / 口语派 / 意象派),再派一个红队子代理逐句挑毛病,主 Agent 按句裁决拼稿,最后统一辙口与意象。收敛判据卡死:字数用 lyric-doctor 的脚本对模板数、每段同辙、hook 不含陈词、主歌二对主歌一有推进。不抄现有歌词,不替使用者决定这首歌要说什么。
日本語の概要は準備中です。原文の説明を表示しています。
当想知道一段 AI 回答"哪些能直接用、哪些必须先验证、哪些只能当建议"时使用。按声明类型分四级——低风险草稿材料、观点与策略建议、可查证的事实声明、会改变状态的可执行指令——每级配一句默认处置动作;再按影响半径排序,给出最小的下一步检查。可执行类一律标"不能直接执行;先做代码审阅/沙箱测试/回滚准备",其中破坏性或提权的命令排在最前。教的是一套可复用的复查习惯,不是替使用者把所有内容都核实一遍:本 skill 只分级、排序、定处置,要逐条核实走 ai-output-fact-checker,整段代码要做入库体检走 ai-code-onboarding-checklist。
日本語の概要は準備中です。原文の説明を表示しています。
当拿到一段 AI 生成的代码,还没决定要不要信、要不要跑、要不要往上继续加东西时使用。先做一遍客观体检:行数与嵌套深度、有没有测试、有没有硬编码密钥或遗留 TODO、依赖是不是真实存在、有没有危险调用(eval/exec、shell=True、递归删除、反序列化、提权、外发网络,按正文给的 grep 模式逐类查);再给风险评级和下一步动作。老实写明它查不了算法正确性——体检通过不等于代码是对的。回答里文字、事实和代码混在一起时先用 ai-answer-triage 分级;只审相对已有代码的一份改动用 ai-diff-review-protocol。
日本語の概要は準備中です。原文の説明を表示しています。
当 AI 改完代码、要决定这份 diff 放不放行时使用。不逐行精读,按四步走查高风险点——意图是否匹配、有没有碰到边界条件、副作用面有多大、能不能回滚——每步有明确的放过与打回判据。改动文件数、增删行数、动到的迁移/锁文件/CI/配置/鉴权/测试文件和危险 hunk 先由 scripts/diff_risk.py 统计(粘贴进来的 diff 文本也能读,不需要 Git),越过固定阈值时必须人工逐段过。只有口头描述、没有改动内容时不给结论,只列要补的材料。diff 里新写的测试可不可信交给 ai-generated-test-auditor;没有基线的整段新代码走 ai-code-onboarding-checklist。
日本語の概要は準備中です。原文の説明を表示しています。