Published 18 days ago

What is being adopted

A third-party Claude Code plugin (forrestchang/andrej-karpathy-skills) providing behavioral coding guidelines as a skill, installed via the Claude Code plugin marketplace system. The plugin injects system-level instructions that shape how Claude Code writes and edits code across every session.

Plugin components (at commit 2c60614)

.claude-plugin/plugin.json — plugin manifest (name: "andrej-karpathy-skills", v1.0.0)
.claude-plugin/marketplace.json — marketplace definition (id: "karpathy-skills"), uses bare relative source ("./"), no SHA pinning
skills/karpathy-guidelines/SKILL.md — single skill containing the behavioral guidelines
NO hooks, NO .mcp.json, NO agents, NO bin/ executables, NO monitors, NO settings.json

What the guidelines instruct Claude Code to do

The skill injects four behavioral principles as system-level instructions:

1. Think Before Coding

State assumptions explicitly, ask if uncertain
Present multiple interpretations instead of picking silently
Push back if simpler approach exists
Stop when confused, ask for clarification

2. Simplicity First

No features beyond what was asked
No abstractions for single-use code
No "flexibility" or "configurability" that wasn't requested
"No error handling for impossible scenarios"
If 200 lines could be 50, rewrite it

3. Surgical Changes

"Don't improve adjacent code, comments, or formatting"
"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
Remove imports/variables/functions that YOUR changes made unused
Don't remove pre-existing dead code unless asked

4. Goal-Driven Execution

Transform tasks into verifiable goals with tests
State a brief plan for multi-step tasks
Define success criteria and loop until verified

Security-relevant implications of active guidelines

These guidelines change how Claude Code approaches security when writing and editing code:

"No error handling for impossible scenarios" — Could discourage defensive coding, input validation, and boundary checking. What seems "impossible" to the LLM may be an actual attack vector. This could lead to missing validation at system boundaries, insufficient error handling for malformed input, or skipped null/bounds checks.
"Don't improve adjacent code" and "Don't refactor things that aren't broken" — Could prevent Claude from proactively fixing security vulnerabilities it notices in nearby code during a task. If Claude sees an SQL injection in a function adjacent to the one being modified, these guidelines tell it not to fix it.
"Match existing style, even if you'd do it differently" — Could perpetuate insecure coding patterns. If existing code uses string concatenation for SQL queries, raw string formatting for shell commands, or outdated crypto, Claude would be instructed to match that style.
"No features beyond what was asked" — Could lead Claude to skip security hardening (rate limiting, input sanitization, authentication checks) unless the user explicitly requests it, treating security measures as "features beyond what was asked."
"If you notice unrelated dead code, mention it — don't delete it" — Could leave attack surface (unused endpoints, dead auth code) in place that should be removed.

Supply chain context

Repo: forrestchang/andrej-karpathy-skills — 74k stars, 6.8k forks, 7 contributors
marketplace.json uses bare relative source, no SHA pinning
No hooks/MCP/bin/monitors — prompt text only, no executable components

Platform-level mitigations for supply chain

SHA commit pinning supported: /plugin marketplace add owner/repo@ref
Auto-update disabled by default for third-party marketplaces
Organizations can fork, use strictKnownMarketplaces, CLAUDE_CODE_PLUGIN_SEED_DIR
Three installation scopes: user (all projects), project, local

CriticalMarketplace Definition Validation for Plugin InstallationsOPLANE_REQ-00035605
The system must validate marketplace.json definitions for plugins to ensure that sources are not bare relative paths without integrity metadata (such as SHA pinning). Any marketplace definition lacking integrity metadata must trigger a warning and require explicit user confirmation.
Rationale
Validating marketplace definitions ensures that plugins are sourced from trusted, immutable references, reducing the risk of supply chain compromise.
Consideration
If marketplace definitions allow bare relative sources without integrity metadata, plugins may be sourced from mutable or untrusted locations, increasing supply chain risk.
Not Implemented
The plugin's marketplace.json uses a bare relative source with no integrity metadata. Platform supports SHA pinning but doesn't warn about its absence.
CriticalPlugin Source Integrity Validation for Third-Party Marketplace AdditionsOPLANE_REQ-00035601
When adding a plugin marketplace (such as forrestchang/andrej-karpathy-skills), the system must support and encourage SHA commit pinning for plugin sources. The marketplace.json definition must be validated to ensure sources are pinned to a specific commit SHA, preventing supply chain attacks via untrusted or mutable sources.
Rationale
Pinning plugin sources to a specific SHA ensures that only the intended, reviewed version of the plugin is installed, reducing the risk of supply chain attacks and unauthorized changes.
Consideration
If plugin sources are not pinned to a specific SHA, malicious updates or compromised repositories could introduce harmful code or instructions without detection, leading to supply chain compromise.
Not Implemented
The plugin repo implements no source integrity controls at either level:

