# Code Style

> Use this skill when implementing/refactoring frontend/backend code and you need Dekart-specific conventions for naming, code organization, architecture boundaries, and style consistency.

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

---


# Code Style Skill

## Trigger

Use when editing code where consistency with existing Dekart patterns matters (especially `src/client`, `src/server/dekart`, and `src/server/*` domain packages). Do not load for non-code tasks.

Policy/architecture guardrails are defined in `AGENTS.md`. This skill is the source of truth for implementation conventions.

## Backend Conventions

- Go file names are short lowercase, no snake case except `_test.go`.
- Keep `context.Context` as first function argument for server/domain methods.
- Use `HandleX` names for HTTP wrappers that bridge transport -> existing server method.
- Return typed gRPC status errors from endpoint business logic.
- Keep auth/workspace gating explicit near method start (`user.GetClaims`, workspace checks).
- Add short rationale comments before non-trivial conditional business logic.
- In integration/transport glue, prefer decoding into existing contract types already used by nearby handlers (proto/shared schema) instead of introducing new local arg structs.

## CSS

- All component-specific styles must live in `*.module.css` files (CSS Modules).
- Use the `classnames` library to combine CSS classes dynamically in JSX, not manual string concatenation.
- Do not manually add browser prefixes (`-webkit-`, `-moz-`, `-ms-`, `-o-`). Autoprefixer handles this.

## Frontend Conventions

- Component files use `PascalCase.jsx`; component styles use matching `PascalCase.module.css`.
- Non-component frontend files use `camelCase.js` (actions, reducers, lib hooks/utils).
- Keep shared application state in Redux.
- Keep side effects/network calls in actions/thunks, not reducers.
- Keep reducers pure and action-driven.
- Keep reusable non-UI logic in `src/client/lib`.
- Prefer Ant Design components for UI by default.

## Redundant Checks

Do not add checks for conditions already guaranteed by code structure or calling context.

Remove checks when:
- A value is always provided by the constructor/factory/initialization.
- Project structure makes only one option valid.
- A value is already validated earlier in the call chain or by middleware.
- Configuration enforces a specific value.

Keep checks for: user input, environment variables, runtime variations, cross-platform paths, optional features.

## Protobuf

- Never handle both protobuf objects and plain objects. Pick one representation.
- If a proto schema defines a property, it's always defined. Access it directly.
  - Bad: `if proto.Message != nil { ... }` when `Message` is in the schema.
  - Good: `proto.Message.Field` directly.
- Only check optional fields, oneof fields, or empty repeated fields (when length matters).

## Change Shape Guidance

- Prefer small, surgical edits over broad refactors unless refactor is required for correctness.
- Keep patterns consistent with neighboring code in the same folder.

## Unit Test Guidance

- Follow the unit-test policy in `AGENTS.md` before adding or changing unit-test coverage.
- Assert meaningful behavior and a clear failure mode through the public or stable interface.
- Keep tests independent from the implementation logic so the same mistake is not copied into both.

## Readability Guidance
- when edit function that already exceeds 50 lines, consider splitting it into smaller functions with clear names and purpose.
- when edit file that already exceeds 300 lines, consider splitting it into smaller files with clear names and purpose.