菜单
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.
