Skip to content
Skillpedia
General coding70k · #1741

programming

Helps your agent write clean and robust code in Python, Rust, TypeScript, and Go. It's useful for ensuring code is maintainable and testable.

What it does

This agent helps write programming code in Python, Rust, TypeScript, and Go. It follows strict practices to ensure the code is high-quality and maintainable.

When to use it

  • ✓When you need to write a new script in Python, Rust, TypeScript, or Go.
  • ✓When fixing a bug in an existing code file (.py, .rs, .ts, .go).
  • ✓To ensure code follows modern best programming practices.

Example of what to ask your AI

“Write a Python function that calculates the average of a list of numbers, ensuring the list is not empty.”

Want more? Open the sections below.

How to use

The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.

Skill link

https://github.com/code-yeongyu/oh-my-openagent/blob/dev/packages/shared-skills/skills/programming/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/code-yeongyu/oh-my-openagent/blob/dev/packages/shared-skills/skills/programming/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
How it works

The agent first identifies the programming language of your file. Then, it reads the specific rules for that language and applies a general philosophy of writing clean and efficient code.

Installation

Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.

In the terminal (Claude Code, Codex, Cursor), in your project folder:

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

Or download just the file:

curl -L https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/dev/packages/shared-skills/skills/programming/SKILL.md -o SKILL.md
Technical content (original SKILL.md)

Original text by the author, straight from GitHub.

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.

…

FAQ

What does 'well-written code' mean?

It means code that is easy to understand, test, and maintain, following strict rules to avoid errors and unnecessary complexity.

Why is it important to follow specific rules for each language?

Each language has its own characteristics and best practices. Following these rules ensures the code is efficient, safe, and makes the most of the language's features.

What are 'tests that can fail'?

These are tests that check if the code works correctly in different situations, including error cases. They are essential to ensure the code is reliable.

Details

Original description by the author

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.

repo: code-yeongyu/oh-my-openagent

Popularity

GitHub stars
70k
Ranking position
#1741
License
NOASSERTION
Updated
10/16/2026

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills