shkumbinhasani 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 for every coding task.
- For React, routing, forms, client state, or UI work, also read references/frontend.md.
- For contracts, oRPC, services, repositories, providers, Drizzle, or server work, also read 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.