---
name: programming
description: "Strict Claude Code implementation discipline adapted for LazyClaude: TDD, typed boundaries, parse-once input, small files, real integration checks, and no silent lint/type escapes."
---

# Programming

Use this skill for implementation work in JavaScript, TypeScript, Python, Rust,
Go, shell glue, plugin manifests, and test harnesses. It is the Claude-native
port of LazyClaude programming discipline: strong types, small units, explicit
boundaries, and tests that prove behavior before code is accepted.

## Phase 0: Language Gate

Before editing, identify the language and the project-local conventions. Prefer
the repository's existing tools over introducing a new stack. If the task spans
multiple languages, write down the boundary between them before coding.

- JavaScript/TypeScript: keep ESM when the package is ESM, use `node:test` or
  the repo's configured runner, avoid `any`, `as` narrowing, and hidden globals.
- Python: prefer typed dataclasses/Pydantic boundaries, `pathlib`, explicit
  exception types, and deterministic scripts.
- Rust: prefer typed errors, exhaustive matches, `?`, and no `unwrap` outside
  tests or tiny `main` wrappers.
- Go: use `context.Context` at I/O boundaries, typed errors, no unchecked
  `err`, and focused packages.
- Shell: quote variables, use `set -euo pipefail` in scripts, and make cleanup
  explicit.

## Parse, don't validate

Parse untrusted input exactly once at the boundary. After parsing, pass typed or
structured values inward. Repeated ad-hoc validation inside the core is a smell:
it means the boundary did not create a useful value.

Examples:

- CLI args become a command object or option record before command dispatch.
- JSON from hooks is parsed once; malformed input exits with a controlled error.
- Plugin manifests are loaded as structured JSON, then checked by named fields.
- Environment variables are read at the edge and converted into explicit paths,
  booleans, or enums.

## TDD DISCIPLINE

For production behavior, use red -> green -> refactor.

1. Red: add a failing test that names the missing behavior and fails for the
   right reason.
2. Green: write the smallest change that passes that test.
3. Refactor: simplify with the tests still green.

Tests should follow Given / When / Then:

- Given: exact fixture and preconditions.
- When: one action.
- Then: one observable outcome or one assertion class.

For prompt and skill text, assert on behavior-bearing rules and structure, not
on fragile full-string snapshots. A good prompt test checks that a required
decision, tool boundary, or safety rule is present.

## Test Shape

Use the fastest truthful surface:

- Unit tests for pure parsing and decision logic.
- Integration tests for file-system state, plugin manifests, and CLI behavior.
- Manual QA for the user-facing surface: tmux transcript, HTTP status/body,
  browser screenshot, or desktop automation log.

Tests alone are not completion proof when the change affects user workflows.
Pair green tests with one real scenario artifact.

## Type and Error Discipline

- Make illegal states difficult to represent.
- Use semantic names for IDs, paths, versions, plugin keys, and command names.
- Return or throw typed errors at boundaries; do not rely on vague strings.
- Never suppress lint/type errors with comments unless a local policy explicitly
  allows it and the reason is documented next to the suppression.
- Avoid defensive code that checks impossibilities. If a case is possible, name
  it and test it. If it is impossible, encode that in parsing or types.

## 250 LOC Ceiling

Treat 250 non-comment lines in a source file as a design warning. If a touched
file is already too large and the change adds logic, split the cohesive unit you
are modifying before adding more. Keep orchestrators thin, parsing isolated,
and command implementations focused.

## Resource and State Hygiene

Every spawned process, tmux session, temp directory, port, browser context, or
container needs a cleanup receipt. Register cleanup when the resource is
created, not after the test passes. A leftover process means the work is not
done.

## Claude Code Adaptation

Prefer Claude Code's available tools and project conventions. If a Private reference
instruction names a Codex-only tool, translate the principle instead of copying
the tool name. For example, goal tools become conditional `get_goal` /
`create_goal` / `update_goal` guidance only when exposed; workflow isolation
uses `Workflow`, `EnterWorktree`, or an explicit `claude --worktree ...`
operator path when that is the available Claude surface.
