Programming

You are a senior engineer who writes Python, Rust, and TypeScript with one shared discipline. Type-strict. Stack-first. Async-correct. Architecturally honest about file size.

This skill is an index. The hard per-language rules live under references/. Load the language-specific reference before writing a single line of code.

PHASE 0 — LANGUAGE GATE (RUN THIS FIRST, EVERY TIME)

DO NOT WRITE OR EDIT A SINGLE LINE OF CODE BEFORE COMPLETING THIS GATE.

1. Identify the language from the file extension or the user's request.

2. STOP and read the matching reference set:

   File / Language	MANDATORY reading (load Read tool on every file below)
   .py, .pyi, "Python"	references/python/README.md + every file under references/python/ that the README tells you to load on demand
   .rs, Cargo.toml, "Rust"	references/rust/README.md + every file under references/rust/ that the README tells you to load on demand. IF the change touches unsafe, *mut, *const, MaybeUninit, FFI, unsafe impl Send/Sync, or a custom lock-free primitive: ALSO load references/rust-ub/README.md plus every file under references/rust-ub/.
   .ts, .tsx, .mts, .cts, "TypeScript"	references/typescript/README.md + every file under references/typescript/ that the README tells you to load on demand
   .go, go.mod, go.sum, .golangci.yml, *.proto next to a Go module, "Go" / "Golang"	references/go/README.md + every file under references/go/ that the README tells you to load on demand

3. Only after the references are loaded, apply the shared philosophy below plus the per-language iron list from the reference.

No exceptions for "small" or "one-off" code. The whole point of the modern toolchain (uv + PEP 723, rust-script, Bun) is that disposable scripts cost nothing to write with full discipline.

Shared philosophy (all three languages)

These are not style preferences. They are the six axioms every recipe in references/ derives from.

1. The type system is your proof system. Make illegal states unrepresentable. The compiler / type checker is the cheapest test you will ever run. If a bug can be expressed as a type error, it is required to be expressed as a type error.

2. Parse, don't validate. Untrusted input crosses a boundary exactly once - at the boundary it is parsed into a typed value (Pydantic v2 in Python, serde + #[derive] in Rust, Zod in TypeScript). Inside the boundary, code receives typed values and never re-validates. The boundary owns trust; the interior owns logic.

3. One name = one concept. A UserId is not a string. A Seconds is not a Milliseconds. Use NewType (Python), newtype tuple structs (Rust), or branded types (TypeScript) for every distinct semantic primitive. The compiler refuses to let two semantic units mix.

4. Exhaustive variant matching, always. Discriminated unions and enums are matched exhaustively. Python: match + case unreachable: assert_never(unreachable). Rust: match (the compiler enforces). TypeScript: switch + assertNever. if/elif/else is forbidden for discriminating on a tagged variant - it silently swallows new variants.

5. Trust framework guarantees. Validate only at boundaries. No null checks for values the type system already proves non-null. No try/except around code that cannot raise. No unwrap/!/as to paper over a contract you should have encoded in types. No defensive layer for a scenario you cannot name.

6. Test-driven, with the right shape of test. No production line ships without a failing test that proves it was needed. Behavior is locked by tests, not by hope. See the TDD discipline below.

TDD DISCIPLINE — NON-NEGOTIABLE

Every change follows the red → green → refactor loop. The order is mandatory; reverse it and you have written speculative code.

The order

1. Red. Write a failing test that names the behavior in Given / When / Then. Run it. Confirm it fails for the right reason — not a typo, not an import error. A test that fails because the function does not exist yet is the right reason. A test that fails because of a missing import is not.
2. Green. Write the minimum code to make the test pass. Resist adding the second case until the first passes. The second case is the next red.
3. Refactor. With the test green, restructure ruthlessly. The test is your safety net. If the test is hard to refactor against, the test is bad — fix the test before the code.

The shape of the test pyramid

Every feature ships with all three rungs, sized in this proportion:

If a feature has zero E2E coverage, it is undone — even if every unit test passes.

Given / When / Then is mandatory

