jeo-code 0.11.5 → 0.12.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +27 -0
- package/README.ja.md +50 -3
- package/README.ko.md +50 -3
- package/README.md +36 -3
- package/README.zh.md +50 -3
- package/package.json +1 -1
- package/src/agent/engine.ts +15 -0
- package/src/agent/skill-router.ts +163 -0
- package/src/ai/model-cache.ts +79 -28
- package/src/ai/model-catalog.ts +38 -9
- package/src/ai/model-discovery.ts +77 -11
- package/src/ai/providers/antigravity.ts +6 -3
- package/src/commands/launch.ts +4 -1
- package/src/prompts/skills/karpathy-guidelines/AGENTS.md +32 -0
- package/src/prompts/skills/karpathy-guidelines/SKILL.md +90 -0
- package/src/skills/catalog.ts +2 -0
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Karpathy-derived behavioral guardrails for coding turns — think before coding, simplicity first, surgical changes, goal-driven execution. Use when writing, reviewing, or refactoring code.
|
|
3
|
+
command: $karpathy-guidelines
|
|
4
|
+
when: When writing, reviewing, or refactoring code — to avoid wrong assumptions, overcomplication, orthogonal edits, and unverified completion.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# karpathy-guidelines
|
|
8
|
+
|
|
9
|
+
Behavioral guardrails derived from Andrej Karpathy's observations on LLM coding
|
|
10
|
+
pitfalls (wrong silent assumptions, hidden confusion, overcomplicated code,
|
|
11
|
+
orthogonal edits, weak success criteria). Source:
|
|
12
|
+
`multica-ai/andrej-karpathy-skills` (`CLAUDE.md` + `skills/karpathy-guidelines`).
|
|
13
|
+
|
|
14
|
+
**Tradeoff:** these guidelines bias toward caution over speed. For trivial tasks
|
|
15
|
+
(simple typo fixes, obvious one-liners), use judgment — not every change needs
|
|
16
|
+
the full rigor. The goal is reducing costly mistakes on non-trivial work.
|
|
17
|
+
|
|
18
|
+
## 1. Think Before Coding
|
|
19
|
+
|
|
20
|
+
**Don't assume. Don't hide confusion. Surface tradeoffs.**
|
|
21
|
+
|
|
22
|
+
Before implementing:
|
|
23
|
+
|
|
24
|
+
- State assumptions explicitly. If uncertain, ask rather than guess.
|
|
25
|
+
- If multiple interpretations exist, present them — don't pick silently.
|
|
26
|
+
- If a simpler approach exists, say so. Push back when warranted.
|
|
27
|
+
- If something is unclear, stop. Name what's confusing. Ask.
|
|
28
|
+
|
|
29
|
+
In jeo terms: this is the `deep-interview` ambiguity gate applied at turn
|
|
30
|
+
scope. A `$deep-interview`-grade clarification belongs before code, not after
|
|
31
|
+
a mistaken implementation.
|
|
32
|
+
|
|
33
|
+
## 2. Simplicity First
|
|
34
|
+
|
|
35
|
+
**Minimum code that solves the problem. Nothing speculative.**
|
|
36
|
+
|
|
37
|
+
- No features beyond what was asked.
|
|
38
|
+
- No abstractions for single-use code.
|
|
39
|
+
- No "flexibility" or "configurability" that wasn't requested.
|
|
40
|
+
- No error handling for impossible scenarios.
|
|
41
|
+
- If 200 lines could be 50, rewrite it.
|
|
42
|
+
|
|
43
|
+
The test: would a senior engineer say this is overcomplicated? If yes,
|
|
44
|
+
simplify. Prefer boring, explicit code over clever constructions.
|
|
45
|
+
|
|
46
|
+
## 3. Surgical Changes
|
|
47
|
+
|
|
48
|
+
**Touch only what you must. Clean up only your own mess.**
|
|
49
|
+
|
|
50
|
+
When editing existing code:
|
|
51
|
+
|
|
52
|
+
- Don't "improve" adjacent code, comments, or formatting.
|
|
53
|
+
- Don't refactor things that aren't broken.
|
|
54
|
+
- Match existing style, even if you'd do it differently.
|
|
55
|
+
- If you notice unrelated dead code, mention it — don't delete it.
|
|
56
|
+
|
|
57
|
+
When your changes create orphans:
|
|
58
|
+
|
|
59
|
+
- Remove imports/variables/functions that YOUR changes made unused.
|
|
60
|
+
- Don't remove pre-existing dead code unless asked.
|
|
61
|
+
|
|
62
|
+
The test: every changed line should trace directly to the user's request.
|
|
63
|
+
|
|
64
|
+
## 4. Goal-Driven Execution
|
|
65
|
+
|
|
66
|
+
**Define success criteria. Loop until verified.**
|
|
67
|
+
|
|
68
|
+
Transform tasks into verifiable goals:
|
|
69
|
+
|
|
70
|
+
- "Add validation" → "Write tests for invalid inputs, then make them pass"
|
|
71
|
+
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
|
|
72
|
+
- "Refactor X" → "Ensure tests pass before and after"
|
|
73
|
+
|
|
74
|
+
For multi-step tasks, state a brief plan:
|
|
75
|
+
|
|
76
|
+
```
|
|
77
|
+
1. [Step] → verify: [check]
|
|
78
|
+
2. [Step] → verify: [check]
|
|
79
|
+
3. [Step] → verify: [check]
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
Strong success criteria let the loop run independently. Weak criteria
|
|
83
|
+
("make it work") require constant clarification. In jeo this maps directly
|
|
84
|
+
onto the done-verification gate (`loop-guards.ts`): no mutation without a
|
|
85
|
+
passing test/build/typecheck signal, and a stale verification after a later
|
|
86
|
+
edit does not count.
|
|
87
|
+
|
|
88
|
+
These guidelines are working if: fewer unnecessary changes in diffs, fewer
|
|
89
|
+
rewrites due to overcomplication, and clarifying questions come before
|
|
90
|
+
implementation rather than after mistakes.
|
package/src/skills/catalog.ts
CHANGED
|
@@ -3,6 +3,7 @@ import deepDiveSkillRaw from "../prompts/skills/deep-dive/SKILL.md" with { type:
|
|
|
3
3
|
import ralplanSkillRaw from "../prompts/skills/ralplan/SKILL.md" with { type: "text" };
|
|
4
4
|
import teamSkillRaw from "../prompts/skills/team/SKILL.md" with { type: "text" };
|
|
5
5
|
import ultragoalSkillRaw from "../prompts/skills/ultragoal/SKILL.md" with { type: "text" };
|
|
6
|
+
import karpathyGuidelinesSkillRaw from "../prompts/skills/karpathy-guidelines/SKILL.md" with { type: "text" };
|
|
6
7
|
|
|
7
8
|
const MAX_SKILL_SUMMARY_CHARS = 180;
|
|
8
9
|
const MAX_SKILL_DETAILS_CHARS = 8_000;
|
|
@@ -28,6 +29,7 @@ export const SKILLS: SkillDoc[] = [
|
|
|
28
29
|
parseSkillMarkdown("ralplan", ralplanSkillRaw),
|
|
29
30
|
parseSkillMarkdown("team", teamSkillRaw),
|
|
30
31
|
parseSkillMarkdown("ultragoal", ultragoalSkillRaw),
|
|
32
|
+
parseSkillMarkdown("karpathy-guidelines", karpathyGuidelinesSkillRaw),
|
|
31
33
|
];
|
|
32
34
|
export const BUILTIN_SKILL_NAMES = SKILLS.map(s => s.name.toLowerCase());
|
|
33
35
|
|