当学生说"Common App 活动栏写不下"、"这段活动描述超字数了"、"帮我把这几条压到限制内"时使用。先按官方申请表核对当季字符限额,再逐条检查;一次把所有条目量完并直接给出压缩版,只在需要砍掉实质内容时才用选择题问该保哪部分。每改一版都用工具重新数一遍字符,绝不凭感觉说"这样应该够了"。只压缩,不代写空白。
日本語の概要は準備中です。原文の説明を表示しています。
当学生说"申请季怎么安排"、"ED 之前要做完哪些事"、"帮我排一下今年的申请节点"时使用。从各校截止日往回推出整个申请季的时间线:推荐信什么时候要请老师、文书初稿什么时候出、标化什么时候送分,全部换算成北京时间直接排出来落进日程,只把"走哪一轮"这类只有本人能定的岔路口做成选择题一次问完。
截止日只用核实过的,本地数据没核实的一律让学生去官网确认后再排。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
从各校的截止日往回推,排出整个申请季的节点,并落进学生的日程。
申请季真正杀人的不是文书难写,是有些事必须提前很久启动: 推荐信要给老师留几周、送分要留处理时间、成绩单要走学校流程。 学生通常在 10 月底才发现这些事该在 9 月做。
不适用于 / Not for:
resolve_deadline(没有这个工具就只跑下文降级一节的换算命令),不必起 skillactivity-list-optimizeradmissions-reader| 输入 | 必填 | 说明 |
|---|---|---|
| 申请清单 | 是 | 哪些学校、走哪一轮。清单空着才问,问就用 ask_user 给选项 |
| 各校截止日 | 是 | 优先用申请清单里已有的;没有再查 get_school_requirements |
| 学生档案 | 否 | 年级与课程体系,用来判断标化与成绩单的节奏 |
get_school_requirements 返回的学校分两种:
verified: true —— 有 deadlines,核对过官网,可以直接用verified: false —— 没有 deadlines 字段,本地一个日期都没存看到 verified: false 时:
requirementsUrl 给学生,请他去官网抄下截止日再回来propose_application 记进申请清单,这样下次不用再查返回里的 unverifiedWarning 要转述给学生,不要私自吞掉。
读清单:get_applications 拿到已有申请(返回里已经带好北京时间与倒计时,不必再算一遍)。
补缺口:清单里没有的学校查 get_school_requirements;查不到或未核实的按上一节处理。
换算:所有截止日过 resolve_deadline 换成北京时间。
warnings 里凡是提到夏令时切换的,必须转述——11 月初 ET 从 EDT 切回 EST,
北京时间会整整差一小时,而 ED/EA 的截止日正好压在那几天。
直接倒推排完,对每个已核实的截止日往回排。
下面的提前量是保守的排程默认值,不是平台承诺或统一行业标准;学生、推荐人和学校的实际要求优先。 最近核对:2026-09-11。流程依据: Common App — First-year application guide; College Board — Sending SAT scores。 这些来源用于核对申请材料与送分流程,不规定下表的统一提前天数;表中区间是本 skill 的保守经验值。 每个申请季开始前应复核这些来源和目标学校官网;若上游流程变化影响默认提前量,更新核对日期并发布 PATCH 版本。
| 节点 | 相对截止日 | 为什么这么早 |
|---|---|---|
| 请老师写推荐信 | 提前 4–6 周 | 老师同时被十几个学生请托,最晚的那批质量最差 |
| 主文书定稿 | 提前 3–4 周 | 留出补充文书的时间 |
| 补充文书初稿 | 提前 2–3 周 | 每校一套,数量比想象中多 |
| 送分 / 成绩单 | 提前 2–3 周 | 走机构与学校流程,不受你控制 |
| 全部材料自查 | 提前 3–5 天 | 活动栏字符数、各篇文书字数对照上限再核一遍(活动栏交给 activity-list-optimizer) |
不要问"要不要我排"、"这个节奏可以吗"——把时间线排出来给他看,他会直接说哪里不合适。
合并同类:多所学校共用的节点(主文书定稿、送分)合成一条,按最早的那个截止日排。 十所学校排出十条"主文书定稿"是噪音。
只问必须他定的:清单为空、或某校的轮次不明时,用 ask_user 一次问完,给选项:
「<校名> 你打算走哪一轮?」ED / EA / RD / 还没想好
ED 是有约束力的承诺,这个决定只能他自己做。 但也仅此而已—— 提前量、节点粒度、要不要留缓冲这些不用问,按上表排就是。
查冲突:节点撞上已有的考试或大考月份时点出来,把取舍摆给他。
提案:propose_events 提案为短期事项,category 用 application,
这样它们会和申请截止日排在同一条时间线上。
## 截止日(北京时间)
| 学校 | 轮次 | 当地 | 北京时间 | 剩余 | 来源 |
|---|---|---|---|---|---|
| <校名> | ED | 11-02 23:59 EST | 11-03 12:59 | 90 天 | 已核实 / **待你确认** |
<夏令时或其他 warning 的转述>
## 倒推节点
- <日期> —— <动作>(为了 <哪个截止日>)
...
## 需要你先确认的
- <校名>:本地没有核实过的截止日,去 <requirementsUrl> 抄一下告诉我
然后调 propose_events 出卡。待确认的学校不要排节点——建在假日期上的时间线比没有更危险。
已核实的那几所照排,不要因为有一所待确认就整份都不给。
上面的流程按 nestudy 的工具写。在 Claude Code 或其他没有这些工具的环境里,流程、输出格式和边界都不变, 只把工具换成下表的做法,并在回复开头写明「降级:没有 nestudy 工具,截止日由你从官网抄来,时区由本地命令换算」。
| 工具 | 没有时怎么做 |
|---|---|
get_applications | 请学生贴出申请清单:学校、轮次,以及官网写的截止日期、时间和时区 |
get_school_requirements | 没有核实过的本地数据:每所学校都按上文 verified: false 那一路走,请学生去该校官网抄下截止日再排,来源一栏写「官网,学生抄录」。学生凭印象报的日期同样算待确认,不排节点 |
resolve_deadline | 跑下面的命令,所有截止日一次算完;结果标「降级计算」,打印出的警告和「夏令时切换」行照样转述 |
get_test_dates、get_profile | 请学生说出已经定下的考试日期、年级和课程体系;他没说的不排、不假设 |
ask_user | 在对话里直接问:同样一次问完、每问给选项,然后停下等他回答 |
propose_events、propose_application | 把倒推节点(日期、动作、为了哪个截止日)和已确认的截止日写成一张 Markdown 卡片,请学生自己存进日历;不说"已加入日程" |
每行一个截止日:日期 时间 时区 标签。时区写 IANA 名(ET → America/New_York,CT → America/Chicago,
MT → America/Denver,PT → America/Los_Angeles,英国 → Europe/London);官网没写具体时间的按 23:59 算,
并注明这是默认值。第一个参数是今天(北京时间)的日期,省略就取本机当天。需要 Python 3.9 以上。
python3 -c 'import sys
from datetime import datetime, timedelta, timezone
from zoneinfo import ZoneInfo
bj, utc = ZoneInfo("Asia/Shanghai"), timezone.utc
today = datetime.fromisoformat(sys.argv[1]).date() if len(sys.argv) > 1 else datetime.now(bj).date()
gap = lambda x: f"北京 = 当地 {(x.astimezone(bj).utcoffset() - x.utcoffset()) / timedelta(hours=1):+g} 小时"
for line in sys.stdin.read().splitlines():
if not line.strip(): continue
d, t, z, *label = line.split()
tz = ZoneInfo(z)
raw = datetime.fromisoformat(f"{d} {t}").replace(tzinfo=tz)
loc = raw.astimezone(utc).astimezone(tz)
b = loc.astimezone(bj)
n = (b.date() - today).days
print(" ".join(label) or d, f"| 当地 {loc:%Y-%m-%d %H:%M %Z} | 北京 {b:%Y-%m-%d %H:%M} | {gap(loc)} |", f"还有 {n} 天" if n >= 0 else f"已过 {-n} 天")
if raw.replace(fold=1).utcoffset() != raw.utcoffset(): print(" 警告:这个当地时间落在夏令时切换的那一小时里(不存在或出现两次),先向学校确认")
u = loc.astimezone(utc).replace(minute=0, second=0, microsecond=0)
prev = (u - timedelta(hours=505)).astimezone(tz)
for h in range(-504, 505):
x = (u + timedelta(hours=h)).astimezone(tz)
if x.utcoffset() != prev.utcoffset(): print(f" 夏令时切换:{x:%Y-%m-%d %H:%M} 起 {prev.tzname()}→{x.tzname()},在截止之" + ("前" if h <= 0 else "后") + f";切换前 {gap(prev)},切换后 {gap(x)}")
prev = x' 2026-08-04 <<'EOF'
2026-11-02 23:59 America/New_York Duke ED
EOF
上例的输出(命令会检查截止时刻前后 21 天内的夏令时切换):
Duke ED | 当地 2026-11-02 23:59 EST | 北京 2026-11-03 12:59 | 北京 = 当地 +13 小时 | 还有 91 天
夏令时切换:2026-11-01 01:00 起 EDT→EST,在截止之前;切换前 北京 = 当地 +12 小时,切换后 北京 = 当地 +13 小时
连命令也跑不了时,把命令交给学生自己运行;拿到结果之前,截止日表格里的北京时间一栏写「待换算」, 不填估出来的时间。
resolve_deadline 就全部走它;没有时跑下文「没有这些工具时(降级)」里的命令,结果标「降级计算」。
夏令时提示(工具的 warnings,或命令打印的警告与「夏令时切换」行)一律转述。ask_user 问,不要按"多数人会选 ED"排。get_applications 一次读齐,它已经带了换算结果;只有清单外的学校才另外调 resolve_deadlineget_school_requirements 按平台或校名取,不要无参数拉全量| 版本 | 日期 | 变更 | 类型 |
|---|---|---|---|
| 0.2.2 | 2026-09-26 | 声明兼容 claude-code 却没有降级路径:补「没有这些工具时(降级)」,截止日改由学生从官网抄录、时区用 zoneinfo 命令换算并标「降级计算」、写入改为 Markdown 卡片;"不自己算时区"改为有工具用工具、无工具跑命令;自查节点去掉学生在日程里用不了的 check_activity_limits、count_essay_words,改写成动作 | patch |
| 0.2.1 | 2026-09-11 | 标明倒推提前量是经验默认值,补充核对日期、流程来源与上游变化时发布 PATCH 的维护约定 | patch |
| 0.2.0 | 2026-08-04 | 转向先产出:已核实的学校直接排完整时间线,不再等所有信息齐;轮次选择改用 ask_user 一次问完 | minor |
| 0.1.0 | 2026-08-04 | 初始草稿 | minor |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
当学生说"Common App 活动栏写不下"、"这段活动描述超字数了"、"帮我把这几条压到限制内"时使用。先按官方申请表核对当季字符限额,再逐条检查;一次把所有条目量完并直接给出压缩版,只在需要砍掉实质内容时才用选择题问该保哪部分。每改一版都用工具重新数一遍字符,绝不凭感觉说"这样应该够了"。只压缩,不代写空白。
日本語の概要は準備中です。原文の説明を表示しています。
当学生说"我参加过一些活动但没整理过"、"帮我把经历录进去"、"我的活动档案是空的"时使用。让学生一口气把记得的活动说出来,直接把这段话拆成结构化的长期事项(角色、组织、起止时间、做了什么、结果、级别),说不清的字段留空标"待补"而不是编,再用一张选择题卡把级别判定与是否重复这类关键项一次问完,然后提案入库。只记录学生真正说出口的内容,级别按事实判定,绝不往高了写。
日本語の概要は準備中です。原文の説明を表示しています。
当学生问"招生官会怎么看我的档案"、"我的背景还差什么"、"帮我评估一下现在的申请竞争力"时使用。以顶尖大学招生官的视角通读学生的档案、长期活动与已写下的反思,不问任何前置问题直接产出一份指名道姓的坦诚点评:这份材料的亮点、招生官真实的解读方式、明显的短板与空白、以及接下来最值得做的一到两件事。只读不写,不修改学生的任何数据,也不代写任何申请材料。
日本語の概要は準備中です。原文の説明を表示しています。
当使用者说"帮我填词"、"按这个字数模板写歌词"、"用多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。
日本語の概要は準備中です。原文の説明を表示しています。