Agent Skills

---

name: light-idea-generation

description: Light 科研主线第 3 步·提 idea:从模糊方向/数据/文献**结构化发散**(激发算子系统生成,不是泛泛头脑风暴) → 产**值得做且做得成的分层候选 idea**(moonshot 冲刺/solid 稳妥/safe 保底),每个必答**为什么值得做·创新点· 比现有强在哪·解决什么具体问题·能投什么层次**,且**提出时就自带撞车前置自查**(最像的前作+delta,吃上游 literature-search 领域地图)。何时用:用户问"这个方向/数据能做什么" / 要创新点·研究思路·选题·突破口 / 帮我想 idea / brainstorm research ideas / 这 idea 行不行(先生成再送 idea-critique 严审)。触发词:提 idea / 想 idea / 创新点 / 研究思路 / 选题 / 突破口 / 差异化 / 这个方向能做什么 / 有什么可做的 / brainstorm / research idea / ideation / 新点子 / 立项。核心纪律:**不下 novel/无创新的最终判决**(那是 idea-critique 的 critical 门,生成端只产撞车 warn 信号);用**证据根→机制/假设 delta→信息增益→最小判别实验**谱系约束候选； 过 **innovation_engine 反拼接门**，把原创来源分型(新问题/新机制/新测量/新数据/新理论/跨域迁移/工程增量)与 claim 强度绑定； 数量/七角度只作 advisory，机制多样性才是硬门。

---

name: light-literature-search

description: Light 科研主线第 1 步·文献调研:在线多源检索(OpenAlex/arXiv/Crossref/Europe PMC/DOAJ,全程免 key)→ 产出**不是论文列表,是可直接喂 idea 的"领域地图"**:近三年前沿 + 经典奠基 + 跨领域方法移植**三层分别 检索分别排序**,合成研究脉络 + 方法谱系 + 未解问题地图,揪出**最像你设想的那一篇**→喂 idea-critique 撞车预警,诚实标检索覆盖度。何时用:调研某方向 / 找综述 / 了解某领域有哪些工作 / 提 idea 前摸清前作 / 收集中英文论文·专利·标准·数据集·开源·竞赛方案·行业报告。触发词:文献调研 / 文献综述 / 调研方向 / 领域地图 / 研究现状 / 有哪些工作 / 相关工作 / related work / literature review / survey / 前沿 / 综述 / 找论文 / 撞车 / 新颖性摸底 / 跨领域 / 检索式。核心纪律:不臆造 DOI/被引(查不到写 unknown);三层分别排序 不一锅 relevance;撞车只产**信号**不下 novel 判决(归 idea-critique);覆盖度按真实 HTTP 码诚实标。

---

name: light-memory-pm

description: Light 项目运行时记忆与项目管理常驻技能:把"项目做到哪/定了啥/出到哪版/术语怎么统一/上次断哪" 落到每个项目自己的 .light/ 目录(项目卡 + 决策日志 + 版本史 + 受控术语表 + 跨会话交接卡), 复用 passport.py 引擎管 DAG 台账(不重造)。它是 consistency 事实源的归属方,定义一改即变更广播 回扫所有材料;是总控"会话开头自动汇报上次断哪"的记忆底座。何时用:长期/跨会话项目、需记住背景/进展/ 版本/决策、会话开头续跑或接手、重要进展后立即落账、上下文将尽要交接、改术语/指标/创新点定义后。 触发词:记忆 / 项目管理 / 项目卡 / 决策日志 / 版本史 / 版本记录 / 续跑 / 接手 / 上次断哪 / 下一步 / 交接 / handoff / 启动提示词 / 术语表 / 变更广播 / 归档 / 台账 / .light / passport / 跨会话。 核心纪律:记忆落 .light/ 显式文件(非向量检索);相对日期转绝对;外部可变事实带 [snapshot]; 自洽用 pm.py audit 出 exit code(不口头说"记过了");不可逆决策(归档/教训回写)停下问用户。

---

name: light-orchestrator

description: Coordinate and recover multi-stage Light research projects through the canonical .light/passport.yaml state, stages 1-13, resident overlays, checkpoints, findings, parallel joins, stale propagation, handoffs and user-authorized reroutes. Use for a new/resumed/partial/dirty/failed/stale/delivered research project; when the user says continue, resume, take over, checkpoint, reroute, recover or deliver; or when work crosses two or more Light research stages. Never turn frontend-design/system-design/patent-disclosure/software-copyright or overlays into stages, never execute a suggested back-edge without explicit user authorization, and never declare delivery from file existence alone.

