# Shkumbin Code Style

> Implement or refactor TypeScript application code in Shkumbin's preferred architecture and coding style. Use for existing better-t-stack-style React, TanStack, oRPC, Drizzle, and related full-stack repositories; do not use for testing strategy or deployment design.

- Skill: `shkumbinhasani/shkumbin-code-style` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add shkumbinhasani/shkumbin-code-style`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shkumbinhasani/shkumbin-code-style/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: shkumbinhasani (https://skillmd.com/u/shkumbinhasani)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/shkumbinhasani/shkumbin-code-style

---


# Shkumbin Code Style

Apply these preferences to implementation and refactoring work in an existing application.

## Start by inspecting the repository

- Read the relevant package manifests, framework configuration, and nearby code before choosing paths or APIs.
- Adapt to the technologies already initialized in the repository. Do not redesign deployment, package management, or application scaffolding.
- Preserve unrelated user changes.
- When modifying a feature, migrate the files that must be touched to this style and update required dependents. Clean each touched file completely while preserving behavior.
- Do not silently refactor adjacent files. Mention worthwhile adjacent cleanup as an optional follow-up.

## Resolve decisions deliberately

- Read [references/shared-code.md](references/shared-code.md) for every coding task.
- For React, routing, forms, client state, or UI work, also read [references/frontend.md](references/frontend.md).
- For contracts, oRPC, services, repositories, providers, Drizzle, or server work, also read [references/backend.md](references/backend.md).
- If a meaningful implementation choice is not covered, ask one concrete question before deciding. Include a realistic code or file-structure example; do not ask abstract architecture questions.
- Ask about every uncovered choice, not only high-risk choices. Apply the answer to the current task only. Do not update this skill unless the user explicitly asks.
- Do not ask about testing strategy; it is intentionally outside this skill.

## Implement and verify

- Prefer the smallest coherent change that fully implements the requested behavior.
- Run the repository's relevant formatter, typecheck, lint, and existing targeted verification after editing. Do not introduce a testing discussion unless the user requests it.
- Report the outcome and any optional nearby migration separately.

## Primary design references

- [Building Type-Safe Compound Components](https://tkdodo.eu/blog/building-type-safe-compound-components)
- [Component Composition is Great](https://tkdodo.eu/blog/component-composition-is-great-btw)
- [Creating Query Abstractions](https://tkdodo.eu/blog/creating-query-abstractions)
- [Zustand and React Context](https://tkdodo.eu/blog/zustand-and-react-context)
- [React: You Might Not Need an Effect](https://react.dev/learn/you-might-not-need-an-effect)