quality-code
Skill4 starsChanged 3 months agoMITView on GitHub
Use when writing or reviewing TypeScript/full-stack code. Encodes principles for type safety (branded types, discriminated unions, end-to-end types), real tests over mocks, OpenTelemetry observability, and picking the right abstractions instead of premature ones.
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use the type system to make invalid states fail at compile time.
- Distinctive: line 31
If the project already uses a library with native branded-type support (e.g.
- Very specific: line 50
Don't restate types you can derive.
- Distinctive: line 83
Don't mock things you can run.
- Distinctive: line 93
When adding observability, instrument with OTel spans.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Writing quality full-stack TypeScript
Apply these principles when writing or reviewing TypeScript code.
Make impossible states unrepresentable
Use the type system to make invalid states fail at compile time. Fewer reachable states = easier code to read and change.
Branded types
Brand primitives so they can't be mixed up. Validate once at the boundary; downstream code trusts the type.
type PhoneNumber = string & { __brand: "PhoneNumber" };
function parsePhone(input: string): PhoneNumber {
if (!/^\+?\d{10,15}$/.test(input)) throw new Error(`Invalid: ${input}`);
return input as PhoneNumber;
}
function sendSMS(to: PhoneNumber, body: string) {
/* input is trusted */
}If the project already uses a library with native branded-type support (e.g. Effect), use their primitives instead of rolling your own.
Discriminated unions over flag bags
// Don't — invalid combos representable
type State = { loading: boolean; user?: User; error?: string };
// Do — only valid states exist
type State =
| { status: "loading" }
| { status: "success"; user: User }
| { status: "error"; error: string };Let the types flow end-to-end
DB schema → server → client should share types without manual duplication. Use whatever end-to-end type tool the project already has (tRPC, oRPC, Elysia, TanStack Start). A users.email branded as Email should arrive on the client still branded.
Don't restate types you can derive. Reach for Pick, Omit, Parameters, ReturnType, Awaited, typeof etc. before writing a new interface. For function arguments, infer from the source instead of typing them by hand:
// Don't — duplicate shape, drifts when the row changes
type UserSummary = { id: string; email: Email };
function renderUser(u: UserSummary) {
/* ... */
}
// Do — derive from the source of truth
type User = Awaited<ReturnType<typeof db.query.users.findFirst>>;
function renderUser(u: Pick<User, "id" | "email">) {
/* ... */
}Pass objects, not positional args
// Don't — swap two args, still compiles
sendEmail("Welcome!", "Hi there");
// Do — order-independent, self-documenting
sendEmail({ to: "alice@x.com", body: "Hi there" });Skip on hot perf-critical paths; use elsewhere by default.
Standard Schema for shared validation
For libraries or code that doesn't want to pick a validator, accept StandardSchemaV1<unknown, T>.
Tests as real as possible
Don't mock things you can run. Spin up real services:
- LocalStack for AWS
- Miniflare for Cloudflare Workers
- Real Postgres/SQLite (e.g.
bun:sqlite), not a mock DB
Mock only third-party services that have no test environment.
OpenTelemetry, not print logging
When adding observability, instrument with OTel spans. The setup cost pays back the first time a user sends a request ID and you can answer instead of guess.
Other versions2 projects use a version of this.
Word for word · 1
- RhysSullivan/skills★ 104100% same
Edited · 0
None found.
Wrote their own version · 1
- gillkyle/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository6 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- effect-client-wrapperSkill
- effect-tsSkill
- opentuiSkill
- shadcnSkill
- lint-and-formatSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

