code-style

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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

- Prefer Ant Design components for UI by default.
- 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`.
- Never create a named function inside another function. Every named function is declared as `function doThing (...)` at module scope and takes what it needs as explicit arguments, including refs and setters. There is no exception for closing over props, state or refs: pass them in, or group them into one object.
- Anonymous inline callbacks are fine.
– Move large useEffect hooks into custom hooks to keep component logic readable.

## 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

- For new self-contained logic/UI, consider a dark library; see `skills/dark-library/SKILL.md`.
- 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
- Keep JavaScript/JSX and Go lines near 80–100 characters; review lines over 120, not a hard limit.
- Break JSX props, conditions, and calls at logical boundaries. In Go, keep `gofmt` output.
- 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.

From dekart-xyz/dekart, AGPL-3.0.

More from dekart-xyz/dekart