メニュー
把一个名词或概念写成可使用的理解：先用普通话讲清它是什么、与相邻概念差在哪里，再说明它怎样运作、会改写什么判断，最后给出面对它时的行动抓手。USE WHEN 用户问 X 是什么、怎么理解、意味着什么、为什么重要、以后怎样判断或使用；尤其适合技术概念、制度、产品、角色、方法、规范与实践。NOT FOR 单纯查事实、公式证明、逐步操作教程、纵向因果深挖（用 ljg-think）或母题结构（用 ljg-structure）。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/lijigang/ljg-skills --skill ljg-isコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Content caster (铸). Transforms text into PNG through precise HTML typography and, when the mold needs it, generated raster imagery. Four molds: -l (default) long reading card, -f source-faithful full text, -c comic, -w whiteboard. USE WHEN user says '铸', 'cast', '做成图', '做成卡片', '做成海报', '原文排版', '全文卡片', '漫画', or '白板'.
用体验而不是定义来教授概念、原理或检验观点：先给与学习者认知水平相称的局面，让其选择，再用公平的意外显化认知缺口，结构化后才命名，并以迁移局面循环复测。USE WHEN 用户调用 '/ljg-teach'、说 '用情境教我'、'别先讲答案'、'通过案例让我学会'，或希望通过选择与反馈理解一个概念或观点。NOT FOR 直接定义查询（用 ljg-is/ljg-word）、八维概念解剖（用 ljg-learn）、伴读文本（用 ljg-read）。
古文逐字注解、组合排版、章节意旨图与全章解读生成器。把原文、字词注、句义注、无字顶部配图和章节解读排成一张可读的长 PNG。USE WHEN 用户调用 ljg-classic OR 要求给文言文、古诗文、经史子集做逐字注解、彩色夹注、章节解读、古文讲义图、章节配图。NOT FOR 只翻译一句古文、只写现代文章或通用内容卡片。
SKILL.md を表示中
| name | ljg-is |
| version | 5.0.0 |
| description | 把一个名词或概念写成可使用的理解：先用普通话讲清它是什么、与相邻概念差在哪里，再说明它怎样运作、会改写什么判断，最后给出面对它时的行动抓手。USE WHEN 用户问 X 是什么、怎么理解、意味着什么、为什么重要、以后怎样判断或使用；尤其适合技术概念、制度、产品、角色、方法、规范与实践。NOT FOR 单纯查事实、公式证明、逐步操作教程、纵向因果深挖（用 ljg-think）或母题结构（用 ljg-structure）。 |
| user_invocable | true |
只给定义，读者可能记住了词，却仍不知道怎样认出它。只讲动词，读者又可能知道它做了什么，却不清楚它究竟是哪一类东西、边界在哪里。
ljg-is 把两者接起来：名词回答「它是什么」，让概念在认知地图里站稳；动词回答「它怎样起作用」，让概念在现实里动起来。真正完成的理解还要继续走一步：它改写了读者原来的什么判断，下次遇到它时又能怎样行动。
它是什么，和什么不一样？
它靠什么动作产生结果？
知道这一点后，我不再怎样想？
下次遇到它，我先看什么、怎样做？
这四个问题是一条理解路径，不是四个正文栏目。文章要像一个人顺着疑惑把事情讲明白，而不是把答案依次填进表格。
赵汀阳的「动词」思想在这里仍然重要，但它是一副有条件的透镜。面对制度、平台、角色或规范，可以继续追问谁选择了这种做法，它怎样改变参与者；面对目标函数、递归这类技术概念，动词首先是对象自身的运算与作用。材料没有显示社会反制，就不把技术说明硬拽成制度批判。
| Workflow | Trigger | File |
|---|---|---|
| UnderstandInUse | 把「是什么」与「怎样运作」接成可辨认、可判断、可行动的 Org 解读 | Workflows/TraceCreation.md |
一篇合格解读会让读者发生四个连续变化：
能用一句普通话说出 X 属于什么，以及它与最容易混淆的对象差在哪里。定义要给边界，不能只给比喻或用途。
能顺着一个真实例子说明 X 怎样起作用。技术概念讲清输入、关键动作和结果；制度概念讲清参与者、规则怎样进入行动以及实际后果。只写对象真正具有的机制。
能指出自己原来哪种看法需要修改。认知变化必须由前面的定义和机制推出，不另起炉灶追求「深刻」。
能在一个具体情境里使用这番理解。行动指导要说清先看什么、怎样判断、何时调整，并能解释为什么。
正文从一个普通读者真的会有的疑惑、误解或使用场景进入，不强制编造人物故事。概念要尽早出现，例子负责验证解释，不负责制造戏剧性。
最后可以落在一句判断、一个行动原则或一个真实未决问题上。哪一种自然，由前文决定；问号不是深度证明。
默认写入：
~/Context/{时间戳}--理解-{目标片段}__is.org
新成品使用 ljg-is-v5 schema。正文使用两到四个随内容生出的标题和四到十个自然段，不把「是什么 / 怎样运作 / 认知改变 / 行动指导」直接用作四个栏目。
定义与理解不同。 用户若只要形式化定义、公式证明或术语翻译，直接回答即可；只有当他想理解概念如何工作、意味着什么或怎样使用时，才进入本技能。
动词不等于社会创制。 技术对象可以通过计算、映射、比较、压缩或递归起作用，不必虚构一个创造者故事。制度对象才追问选择者、规则与反作用。
行动指导不是操作手册。 本技能给判断抓手，不替代某个软件、流程或行业的逐步教程。
理由不能伪造。 区分材料支持的事实和分析者的推断。不知道就缩小判断，不替人物补写动机，也不把一般机制冒充具体案例事实。
不要把新合同写成新清单。 「定义、机制、启发、建议」若各占一栏，文章仍然生硬。它们应当像一条推理：因为 X 是这样运作的，所以原来的判断不够准确，下一次才应当这样做。
不要只给用途当定义。 「目标函数用来优化」没有说明它是什么；要补上它怎样给候选方案建立可比较关系，读者才可能把它与约束、指标或奖励区分开。
不要强制具体场景。 一个真实疑惑往往比虚构工程师或司机更自然。只有当人物行动确实承载机制时才使用故事。
不要强造赵汀阳式转折。 未选可能、反制、本源和未来不是必填项。它们只有能解释对象，并且有现实根据时才进入正文。
不要在结尾突然升级尺度。 前文讲算法，结尾忽然质问社会正义，通常不是深刻，而是换了问题。认知改变与行动指导必须能够逐句追溯到已经讲清的机制。
不要给万能建议。 「保持关注」「综合考虑」「具体问题具体分析」删除概念名后仍然成立，说明它没有使用前文的理解。
不要让元数据替正文说话。 definition、operation、recognition 与 guidance 是后台索引；正文可以用更自然的说法，但全文读回必须找到同一内容。
目标函数
不要写：目标函数是优化的灵魂，它最终会反过来支配设计者。
可以写：目标函数是一把供求解过程比较方案的尺子。它给每个候选方案一个
可比较的结果，让程序知道往哪边改进。因此看到「最优」时，先补问一句：
这是按照哪把尺子得到的最优？
绩效考核
先讲清：它是组织定期判断工作表现并连接后续决定的一套正式做法。
再讲它怎样通过指标、叙述或评议进入奖金与机会。由此自然推出：考核不只
记录工作，也会改变人们接下来选择什么工作；设计考核时要检查它正在奖励的
行为，而不能只检查表格是否完整。
边界案例
User: 请给出递归函数的形式化定义并证明这个定理。
→ 不调用 ljg-is；这是形式定义与证明任务。
User: 我知道递归是自己调用自己，但还是不懂它到底是什么，写程序时怎么判断该不该用？
→ 调用 ljg-is；这需要把定义、运作方式、认知修正与使用判断接起来。