Code Style Skill
SkillDev toolsGives 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.
Account requirements not reviewed. Check the skill instructions before use; Ahel provides instructions and does not run this skill.
No other account needed.
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.Contextas first function argument for server/domain methods. - Use
HandleXnames 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.cssfiles (CSS Modules). - Use the
classnameslibrary 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 matchingPascalCase.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 { ... }whenMessageis in the schema. - Good:
proto.Message.Fielddirectly.
- Bad:
- 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.mdbefore 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
gofmtoutput. - 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
Related picks
Skill · samber
The pick for Godbos-golang
Skill · sickn33
The pick for Goduplicate-js
Skill · thedaviddias
The pick for JavaScriptmodern-javascript-patterns
Skill · sickn33
The pick for JavaScriptreact-component-performance
Skill · davila7
The pick for Reactreact-doctor
Skill · millionco
The pick for React