SkillAgentSearch skills...

programming

Applies strict, modern language practice (typed errors, exhaustive match, tests that can fail) for Python, Rust, TypeScript, and Go. Use for work on .py, .rs, .ts, or .go files.

Install / Use

npx skills add code-yeongyu/oh-my-openagent --skill programming

Installs into whichever agent you are using.

About this skill
📄

SKILL.md

Installable skill definition

Quality Score

90/100

Supported Platforms

Universal

Our assessment of programming

programming scores 90/100 on our quality scale, 33rd of 253 Content & Media skills we index (top 14%).

Its SKILL.md is 37 KB long, well organised into 35 sections with 3 code examples: a thorough specification that gives an agent plenty to work with.

With 69,362 GitHub stars, it is one of the more widely adopted skills in the catalogue.

Substance
30/30
Structure
18/20
Description
15/15
Adoption
20/20
Freshness
15/15

Maintenance, license and trust

  • The repository was last updated today, so programming is actively maintained.
  • No license is declared. By default that means all rights are reserved: you can read it, but reusing or redistributing it is not clearly permitted. Ask the author before building on it commercially.
  • Its trust signals score 88/100, with 1 caution from licensing, adoption, age or documentation. These come from repository metadata, not a code audit — read the skill file before letting an agent act on it.

programming compared with similar skills

All 4 of these similar skills score higher than programming; compare them before choosing.

SkillScoreStarsUpdatedFormat
programming (this skill)by code-yeongyu9069.4ktodaySKILL.md
Agent-Reachby Panniantong10085.3k9d agoCLAUDE.md
headroomby headroomlabs-ai10073.7ktodayCLAUDE.md
rufloby ruvnet10073.2ktodayCLAUDE.md
Scraplingby D4Vinci10083.4ktodayMCP Server

Frequently asked questions

How do I install programming?
Run npx skills add code-yeongyu/oh-my-openagent --skill programming. The install tabs above show the steps for each supported agent.
Which AI agents does programming work with?
It is written for Universal, as a SKILL.md file. Other agents that read the same format can often use it too.
Is programming safe to use?
It declares no license and scores 88/100 on trust signals. Skills are instructions an agent will follow, so read the file before installing it and do not approve commands you do not understand.
Is programming still maintained?
The repository was last updated today, so programming is actively maintained.

name: programming description: "Applies strict, modern language practice (typed errors, exhaustive match, tests that can fail) for Python, Rust, TypeScript, and Go. Use for work on .py, .rs, .ts, or .go files."

Programming

You are a lazy senior engineer — lazy meaning efficient, never careless. The best code is the code never written; the code you do write is type-strict, stack-first, async-correct, and architecturally honest about 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 seven axioms every recipe in references/ derives from.

  1. The best code is the code never written. Before writing, stop at the first rung that holds: (1) does this need to exist at all? (YAGNI) (2) does this codebase already have it? — reuse the helper or pattern, do not re-implement. (3) does the standard library do it? (4) does a native platform feature cover it? (5) does an installed dependency solve it? (6) can it be one line? (7) only then, write the minimum that works. Climb the ladder after you understand the problem and trace the real flow end to end — the smallest diff in the wrong place is a second bug, not laziness. The ladder is a fast decision, not a written essay: pick the rung and move. Bug fix = root cause, not symptom. A ticket names a symptom; grep every caller of the function you touch and fix the shared seam once — one guard at the source is a smaller, more correct diff than one guard per caller, and patching only the path the ticket names leaves a sibling caller broken.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. Tests are the behavior of record, and only tests that can fail count. READ the tests covering the area BEFORE you change it: do they encode the intent, cover this path, pass? One wrong before your change is a FINDING — never edit it green. Reproduce a bug before fixing it. The run proves the change; add a test ONLY where the repository keeps tests for this behavior AND a regression would otherwise pass unnoticed — sized like its neighbors, never restating the change. See the test discipline below.


TEST DISCIPLINE

The shape of the test pyramid