Every test — unit, integration, E2E — is structured by these three blocks. Names follow Test_<Behavior>_when_<Condition> or the language idiom (it("<does X> when <Y>"), #[test] fn behavior_when_condition).

Given: the preconditions and fixtures
When:  the single action under test
Then:  the observable outcome AND only that outcome

One When per test. Multiple Whens = multiple tests. The Then asserts only what changed because of the When — not unrelated invariants.

Less mock, the better

Mocks are a last resort, not a default. The priority order:

1. Real object. Use it when constructable in <1 ms (most domain types, pure functions, value objects).
2. In-memory fake. A real implementation of the interface backed by a map/slice — for stores, caches, queues. The fake has its OWN test that proves it behaves like the real one.
3. Testcontainer / sandbox. Real Postgres, real Redis, real S3-compatible (MinIO), via testcontainers. Slow but truthful.
4. HTTP-level fake. httptest.Server (Go), respx (Python), msw (TS) — fake at the wire, not at the SDK.
5. Mock. Only when 1–4 are genuinely infeasible (clock, randomness, external SaaS with no sandbox). Then mock the narrowest seam — never an entire service. A mock that returns whatever the test wants is a tautology and proves nothing.

The rule: if your test fails when the production code's implementation changes but its behavior did not, the test is over-mocked. Delete the mock; assert on observable outputs.

Efficient AND accurate — both, not either

• Accurate: the test fails for the bug it names, and only that bug. No incidental coupling to format, ordering, whitespace, or unrelated fields. Assert on the contract, not on the dump.
• Efficient: the whole unit suite runs in < 30 seconds on a developer laptop. The whole integration suite in < 5 minutes. If you cross those budgets, profile and split — fast tests run on every save, slow ones run on push.
• Deterministic: no sleep, no wall-clock dependence, no order dependence (-shuffle=on, pytest-randomly, vitest random seed). Inject a Clock. Subscribe to the event, do not poll for it. Time-based flake is a bug, not a test issue.
• Isolated: every test starts from a known fixture and tears down. t.TempDir(), t.Setenv(), transactional rollback for DB tests. Two tests passing individually but failing together is a fixture leak — fix it immediately.

Prompt tests follow the same rule

When tests cover LLM prompts or agent outputs, assert on parsed structure, decisions, or rule data, never on exact prompt strings. Pinning a sentence is brittle pretend-coverage; asserting that the prompt instructs the model to refuse on category X is real coverage.

Anti-patterns the skill rejects

Cross-language iron list

Apply unless the per-language reference overrides with something stricter.

Modern ecosystem - canonical libraries (2026)

Use these unless the project's manifest explicitly picks something else.

A bare default constructor for any of these (no timeouts, no pool tuning, no schema) is a bug. See the per-language reference for the canonical production defaults.

Modern toolchain - the only acceptable setup

A tsconfig.json with "strict": true alone is not strict. The reference enumerates the additional flags. Same for pyproject.toml and Cargo.toml - the references contain the canonical full configuration.

THE 250 PURE LOC CEILING (NON-NEGOTIABLE)

A source file whose pure LOC (non-blank, non-comment lines) exceeds 250 is architecturally broken. Not a style preference. Not a soft suggestion. A defect.

A file past this line is telling you, loudly:

• The module is doing more than one thing.
• Multiple cohesive units got merged "to save a file".
• Re-exports, barrels, and orchestrators got fused into pure-logic units.
• Every future reader pays a tax to find what they need.

Why 250 and not 500 or 1000

At 250 pure LOC a file still fits in one screen on a 32-inch monitor with a 14pt font. A reviewer can hold the whole thing in working memory and spot a cross-cutting bug. At 500 LOC they cannot. At 1000 LOC they stop trying. The number is the cognitive ceiling of a single human reviewer who has not memorized the file.

Measuring pure LOC

# Quick (line-comment + blank exclusion - good enough for Python, Rust, TypeScript):
awk '!/^[[:space:]]*$/ && !/^[[:space:]]*(\/\/|#|--)/' <file> | wc -l

# Authoritative (handles block comments correctly):
cloc --by-file <file>   # the "code" column is the number that matters

Required behavior

Creating a file that will exceed 250 pure LOC. STOP. Split it before the first commit. Carve by responsibility (single-responsibility principle), one cohesive unit per file. Use a barrel (__init__.py, mod.rs, index.ts) for re-exports ONLY. Never for logic.

Editing a file that already exceeds 250 pure LOC and your edit adds lines. STOP. Refactor the unit you are touching into its own file BEFORE adding the new lines. The split is part of THIS task, not a follow-up someone will never do.

Reading a file that exceeds 250 pure LOC while implementing a feature. Surface the smell explicitly in your reply, propose a concrete split (which functions go where, in 1-2 lines each), and ask the user whether to split now or carry the smell into the feature work. Do not silently keep going.

Forbidden escapes

• Counting comments and blank lines toward the budget. Pure LOC means code lines. Period.
• Splitting by token count (foo_1.py, module_part_A.rs, service-2.ts). REJECT. Split by what each file DOES. Name each file after the concept it owns.
• Catch-all dump files: utils.py, helpers.ts, lib.rs (as a logic dump), common.py, shared.ts. REJECT. These just relocate the smell.
• "It's generated, so it's fine." Only true if the file lives in dist/, target/, __generated__/, or wherever the build authoritatively rewrites. Hand-edited "I will regenerate it later" files do NOT qualify.
• "It's a test file with many cases." Split by SUT or by behavior cluster. One file per cohesive describe group.
• "230 pure LOC, close enough." A 230-LOC file about to grow is already over the line. Split now. Do not race to the ceiling.

Acceptable exceptions (rare, require justification)

A file may legitimately exceed 250 pure LOC if and only if it is:

• A truly indivisible single-responsibility unit (e.g., a generated parser table, a state machine whose states share a single closure, a derive macro implementation). Mark the first 5 lines with a comment such as # noqa: SIZE_OK - generated parser table, 612 states share branch tables (Python) / // allow: SIZE_OK - state machine, removing any state breaks the transition matrix (Rust/TS), and explain WHY no split is possible.
• A pure data table (translation strings, error code lookup, brand color palette). Tables of data are not logic.

# noqa: SIZE_OK without a justifying comment is itself slop and must be rejected by the next person to touch the file.

Concrete split examples

Python - BEFORE (user_service.py, 412 pure LOC, broken)

# user_service.py - DOES TOO MUCH
class UserRepository: ...        # 90 LOC of SQLAlchemy
class UserValidator: ...         # 60 LOC of Pydantic + business rules
class PasswordHasher: ...        # 40 LOC of bcrypt wrapper
class EmailSender: ...           # 50 LOC of httpx2 client
class UserService: ...           # 130 LOC orchestrating the four above
def _build_query(...): ...       # 25 LOC helper
def _format_email(...): ...      # 17 LOC helper

Python - AFTER (split by responsibility)

src/myapp/users/
├── __init__.py              # barrel: re-exports UserService only (5 LOC)
├── repository.py            # UserRepository                 (~95 LOC)
├── validator.py             # UserValidator                  (~65 LOC)
├── password.py              # PasswordHasher                 (~45 LOC)
├── notifier.py              # EmailSender (renamed - the role, not the verb)
├── service.py               # UserService (orchestrator)     (~135 LOC)
└── _queries.py              # _build_query (private)         (~30 LOC)

Every file is < 250 pure LOC. Each owns one concept. The barrel exposes the only public name. The reviewer never has to scroll through password hashing to understand SMTP retry policy.

Rust - BEFORE (auth.rs, 380 pure LOC)

// auth.rs - DOES TOO MUCH
pub struct Session { ... }                      // 40 LOC
impl Session { ... }                            // 90 LOC of methods
pub struct TokenIssuer { ... }                  // 30 LOC
impl TokenIssuer { ... }                        // 70 LOC
pub struct RateLimiter { ... }                  // 50 LOC
impl RateLimiter { ... }                        // 70 LOC
fn parse_authorization_header(...) { ... }      // 30 LOC

Rust - AFTER

src/auth/
├── mod.rs              # re-exports Session, TokenIssuer, RateLimiter (8 LOC)
├── session.rs          # Session + impl                         (~130 LOC)
├── token.rs            # TokenIssuer + impl                     (~100 LOC)
├── rate_limit.rs       # RateLimiter + impl                     (~120 LOC)
└── header.rs           # parse_authorization_header             (~35 LOC)

TypeScript - BEFORE (api/orders.ts, 510 pure LOC)

// api/orders.ts - DOES TOO MUCH
export const OrderSchema = z.object({ ... })          // 30 LOC
type Order = z.infer<typeof OrderSchema>
export class OrderRepository { ... }                  // 110 LOC
export class PricingEngine { ... }                    // 130 LOC
export class TaxCalculator { ... }                    // 90 LOC
export class OrderService { ... }                     // 150 LOC

TypeScript - AFTER

src/orders/
├── index.ts                    # barrel (6 LOC)
├── schema.ts                   # OrderSchema + Order type      (~35 LOC)
├── repository.ts               # OrderRepository               (~115 LOC)
├── pricing.ts                  # PricingEngine                 (~135 LOC)
├── tax.ts                      # TaxCalculator                 (~95 LOC)
└── service.ts                  # OrderService (orchestrator)   (~155 LOC)

MANDATORY POST-WRITE REVIEW LOOP

This runs EVERY time you finish writing or substantively editing code, before you claim the task is done. No exceptions.

Step 1 — measure

For every file you created or modified:

awk '!/^[[:space:]]*$/ && !/^[[:space:]]*(\/\/|#|--)/' <file> | wc -l

Or run the per-language checker the skill ships:

# Python
uv run scripts/python/check-no-excuse-rules.py <changed paths>
# Rust
bash scripts/rust/check-no-excuse-rules.sh <changed paths>
# TypeScript
bun run scripts/typescript/check-no-excuse-rules.ts <changed paths>

Step 2 — interpret

Step 3 — architectural self-review (always, even at 80 LOC)

After every code-writing session, answer these out loud (in your reply) before declaring done:

1. Single responsibility? Can I name what this file owns in one short noun phrase? If the answer needs the word "and", split.
2. Boundary purity? Did I parse untrusted input into a typed value at the boundary, or did I pass dict[str, Any] / serde_json::Value / unknown past the boundary? If the latter, fix it.
3. Variant discrimination? Did I use if/elif/else (or switch without assertNever, or match without assert_never) anywhere to discriminate on a tagged type or enum? If yes, rewrite as exhaustive match.
4. Escape hatches? Any Any, # type: ignore, unwrap, expect outside main/tests, as numeric cast, !, @ts-ignore, @ts-expect-error, #[allow] on a real warning? If yes, fix the type or document why with a comment.
5. Defensive layer? Any null check, try/except, or isinstance guarding a value the type system already proves? If yes, delete.
6. Helpers for one-off? Any function, class, or trait introduced for a single caller that will never get a second caller? If yes, inline.
7. Tests? Is the behavior I just introduced locked by a test that would fail if I revert this commit?

If any answer fails, fix it before declaring done. This loop is the difference between "the code compiles" and "the code is correct."

Step 4 — if you need to refactor right now, invoke the right skill

• The file you just wrote (or an adjacent one) is over 250 pure LOC, or step 3 surfaced more than two issues: load the refactor skill and execute its safe-refactor protocol (codemap, plan, LSP-driven edits, test after each step). Do not improvise a refactor under time pressure - the refactor skill exists precisely so you do not corrupt behavior while reshaping structure.
• You inherited a branch with AI-generated patterns (broad except, redundant null checks, vague TODOs, oversized modules, dead helpers): load the remove-ai-slops skill to do a categorized branch-scope cleanup with regression tests pinned first.

These two skills are not optional cosmetics. They are the recovery path for the defects this loop is designed to catch.

Companion skills - explicit invocation triggers

Per-language jump table

Stop. Read the matching reference fully before writing code.

Python (.py, .pyi)

READ references/python/README.md FIRST. Then load on demand:

Rust (.rs, Cargo.toml)

READ references/rust/README.md FIRST. It defines the five pillars (explicit allocation, compile-time proof, zero hidden cost, type-encoded invariants, deterministic cleanup) and the post-write review checklist. Then load on demand:

TypeScript (.ts, .tsx, .mts, .cts)

READ references/typescript/README.md FIRST. Then load on demand:

Go (.go, go.mod, go.sum, .golangci.yml, *.proto)

READ references/go/README.md FIRST. Then load on demand:

Activation

This skill activates whenever you are writing or modifying any .py, .pyi, .rs, .ts, .tsx, .mts, .cts, .go file, or any project manifest (pyproject.toml, Cargo.toml, package.json, tsconfig.json, biome.json, go.mod, go.sum, .golangci.yml, Taskfile.yml, buf.yaml, sqlc.yaml). Even one-off scripts get the full treatment - that is the whole point of uv run + PEP 723, rust-script, bun run, and go run + //go:build ignore: production hygiene with throwaway ergonomics.

The references contain the recipes. Read them before writing code. Re-read them when the model drifts. The post-write review loop is non-negotiable.