Marketplace source: The repo provides no guidance on pinning the marketplace itself when adding it. Users adding via /plugin marketplace add forrestchang/andrej-karpathy-skills get an unpinned clone tracking the default branch. Users should instead pin: /plugin marketplace add forrestchang/andrej-karpathy-skills@2c60614. Organizations declaring this in extraKnownMarketplaces should use the ref field to pin to a tag or commit.

Plugin source inside marketplace.json: Uses a bare relative path ("source": "./") which resolves from the same repo as the marketplace. Since the plugin is co-located with the marketplace, pinning the marketplace source (level 1) effectively pins the plugin too. However, if the repo were restructured to use an external source (e.g., github type), the sha field should be used.

Both levels of pinning are supported by the Claude Code platform but neither is used or documented by this plugin repo.
CriticalSecurity Hardening Guidance Injection for Behavioral Coding PluginsOPLANE_REQ-00035635
When behavioral coding guideline plugins (such as andrej-karpathy-skills) are installed, the system must inject a supplemental security guidance prompt to Claude Code sessions. This guidance should explicitly instruct Claude to always implement input validation, error handling, and security hardening measures—even if the behavioral guidelines discourage them or treat them as 'features beyond what was asked.' The supplemental prompt must override any plugin instructions that would suppress essential security controls.
Rationale
Injecting explicit security guidance ensures that essential security controls are not omitted due to behavioral plugin instructions, mitigating the risk of code generation vulnerabilities.
Consideration
If behavioral guidelines discourage defensive coding, input validation, or error handling, Claude may generate code vulnerable to injection, boundary errors, or missing authentication checks, leading to critical security flaws.
Not Implemented
The plugin's SKILL.md contains no supplemental security guidance. It instructs "no error handling for impossible scenarios" and "no features beyond what was asked" without any carve-out for security. There is no language ensuring that input validation, boundary checks, or security hardening are exempt from the simplicity guidelines. A user adopting this plugin should add their own supplemental CLAUDE.md instructions explicitly stating that security controls are never optional, e.g.: "Security hardening (input validation, authentication, authorization, output encoding) is never a 'feature beyond what was asked' — always include it."
CriticalSecurity Vulnerability Detection and Remediation Override for Behavioral Coding PluginsOPLANE_REQ-00035636
When behavioral coding guideline plugins are active, the system must allow Claude Code to proactively fix security vulnerabilities it detects in adjacent or related code, regardless of plugin instructions that discourage improving or refactoring code outside the immediate task. This override must apply to vulnerabilities such as SQL injection, unsafe deserialization, insecure cryptography, and missing authentication checks.
Rationale
Allowing proactive remediation of detected vulnerabilities ensures that behavioral guidelines do not perpetuate insecure coding patterns or leave critical flaws unaddressed.
Consideration
If Claude is prevented from fixing adjacent security vulnerabilities, latent flaws may persist in the codebase, leading to privilege escalation, data breaches, or remote code execution.
Not Implemented
The plugin's "Surgical Changes" guidelines explicitly instruct: "Don't improve adjacent code" and "Don't refactor things that aren't broken." There is no exception for security vulnerabilities. If Claude notices an SQL injection, XSS, or insecure deserialization in code adjacent to what it's editing, these guidelines tell it to leave the vulnerability in place. The plugin should add an explicit carve-out: "Security vulnerabilities are always in scope for remediation, regardless of whether they are adjacent to the current task."
CriticalSecure Communication for Plugin Marketplace CloningOPLANE_REQ-00035603
All plugin marketplace cloning operations (such as cloning forrestchang/andrej-karpathy-skills from GitHub) must use HTTPS with certificate validation to ensure the integrity and authenticity of the source repository.
Rationale
Secure communication is essential to prevent man-in-the-middle attacks and ensure that plugin sources are obtained from trusted repositories.
Consideration
If cloning is performed over insecure channels or without certificate validation, attackers could intercept or modify plugin sources, leading to supply chain compromise.
Out of Scope
HTTPS with certificate validation is enforced by Claude Code and the underlying git client. Platform-level control, not something the plugin repo implements.
HighSecurity Pattern Consistency Enforcement for Code GenerationOPLANE_REQ-00035637
When behavioral coding guideline plugins instruct Claude Code to match existing code style, the system must enforce a check that prevents perpetuation of insecure coding patterns (such as string concatenation for SQL queries, raw shell command formatting, or outdated cryptographic primitives). Claude must be allowed to use secure patterns even if they differ from the existing style.
Rationale
Enforcing secure coding patterns ensures that behavioral guidelines do not override essential security practices, reducing the risk of systemic vulnerabilities.
Consideration
If insecure coding patterns are perpetuated due to style matching, the codebase may accumulate vulnerabilities such as SQL injection, command injection, or weak encryption.
Not Implemented
The plugin instructs "Match existing style, even if you'd do it differently" with no exception for insecure patterns. If existing code uses string concatenation for SQL, raw formatting for shell commands, MD5 for hashing, or Math.random for tokens, Claude is told to match that style. The plugin should add: "Never match existing style when it involves insecure patterns. Always use secure alternatives (parameterized queries, subprocess arrays, strong cryptography, CSPRNG) regardless of surrounding code style."
HighRestrict Plugin Installation Scope to Minimize Privilege ExposureOPLANE_REQ-00035604
When installing plugins from third-party marketplaces, users must be informed of the privilege implications of each installation scope (user, project, local). The system should default to the least privileged scope and require explicit confirmation for broader scopes.
Rationale
Restricting installation scope minimizes the impact of potential vulnerabilities and limits the plugin's influence to only the intended context.
Consideration
If plugins are installed at a broader scope without user awareness, they may affect all projects and sessions, increasing the risk of widespread security vulnerabilities.
Out of Scope
Scope selection is a Claude Code platform feature. The plugin cannot control which scope users choose. Recommendation: install at local or project scope.
HighUser Warning and Explicit Confirmation for Installation of Highly Trusted Plugins from Third-Party SourcesOPLANE_REQ-00035602
When installing plugins or marketplaces from third-party sources (such as forrestchang/andrej-karpathy-skills), the system must display a clear warning about the trust implications and require explicit user confirmation. The warning must highlight that plugins can inject system-level instructions affecting all code generation and editing sessions.
Rationale
Explicit warnings and confirmation ensure users are aware of the risks associated with highly trusted plugins, especially those that affect system-level code generation behavior.
Consideration
Without explicit warning and confirmation, users may unknowingly install plugins that alter code generation behavior in ways that could introduce security vulnerabilities or perpetuate insecure coding practices.
Out of Scope
User warnings and confirmation prompts are Claude Code platform responsibilities. Claude Code warns that plugins can execute arbitrary code with user privileges. Not something a plugin repo controls.
MediumSecurity Review Requirement for Dead Code and Unused EndpointsOPLANE_REQ-00035638
When behavioral coding guideline plugins instruct Claude Code to leave unrelated dead code or unused endpoints in place, the system must require a security review of such code during plugin-driven edits. Any dead code or unused endpoints must be flagged for removal or isolation to reduce attack surface.
Rationale
Requiring security review and removal of dead code ensures that behavioral guidelines do not inadvertently preserve attack surface, reducing the risk of exploitation.
Consideration
Leaving dead code or unused endpoints in place increases the attack surface and may expose latent vulnerabilities, such as insecure endpoints or legacy authentication logic.
Partially Implemented
The plugin instructs "If you notice unrelated dead code, mention it — don't delete it." This partially addresses the concern: Claude will at least surface the existence of dead code rather than silently ignoring it. However, there is no instruction to specifically flag dead code with security implications (unused endpoints, legacy auth code, exposed debug routes) for priority review. The mention-but-don't-delete approach leaves attack surface in place. The guideline could be strengthened to: "If dead code has security implications (unused endpoints, legacy auth, debug routes), flag it as a security concern requiring review."

Adopting third-party Claude Code plugin: andrej-karpathy-skills