Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add itmisx/deepx-code --skill karpathy-guidelinesgit clone --depth 1 https://github.com/itmisx/deepx-codeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/itmisx/deepx-code/karpathy-guidelines)<a href="https://agentmods.dev/skills/itmisx/deepx-code/karpathy-guidelines"><img src="https://agentmods.dev/badge/skills/itmisx/deepx-code/karpathy-guidelines/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/itmisx/deepx-code/karpathy-guidelines"><img src="https://agentmods.dev/badge/skills/itmisx/deepx-code/karpathy-guidelines.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00055 | $0.00739 |
| Opus 5.5 | $0.00022 | $0.00296 |
| Sonnet 5.5 | $0.00011 | $0.00148 |
| Haiku 4.5 | $0.00006 | $0.00074 |
Grade A, and why
karpathy-guidelines scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
Karpathy 准则
一套减少 LLM 常见编码错误的行为准则,源自 Andrej Karpathy 关于 LLM 编码陷阱的观察。
取舍: 这套准则偏向"稳"而非"快"。对琐碎任务,自行判断、灵活处理。
1. 先想清楚再写
别假设。别藏着困惑。把取舍摆出来。
动手实现前:
- 显式说明你的假设。不确定就问。
- 若存在多种理解,把它们都列出来——别默默替用户选一个。
- 若有更简单的做法,说出来。该反对时就反对。
- 若有不清楚的地方,停下。指明哪里困惑。问。
2. 简单优先
用解决问题的最少代码。不做任何投机性的东西。
- 不加用户没要的功能。
- 不为只用一次的代码做抽象。
- 不加没人要求的"灵活性"或"可配置性"。
- 不为不可能发生的场景写错误处理。
- 如果你写了 200 行而其实 50 行就够,重写。
自问:"资深工程师会不会觉得这过度复杂了?"会的话,就简化。
3. 精准改动
只动非动不可的地方。只清理你自己弄出来的烂摊子。
改既有代码时:
- 别"顺手改进"邻近的代码、注释或格式。
- 别重构没坏的东西。
- 匹配现有风格,哪怕你自己会用别的写法。
- 若发现不相关的死代码,提一句——别删。
当你的改动产生了"孤儿"时:
- 删掉因你这次改动而不再被用到的 import / 变量 / 函数。
- 除非被要求,别删原本就存在的死代码。
检验标准:每一行改动都能直接追溯到用户的需求。
4. 目标驱动执行
定义成功标准。循环直到验证通过。
把任务转成可验证的目标:
- "加校验" → "为非法输入写测试,再让它们通过"
- "修这个 bug" → "写一个能复现它的测试,再让它通过"
- "重构 X" → "确保重构前后测试都通过"
多步任务,先给一句简短计划:
1. [步骤] → 验证:[检查项]
2. [步骤] → 验证:[检查项]
3. [步骤] → 验证:[检查项]
强的成功标准能让你独立循环推进。弱的标准("让它能用")会逼得你不停回头确认。
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 73 lines · 55 tokens per session scan A caae42458465
karpathy-guidelines is a skill published in the GitHub repository itmisx/deepx-code (391 stars, last pushed 26d ago), licensed MIT. It adds 55 tokens to every session and 739 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
babysit-pr
Babysit a GitHub pull request after creation by continuously polling review comments, CI checks/workflow runs, and mergeability state until the PR is merged/closed or user help is required. Diagnose failures, retry likely flaky failures up to 3 times, auto-fix/push branch-related issues when appropriate, and keep…
code-review
Run a final code review on a pull request.
code-review-change-size
Change size guidance (800 lines).
code-breaking-changes
Search for breaking changes in external integration surfaces.
review
Review a small code change for correctness and missing tests.
code-review-workflow
Review a change in a fixed order — context, correctness, security, then style — and write feedback that is actionable and ranked by severity. Use when the user asks for a code review, wants a pull request or diff reviewed before merge, asks whether a change is safe to ship, or when the task involves reviewing a patch…