Code Style Skill

SkillDev tools

Gives your agent Dekart's coding conventions for naming, file layout, and style when writing or refactoring its code.

Then ask your AI: use the Code Style Skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Add it as a step in a pipeline you build on Ahel, or connect Ahel to Claude, ChatGPT, Cursor, Claude Code or Codex and ask your AI to use it.

About this skill

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

What this skill tells your AI

The instructions your AI receives, as published by dekart-xyz/dekart in skills/code-style/SKILL.md and read by Ahel’s review.

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.

Signals

GitHub stars
431
Forks
61
Last commit
Oct 2026
Advanced
Item type
skill
Key
code-style-dekart-xyz
Source
github.com/dekart-xyz/dekart