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.
1---2name: code-style3description: Use this skill when implementing/refactoring frontend/backend code and you need Dekart-specific conventions for naming, code organization, architecture boundaries, and style consistency.4---56# Code Style Skill78## Trigger910Use 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.1112Policy/architecture guardrails are defined in `AGENTS.md`. This skill is the source of truth for implementation conventions.1314## Backend Conventions1516- Go file names are short lowercase, no snake case except `_test.go`.17- Keep `context.Context` as first function argument for server/domain methods.18- Use `HandleX` names for HTTP wrappers that bridge transport -> existing server method.19- Return typed gRPC status errors from endpoint business logic.20- Keep auth/workspace gating explicit near method start (`user.GetClaims`, workspace checks).21- Add short rationale comments before non-trivial conditional business logic.22- 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.2324## CSS2526- All component-specific styles must live in `*.module.css` files (CSS Modules).27- Use the `classnames` library to combine CSS classes dynamically in JSX, not manual string concatenation.28- Do not manually add browser prefixes (`-webkit-`, `-moz-`, `-ms-`, `-o-`). Autoprefixer handles this.2930## Frontend Conventions3132- Component files use `PascalCase.jsx`; component styles use matching `PascalCase.module.css`.33- Non-component frontend files use `camelCase.js` (actions, reducers, lib hooks/utils).34- Keep shared application state in Redux.35- Keep side effects/network calls in actions/thunks, not reducers.36- Keep reducers pure and action-driven.37- Keep reusable non-UI logic in `src/client/lib`.38- Prefer Ant Design components for UI by default.3940## Redundant Checks4142Do not add checks for conditions already guaranteed by code structure or calling context.4344Remove checks when:45- A value is always provided by the constructor/factory/initialization.46- Project structure makes only one option valid.47- A value is already validated earlier in the call chain or by middleware.48- Configuration enforces a specific value.4950Keep checks for: user input, environment variables, runtime variations, cross-platform paths, optional features.5152## Protobuf5354- Never handle both protobuf objects and plain objects. Pick one representation.55- If a proto schema defines a property, it's always defined. Access it directly.56 - Bad: `if proto.Message != nil { ... }` when `Message` is in the schema.57 - Good: `proto.Message.Field` directly.58- Only check optional fields, oneof fields, or empty repeated fields (when length matters).5960## Change Shape Guidance6162- Prefer small, surgical edits over broad refactors unless refactor is required for correctness.63- Keep patterns consistent with neighboring code in the same folder.6465## Unit Test Guidance6667- Follow the unit-test policy in `AGENTS.md` before adding or changing unit-test coverage.68- Assert meaningful behavior and a clear failure mode through the public or stable interface.69- Keep tests independent from the implementation logic so the same mistake is not copied into both.7071## Readability Guidance72- when edit function that already exceeds 50 lines, consider splitting it into smaller functions with clear names and purpose.73- when edit file that already exceeds 300 lines, consider splitting it into smaller files with clear names and purpose.