Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| public:computer:antigravity [2026/01/22 23:18] – alex | public:computer:antigravity [2026/02/25 23:22] (current) – alex | ||
|---|---|---|---|
| Line 8: | Line 8: | ||
| ===== Settings ===== | ===== Settings ===== | ||
| * 오른쪽 상단 ' | * 오른쪽 상단 ' | ||
| + | * < | ||
| + | | ||
| + | 1. **Language**: | ||
| + | 2. **Tone**: Maintain a helpful, professional, | ||
| * Model 선택 | * Model 선택 | ||
| * 오른쪽 상단 ⚙️ Editor-Specific Settings -> Editor Settings 메뉴 -> Antigravity Settings 탭 -> Terminal Command Auto Execution 항목에서 Request Review | * 오른쪽 상단 ⚙️ Editor-Specific Settings -> Editor Settings 메뉴 -> Antigravity Settings 탭 -> Terminal Command Auto Execution 항목에서 Request Review | ||
| + | ==== Skills ==== | ||
| + | * [[https:// | ||
| + | <code markdown> | ||
| + | --- | ||
| + | name: karpathy-guidelines | ||
| + | description: | ||
| + | license: MIT | ||
| + | --- | ||
| + | |||
| + | # Karpathy Guidelines | ||
| + | |||
| + | Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy' | ||
| + | |||
| + | **Tradeoff: | ||
| + | |||
| + | ## 1. Think Before Coding | ||
| + | |||
| + | **Don' | ||
| + | |||
| + | Before implementing: | ||
| + | - State your assumptions explicitly. If uncertain, ask. | ||
| + | - If multiple interpretations exist, present them - don't pick silently. | ||
| + | - If a simpler approach exists, say so. Push back when warranted. | ||
| + | - If something is unclear, stop. Name what's confusing. Ask. | ||
| + | |||
| + | ## 2. Simplicity First | ||
| + | |||
| + | **Minimum code that solves the problem. Nothing speculative.** | ||
| + | |||
| + | - No features beyond what was asked. | ||
| + | - No abstractions for single-use code. | ||
| + | - No " | ||
| + | - No error handling for impossible scenarios. | ||
| + | - If you write 200 lines and it could be 50, rewrite it. | ||
| + | |||
| + | Ask yourself: "Would a senior engineer say this is overcomplicated?" | ||
| + | |||
| + | ## 3. Surgical Changes | ||
| + | |||
| + | **Touch only what you must. Clean up only your own mess.** | ||
| + | |||
| + | When editing existing code: | ||
| + | - Don't " | ||
| + | - Don't refactor things that aren't broken. | ||
| + | - Match existing style, even if you'd do it differently. | ||
| + | - If you notice unrelated dead code, mention it - don't delete it. | ||
| + | |||
| + | When your changes create orphans: | ||
| + | - Remove imports/ | ||
| + | - Don't remove pre-existing dead code unless asked. | ||
| + | |||
| + | The test: Every changed line should trace directly to the user's request. | ||
| + | |||
| + | ## 4. Goal-Driven Execution | ||
| + | |||
| + | **Define success criteria. Loop until verified.** | ||
| + | |||
| + | Transform tasks into verifiable goals: | ||
| + | - "Add validation" | ||
| + | - "Fix the bug" → "Write a test that reproduces it, then make it pass" | ||
| + | - " | ||
| + | |||
| + | For multi-step tasks, state a brief plan: | ||
| + | ``` | ||
| + | 1. [Step] → verify: [check] | ||
| + | 2. [Step] → verify: [check] | ||
| + | 3. [Step] → verify: [check] | ||
| + | ``` | ||
| + | |||
| + | Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification. | ||
| + | </ | ||
| ===== References ===== | ===== References ===== | ||
| + | |||
| + | * [[https:// | ||
| * [[https:// | * [[https:// | ||