← library
skill🧰 Engineering practicev3 · updated 2026-09-10

Code Style

Enforces Uplift Duo house code style — naming, comments, error handling, and structure. Use when writing, editing, or reviewing code in any language.

Run it as a prompt

Paste this into any AI agent, or fetch it: curl -s https://uplift.page/api/v1/prompts/code-style/raw

prompt.md
# Code Style

Baseline style rules that apply across all codebases. Language- or project-specific
rules belong in that project's own config, not here.

## Naming

- Names describe intent, not mechanics: `retryDelayMs`, not `num2`.
- Booleans read as predicates: `isReady`, `hasAccess`, `shouldRetry`.
- No abbreviations unless industry-standard (`id`, `url`, `db`).

## Comments

- Comment only what the code cannot say: constraints, invariants, links to specs or issues.
- Never write comments that narrate the code ("increment counter") or talk to a reviewer ("changed this to fix the bug").
- Delete commented-out code; git history keeps it.

## Error handling

- Fail loudly at boundaries; don't swallow exceptions or return silent defaults.
- Error messages state what failed and what input caused it.
- Don't catch an error you can't handle meaningfully — let it propagate.

## Structure

- Functions do one thing; if a function needs section comments, split it.
- Match the surrounding file's idiom and formatting — consistency beats personal preference.
- Avoid speculative abstraction: no interfaces, flags, or layers for needs that don't exist yet.

Install it as a skill

Agents that support the Agent Skills standard load it automatically when it applies.

download
curl -fsSL https://uplift.page/p/code-style/SKILL.md --create-dirs -o .agents/skills/code-style/SKILL.md
or from any MCP client
MCP server: https://uplift.page/mcp
Tool: pull_skill  {"slug": "code-style"}

The full skill

Baseline style rules that apply across all codebases. Language- or project-specific rules belong in that project's own config, not here.

Naming

  • Names describe intent, not mechanics: retryDelayMs, not num2.
  • Booleans read as predicates: isReady, hasAccess, shouldRetry.
  • No abbreviations unless industry-standard (id, url, db).

Comments

  • Comment only what the code cannot say: constraints, invariants, links to specs or issues.
  • Never write comments that narrate the code ("increment counter") or talk to a reviewer ("changed this to fix the bug").
  • Delete commented-out code; git history keeps it.

Error handling

  • Fail loudly at boundaries; don't swallow exceptions or return silent defaults.
  • Error messages state what failed and what input caused it.
  • Don't catch an error you can't handle meaningfully — let it propagate.

Structure

  • Functions do one thing; if a function needs section comments, split it.
  • Match the surrounding file's idiom and formatting — consistency beats personal preference.
  • Avoid speculative abstraction: no interfaces, flags, or layers for needs that don't exist yet.

Served from the uplift.page library and refreshed within 5 minutes of every update.