Agent安装
- 作者仓库星标 1,187
- 叉子 185
- 作者更新于 2026年6月14日 10:01
- 作者仓库 claude-code-skills
- 领域
- AI 智能
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @daymade · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- 未声明（默认跨平台）
- 底层运行要求
- Python
- 文件与系统权限
-
- 只读
- Shell 执行
- 允许写入 / 修改
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生，可能与作者实际意图存在差异。
需要注意： 未限定 allowed-tools，默认拥有全部工具权限。
---
name: llm-wiki-setup
description: Co-create a personal investment-research LLM Wiki (Andrej Karpathy's pattern) where the user's O…
category: AI 智能
runtime: Python
---
# llm-wiki-setup 输出预览
## PART A: 任务判断
- 适用问题：提示词、Agent 工作流、模型评估或自动化推理。
- 输入要求：目标材料、限制条件、期望输出和验收方式。
- 证据边界：围绕“★ 先读这一条（这个 skill 的灵魂） / 不碰的红线（Karpathy 原意，别 over-engineer） / 机制层 vs 规则层（贯穿全程的区分）”读取原文规则，不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断：确认你的需求是否属于提示词、Agent 工作流、模型评估或自动化推理，并标出输入、限制和预期结果。
- **02** 执行计划：优先按“★ 先读这一条（这个 skill 的灵魂） / 不碰的红线（Karpathy 原意，别 over-engineer） / 机制层 vs 规则层（贯穿全程的区分）”拆成步骤，说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果：给出可复制的命令、文件改动、检查清单或内容草稿，并说明如何继续迭代。
- **04** 风险边界：结合 读取文件、执行终端命令、写入/修改文件、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、执行终端命令、写入/修改文件；主要在本地完成；通常不需要额外 API Key。
- 先小样例验证，再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。原文没有稳定的斜杠命令要求。安装验证后通常全局生效，直接在对话里点名这个 Skill 并描述任务即可。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是：读取文件、执行终端命令、写入/修改文件。
先用一个小任务确认它会围绕“★ 先读这一条（这个 skill 的灵魂） / 不碰的红线（Karpathy 原意，别 over-engineer） / 机制层 vs 规则层（贯穿全程的区分）”工作；涉及文件或命令时，先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作；如果输出泛泛而谈，就补充输入、边界和验收标准后重跑。
---
name: llm-wiki-setup
description: Co-create a personal investment-research LLM Wiki (Andrej Karpathy's pattern) where the user's O…
category: AI 智能
source: daymade/claude-code-skills
---
# llm-wiki-setup
## 什么时候使用
- 投研知识分散难复用时，搭建个人 LLM Wiki 它用纯 Markdown、[[wikilink]]、grep 和本地脚本建立 vault 机制层 适合处理AI Agent、提示词、模型评估与自动化推理，核心价值是把输入、判断、执行、验…
- 面向提示词、Agent 工作流、模型评估或自动化推理，优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「★ 先读这一条（这个 skill 的灵魂） / 不碰的红线（Karpathy 原意，别 over-engineer） / 机制层 vs 规则层（贯穿全程的区分）」组织步骤，不把推断写成作者事实。
- 读取文件、执行终端命令、写入/修改文件；主要在本地完成；通常不需要额外 API Key。
- 先跑小样例，确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown，不编造命令、平台或依赖。作者原文负责流程事实；仓库文件负责来源和命令；流狐只补充适用场景、限制和质量判断。
skill "llm-wiki-setup" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> ★ 先读这一条（这个 skill 的灵魂） / 不碰的红线（Karpathy 原意，别 over-engineer） / 机制层 vs 规则层（贯穿全程的区分）
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> Python | 读取文件、执行终端命令、写入/修改文件 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
}LLM Wiki Setup（投研第二大脑共创）
帮用户搭一个金融投研专用 LLM Wiki（Karpathy 模式）：纯 markdown 文件 + [[wikilink]] 互联 + LLM 维护，知识随用复利。
但核心不是给一份投研模板——是引导用户把他自己的投资判断方式，提炼成他专属的 CLAUDE.md。
★ 先读这一条（这个 skill 的灵魂）
每个人用自己的语言、自己的投资偏好，建自己的 CLAUDE.md。
两个投资者看同一家公司，关注点可能完全不同——一个看「下季度订单能否超市场预期」，另一个看「管理层电话会上的语气和信心」。给他们同一份模板，就抹掉了让 wiki 有用的那个东西。
- ✅ 你的工作 = 访谈用户 → 提炼他的关注维度 → 用他的话写进 CLAUDE.md
- ❌ 你的失败 = 套一份「标准投研 schema」让他填空，或让他照抄
examples/
examples/investment-research-CLAUDE.md 是一个人长成的样子，给用户看可能性，禁止照抄。它像模板一样被搬走，这个 skill 就失败了。
不碰的红线（Karpathy 原意，别 over-engineer）
纯 markdown + wikilink + grep。不加 RAG / 向量库 / embedding。 知识靠预编译进结构化页「复利」，不是每次 query 重新检索原始文档——这是本模式相对 RAG 的根本区别，也是 Karpathy 的核心 idea。别加回任何检索层，别加 knowledge graph / 自动 health-check 之类机制（社区有些版本加了，那是 over-engineer）。
机制层 vs 规则层（贯穿全程的区分）
| 内容 | 处置 | |
|---|---|---|
| 机制层 | 三层目录 + wikilink + lint + git hook | ✅ 通用工程结构，scripts/init_vault.py 直接装 |
| 规则层 | 看哪些维度 / 怎么记观点 / 要不要分析师归属 / 怎么复盘 / 要长报告还是三行 | ❌ 用户的投资大脑，访谈长出来，绝不给模板 |
机制层照抄没问题（它是 Karpathy 模式的工程卫生，跟「你怎么投资」无关）。规则层照抄 = 背叛方法论。
工作流
Phase 0 — 判断意图
- 新建 vault → Phase 1
- 已有 vault，ingest 一份源 → 直接读
references/ingest_sop.md - 已有 vault，财报后复盘某标的 →
references/fulfillment_sop.md - query → 读 vault 的
index.md+ 相关页，带 citation 综合答；好答案回填 synthesis
Phase 1 — scaffold 机制层
python scripts/init_vault.py <目标目录>建空骨架（三层目录 + lint + hook 占位 + 空 index/log + CLAUDE 骨架）。这一步只装机制层，不写任何 schema。
Phase 2 — 访谈共创 CLAUDE.md ★核心步骤
读 references/interview.md，按它的 8 个维度一条条访谈用户，把回答用他自己的话写进 <vault>/CLAUDE.md 规则层的占位。
- 一次问一个维度，别一口气灌
- 用户不在乎的维度直接砍（极简 > 全面）
- 卡住才翻
examples/给灵感，明说「别抄，挑你戳中的」 - 自检：写好的 CLAUDE.md 像不像「这个人」？像通用模板就重来
Phase 3 — 启用防腐
cd <vault> && git init
git config core.hooksPath .githooks # local 配置，换机/重 clone 要重设
PYTHONUTF8=1 uv run --no-project --with pyyaml python3 scripts/lint-vault.py wiki # 确认绿灯Phase 4 — 首次 ingest 演示
拿用户一份真实的源（研报 / 电话会 / 纪要），按 references/ingest_sop.md 走一遍 HITL 5 卡点，让他亲眼看到 wiki 怎么从源长出来。用用户自己的素材，不要用 examples。
后续运营（按需读 references）
| 场景 | 读 |
|---|---|
| ingest 新源 | references/ingest_sop.md（doc_type 用用户自己定的分类） |
| 财报后复盘 | references/fulfillment_sop.md（分析师回测调 analyst-track-record skill，别重造） |
| vault 卫生（派生值漂移） | references/prune_discipline.md |
| 复盘页对抗审查 | references/counter_review.md |
| 怎么访谈提炼用户的投资大脑 | references/interview.md（Phase 2 的完整方法） |
为什么这个 skill 是 inline（不设 context: fork）
它要调 analyst-track-record skill（复盘回测）、跑 Bash（scaffold / lint）、可能并行 Task 取财报数据——subagent 不能调 skill 或 spawn subagent，所以必须 inline。
Next Step
vault 搭好、用户开始 ingest 卖方研报后，如果他想回测某分析师过去准不准 → 建议接 analyst-track-record skill（双维度命中率，有 validated 脚本）。
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核