SuggestSkills Scan 工作流解析如何用工作历史与挫败信号发现真正的技能缺口【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS本篇技术指南围绕 LifeOS 中 SuggestSkills 技能的Scan 工作流Scan.md展开它负责回答一个关键问题结合你最近实际做过的事和遇到的挫败是否存在一个反复出现、值得单独建技能、但目前还没有被任何技能覆盖的问题读完本文你将掌握 Scan 从确定性数据收集、按痛点聚类、覆盖判定到输出带证据的候选短名单的完整五步流程以及底层工具 CollectSignals.ts 的参数语义、路径解析规则与输出契约可以直接在自己的 LifeOS 安装上复现一次完整的技能缺口扫描。Scan 与 CreateSkill 是两个刻意拆开的阶段Scan 只读、只提议不写任何技能你批准候选后才由 CreateSkill 单独完成创建。这种发现与创建分离的设计让绝不自动建技能成为代码层面可执行的权限边界而非一句口头承诺。一、Scan 的定位只读的分析通道Scan 是 SuggestSkills 技能的唯一工作流。当用户说出what skills should I build、skill gap、suggest skills、am I missing a skill这类意图时触发路由规则见 SKILL.md。它有三个硬性约束Read-only整个流程只读取存储、只输出建议Proposes only只产出候选短名单绝不落盘任何技能Frustration is a first-class signal不仅看会话主题频率还把低评分low ratings与复发标记如 regressed again作为一等证据——这正是它区别于普通话题统计工具的核心。从源码结构看这个权限边界在工具层就被坐实CollectSignals.ts 的文件头注释明确写着 Writes nothing不写任何东西且resolveStore、parseFrustrations、collectSessions等函数全部只使用fs的读取接口readFileSync/readdirSync/statSync/existsSync没有任何写入类调用。二、运行前的两个准备语音通知与充分性检查语音通知执行任何 SuggestSkills 工作流前先通过本地通知端点localhost:31337发送一条语音/推送通知并在界面输出同步文本。命令如下curl -s -X POST http://localhost:31337/notify \ -H Content-Type: application/json \ -d {message: Running Scan in SuggestSkills} \ /dev/null 21 同时输出文本行Running **Scan** in **SuggestSkills**...Step 0 — 充分性检查Sufficiency check语料corpus就是证据上下文。开跑前先做两项检查ratings store 是否缺失如果工具报告评分存储缺失missing数组含ratings说明本次运行的挫败信号不可用——必须在报告中明说本次缺少挫败信号而不是把一份只有主题、没有挫败的话题级结果当作完整结论呈现是否限定领域如果调用者问的是具体领域如 am I missing anything around deploys?则把聚类范围收窄到该领域并在报告中注明你确实做了范围限定。三、Step 1 — 确定性收集工具收集而非人工归纳bun ~/.claude/skills/SuggestSkills/Tools/CollectSignals.ts --days 45 /tmp/skill-scan-corpus.json说明~/.claude/skills/...是典型安装布局下的调用路径仓库内对应实现位于 Tools/CollectSignals.ts。这条命令的原则是LLM 不收集只裁判。LLM 的角色是判断工具返回什么而不是自己去 grep 存储否则两次运行看到的证据不一致评估就失去意义。意图到参数映射表不同问法对应不同的收集参数原工作流给出的完整映射如下用户说Flag效果(默认)、recently、lately--days 4545 天窗口this quarter、last few months--days 90更宽窗口会话列表会明显变长all time、everything--days 3650全量历史上限钳制为 3650only the really bad ones--max-rating 2收紧挫败阈值默认 4scan another install / another tree--root dir在另一棵根目录下重新解析所有存储某存储位于非标准位置--ratings file--work dir--skills dir--loops dir覆盖单个存储显式路径不存在会被报告绝不会静默回退默认值存储解析顺序flag env 约定默认值每个存储store按以下优先级解析显式 CLI flag如--ratings file环境变量SKILLSCAN_MEMORY_ROOT、SKILLSCAN_RATINGS_FILE、SKILLSCAN_WORK_DIR、SKILLSCAN_SKILLS_DIR、SKILLSCAN_LOOPS_DIR--root下第一个存在的约定默认路径先试LIFEOS/MEMORY/...再试裸的MEMORY/...适配不同安装布局。Loops 是 opt-in 的没有默认路径如果该安装维护 loop 目录loop catalog必须显式传--loops或环境变量。这条规则的源码实现在 CollectSignals.ts 的resolveStore()函数中显式路径若existsSync失败会向warnings写入--label path ... does not exist并返回 null——报错而不是静默兜底避免把用户的错误路径悄悄替换成默认值而掩盖问题。语料结构工具输出到 stdout 的 JSON 语料结构为{ window, sessions[], frustrations[], registries[], warnings[], missing[], sources }阅读顺序有讲究先读warnings和missing哪些存储缺失、哪些行被跳过再读主数据。sources记录了实际解析到的每个存储路径便于审计本次运行到底读了什么。四、CollectSignals.ts 源码级解析参数、契约与守护参数与默认值intArg()是严格的整数解析器非整数会告警并回退默认值超出范围会钳制并告警warns, never silently accepts garbage。完整参数表参数默认范围语义--root dir$HOME/.claude或SKILLSCAN_MEMORY_ROOT—约定默认存储的基准目录--days n451–3650回看窗口天数--max-rating n41–10仍计为挫败的最高评分--ratings fileLIFEOS/MEMORY/LEARNING/SIGNALS/ratings.jsonl再试MEMORY/...—评分 JSONL 存储--work dirLIFEOS/MEMORY/WORK再试MEMORY/WORK—工作会话目录--skills dirskills—技能树--loops dir无opt-in—loop 目录输出契约sessions最近窗口内的会话目录跳过.和_前缀的系统目录按 mtime 降序、slug 升序完全 tie-brokenfrustrations低评分行过滤rating maxRating剔除无法解析的时间戳note 截断至 500 字符按 rating/date/note 排序registries从每个技能目录的SKILL.mdYAML frontmatter 中提取name与description支持折叠/块标量语法并把各技能Workflows/下的.md也注册为workflow条目、loop 目录下的.md注册为loop条目——它们都是可复用的覆盖单元warnings/missing非致命问题超大文件、不可读、格式错误行、存储不存在都会进这里绝不致命中断退出码语义即使存储全部缺失也退出 0全新安装是一个合法空语料仅内部意外错误才返回非零。两个防滥用守护MAX_RATINGS_BYTES 10_000_000防止巨型/FIFO 评分存储把进程拖垮MAX_NOTE_CHARS 500限制挫败备注的截断长度并清洗控制字符保证输出 JSON 可被 jq 等工具正常解析。五、Step 2 — 按痛点聚类recurrence 与 friction 两个数字把sessions与frustrations归并为反复出现的主题簇cluster。每个簇携带两个数字recurrence复发次数涉及多少个会话friction摩擦强度有多少低评分/复发标记如 regressed again。关键裁决原则挫败信号frustration的权重高于原始主题频率。一个话题被反复提及 20 次但从不低分与一个话题被提及 3 次但每次都低分后者更值得建技能。这与 RecurrenceLedger.ts 中的挫败模式字典FRUSTRATION_PATTERNS覆盖 Incomplete Work、Wrong Approach、Repetitive Issues 等类别一脉相承——系统的挫败识别不是拍脑袋而是有可复用的模式词典支撑。六、Step 3 — 三分类BEHAVIOR-FEEDBACK / COVERED / GAP对每个簇做三分BEHAVIOR-FEEDBACK话痨verbosity、误解范围scope misreads、提醒节奏reminder cadence——这些是行为反馈不是技能缺口路由到记忆/偏好memory/preferences排除出技能候选COVERED已有技能/loop/workflow真正覆盖该纪律discipline。判定标准极其严格必须阅读覆盖单元的正文而不是看名字并把具体失败类别映射到该正文中的明确指引。如果正文没有处理该失败类别就不算覆盖GAP同时满足复发按严重度加权高严重度的反复痛苦即使低于 ~3 次也算和未被覆盖。注意主题上被某构建/测试技能名义覆盖但该主题下的纪律缺口依然算 GAP。这里有一个容易踩的认知陷阱名字匹配不等于覆盖。App development 映射到某个构建技能但反复出现的痛苦可能是构建技能从未处理的无主纪律如状态建模、错误处理、迁移安全——这正是 Scan 存在要暴露的第二类盲区。七、Step 4 — 双通道独立验证报告并集UNION派两个独立通道对同一语料分别分类。报告任一侧标记为 GAP 的所有簇并按一致程度打标both两侧都判 GAP → 高置信one仅一侧判 GAP → 需要人工复核。绝不能只报交集严格取交集会恰好压制掉本技能存在的意义——那些隐蔽的纪律缺口subtle discipline gaps。原工作流明确要求 Do NOT drop single-pass gaps。八、Step 5 — 提议绝不创建输出一个带排序的候选短名单每条提议包含name候选技能名one-line description一句话描述evidence复发次数、摩擦强度、它将要预防的具体反复失败。任何写入评审位置review location的内容都必须脱敏去掉 secrets、客户/项目名、个人路径。被采纳的候选进入CreateSkill作为独立的人工批准步骤创建流程见 CreateSkill/Workflows/CreateSkill.md。Scan 工作流本身不写任何技能。九、输出模板Scan 的最终报告遵循固定模板## Skill-gap scan (last N days, M sessions; frustration store: present/absent) ### Gaps worth building - Name [confidence: both|one] — desc. Evidence: N sessions, K frustration signals, recurring failure .... → CreateSkill? ### Covered (verified against bodies, no action) - theme → skill/loop/workflow ### Behavior-feedback (route to memory, not a skill) - theme ### Recommendation 1-2 sentences; nothing new is valid ONLY when the frustration signals are also clean注意模板的两个细节报告头必须标注frustration store: present/absent呼应 Step 0 的充分性检查nothing new 作为结论仅在挫败信号同样干净时才合法——否则就是漏报false negative。十、挫败数据从哪来SatisfactionCapture → ratings.jsonl 链路Scan 读的ratings.jsonl约定位于LIFEOS/MEMORY/LEARNING/SIGNALS/ratings.jsonl不是凭空出现的它由 SatisfactionCapture.hook.ts 在每次UserPromptSubmit时写入显式评分用户输入裸数字8、N/10 或英文数字形式ten→ 直接捕获评分 1–10正面表扬快路径≤2 个词的 praisegreat job、perfect→ 记为隐性评分 8并写sentiment_summary: Direct praise: ...显式纠正thats wrong、still broken 等精确短语匹配 → 捕获为 FAILURES 事件摘要即原话deterministic无推理长期指令from now on X → 写入 Upgrades 存储。评分 ≤ 3 时会进一步调用 FailureCapture.ts 生成完整失败上下文CONTEXT.mdtranscript.jsonlsentiment.jsontool-calls.json写入MEMORY/LEARNING/FAILURES/YYYY-MM/且写盘前会按 SECRET_SHAPES 规则对密钥、Bearer token、PEM 私钥等做[REDACTED]脱敏。理解这条链路对使用 Scan 很关键挫败信号的密度取决于日常评分采集的完备度。如果习惯性不评分、不纠正ratings store 就会偏空Scan 的挫败加权优势就无从发挥——这时报告会如实标注 frustration store 的状态提醒你信号不足。十一、常见误用与反模式Gotchas结合 SKILL.md 与工作流原文以下反模式必须避免干净覆盖 肮脏挫败 假阴性如果评分显示某个你已标记为已覆盖的领域仍有反复挫败必须重新打开它——该主题之下的纪律才是缺口。这正是本技能要修的问题复发按严重度加权不是裸计数三个琐碎会话不如一次漫长、痛苦、反复发生的迁移重要。高严重度、跨少量会话反复出现的痛苦即使低于任意阈值也够格行为不是技能太啰嗦、误解范围、重复提醒属于转向/反馈应路由到记忆/偏好而不是 CreateSkill收集必须确定性如果发现自己在工作流里手工 grep 存储请改用工具——手工收集会让运行不可复现评估失去意义路径是被发现的不是被假设的工具通过 flag/env/root 解析存储跨安装可用不要把某个 home 目录硬编码进去大工作存储只会让会话列表变长不会让分析更好默认 45 天窗口就是杠杆——刻意放宽它并预期聚类步骤承担成本。结语Scan 工作流把我该建什么技能从一个玄学问题变成了一个可复现的数据问题确定性收集CollectSignals.ts→ 按痛点聚类 → 三分类去重 → 双通道验证取并集 → 提议不创建。它的独特价值不在于统计话题频率而在于把挫败信号与纪律缺口摆到台面上——那些藏在已覆盖主题名之下、靠主题匹配永远看不见的洞正是 Scan 存在的理由。想继续深入可以阅读 工作流原文、技能总纲 与 收集器实现。【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SuggestSkills Scan 工作流解析：如何用工作历史与挫败信号发现真正的技能缺口
SuggestSkills Scan 工作流解析如何用工作历史与挫败信号发现真正的技能缺口【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS本篇技术指南围绕 LifeOS 中 SuggestSkills 技能的Scan 工作流Scan.md展开它负责回答一个关键问题结合你最近实际做过的事和遇到的挫败是否存在一个反复出现、值得单独建技能、但目前还没有被任何技能覆盖的问题读完本文你将掌握 Scan 从确定性数据收集、按痛点聚类、覆盖判定到输出带证据的候选短名单的完整五步流程以及底层工具 CollectSignals.ts 的参数语义、路径解析规则与输出契约可以直接在自己的 LifeOS 安装上复现一次完整的技能缺口扫描。Scan 与 CreateSkill 是两个刻意拆开的阶段Scan 只读、只提议不写任何技能你批准候选后才由 CreateSkill 单独完成创建。这种发现与创建分离的设计让绝不自动建技能成为代码层面可执行的权限边界而非一句口头承诺。一、Scan 的定位只读的分析通道Scan 是 SuggestSkills 技能的唯一工作流。当用户说出what skills should I build、skill gap、suggest skills、am I missing a skill这类意图时触发路由规则见 SKILL.md。它有三个硬性约束Read-only整个流程只读取存储、只输出建议Proposes only只产出候选短名单绝不落盘任何技能Frustration is a first-class signal不仅看会话主题频率还把低评分low ratings与复发标记如 regressed again作为一等证据——这正是它区别于普通话题统计工具的核心。从源码结构看这个权限边界在工具层就被坐实CollectSignals.ts 的文件头注释明确写着 Writes nothing不写任何东西且resolveStore、parseFrustrations、collectSessions等函数全部只使用fs的读取接口readFileSync/readdirSync/statSync/existsSync没有任何写入类调用。二、运行前的两个准备语音通知与充分性检查语音通知执行任何 SuggestSkills 工作流前先通过本地通知端点localhost:31337发送一条语音/推送通知并在界面输出同步文本。命令如下curl -s -X POST http://localhost:31337/notify \ -H Content-Type: application/json \ -d {message: Running Scan in SuggestSkills} \ /dev/null 21 同时输出文本行Running **Scan** in **SuggestSkills**...Step 0 — 充分性检查Sufficiency check语料corpus就是证据上下文。开跑前先做两项检查ratings store 是否缺失如果工具报告评分存储缺失missing数组含ratings说明本次运行的挫败信号不可用——必须在报告中明说本次缺少挫败信号而不是把一份只有主题、没有挫败的话题级结果当作完整结论呈现是否限定领域如果调用者问的是具体领域如 am I missing anything around deploys?则把聚类范围收窄到该领域并在报告中注明你确实做了范围限定。三、Step 1 — 确定性收集工具收集而非人工归纳bun ~/.claude/skills/SuggestSkills/Tools/CollectSignals.ts --days 45 /tmp/skill-scan-corpus.json说明~/.claude/skills/...是典型安装布局下的调用路径仓库内对应实现位于 Tools/CollectSignals.ts。这条命令的原则是LLM 不收集只裁判。LLM 的角色是判断工具返回什么而不是自己去 grep 存储否则两次运行看到的证据不一致评估就失去意义。意图到参数映射表不同问法对应不同的收集参数原工作流给出的完整映射如下用户说Flag效果(默认)、recently、lately--days 4545 天窗口this quarter、last few months--days 90更宽窗口会话列表会明显变长all time、everything--days 3650全量历史上限钳制为 3650only the really bad ones--max-rating 2收紧挫败阈值默认 4scan another install / another tree--root dir在另一棵根目录下重新解析所有存储某存储位于非标准位置--ratings file--work dir--skills dir--loops dir覆盖单个存储显式路径不存在会被报告绝不会静默回退默认值存储解析顺序flag env 约定默认值每个存储store按以下优先级解析显式 CLI flag如--ratings file环境变量SKILLSCAN_MEMORY_ROOT、SKILLSCAN_RATINGS_FILE、SKILLSCAN_WORK_DIR、SKILLSCAN_SKILLS_DIR、SKILLSCAN_LOOPS_DIR--root下第一个存在的约定默认路径先试LIFEOS/MEMORY/...再试裸的MEMORY/...适配不同安装布局。Loops 是 opt-in 的没有默认路径如果该安装维护 loop 目录loop catalog必须显式传--loops或环境变量。这条规则的源码实现在 CollectSignals.ts 的resolveStore()函数中显式路径若existsSync失败会向warnings写入--label path ... does not exist并返回 null——报错而不是静默兜底避免把用户的错误路径悄悄替换成默认值而掩盖问题。语料结构工具输出到 stdout 的 JSON 语料结构为{ window, sessions[], frustrations[], registries[], warnings[], missing[], sources }阅读顺序有讲究先读warnings和missing哪些存储缺失、哪些行被跳过再读主数据。sources记录了实际解析到的每个存储路径便于审计本次运行到底读了什么。四、CollectSignals.ts 源码级解析参数、契约与守护参数与默认值intArg()是严格的整数解析器非整数会告警并回退默认值超出范围会钳制并告警warns, never silently accepts garbage。完整参数表参数默认范围语义--root dir$HOME/.claude或SKILLSCAN_MEMORY_ROOT—约定默认存储的基准目录--days n451–3650回看窗口天数--max-rating n41–10仍计为挫败的最高评分--ratings fileLIFEOS/MEMORY/LEARNING/SIGNALS/ratings.jsonl再试MEMORY/...—评分 JSONL 存储--work dirLIFEOS/MEMORY/WORK再试MEMORY/WORK—工作会话目录--skills dirskills—技能树--loops dir无opt-in—loop 目录输出契约sessions最近窗口内的会话目录跳过.和_前缀的系统目录按 mtime 降序、slug 升序完全 tie-brokenfrustrations低评分行过滤rating maxRating剔除无法解析的时间戳note 截断至 500 字符按 rating/date/note 排序registries从每个技能目录的SKILL.mdYAML frontmatter 中提取name与description支持折叠/块标量语法并把各技能Workflows/下的.md也注册为workflow条目、loop 目录下的.md注册为loop条目——它们都是可复用的覆盖单元warnings/missing非致命问题超大文件、不可读、格式错误行、存储不存在都会进这里绝不致命中断退出码语义即使存储全部缺失也退出 0全新安装是一个合法空语料仅内部意外错误才返回非零。两个防滥用守护MAX_RATINGS_BYTES 10_000_000防止巨型/FIFO 评分存储把进程拖垮MAX_NOTE_CHARS 500限制挫败备注的截断长度并清洗控制字符保证输出 JSON 可被 jq 等工具正常解析。五、Step 2 — 按痛点聚类recurrence 与 friction 两个数字把sessions与frustrations归并为反复出现的主题簇cluster。每个簇携带两个数字recurrence复发次数涉及多少个会话friction摩擦强度有多少低评分/复发标记如 regressed again。关键裁决原则挫败信号frustration的权重高于原始主题频率。一个话题被反复提及 20 次但从不低分与一个话题被提及 3 次但每次都低分后者更值得建技能。这与 RecurrenceLedger.ts 中的挫败模式字典FRUSTRATION_PATTERNS覆盖 Incomplete Work、Wrong Approach、Repetitive Issues 等类别一脉相承——系统的挫败识别不是拍脑袋而是有可复用的模式词典支撑。六、Step 3 — 三分类BEHAVIOR-FEEDBACK / COVERED / GAP对每个簇做三分BEHAVIOR-FEEDBACK话痨verbosity、误解范围scope misreads、提醒节奏reminder cadence——这些是行为反馈不是技能缺口路由到记忆/偏好memory/preferences排除出技能候选COVERED已有技能/loop/workflow真正覆盖该纪律discipline。判定标准极其严格必须阅读覆盖单元的正文而不是看名字并把具体失败类别映射到该正文中的明确指引。如果正文没有处理该失败类别就不算覆盖GAP同时满足复发按严重度加权高严重度的反复痛苦即使低于 ~3 次也算和未被覆盖。注意主题上被某构建/测试技能名义覆盖但该主题下的纪律缺口依然算 GAP。这里有一个容易踩的认知陷阱名字匹配不等于覆盖。App development 映射到某个构建技能但反复出现的痛苦可能是构建技能从未处理的无主纪律如状态建模、错误处理、迁移安全——这正是 Scan 存在要暴露的第二类盲区。七、Step 4 — 双通道独立验证报告并集UNION派两个独立通道对同一语料分别分类。报告任一侧标记为 GAP 的所有簇并按一致程度打标both两侧都判 GAP → 高置信one仅一侧判 GAP → 需要人工复核。绝不能只报交集严格取交集会恰好压制掉本技能存在的意义——那些隐蔽的纪律缺口subtle discipline gaps。原工作流明确要求 Do NOT drop single-pass gaps。八、Step 5 — 提议绝不创建输出一个带排序的候选短名单每条提议包含name候选技能名one-line description一句话描述evidence复发次数、摩擦强度、它将要预防的具体反复失败。任何写入评审位置review location的内容都必须脱敏去掉 secrets、客户/项目名、个人路径。被采纳的候选进入CreateSkill作为独立的人工批准步骤创建流程见 CreateSkill/Workflows/CreateSkill.md。Scan 工作流本身不写任何技能。九、输出模板Scan 的最终报告遵循固定模板## Skill-gap scan (last N days, M sessions; frustration store: present/absent) ### Gaps worth building - Name [confidence: both|one] — desc. Evidence: N sessions, K frustration signals, recurring failure .... → CreateSkill? ### Covered (verified against bodies, no action) - theme → skill/loop/workflow ### Behavior-feedback (route to memory, not a skill) - theme ### Recommendation 1-2 sentences; nothing new is valid ONLY when the frustration signals are also clean注意模板的两个细节报告头必须标注frustration store: present/absent呼应 Step 0 的充分性检查nothing new 作为结论仅在挫败信号同样干净时才合法——否则就是漏报false negative。十、挫败数据从哪来SatisfactionCapture → ratings.jsonl 链路Scan 读的ratings.jsonl约定位于LIFEOS/MEMORY/LEARNING/SIGNALS/ratings.jsonl不是凭空出现的它由 SatisfactionCapture.hook.ts 在每次UserPromptSubmit时写入显式评分用户输入裸数字8、N/10 或英文数字形式ten→ 直接捕获评分 1–10正面表扬快路径≤2 个词的 praisegreat job、perfect→ 记为隐性评分 8并写sentiment_summary: Direct praise: ...显式纠正thats wrong、still broken 等精确短语匹配 → 捕获为 FAILURES 事件摘要即原话deterministic无推理长期指令from now on X → 写入 Upgrades 存储。评分 ≤ 3 时会进一步调用 FailureCapture.ts 生成完整失败上下文CONTEXT.mdtranscript.jsonlsentiment.jsontool-calls.json写入MEMORY/LEARNING/FAILURES/YYYY-MM/且写盘前会按 SECRET_SHAPES 规则对密钥、Bearer token、PEM 私钥等做[REDACTED]脱敏。理解这条链路对使用 Scan 很关键挫败信号的密度取决于日常评分采集的完备度。如果习惯性不评分、不纠正ratings store 就会偏空Scan 的挫败加权优势就无从发挥——这时报告会如实标注 frustration store 的状态提醒你信号不足。十一、常见误用与反模式Gotchas结合 SKILL.md 与工作流原文以下反模式必须避免干净覆盖 肮脏挫败 假阴性如果评分显示某个你已标记为已覆盖的领域仍有反复挫败必须重新打开它——该主题之下的纪律才是缺口。这正是本技能要修的问题复发按严重度加权不是裸计数三个琐碎会话不如一次漫长、痛苦、反复发生的迁移重要。高严重度、跨少量会话反复出现的痛苦即使低于任意阈值也够格行为不是技能太啰嗦、误解范围、重复提醒属于转向/反馈应路由到记忆/偏好而不是 CreateSkill收集必须确定性如果发现自己在工作流里手工 grep 存储请改用工具——手工收集会让运行不可复现评估失去意义路径是被发现的不是被假设的工具通过 flag/env/root 解析存储跨安装可用不要把某个 home 目录硬编码进去大工作存储只会让会话列表变长不会让分析更好默认 45 天窗口就是杠杆——刻意放宽它并预期聚类步骤承担成本。结语Scan 工作流把我该建什么技能从一个玄学问题变成了一个可复现的数据问题确定性收集CollectSignals.ts→ 按痛点聚类 → 三分类去重 → 双通道验证取并集 → 提议不创建。它的独特价值不在于统计话题频率而在于把挫败信号与纪律缺口摆到台面上——那些藏在已覆盖主题名之下、靠主题匹配永远看不见的洞正是 Scan 存在的理由。想继续深入可以阅读 工作流原文、技能总纲 与 收集器实现。【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考