---

name: light-paper-writing

description: Light 科研主线第 8 步·论文写作：围绕「如何让审稿人相信值得发表」组织，初稿→审稿人视角循环打磨； 每个 claim 都有证据、措辞强度匹配证据强度、绝不过度宣称。何时用：实验+分析做完要写论文 / 写/改摘要·引言· 贡献句·结论 / 担心「claim 无证据 或 措辞夸大」/ 要让贡献三处(摘要·引言·结论)一致 / 引言四段式(痛点→不足→ 洞察→贡献) / 要当审稿人自己挑一遍 / 论文初稿润色去 AI 腔/被动/语法。 触发词：写论文 / 论文写作 / 写摘要 abstract / 写引言 introduction / 贡献句 contribution / 写结论 / 润色 polish / 改写 / 措辞 / 过度宣称 overclaim / claim 无证据 / 审稿人视角 / 自我审稿 / 贡献一致 / hedge / 学术腔 / AI 腔 / 被动语态 / paper writing / draft。 核心纪律：**claim 无证据 = critical 诚信门**（spec §4.2，STAGE_GATES[8]=[claim_evidence,overclaim]）； 过度宣称 / 贡献三处不一致 = warn（critical 措辞红线在 research-ethics 交付门）；**措辞强度必须匹配证据强度**、 不显著只能报「未见显著差异」、绝不过度宣称；机检措辞有边界，逻辑/创新/论证终判仍需人/审稿人。 本技能是 **8→7（claim 无证据→result-analysis）/ 8→6（实现缺口→experiment-coding）回炉发起方**。

---

name: light-patent-disclosure

description: Prepare evidence-backed patent invention disclosure materials for attorney or patent-agent review. Use when the user asks for 专利点挖掘, 技术交底书, 现有技术/查新记录, claim/patent-point support mapping, invention disclosure drafts, patent figures, or a handoff package for a software/research/project invention. This is an off-DAG engineering/IP handoff skill: it does not provide legal advice, does not submit filings, does not guarantee novelty, grant, allowance, validity or registration, and emits no Light research findings or back-edges.

---

name: light-project-structure

description: Audit, plan, scaffold, and safely migrate research project structures across greenfield, existing Git/non-Git repositories, and monorepo subroots. Use for project folders, repository cleanup, source inventory, move maps, naming and storage policy, Python/R/mixed/LaTeX profiles, template provenance, conflict review, applied-move evidence, or rollback. Existing projects are read-only until the user authorizes exact action IDs bound to a plan digest. Preserve uncommitted and untracked work, symlinks, submodules, and memory-pm's .light content. This is an off-DAG local tool: do not emit findings or invent a STAGE_GATES/ROUTES connection.

---

name: light-research-ethics

description: Light 科研诚信与伦理全生命周期常驻红线门:在研究分诊、审批、采集、变更、分析、投稿、发布与出版后检查 学术不端/数据造假/统计自洽/结论夸大/幻觉与撤稿 引用/自我抄袭/隐私/版权/署名与 AI 披露/软著专利权属/论文工厂洗稿等风险,把"别造假别夸大"从口头建议 落成**可机检、可阻断、可被总控 run_checkpoint 聚合的机读门**(产 light.findings.v1,Critical fail → exit 1)。 何时用:投稿/camera-ready 前、数据或代码发布前、软著提交前、涉人或涉动物实验设计时——这些是硬闸门; 以及任意写作/分析/引用任务的后台诚信扫描。触发词:伦理 / 诚信 / 学术不端 / 造假 / p-hacking / 夸大 / SOTA / 撤稿 / 查重 / 抄袭 / 隐私 / IRB / 知情同意 / 署名 / AI 披露 / 论文工厂 / 软著权属。核心纪律:**信号≠定罪**, AI 不能自评 → 一律"机读门 + 人工复核";查不到写"待核查/UNRESOLVED",绝不编造;全程在线核实、零本地知识库、零付费 key。

---

name: light-research-plan

