{"id":"d5b3202f-81a7-4edf-b830-7c5453ca481c","entityType":"agent","slug":"clawhub-gmvp3-karpathy-engineering-guidelines","name":"Karpathy Guidelines","canonicalUrl":"https://www.xpersona.co/agent/clawhub-gmvp3-karpathy-engineering-guidelines","canonicalPath":"/agent/clawhub-gmvp3-karpathy-engineering-guidelines","generatedAt":"2026-10-10T07:40:01.385Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-09T21:30:18.047Z","emptyReason":null},"description":"engineering execution guardrails for coding, implementing features, fixing bugs, debugging failures, reviewing diffs, refactoring code, simplifying overbuilt... Skill: Karpathy Guidelines Owner: gmvp3 Summary: engineering execution guardrails for coding, implementing features, fixing bugs, debugging failures, reviewing diffs, refactoring code, simplifying overbuilt... Tags: latest:1.0.3 Version history: v1.0.3 | 2026-05-19T02:39:40.401Z | user Add agent-era engineering discipline: deterministic logic in code, read-before-write, explicit conflicts, intent-focused tests, check","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 2K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s178cextnnpf4qperwwzm27py984wm6f:karpathy-engineering-guidelines","sourceUrl":"https://clawhub.ai/gmvp3/karpathy-engineering-guidelines","homepage":"https://clawhub.ai/gmvp3/skills/karpathy-engineering-guidelines","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/gmvp3/karpathy-engineering-guidelines","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/gmvp3/skills/karpathy-engineering-guidelines","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":66,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"engineering execution guardrails for coding, implementing features, fixing bugs, debugging failures, reviewing diffs, refactoring code, simplifying overbuilt..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T21:30:18.047Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T21:30:18.047Z","emptyReason":null},"stars":null,"forks":null,"downloads":1978,"packageName":null,"latestVersion":"1.0.3","tractionLabel":"2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T21:30:18.047Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T21:30:18.047Z","lastCrawledAt":"2026-10-09T21:30:18.047Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T21:30:18.047Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.3","createdAt":"2026-05-19T02:39:40.401Z","changelog":"Add agent-era engineering discipline: deterministic logic in code, read-before-write, explicit conflicts, intent-focused tests, checkpoints, and visible skipped work.","fileCount":4,"zipByteSize":4814},{"version":"1.0.2","createdAt":"2026-04-15T05:25:43.791Z","changelog":"- Minor edit to the description for clarity: now says \"use for choosing implementation approaches, editing code safely...\" instead of \"use when chatgpt needs to choose...\" - No changes to the skill name or substantive guidance content.","fileCount":3,"zipByteSize":2986},{"version":"1.0.1","createdAt":"2026-04-15T05:11:41.243Z","changelog":"- Expanded and clarified the skill description for broader coverage of engineering activities. - Improved language for greater precision and conciseness throughout. - Refined rules for simplicity, scope control, and verification, emphasizing actionable decision frames. - Updated guidance sections to clarify preferred behaviors for debugging, reviewing, implementing, and planning. - Tightened response expectations to stress concise reporting and discipline in action, not explanation.","fileCount":3,"zipByteSize":2994},{"version":"1.0.0","createdAt":"2026-04-15T04:32:41.105Z","changelog":"## 1.0.0 - Initial OpenClaw-compatible release - Ported the original karpathy-guidelines into a standalone skill - Added OpenClaw-friendly `SKILL.md` structure - Added `agents/openai.yaml` metadata - Removed Claude-specific plugin/install scaffolding ## 1.0.0 首次发布 OpenClaw 版本。 - 将原始 karpathy-guidelines 整理为可发布的 OpenClaw skill - 保留核心工程实践指导内容 - 调整为适合 skill 加载的目录结构 - 补充 `agents/openai.yaml` 元数据 - 移除 Claude Code 专用的插件与安装层","fileCount":3,"zipByteSize":2987}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s178cextnnpf4qperwwzm27py984wm6f:karpathy-engineering-guidelines","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gmvp3-karpathy-engineering-guidelines/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gmvp3-karpathy-engineering-guidelines/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gmvp3-karpathy-engineering-guidelines/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-gmvp3-karpathy-engineering-guidelines/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-gmvp3-karpathy-engineering-guidelines/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-gmvp3-karpathy-engineering-guidelines/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T07:40:01.384Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gmvp3-karpathy-engineering-guidelines/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gmvp3-karpathy-engineering-guidelines/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gmvp3-karpathy-engineering-guidelines/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gmvp3-karpathy-engineering-guidelines/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-09T21:30:18.047Z","emptyReason":null},"readme":"Skill: Karpathy Guidelines\n\nOwner: gmvp3\n\nSummary: engineering execution guardrails for coding, implementing features, fixing bugs, debugging failures, reviewing diffs, refactoring code, simplifying overbuilt...\n\nTags: latest:1.0.3\n\nVersion history:\n\nv1.0.3 | 2026-05-19T02:39:40.401Z | user\n\nAdd agent-era engineering discipline: deterministic logic in code, read-before-write, explicit conflicts, intent-focused tests, checkpoints, and visible skipped work.\n\nv1.0.2 | 2026-04-15T05:25:43.791Z | user\n\n- Minor edit to the description for clarity: now says \"use for choosing implementation approaches, editing code safely...\" instead of \"use when chatgpt needs to choose...\"\n- No changes to the skill name or substantive guidance content.\n\nv1.0.1 | 2026-04-15T05:11:41.243Z | user\n\n- Expanded and clarified the skill description for broader coverage of engineering activities.\n- Improved language for greater precision and conciseness throughout.\n- Refined rules for simplicity, scope control, and verification, emphasizing actionable decision frames.\n- Updated guidance sections to clarify preferred behaviors for debugging, reviewing, implementing, and planning.\n- Tightened response expectations to stress concise reporting and discipline in action, not explanation.\n\nv1.0.0 | 2026-04-15T04:32:41.105Z | user\n\n## 1.0.0\n\n- Initial OpenClaw-compatible release\n- Ported the original karpathy-guidelines into a standalone skill\n- Added OpenClaw-friendly `SKILL.md` structure\n- Added `agents/openai.yaml` metadata\n- Removed Claude-specific plugin/install scaffolding\n\n## 1.0.0\n\n首次发布 OpenClaw 版本。\n\n- 将原始 karpathy-guidelines 整理为可发布的 OpenClaw skill\n- 保留核心工程实践指导内容\n- 调整为适合 skill 加载的目录结构\n- 补充 `agents/openai.yaml` 元数据\n- 移除 Claude Code 专用的插件与安装层\n\nArchive index:\n\nArchive v1.0.3: 4 files, 4814 bytes\n\nFiles: agents/openai.yaml (159b), skill-card.md (1919b), SKILL.md (7020b), _meta.json (150b)\n\nFile v1.0.3:SKILL.md\n\n---\nname: karpathy-guidelines\ndescription: engineering execution guardrails for coding, implementing features, fixing bugs, debugging failures, reviewing diffs, refactoring code, simplifying overbuilt solutions, and planning multi-step code changes. use for choosing implementation approaches, editing code safely, reviewing correctness and scope, reducing unnecessary complexity, surfacing hidden assumptions, deciding what belongs in deterministic code rather than model judgment, defining concrete verification steps, and keeping software tasks to the smallest effective change.\n---\n\n# Karpathy Guidelines\n\nApply this skill to non-trivial software engineering work. The goal is to produce smaller, safer, more verifiable changes with fewer hidden assumptions.\n\nFor trivial edits such as a typo, a one-line mechanical rename, or an obvious localized fix, use judgment and do not add ceremony.\n\n## Default operating loop\n\nFor non-trivial tasks, follow this sequence:\n\n1. Restate the task in concrete engineering terms.\n2. Read the nearest relevant callers, utilities, tests, and conventions before editing.\n3. Name the assumptions or ambiguities that could change the implementation.\n4. Choose the smallest viable approach.\n5. Make only the changes required for that approach.\n6. Verify the result with concrete checks.\n7. Report what changed, how it was verified, and any remaining uncertainty.\n\nWhen useful, think in this compact frame before acting:\n\n- **assumptions:** what must be true\n- **read:** the nearby evidence that guides the change\n- **plan:** the minimum set of steps\n- **verify:** the checks that define success\n\n## Core rules\n\n### 1. Think before coding\n\nDo not silently pick an interpretation when the request is ambiguous.\n\n- State assumptions that materially affect design or code changes.\n- Surface the main options when multiple interpretations would lead to different implementations.\n- Prefer the lower-risk interpretation when it still satisfies the request.\n- Stop and call out conflicts between the request, the prompt, and the codebase.\n- Push back on complexity when a simpler path clearly achieves the goal.\n\n### 2. Simplicity first\n\nImplement the minimum change that solves the actual problem.\n\n- Do not add features that were not requested.\n- Do not add abstractions for a single use case unless the local codebase already needs that pattern.\n- Do not introduce flags, extension points, or configuration without a present need.\n- Prefer straightforward control flow over cleverness.\n- Prefer the substantially smaller solution when two options achieve the same result.\n\nUse this test: would a strong senior engineer call this overbuilt for the current requirement? If yes, simplify.\n\n### 3. Surgical changes\n\nTouch only what the request requires.\n\n- Do not refactor adjacent code just because you noticed something better.\n- Do not reformat, rename, or reorganize unrelated code.\n- Match existing local style and patterns unless the task explicitly asks for a broader change.\n- Remove imports, variables, functions, or files that become unused because of your own change.\n- Mention unrelated dead code or separate bugs without changing them unless they block the requested work.\n\nEvery changed line should trace back to the request or to a direct dependency of the request.\n\n### 4. Goal-driven execution\n\nConvert vague requests into verifiable outcomes.\n\n- For bug fixes: reproduce or isolate the failure, apply the fix, then verify the failure is gone.\n- For new features: define observable acceptance checks before implementation.\n- For refactors: preserve behavior with tests, builds, or focused before-and-after checks.\n- For risky edits: prefer incremental steps with verification after each step.\n- For multi-step tasks: say what each step will prove before moving on.\n- Write tests that assert the intended behavior or invariant, not just tests that execute the changed code.\n\nWeak success criteria such as \"make it work\" are not enough. Anchor the work to a checkable result.\n\n### 5. Agent-era discipline\n\nTreat coding agents as accelerators for engineering work, not as a place to hide deterministic product logic.\n\n- Put parsing, validation, routing, migrations, retry policy, and other deterministic decisions in code or tests instead of relying on model judgment.\n- Read local code before writing. Nearby callers, helper functions, fixtures, and error paths are usually more authoritative than a generic plan.\n- When the codebase shows conflicting patterns, expose the conflict and choose a specific precedent instead of averaging them together.\n- Make skipped work visible. If tests, data, migrations, tool output, or credentials are unavailable, say exactly what was skipped and why.\n- For long agent loops, checkpoint before continuing: summarize what has been tried, what evidence changed, and what the next verification step proves.\n- Prefer explicit failure over silent fallback when missing data or ambiguous state would make the result misleading.\n\n## Task-specific guidance\n\n### When implementing code\n\n- Prefer the smallest diff that meets the requirement.\n- Reuse existing utilities before creating new ones.\n- Keep existing comments unless they become inaccurate because of your change.\n- Do not broaden API surface area without a demonstrated need.\n- Do not use an LLM call as a hidden parser, validator, or policy engine when ordinary code can express the rule.\n\n### When debugging\n\n- Narrow the failure mode before changing code.\n- Prefer evidence from tests, logs, traces, or a minimal reproduction over guesswork.\n- Separate confirmed facts from hypotheses.\n- After fixing, verify both the target bug and the nearest likely regression boundary.\n- If a tool, fixture, or environment dependency fails, surface that failure instead of treating missing evidence as success.\n\n### When reviewing code\n\n- Focus first on correctness, simplicity, scope control, and verification.\n- Flag hidden assumptions, unnecessary abstractions, and unrelated changes.\n- Flag silent fallbacks, unverifiable claims, and places where deterministic behavior depends on model judgment.\n- Distinguish must-fix issues from optional improvements.\n- Prefer comments that point to concrete risk or a simpler alternative.\n\n### When planning work\n\n- Offer the minimum viable plan first.\n- Include explicit verification points.\n- Mention tradeoffs only when they materially affect implementation or risk.\n- Avoid speculative future-proofing unless the task is explicitly about architecture.\n- For long tasks, define checkpoint moments where the plan can be corrected using fresh evidence.\n\n## Response expectations\n\nFor non-trivial engineering tasks, the final response should usually include:\n\n- what changed or what should change\n- the key assumption or tradeoff, if any\n- how the result was verified or should be verified\n- any remaining risk, uncertainty, or directly relevant follow-up\n\nKeep the response concise. Let the discipline show up in the work rather than in long explanations.\n\nFile v1.0.3:_meta.json\n\n{\n  \"ownerId\": \"kn7ca14yv5ext6a8r07mrwaws1821snr\",\n  \"slug\": \"karpathy-engineering-guidelines\",\n  \"version\": \"1.0.3\",\n  \"publishedAt\": 1779158380401\n}\n\nFile v1.0.3:skill-card.md\n\n## Description:\n\nKarpathy Guidelines provides engineering execution guardrails for coding, bug fixing, debugging, review, refactoring, planning, and verification.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[gmvp3](https://clawhub.ai/user/gmvp3)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and coding agents use this skill to keep non-trivial software changes focused, evidence-driven, and verifiable while avoiding unnecessary abstractions and unrelated edits.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can influence how an agent approaches substantive coding tasks and may add process to larger tasks.\n\nMitigation: Apply it to non-trivial software engineering work and skip extra ceremony for trivial localized edits, as the skill directs.\n\nRisk: Engineering guidance can still lead to incorrect changes if assumptions, skipped checks, or verification gaps are not made visible.\n\nMitigation: Require concrete local evidence before editing, keep changes scoped, and report verification results and remaining uncertainty.\n\n## Reference(s):\n\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown guidance with implementation plans, review notes, code snippets, shell commands, configuration suggestions, and verification steps.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [No executable code is included in the artifact; outputs are guidance for an agent's software engineering workflow.]\n\n## Skill Version(s):\n\n1.0.3 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v1.0.3:agents/openai.yaml\n\ninterface:\n  display_name: \"Karpathy Guidelines\"\n  short_description: \"Engineering guardrails for smaller diffs, clearer reasoning, and stronger verification\"\n\nArchive v1.0.2: 3 files, 2986 bytes\n\nFiles: agents/openai.yaml (159b), SKILL.md (5263b), _meta.json (150b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: karpathy-guidelines\ndescription: engineering execution guardrails for coding, implementing features, fixing bugs, debugging failures, reviewing diffs, refactoring code, simplifying overbuilt solutions, and planning multi-step code changes. use for choosing implementation approaches, editing code safely, reviewing correctness and scope, reducing unnecessary complexity, surfacing hidden assumptions, defining concrete verification steps, and keeping software tasks to the smallest effective change.\n---\n\n# Karpathy Guidelines\n\nApply this skill to non-trivial software engineering work. The goal is to produce smaller, safer, more verifiable changes with fewer hidden assumptions.\n\nFor trivial edits such as a typo, a one-line mechanical rename, or an obvious localized fix, use judgment and do not add ceremony.\n\n## Default operating loop\n\nFor non-trivial tasks, follow this sequence:\n\n1. Restate the task in concrete engineering terms.\n2. Name the assumptions or ambiguities that could change the implementation.\n3. Choose the smallest viable approach.\n4. Make only the changes required for that approach.\n5. Verify the result with concrete checks.\n6. Report what changed, how it was verified, and any remaining uncertainty.\n\nWhen useful, think in this compact frame before acting:\n\n- **assumptions:** what must be true\n- **plan:** the minimum set of steps\n- **verify:** the checks that define success\n\n## Core rules\n\n### 1. Think before coding\n\nDo not silently pick an interpretation when the request is ambiguous.\n\n- State assumptions that materially affect design or code changes.\n- Surface the main options when multiple interpretations would lead to different implementations.\n- Prefer the lower-risk interpretation when it still satisfies the request.\n- Stop and call out conflicts between the request, the prompt, and the codebase.\n- Push back on complexity when a simpler path clearly achieves the goal.\n\n### 2. Simplicity first\n\nImplement the minimum change that solves the actual problem.\n\n- Do not add features that were not requested.\n- Do not add abstractions for a single use case unless the local codebase already needs that pattern.\n- Do not introduce flags, extension points, or configuration without a present need.\n- Prefer straightforward control flow over cleverness.\n- Prefer the substantially smaller solution when two options achieve the same result.\n\nUse this test: would a strong senior engineer call this overbuilt for the current requirement? If yes, simplify.\n\n### 3. Surgical changes\n\nTouch only what the request requires.\n\n- Do not refactor adjacent code just because you noticed something better.\n- Do not reformat, rename, or reorganize unrelated code.\n- Match existing local style and patterns unless the task explicitly asks for a broader change.\n- Remove imports, variables, functions, or files that become unused because of your own change.\n- Mention unrelated dead code or separate bugs without changing them unless they block the requested work.\n\nEvery changed line should trace back to the request or to a direct dependency of the request.\n\n### 4. Goal-driven execution\n\nConvert vague requests into verifiable outcomes.\n\n- For bug fixes: reproduce or isolate the failure, apply the fix, then verify the failure is gone.\n- For new features: define observable acceptance checks before implementation.\n- For refactors: preserve behavior with tests, builds, or focused before-and-after checks.\n- For risky edits: prefer incremental steps with verification after each step.\n- For multi-step tasks: say what each step will prove before moving on.\n\nWeak success criteria such as \"make it work\" are not enough. Anchor the work to a checkable result.\n\n## Task-specific guidance\n\n### When implementing code\n\n- Prefer the smallest diff that meets the requirement.\n- Reuse existing utilities before creating new ones.\n- Keep existing comments unless they become inaccurate because of your change.\n- Do not broaden API surface area without a demonstrated need.\n\n### When debugging\n\n- Narrow the failure mode before changing code.\n- Prefer evidence from tests, logs, traces, or a minimal reproduction over guesswork.\n- Separate confirmed facts from hypotheses.\n- After fixing, verify both the target bug and the nearest likely regression boundary.\n\n### When reviewing code\n\n- Focus first on correctness, simplicity, scope control, and verification.\n- Flag hidden assumptions, unnecessary abstractions, and unrelated changes.\n- Distinguish must-fix issues from optional improvements.\n- Prefer comments that point to concrete risk or a simpler alternative.\n\n### When planning work\n\n- Offer the minimum viable plan first.\n- Include explicit verification points.\n- Mention tradeoffs only when they materially affect implementation or risk.\n- Avoid speculative future-proofing unless the task is explicitly about architecture.\n\n## Response expectations\n\nFor non-trivial engineering tasks, the final response should usually include:\n\n- what changed or what should change\n- the key assumption or tradeoff, if any\n- how the result was verified or should be verified\n- any remaining risk, uncertainty, or directly relevant follow-up\n\nKeep the response concise. Let the discipline show up in the work rather than in long explanations.\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn7ca14yv5ext6a8r07mrwaws1821snr\",\n  \"slug\": \"karpathy-engineering-guidelines\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1776230743791\n}\n\nFile v1.0.2:agents/openai.yaml\n\ninterface:\n  display_name: \"Karpathy Guidelines\"\n  short_description: \"Engineering guardrails for smaller diffs, clearer reasoning, and stronger verification\"\n\nArchive v1.0.1: 3 files, 2994 bytes\n\nFiles: agents/openai.yaml (159b), SKILL.md (5265b), _meta.json (150b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: karpathy-guidelines\ndescription: engineering execution guardrails for coding, implementing features, fixing bugs, debugging failures, reviewing diffs, refactoring code, simplifying overbuilt solutions, and planning multi-step code changes. use when chatgpt needs to choose an implementation approach, edit code safely, review correctness and scope, reduce unnecessary complexity, surface hidden assumptions, define concrete verification steps, or keep a software task to the smallest effective change.\n---\n\n# Karpathy Guidelines\n\nApply this skill to non-trivial software engineering work. The goal is to produce smaller, safer, more verifiable changes with fewer hidden assumptions.\n\nFor trivial edits such as a typo, a one-line mechanical rename, or an obvious localized fix, use judgment and do not add ceremony.\n\n## Default operating loop\n\nFor non-trivial tasks, follow this sequence:\n\n1. Restate the task in concrete engineering terms.\n2. Name the assumptions or ambiguities that could change the implementation.\n3. Choose the smallest viable approach.\n4. Make only the changes required for that approach.\n5. Verify the result with concrete checks.\n6. Report what changed, how it was verified, and any remaining uncertainty.\n\nWhen useful, think in this compact frame before acting:\n\n- **assumptions:** what must be true\n- **plan:** the minimum set of steps\n- **verify:** the checks that define success\n\n## Core rules\n\n### 1. Think before coding\n\nDo not silently pick an interpretation when the request is ambiguous.\n\n- State assumptions that materially affect design or code changes.\n- Surface the main options when multiple interpretations would lead to different implementations.\n- Prefer the lower-risk interpretation when it still satisfies the request.\n- Stop and call out conflicts between the request, the prompt, and the codebase.\n- Push back on complexity when a simpler path clearly achieves the goal.\n\n### 2. Simplicity first\n\nImplement the minimum change that solves the actual problem.\n\n- Do not add features that were not requested.\n- Do not add abstractions for a single use case unless the local codebase already needs that pattern.\n- Do not introduce flags, extension points, or configuration without a present need.\n- Prefer straightforward control flow over cleverness.\n- Prefer the substantially smaller solution when two options achieve the same result.\n\nUse this test: would a strong senior engineer call this overbuilt for the current requirement? If yes, simplify.\n\n### 3. Surgical changes\n\nTouch only what the request requires.\n\n- Do not refactor adjacent code just because you noticed something better.\n- Do not reformat, rename, or reorganize unrelated code.\n- Match existing local style and patterns unless the task explicitly asks for a broader change.\n- Remove imports, variables, functions, or files that become unused because of your own change.\n- Mention unrelated dead code or separate bugs without changing them unless they block the requested work.\n\nEvery changed line should trace back to the request or to a direct dependency of the request.\n\n### 4. Goal-driven execution\n\nConvert vague requests into verifiable outcomes.\n\n- For bug fixes: reproduce or isolate the failure, apply the fix, then verify the failure is gone.\n- For new features: define observable acceptance checks before implementation.\n- For refactors: preserve behavior with tests, builds, or focused before-and-after checks.\n- For risky edits: prefer incremental steps with verification after each step.\n- For multi-step tasks: say what each step will prove before moving on.\n\nWeak success criteria such as \"make it work\" are not enough. Anchor the work to a checkable result.\n\n## Task-specific guidance\n\n### When implementing code\n\n- Prefer the smallest diff that meets the requirement.\n- Reuse existing utilities before creating new ones.\n- Keep existing comments unless they become inaccurate because of your change.\n- Do not broaden API surface area without a demonstrated need.\n\n### When debugging\n\n- Narrow the failure mode before changing code.\n- Prefer evidence from tests, logs, traces, or a minimal reproduction over guesswork.\n- Separate confirmed facts from hypotheses.\n- After fixing, verify both the target bug and the nearest likely regression boundary.\n\n### When reviewing code\n\n- Focus first on correctness, simplicity, scope control, and verification.\n- Flag hidden assumptions, unnecessary abstractions, and unrelated changes.\n- Distinguish must-fix issues from optional improvements.\n- Prefer comments that point to concrete risk or a simpler alternative.\n\n### When planning work\n\n- Offer the minimum viable plan first.\n- Include explicit verification points.\n- Mention tradeoffs only when they materially affect implementation or risk.\n- Avoid speculative future-proofing unless the task is explicitly about architecture.\n\n## Response expectations\n\nFor non-trivial engineering tasks, the final response should usually include:\n\n- what changed or what should change\n- the key assumption or tradeoff, if any\n- how the result was verified or should be verified\n- any remaining risk, uncertainty, or directly relevant follow-up\n\nKeep the response concise. Let the discipline show up in the work rather than in long explanations.\n\nFile v1.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn7ca14yv5ext6a8r07mrwaws1821snr\",\n  \"slug\": \"karpathy-engineering-guidelines\",\n  \"version\": \"1.0.1\",\n  \"publishedAt\": 1776229901243\n}\n\nFile v1.0.1:agents/openai.yaml\n\ninterface:\n  display_name: \"Karpathy Guidelines\"\n  short_description: \"Engineering guardrails for smaller diffs, clearer reasoning, and stronger verification\"\n\nArchive v1.0.0: 3 files, 2987 bytes\n\nFiles: agents/openai.yaml (148b), SKILL.md (5116b), _meta.json (150b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: karpathy-guidelines\ndescription: behavioral guardrails for coding, code review, debugging, refactoring, and other engineering tasks. use when an agent is about to change code, design an implementation, review a diff, or plan a multi-step fix and should avoid hidden assumptions, overengineering, unrelated edits, and weak success criteria.\n---\n\n# Karpathy Guidelines\n\n## Overview\n\nApply these rules during non-trivial engineering work. The goal is to reduce silent assumptions, bloated implementations, unrelated edits, and vague definitions of success.\n\nFor trivial changes such as an obvious typo or a one-line mechanical fix, use judgment and avoid unnecessary ceremony.\n\n## Default operating loop\n\nFor non-trivial tasks, follow this sequence:\n\n1. Restate the task in concrete engineering terms.\n2. Name any assumptions or ambiguities that could change the implementation.\n3. Choose the smallest viable approach.\n4. Make only the changes required for that approach.\n5. Verify the result with concrete checks.\n6. Report what changed, how it was verified, and any remaining uncertainty.\n\nWhen it helps, start with this compact structure:\n\n- **assumptions:** what you believe to be true\n- **plan:** the minimum set of steps\n- **verify:** how success will be checked\n\n## Core rules\n\n### 1. Think before coding\n\nDo not silently pick an interpretation when the request is ambiguous.\n\n- State assumptions that materially affect design or code changes.\n- If there are multiple plausible interpretations, surface the main options.\n- If one interpretation is clearly lower risk, say so and prefer it.\n- If the task conflicts with evidence in the codebase or prompt, stop and call that out.\n- If a simpler path satisfies the goal, push back on the more complex path.\n\n### 2. Simplicity first\n\nImplement the minimum change that solves the actual problem.\n\n- Do not add features that were not requested.\n- Do not add abstractions for a single use case unless the local codebase already requires that pattern.\n- Do not introduce configurability, flags, or extension points without a real current need.\n- Prefer straightforward control flow over cleverness.\n- If the same outcome can be achieved with substantially less code, prefer the smaller version.\n\nUse this test: would a strong senior engineer call this overbuilt for the requirement at hand? If yes, simplify.\n\n### 3. Surgical changes\n\nTouch only what the request requires.\n\n- Do not refactor adjacent code just because you noticed something better.\n- Do not reformat, rename, or reorganize unrelated code.\n- Match existing local style and patterns unless the task explicitly asks for a broader change.\n- You may remove imports, variables, functions, or files that become unused because of your own change.\n- If you notice unrelated dead code or a separate bug, mention it separately instead of changing it.\n\nEvery changed line should trace back to the user's request or to a dependency of that request.\n\n### 4. Goal-driven execution\n\nConvert vague requests into verifiable outcomes.\n\n- For bug fixes: reproduce the issue, apply the fix, then verify the failure is gone.\n- For new features: define observable acceptance checks before implementation.\n- For refactors: preserve behavior with tests, builds, or focused before-and-after checks.\n- For risky edits: prefer incremental steps with verification after each step.\n- For multi-step tasks: say what each step will prove before moving on.\n\nWeak success criteria such as \"make it work\" are not enough. Always anchor the work to a checkable result.\n\n## Task-specific guidance\n\n### When implementing code\n\n- Prefer the smallest diff that meets the requirement.\n- Reuse existing utilities before creating new ones.\n- Keep comments that already exist unless they become inaccurate because of your change.\n- Do not broaden API surface area without a demonstrated need.\n\n### When debugging\n\n- Start by narrowing the failure mode.\n- Prefer evidence from tests, logs, traces, or a minimal reproduction over guesswork.\n- Separate confirmed facts from hypotheses.\n- After fixing, verify both the target bug and the most likely regression boundary.\n\n### When reviewing code\n\n- Focus first on correctness, simplicity, scope control, and verification.\n- Flag hidden assumptions, unnecessary abstractions, and unrelated changes.\n- Distinguish must-fix issues from optional improvements.\n- Prefer comments that point to concrete risk or simpler alternatives.\n\n### When planning work\n\n- Offer the minimum viable plan first.\n- Include explicit verification points.\n- Mention tradeoffs only when they materially affect implementation or risk.\n- Avoid speculative future-proofing unless the request is explicitly about architecture.\n\n## Response expectations\n\nFor non-trivial engineering tasks, the final response should usually include:\n\n- what you changed or recommend changing\n- the key assumption or tradeoff, if any\n- how you verified the result\n- any remaining risk, uncertainty, or follow-up that is directly relevant\n\nKeep the response concise. The discipline should show up in the work, not in long self-explanations.\n\nFile v1.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn7ca14yv5ext6a8r07mrwaws1821snr\",\n  \"slug\": \"karpathy-engineering-guidelines\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1776227561105\n}\n\nFile v1.0.0:agents/openai.yaml\n\ninterface:\n  display_name: \"Karpathy Guidelines\"\n  short_description: \"Lean coding guardrails for simpler, safer, more verifiable engineering work\"","readmeExcerpt":"Skill: Karpathy Guidelines Owner: gmvp3 Summary: engineering execution guardrails for coding, implementing features, fixing bugs, debugging failures, reviewing diffs, refactoring code, simplifying overbuilt... Tags: latest:1.0.3 Version history: v1.0.3 | 2026-05-19T02:39:40.401Z | user Add agent-era engineering discipline: deterministic logic in code, read-before-write, explicit conflicts, intent-focused tests, check","codeSnippets":[],"executableExamples":[],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: karpathy-guidelines\ndescription: engineering execution guardrails for coding, implementing features, fixing bugs, debugging failures, reviewing diffs, refactoring code, simplifying overbuilt solutions, and planning multi-step code changes. use for choosing implementation approaches, editing code safely, reviewing correctness and scope, reducing unnecessary complexity, surfacing hidden assumptions, deciding what belongs in deterministic code rather than model judgment, defining concrete verification steps, and keeping software tasks to the smallest effective change.\n---\n\n# Karpathy Guidelines\n\nApply this skill to non-trivial software engineering work. The goal is to produce smaller, safer, more verifiable changes with fewer hidden assumptions.\n\nFor trivial edits such as a typo, a one-line mechanical rename, or an obvious localized fix, use judgment and do not add ceremony.\n\n## Default operating loop\n\nFor non-trivial tasks, follow this sequence:\n\n1. Restate the task in concrete engineering terms.\n2. Read the nearest relevant callers, utilities, tests, and conventions before editing.\n3. Name the assumptions or ambiguities that could change the implementation.\n4. Choose the smallest viable approach.\n5. Make only the changes required for that approach.\n6. Verify the result with concrete checks.\n7. Report what changed, how it was verified, and any remaining uncertainty.\n\nWhen useful, think in this compact frame before acting:\n\n- **assumptions:** what must be true\n- **read:** the nearby evidence that guides the change\n- **plan:** the minimum set of steps\n- **verify:** the checks that define success\n\n## Core rules\n\n### 1. Think before coding\n\nDo not silently pick an interpretation when the request is ambiguous.\n\n- State assumptions that materially affect design or code changes.\n- Surface the main options when multiple interpretations would lead to different implementations.\n- Prefer the lower-risk interpretation when it still satisfies the request.\n- Stop and call out conflicts between the request, the prompt, and the codebase.\n- Push back on complexity when a simpler path clearly achieves the goal.\n\n### 2. Simplicity first\n\nImplement the minimum change that solves the actual problem.\n\n- Do not add features that were not requested.\n- Do not add abstractions for a single use case unless the local codebase already needs that pattern.\n- Do not introduce flags, extension points, or configuration without a present need.\n- Prefer straightforward control flow over cleverness.\n- Prefer the substantially smaller solution when two options achieve the same result.\n\nUse this test: would a strong senior engineer call this overbuilt for the current requirement? If yes, simplify.\n\n### 3. Surgical changes\n\nTouch only what the request requires.\n\n- Do not refactor adjacent code just because you noticed something better.\n- Do not reformat, rename, or reorganize unrelated code.\n- Match existing local style and patterns unless the task explicitly asks for a broader"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7ca14yv5ext6a8r07mrwaws1821snr\",\n  \"slug\": \"karpathy-engineering-guidelines\",\n  \"version\": \"1.0.3\",\n  \"publishedAt\": 1779158380401\n}"},{"path":"skill-card.md","content":"## Description:\n\nKarpathy Guidelines provides engineering execution guardrails for coding, bug fixing, debugging, review, refactoring, planning, and verification.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[gmvp3](https://clawhub.ai/user/gmvp3)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and coding agents use this skill to keep non-trivial software changes focused, evidence-driven, and verifiable while avoiding unnecessary abstractions and unrelated edits.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can influence how an agent approaches substantive coding tasks and may add process to larger tasks.\n\nMitigation: Apply it to non-trivial software engineering work and skip extra ceremony for trivial localized edits, as the skill directs.\n\nRisk: Engineering guidance can still lead to incorrect changes if assumptions, skipped checks, or verification gaps are not made visible.\n\nMitigation: Require concrete local evidence before editing, keep changes scoped, and report verification results and remaining uncertainty.\n\n## Reference(s):\n\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown guidance with implementation plans, review notes, code snippets, shell commands, configuration suggestions, and verification steps.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [No executable code is included in the artifact; outputs are guidance for an agent's software engineering workflow.]\n\n## Skill Version(s):\n\n1.0.3 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."},{"path":"agents/openai.yaml","content":"interface:\n  display_name: \"Karpathy Guidelines\"\n  short_description: \"Engineering guardrails for smaller diffs, clearer reasoning, and stronger verification\""}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"engineering execution guardrails for coding, implementing features, fixing bugs, debugging failures, reviewing diffs, refactoring code, simplifying overbuilt... Skill: Karpathy Guidelines Owner: gmvp3 Summary: engineering execution guardrails for coding, implementing features, fixing bugs, debugging failures, reviewing diffs, refactoring code, simplifying overbuilt... Tags: latest:1.0.3 Version history: v1.0.3 | 2026-05-19T02:39:40.401Z | user Add agent-era engineering discipline: deterministic logic in code, read-before-write, explicit conflicts, intent-focused tests, check","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1207,"uniquenessScore":55,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T21:30:18.047Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T21:30:18.047Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T07:40:01.385Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}