andrej-karpathy-skills
- Repo stars 83
- Author repo 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.
- Fluxly category
- AI
- Author-declared agents
- No explicit declaration found; this is not inferred or tested compatibility
- Static check
- 88 / 100 · heuristic scan, not runtime safety proof
- Author / version / license
- @dmae97 · no license declared
- Fluxly token estimate
- Lean
- Fluxly setup estimate
- Plug-and-play
- External API key
- No requirement detected
- Detected OS requirements
- Unspecified
- Runtime requirements
- Unspecified
- Detected file/system behavior
-
- Read-only
- Detected network behavior
- Local-only
- Install commands
- None (reference only)
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
The current SKILL.md does not define a fixed output example. 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. Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.
sections -> Use when → OMK workflow → Output contract → Guardrails
terms -> 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.
files/cmd -> forrestchang/andrej-karpathy-skills · pass/fail
body sha256 -> bffb1e3bf840
Decide Fit First
Design Intent
How To Use It
Boundaries And Review