description: Light 科研主线第 5 步·研究方案与实验设计：把 idea-critique 放行的 idea 与 data feasibility 拆成**能真执行、能写进论文、 能复现**的 question/estimand、实验矩阵与预注册包。何时用：idea 已通过审查要落地 / 要设计实验·消融·对比·敏感性· 泛化·鲁棒性 / 写研究方案 PROJECT_PLAN / 锁 primary outcome、排除/停止规则或 preregistration / 规划样本量、种子与统计功效 / 算实验算力预算 / 复现已有论文 / 担心 baseline 放水或假设推不翻。触发词：研究方案 / 实验设计 / 实验矩阵 / 假设 / 对照 baseline / 消融 ablation / 公平比较 / 可证伪 / 统计功效 power / 多少种子 / 复现 / reproducibility / research plan / experiment design / 可复现。核心纪律：**对照不公平(baseline 放水)/不可证伪 = critical 一票否决** （spec §4.2，STAGE_GATES[5]=[fair_baseline,falsifiable]）；消融不隔离/欠功效 = warn；功效是计划阶段反推非结果检验； lint 是启发式有边界，公平/可证伪终判仍需人/领域判断，绝不吹"证明了对照绝对公平"。

---

name: light-result-analysis

description: Light 科研主线第 7 步·结果分析：不描述好坏、解释「为什么」，把每条结论**绑死到 claim + 证据强度**，并防 p-hacking。 何时用：实验跑完要解读结果 / 问「这些数说明什么」/ 要做显著性检验 + 效应量 + 置信区间 + 多重比较校正 / 担心 p-hacking (多重比较不校正、选择性报告、HARKing) / 要给每条 claim 定证据强度供写作校准措辞 / 判结果支不支撑假设、可不可复现。 触发词：结果分析 / 解读数据 / 这些结果说明什么 / 显著性 / p 值 / 效应量 effect size / Cohen's d / 置信区间 CI / 多重比较 / BH-FDR / Bonferroni / 校正 / p-hacking / 选择性报告 / garden of forking paths / HARKing / 证据强度 / claim 证据绑定 / SHAP / 消融分析 / 切片分析 / 配对检验 / result analysis。 核心纪律：**统计错误 / p-hacking = critical**（spec §4.2，STAGE_GATES[7]=[stat_validity,evidence_strength]）； 过度解读 / 效应量缺失 = warn；**显著性看 q 不看 p**、不显著只能报「未见显著差异」、措辞强度必须匹配证据强度； 统计检查有边界，绝不吹「证明了方法有效 / 因果成立」。本技能是 **7→5（不支撑假设）/ 7→6（不可复现）回炉发起方**。

---

name: light-review-rebuttal

description: Build auditable peer-review revision and author-response packages for Light stage 13. Use after receiving reviewer comments, a decision or meta-review; when drafting a rebuttal or response letter; when triaging major/minor revisions; when simulating a pre-submission review; or when a rejection may require a user-chosen 13→3 novelty, 13→5 experiment, or 13→8 writing back-edge. Consumes the selected venue/context and real PDF facts, preserves reviewer wording, atomizes issues, binds claims/evidence/actions/provenance, separates PLANNED from DONE, checks current venue limits without borrowing another venue's rules, and emits the stage-13 gate without changing venue, manuscript, evidence, citations, figures, PDF, or passport automatically.

---

name: light-software-copyright

description: Prepare China software copyright registration material drafts from a real software project: application-field worksheet, source-code deposit material, user/operation manual, screenshots when needed, consistency checks and local formal-output evidence. Use for 软著, 软件著作权, 软件版权登记, source-code page extraction, operation manual drafts, version/name consistency, or pre-submit review. This off-DAG engineering/IP handoff skill does not provide legal advice, does not submit applications, does not guarantee registration, and never fabricates source code.

---

name: light-system-design

description: Design or modernize a software system from an evidence-backed current-state inventory through quality attributes, architecture options, API and schema contracts, migration/rollback plans, ADRs, and verification. Use for greenfield or existing monoliths, modular monoliths, services, system/API/ database design, schema migration review, data-flow reliability, tenant/PII controls, or architecture evolution. Existing systems stay read-only until the user selects an option and authorizes exact mutations. Unknown facts stay UNKNOWN. This is an off-DAG engineering skill: do not emit findings or invent STAGE_GATES, ROUTES, stages, or back-edges.

---

name: light-typesetting

description: Build and preflight submission-ready LaTeX/PDF artifacts for Light stage 11. Use when receiving a paper-writing manuscript, figure delivery, citation delivery.json/references.bib/citekey-audit.json, or a venue/template profile; when selecting pdfLaTeX/XeLaTeX/LuaLaTeX and BibTeX/Biber; when diagnosing LaTeX errors or unresolved references; when checking page limits, double-blind identity, PDF metadata, template, page box, embedded fonts, TODOs, figures, tables, labels and citations; or when producing a reproducible compile manifest, PDF, compliance report, failure bundle and venue-matching handoff. Distinguishes PASS, manuscript ERROR, toolchain UNAVAILABLE and convergence UNRESOLVED without redoing citation authenticity or figure scientific QA.

