菜单
Use when working in `src/domains/`, introducing/extending a domain's public API (services, resources, hooks, repositories, schemas, README), modeling a user action in domain terms, event-storming domain seams, or deciding whether business logic belongs in a domain.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use BEFORE writing or changing any non-trivial code in `src/` — new code, new/moved/renamed files, a new abstraction, extending behavior, or a refactor that relocates logic. The single entry point that decides what the change is and where it goes before any file path is generated. Skip only for trivial in-place edits within one existing file.
Use before writing any non-trivial utility, helper, algorithm, data transformation, or wrapper that an installed dependency might already provide. Symptoms — about to hand-roll debounce/merge/groupBy/retry, a stream operator, a validator, or a wrapper around a first-party host/SDK package whose API you don't have in context.
Use BEFORE `domain-development`/`feature-development` when the target layer (domain, aggregate, feature, widget, shared) is uncertain — multi-layer changes, new abstractions, promoting code out of a feature, or "where should this live?". Skip when the layer is obvious.
Use when working in `src/features/` or `src/routes/` files hosting features, scaffolding a feature, wiring into `src/bootstrap.ts`, defining/injecting DI extension points (slots, pipelines, transformers, side effects, SDKs), placing cross-feature logic, or deciding whether two flows are one feature.
Use when writing, reviewing, or refactoring React code — components, hooks, data fetching, bundle optimization, re-render performance, or rendering throughput. Skip for non-React TypeScript, backend, or framework configuration.
Use to audit a branch diff or PR against THIS project's architecture and code rules — after implementing a change, before merging, or when asked to review a PR/branch. Project-rule-aware (cites docs/claude checklists with blocking/major/minor severity); complements the generic /code-review. Reads a plan in docs/_plans/ if present to diff intent vs implementation.
| name | domain-development |
| description | Use when working in `src/domains/`, introducing/extending a domain's public API (services, resources, hooks, repositories, schemas, README), modeling a user action in domain terms, event-storming domain seams, or deciding whether business logic belongs in a domain. |
Precondition: if you have not yet decided that the change is a domain change, run the code-placement skill first. This skill assumes the target layer is already src/domains/.
Then read docs/code/domain-development.md before touching domain code. It is the authoritative flow for src/domains/: principle, step-by-step path, file contracts, merge checklist, and event-storming guidance for spotting domain seams.
The skill body intentionally carries no rules — they live in the doc only, to keep one source of truth. Open the doc.
Cross-references:
docs/code/project-structure.md (Domain section) — folder/file rules.docs/code/code-placement.md — which layer/file + cut rules, when placement is uncertain.docs/code/architecture.md — how domain artifacts flow at runtime (read/write traces).docs/code/di.md — when DI wiring is involved.