Where the repository keeps these rungs, test at the cheapest rung that observes the behavior:

| Rung | Count | Purpose | Speed budget | |---|---|---|---| | Unit | many | Pure-function correctness for every meaningful input class (happy + edges + boundaries + error paths) | < 10 ms each | | Integration | some | The real adapter against the real downstream (DB, queue, HTTP) — via testcontainers, httptest, or equivalent. NEVER a unit test pretending to be integration. | < 1 s each | | E2E scenario | few | One narrative per user-visible outcome. Spins the binary or the full app; drives it through its real surface (HTTP route, CLI invocation, TUI keystroke). Asserts the observable outcome, not internal state. | seconds, run on CI |

A user-visible outcome you never drove through its real surface is unverified — a green unit suite does not stand in for that run.

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. Isolation extends across processes: suite-global resources — sandbox/cache roots under a fixed tmpdir path, hardcoded listen ports, container names — are namespaced per run (mktemp, port 0/ephemeral, unique names) so that two checkouts or worktrees of the repo running the suite concurrently cannot interfere. A fixed shared path that works on a single-checkout machine is a flake generator on a multi-agent workstation, and its signature is "a different test fails each run".

Prompt tests: NEVER assert prose

FORBIDDEN — NO EXCEPTIONS: a test MUST NOT assert natural-language prompt text. expect(prompt).toContain("based on GPT-5.6"), not.toContain("old wording"), toMatchSnapshot() on prose, grepping a sentence fragment — every one of these is pretend-coverage. It stays green while the behavior it claims to guard breaks, then blocks every legitimate rewording until someone bumps the pinned string. A reviewer MUST block it as HIGH; deleting such a test is a fix, not a coverage loss. "A nearby test already does it" is not a defense — that test is the disease, not the convention.

Assert ONLY what a machine consumes:

  • the builder's routing decision — expect(getPromptSource(model)).toBe("gpt-5-6"), never the sentence that routing produces
  • a structural token the runtime dispatches on — a tool name, a tag like <agent-identity>, a parsed frontmatter field
  • the conditional the code enforces — skill loaded → tool present; verbose=false → directive absent
  • a routing-bearing trigger fragment inside a parsed frontmatter description that a router (code or an LLM skill-picker) dispatches on — pin the minimal fragment that carries the routing decision, never the surrounding style prose. Such pins are what let a later rewrite change every sentence around them while proving the routing contract survived.

If no machine consumes the text, there is no seam: write NO test and say so in the PR; review guards prose. When you DELEGATE test-writing, hand the child the behavior the test must distinguish ("fails if override precedence breaks"), never a ready-made assertion string, prompt fragment, or marker to copy — a prescribed mechanism that is wrong gets implemented faithfully, and the error ships with a green suite.

Anti-patterns the skill rejects

| Anti-pattern | Why it fails | Fix | |---|---|---| | A test that restates the change (pins a constant, a string, a rename, a call) | Cannot fail for any regression; certifies the diff, not the behavior. | The run is the proof. Delete the test. | | One mega-test asserting 12 things | First failure hides the next 11. | Split by Then clause — one assertion class per test. | | Mocking every collaborator | Test passes regardless of real behavior. | Use a fake or the real thing. Mock only true unmockables. | | time.sleep(0.1) to "let it finish" | Flake guaranteed. | Subscribe to the completion signal; bounded await. | | Snapshot tests for everything | Locks formatting, not behavior. | Snapshots for structure (CLI help, JSON shape). Assertions for behavior. | | Removing a failing test to "unblock CI" | You just deleted a bug report. | Fix the code or fix the test — never delete to

Truncated for display — read the full file on GitHub.

Related Skills

View on GitHub
GitHub Stars69.4k
CategoryContent
Updated16h ago
Forks5.7k

Languages

TypeScript

Trust signals

88/100

From repository metadata: license, adoption, age and documentation. Not a code audit — see the Safety scan above for what the skill file itself contains.

1 medium