| name | karpathy-guidelines |
| description | Repo-local execution discipline for Zoolanding Lambda tasks. Use when implementing, debugging, refactoring, reviewing, or planning Python handler, shared helper, or SAM template changes in this repository. |
| user-invocable | true |
Karpathy Guidelines
Use this repo-local version to keep disciplined execution portable across clones of this Zoolanding Lambda repo.
When to Use
- behavior-changing handler or helper work
- contract-sensitive request or response changes
- shared helper or integration changes
- SAM template, env var, or deploy-surface updates
- any task where ambiguity or over-engineering would create risk
Workflow
-
Define the target.
- Restate the requested outcome.
- Name the narrowest proof that would show the task is done.
- Call out what is out of scope.
-
Read the real contract first.
- Read
README.md, lambda_function.py, shared helpers, requirements.txt, and template.yaml before editing behavior.
- Read any examples or request fixtures before changing verification strategy.
-
Choose the smallest affected surface.
- Prefer a surgical change in
lambda_function.py, shared helpers, requirements, or template.yaml.
- Reuse the current contract and deployment boundaries before inventing abstractions.
-
Make the smallest working change.
- Avoid speculative helpers, flags, or extension points.
- Keep unrelated cleanup out of the diff.
-
Verify concretely.
- Use the narrowest relevant payload check, local harness, or SAM check.
- If dependency or deploy wiring changed, verify the packaging assumptions explicitly.
-
Close with signal.
- Summarize what changed.
- State what was verified and what was not.
- Call out residual risks or assumptions.
Repo-Specific Rules
- Prefer the repo-local
zoolanding-lambda-workflow skill before falling back to generic patterns.
- Keep API shape, env vars, and storage contracts stable unless the task explicitly changes them.
- Update docs with the code when contract or deployment behavior changes.
