typescript-coder

Implement minimal backend TypeScript changes while preserving existing design, contracts, and runtime behavior.

1|1|Updated Apr 8, 2026
One-click install
npx skills add https://github.com/GonkaGate/opencode-setup --skill typescript-coder-gonkagate
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: typescript-coder
Source: https://github.com/GonkaGate/opencode-setup/tree/main/.agents/skills/typescript-coder
Command: npx skills add https://github.com/GonkaGate/opencode-setup --skill typescript-coder-gonkagate

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Backend TypeScript edits often drift into unplanned rewrites, silently change contracts or persisted behavior, or add proof that does not match the real risk. This Skill keeps implementation work inside the existing seams of a repository so changes stay small, safe, and honest. ## Core Features & Use Cases - Seam-aware implementation: Names the active seam (TypeScript modeling, API contract, Fastify runtime, Prisma/PostgreSQL, Redis, or Vitest testing) and activates only the references the change actually crosses. - Design preservation: Checklists enforce that architecture boundaries, request/response shapes, error envelopes, and persisted data stay stable unless the task explicitly changes them. - Proof-slice selection: Guides choosing the smallest honest test or verification step for the touched risk instead of broad, low-signal test suites. - Use Case: When asked to refactor a Fastify handler that parses request bodies and writes to Postgres, the Skill keeps boundary parsing explicit, reuses existing error constants, preserves the transaction owner, and adds one focused test for the changed branch. ## Quick Start Ask the agent to implement a specific backend TypeScript change, such as refactoring a handler or wiring a new boundary, while preserving the existing design and adding a narrow test.

Frequently Asked Questions about typescript-coder

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refactor a TypeScript handler without breaking existing behavior?

Identify the source of truth first (spec, schema, or existing test), name the seams the edit touches, and choose the smallest safe delta. Preserve public types, error envelopes, and persisted behavior, then add one focused test for the changed risk.

When should I use neverthrow Result versus throwing errors in TypeScript?

Use Result for synchronous composed failure and ResultAsync only for non-async pipeline-style functions; use Promise<Result> when async/await reads better. Extend the error style the codebase already uses instead of mixing thrown errors and Results in one path.

When is ts-pattern a good fit for backend TypeScript code?

Use ts-pattern only for a real closed decision table or a clearer match over trusted discriminated unions, with .exhaustive() for closed inputs. Reject it for sequential, algorithmic, or boundary-validation logic where plain branching is clearer.

How do I choose the right test scope for a small code change?

Match the proof to the touched risk: unit tests for local branching, app.inject() route tests for Fastify schema and handler behavior, and real database or Redis tests when transactions, Decimal, TTL, or Lua semantics matter. Avoid tests that mirror implementation structure.

What are the limitations of a seam-preserving implementation approach?

It deliberately does not redesign architecture, change public contracts, or alter persisted behavior without explicit approval. When a change is blocked on a missing design or planning decision, the work stops and hands off to planning or architecture review instead of guessing.