From godmode
Enforces pre-edit coding discipline: Think before coding, prioritize simplicity, make surgical changes. Prevents LLM mistakes like over-engineering before edits.
npx claudepluginhub arbazkhan971/godmodeThis skill uses the workspace's default tool permissions.
**Scope.** Governs what you *decide to write*. The Universal Protocol in
Guides code writing, review, and refactoring with Karpathy-inspired rules to avoid overcomplication, ensure simplicity, surgical changes, and verifiable success criteria.
Applies Karpathy guidelines to reduce LLM coding mistakes: think before coding, prioritize simplicity, make surgical changes, and define verifiable success criteria when writing, reviewing, or refactoring code.
Enforces Karpathy guidelines to prevent LLM coding errors: read before writing, surgical changes only, verify assumptions, define success upfront. Use for feature implementation, code modifications, or scope discipline.
Share bugs, ideas, or general feedback.
Scope. Governs what you decide to write. The Universal Protocol in
SKILL.md governs how you verify and keep it. On conflict, Protocol wins.
Tradeoff. Biases toward caution over speed. For trivial tasks (one-line fixes, typos, renames, pure formatting), use judgment and skip the pre-flight. The gates apply to tasks that change behavior.
When. Every agent, every skill, every round — before the first Edit.
Don't assume. Don't hide confusion. Surface tradeoffs. Before the first Edit:
NEEDS_CONTEXT.Rule. If you cannot write one sentence stating what the user wants, ask before coding, not after.
Minimum code that solves the problem. Nothing speculative.
Pre-MODIFY checklist — run before writing a single line:
Hard stops. Never add features beyond the request, abstractions for single-use code, configurability nobody asked for, error handling for impossible scenarios, or refactors "while we're here."
Post-MODIFY complexity falls under the Protocol's line-vs-delta table. This checklist catches complexity before it is written.
Touch only what you must. Clean up only your own mess.
Line-trace rule. Every semantically changed line must trace directly to
the user's request. If not, classify as line_scope_drift and remove from
your diff before committing. The pre-commit audit specified in
docs/discard-audit.md enforces this mechanically: it reads
git diff --cached, classifies each hunk, and drops untraceable hunks via
git restore -p --staged before the commit lands. A Cost-2 revert that
could have been caught by this audit is logged as escaped_discard
feedback against this checklist.
In scope: lines implementing the requested behavior, tests covering it, orphans YOUR changes created (imports/vars/helpers your edit made unused).
Out of scope: improving adjacent code, comments, or formatting; refactoring things that aren't broken; renaming for consistency; deleting pre-existing dead code (mention it in the report — do NOT delete); auto-formatter churn on lines you didn't touch semantically.
Match existing style, even if you'd do it differently. task.files controls
which files you may touch; the line-trace rule controls which lines inside
those files you may touch.
Define success. Loop until verified. The success criterion MUST be a shell command that exits zero when the goal is met. Subjective criteria ("works well," "looks good," "is faster") are vibes — reject before coding, replace with a command.
Multi-step tasks state a brief plan, verify step per step:
1. [step] -> verify: [shell command that exits zero]
2. [step] -> verify: [shell command that exits zero]
Strong criteria let you loop independently. Weak criteria force clarification.
Effectiveness signal. Fewer unnecessary diff lines, fewer rewrites,
ambiguity surfaced as NEEDS_CONTEXT before implementation.