Andrej 技能审查
- 作者仓库星标 83
- 作者仓库 oh-my-kimi
andrej-karpathy-skills
Source basis: forrestchang/andrej-karpathy-skills at commit 2c606141936f1eeef17fa3043a72095b4765b9c2. This OMK skill is a compact adaptation, not a vendored copy of upstream prompts or code.
Use when
- Any non-trivial code change needs tight scope and proof.
- The request is ambiguous enough that silent assumptions could be wrong.
- A refactor or bugfix risks drive-by edits.
- You need to turn an imperative request into verifiable success criteria.
OMK workflow
- State assumptions and tradeoffs only when they affect the implementation path. Ask if ambiguity blocks safe progress.
- Define success as observable checks: tests, typecheck, lint, build, screenshots, replay, or exact output.
- Make the smallest change that satisfies the goal. Avoid speculative abstractions and features not requested.
- Touch only files directly tied to the request. Preserve existing style and avoid unrelated cleanup.
- Remove only dead code introduced by your own change unless the user asked for broader cleanup.
- Verify, inspect the diff, and report remaining risks honestly.
Output contract
Return:
- assumptions that mattered
- success criteria and checks
- changed files
- commands run
- pass/fail status
- risks or blocked items
Guardrails
- Do not broaden scope to improve adjacent code.
- Do not hide confusion behind a confident implementation.
- Do not claim completion without evidence.
- 流狐分类
- AI 智能
- 作者声明 Agent
- 未找到明确声明；不据此推断已兼容或已测试
- 静态检查
- 88 / 100 · 启发式扫描，不代表运行安全
- 作者 / 版本 / 许可
- @dmae97 · 未声明 license
- 流狐 Token 估算
- 低消耗
- 流狐接入估算
- 即装即用
- 是否需要外部 API Key
- 未发现要求
- 检测到的系统要求
- 未声明
- 底层运行要求
- 未声明
- 检测到的文件与系统行为
-
- 只读
- 检测到的网络行为
- 仅限本地
- 安装命令数
- 无（仅作为资料）
档案由构建时根据 SKILL.md 与安装命令自动衍生，可能与作者实际意图存在差异。
需要注意： 未限定 allowed-tools，默认拥有全部工具权限。
作者没有在当前 SKILL.md 中定义固定输出样例。Any non-trivial code change needs tight scope and proof. The request is ambiguous enough that silent assumptions could be wrong. A refactor or bugfix risks drive-by edits.
State assumptions and tradeoffs only when they affect the implementation path. Ask if ambiguity blocks safe progress. Define success as observable checks: tests, typecheck, lint, build, screenshots, replay, or exact output.
Return: assumptions that mattered success criteria and checks
Do not broaden scope to improve adjacent code. Do not hide confusion behind a confident implementation. Do not claim completion without evidence.
# andrej-karpathy-skills
Source basis: forrestchang/andrej-karpathy-skills at commit 2c606141936f1eeef17fa3043a72095b4765b9c2. This OMK skill is a compact adaptation, not a vendored copy of upstream prompts or code.
## Use when
- Any non-trivial code change needs tight scope and proof.
- The request is ambiguous enough that silent assumptions could be wrong.
- A refactor or bugfix risks drive-by edits.
- You need to turn an imperative request into verifiable success criteria.
## OMK workflow
1. State assumptions and tradeoffs only when they affect the implementation path. Ask if ambiguity blocks safe progress.
2. Define success as observable checks: tests, typecheck, lint, build, screenshots, replay, or exact output.
3. Make the smallest change that satisfies the goal. Avoid speculative abstractions and features not requested.
4. Touch only files directly tied to the request. Preserve existing style and avoid unrelated cleanup.
5. Remove only dead code introduced by your own change unless the user asked for broader cleanup.
6. Verify, inspect the diff, and report remaining risks honestly.
## Output contract
Return:
- assumptions that mattered
- success criteria and checks
- changed files
- commands run
- pass/fail status
- risks or blocked items
## Guardrails
- Do not broaden scope to improve adjacent code.
- Do not hide confusion behind a confident implementation.
- Do not claim completion without evidence.作者原文负责流程事实；流狐只索引当前章节、要点、文件与命令。
章节 -> Use when → OMK workflow → Output contract → Guardrails
要点 -> Source basis: forrestchang/andrej-karpathy-skills at commit 2c606141936f1eeef17fa3043a72095b4765b9c2. · - Any non-trivial code change needs tight scope and proof. · 1. State assumptions and tradeoffs only when they affect the implementation path. · - Do not broaden scope to improve adjacent code.
文件/命令 -> forrestchang/andrej-karpathy-skills · pass/fail
内容 SHA-256 -> bffb1e3bf840
方法与流程
适用与边界
原文中的明确线索
forrestchang/andrej-karpathy-skills、pass/fail