Karpathy Guidelines

基于 Andrej Karpathy 观察的编码指南。用于编写、审查或重构代码时，避免过度复杂化、进行精准修改、表面化假设，并定义可验证的成功标准。

Security Scan

This is an instruction-only coding-guidelines skill whose requested resources and instructions are consistent with its stated purpose.

Purpose & Capability

Name/description match the content: the skill is a prose guideline for writing/reviewing code. It does not request credentials, binaries, or config paths unrelated to that purpose.

Instruction Scope

SKILL.md contains only behavioral guidelines for coding, review, and verification. It mentions optionally triggering a 'self-improving-agent' for post-task reflection and updating a repository file 'references/learnings.md' — these are within the scope of a developer workflow but are external actions the agent could take, so users should confirm they want the agent to write project files or invoke other skills.

Install Mechanism

No install spec and no code files — no binaries or downloads will be written to disk by this skill.

Credentials

The skill requests no environment variables, credentials, or config paths. Nothing appears disproportionate to a guidelines document.

Persistence & Privilege

always is false and model invocation is allowed (the platform default). The skill does not request permanent presence or elevated agent-wide changes.

Scan Findings in Context

[no_regex_findings] expected: The static scanner had no code files to analyze. This is expected for an instruction-only SKILL.md.

Assessment

This skill is a plain set of coding and review guidelines and is internally consistent. Before installing, decide whether you want autonomous agents to be allowed to (a) write project files like references/learnings.md and (b) trigger other skills such as a 'self-improving-agent' — if you do not want those behaviors, ensure your agent policy or prompts prevent automatic file writes or cross-skill invocation. Otherwise this skill appears safe and proportional to its stated purpose.

Karpathy 编码指南

源自 Andrej Karpathy 的观察，用于减少 LLM 编码常见错误的行为指南。

权衡： 这些指南偏向谨慎而非速度。对于简单任务，使用判断力。

1. 编码前思考 (Think Before Coding)

不要假设。不要隐藏困惑。表面化权衡。

在实现之前：

• 明确陈述你的假设。如果不确定，请问。
• 如果存在多种解释，呈现它们——不要静默选择。
• 如果存在更简单的方法，说出来。在合理的情况下push back。
• 如果某事不清楚，停下来。说出困惑所在。请澄清。

2. 简单优先 (Simplicity First)

解决问题所需的最小代码。没有投机性代码。

• 不要添加超出要求的特性。
• 不要为单一用途代码创建抽象。
• 不要添加未被要求的"灵活性"或"可配置性"。
• 不要为不可能的场景添加错误处理。
• 如果你能写50行但写了200行，重写。

问自己："高级工程师会说这过度复杂吗？"如果是的，简化。

3. 精准修改 (Surgical Changes)

只触碰必须触碰的。只清理你自己的烂摊子。

编辑现有代码时：

• 不要"改进"相邻代码、注释或格式。
• 不要重构没有坏的部分。
• 匹配现有风格，即使你会有所不同。
• 如果你注意到无关的死代码，提出来——不要删除。

当你的更改造成孤立内容时：

• 删除因你的更改而未使用的导入/变量/函数。
• 除非被要求，否则不要删除预先存在的死代码。

验证标准：每一行更改都应该可以直接追溯到用户的请求。

4. 目标驱动执行 (Goal-Driven Execution)

定义成功标准。循环验证直到达成。

将任务转化为可验证的目标：

• "添加验证" → "为无效输入编写测试，然后让它们通过"
• "修复bug" → "编写一个复现它的测试，然后让测试通过"
• "重构X" → "确保之前和之后测试都通过"

对于多步骤任务，简述计划：

1. [步骤] → 验证: [检查]
2. [步骤] → 验证: [检查]
3. [步骤] → 验证: [检查]

强有力的成功标准让你能够独立循环。弱标准（"让它工作"）需要持续澄清。

激活时机

在以下情况下自动激活：

• 编写新代码时
• 审查或重构现有代码时
• 面对复杂决策时
• 用户要求"检查代码质量"或"审查"时

与自我改进Agent的协作

当完成编码任务后，可以触发 self-improving-agent 进行反思：

• 决策是否合理？
• 是否有更简单的方案？
• 学到了什么？

更新 references/learnings.md 记录经验教训。

---

最小化代码，最大化效果。