메뉴
project coding guidelines input validation, error handling, DDD structure, type safety, testing, gRPC, Rust, linting, and more. Invoke when writing, reviewing, or planning code — including setting up a backend, API, service, or any new project.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Set up an opinionated TypeScript Node.js project in the current directory or a new named directory. Uses pnpm via corepack, strict tsconfig, eslint-config-agent, Prettier, Vitest, and git hooks. Use when initializing any Node.js service, CLI, or library — not Next.js (use new-project-nextjs for that).
Set up an opinionated Rust project in the current directory or a new named directory. Configures Cargo with common deps via cargo add, rustfmt, clippy, rust-toolchain, and git hooks. Use when initializing any Rust binary, library, or service.
This skill should be used when the user wants to "add a rule", "create a rule", "write a guideline rule", or asks to document a coding convention in the guidelines repo.
| name | coding-guidelines |
| description | project coding guidelines input validation, error handling, DDD structure, type safety, testing, gRPC, Rust, linting, and more. Invoke when writing, reviewing, or planning code — including setting up a backend, API, service, or any new project. |
| version | 0.1.2 |
Apply these rules when writing or reviewing code.
Client must not hardcode error message strings. Display message received from server response directly to user.
Keep info next to its source: spec files beside logic files, JSDoc instead of separate doc files, tests colocated with implementation.
Organize code by domain, not by layer. Each domain owns its models, services, repositories, and interfaces in a single cohesive directory.
Prefer gRPC over REST for internal service communication. Use REST only when clients cannot support gRPC (e.g., browsers without grpc-web).
Handle every branch, edge case, and error path — never skip logic with a stub, empty catch, or silent fallthrough.
Use an i18n library that supports type-safe language JSON files. This ensures translation keys are validated at compile time and refactoring is safe.
Prefer using an existing library over implementing logic yourself. Before writing custom code, check if a well-maintained library already solves the problem.
Prefer SSG over SSR or client-side rendering whenever content does not require per-request dynamic data.
Use Result/Option and pattern matching instead of panicking or throwing. Never use unwrap/expect in production paths; propagate errors with ? or match exhaustively.
Always use official SDKs for network communications. Never use plain HTTP/fetch/axios calls directly.
Always make small changes. Each change should be self-contained and easy to track in version control.
Migrate legacy systems incrementally by routing new functionality to new code alongside the old, not in a big-bang rewrite. Remove the old code only once the new path fully covers its behavior.
Run full lint, type-check, and test suite in pre-commit; run build and integration tests in pre-push. Never allow --no-verify to bypass hooks.
Enable all available linter rules and set warnings as errors. Never disable or suppress lint rules inline or in config without team approval.
Aim for 100% test coverage. Every code path, branch, and edge case must have a corresponding test.
Never use Python. Always choose type-safe languages; prefer Rust for new projects.
Always validate env values at startup using a schema library (e.g. env-schema, zod, envalid). Never access raw process.env without validation.
Always validate data at system boundaries: user inputs, API responses, and any network-received data before use.