---

name: light-venue-matching

description: Build evidence-bound journal or conference shortlists for Light stage 12. Use after typesetting delivers venue-handoff.json/PDF/compliance facts; when an author asks where to submit, journal selection, conference fit, scope or article-type matching, publication strategy, reach/match/safety tiers, transfer order, APC/OA/indexing/deadline constraints, or predatory/hijacked-journal risk. Produces a current-source candidate registry, fit/risk/unknown reports, and an unchosen decision packet; never recompiles the PDF, invents acceptance rates, condemns a venue from soft signals, chooses without a direct user choice or explicit delegation, or submits.

---

name: best-skills

description: Daily cross-platform rankings of AI agent skills (skills.sh, ClawHub, Tencent SkillHub, GitHub, X/HN/Bluesky). Use when the user asks which agent skill to install, what is trending, whether a skill is popular or trusted, or wants to compare skills. Read-only public CSV data; it recommends and links, it does not install anything.

---

name: get-job

description: 实习.skill / get-job.skill：从岗位调研、简历改写到分轮次面试准备的全流程求职 skill。适合找工作、投实习、校招、秋招、春招、暑期实习、社招、跳槽、转行、跨专业求职、留学生求职，以及产品经理、运营、市场、咨询、AI 产品、AI Coding、数据分析、技术岗等目标岗位准备。 核心能力：① WebSearch 调研公司、岗位 JD、业务线、竞品、面经、招聘流程和隐性门槛；② 按目标岗位反向定位简历，做 JD 匹配、ATS 关键词、经历筛选、STAR/CAR 改写、可迁移能力翻译、docx 简历生成；③ 按真实轮次准备面试，覆盖一面/业务面/专业面/主管面/HR 面/recruiter screen 等已确认或高置信轮次，逐条深挖简历 bullet、项目逐字稿、自我介绍、表达训练、模拟面试、反问清单、面后复盘题库。 适用于「改简历」「简历优化」「简历润色」「简历匹配 JD」「求职简历」「投递前改简历」「按岗位改简历」「准备面试」「面试准备」「面经分析」「模拟面试」「自我介绍」「项目经历怎么讲」「简历被追问怎么办」「双非拿大厂 offer」「背景不对口怎么办」「AI 产品实习」「运营实习」「产品经理校招」等场景。 质量保障：不编造经历、不改背调硬信息；所有强 claim 做证据化审计；搜索源按市场和 A/B/C/D 分级；轮次不写死；最终交付前必须跑质量闸门和覆盖矩阵，避免漏 bullet、标签泄漏和过度包装。

---

name: openqodex

description: Code review for the current change, before it is pushed. One command runs the security, secret, dependency and lint scanners that fit the changed files, a separate reviewer that checks every scanner finding and is given every changed line, and prints a short receipt with the path of the full report. Use before every git push, when asked for a code review, a security scan, or to review changes, a diff or a pull request, and when a push was blocked or warned by OpenQodex.

---

name: openqodex

description: Code review for the current change, before it is pushed. One command runs the security, secret, dependency and lint scanners that fit the changed files, a separate reviewer that checks every scanner finding and is given every changed line, and prints a short receipt with the path of the full report. Use before every git push, when asked for a code review, a security scan, or to review changes, a diff or a pull request, and when a push was blocked or warned by OpenQodex.

---

name: openqodex

description: Code review for the current change, before it is pushed. One command runs the security, secret, dependency and lint scanners that fit the changed files, a separate reviewer that checks every scanner finding and is given every changed line, and prints a short receipt with the path of the full report. Use before every git push, when asked for a code review, a security scan, or to review changes, a diff or a pull request, and when a push was blocked or warned by OpenQodex.

---

name: svg-diagram

description: SVG diagramming conventions blending a technical look with CJK-friendly typography. Use when creating flowcharts, architecture diagrams, and similar SVG figures. For one-shot generation, prefer invoking it from a subagent so the main context does not have to carry this skill plus the SVG XML; for multi-round tweaking, use it directly in the main context.

---

name: nw-ab-critique-dimensions

description: Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation

---

name: nw-abr-critique-dimensions

description: Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation

---

name: nw-ad-critique-dimensions

description: Review dimensions for acceptance test quality - happy path bias, GWT compliance, business language purity, coverage completeness, walking skeleton user-centricity, priority validation, observable behavior assertions, traceability coverage, and walking skeleton boundary proof