specx-foundation

Use specx foundation bases in Python services, or add a tiny project-local `foundation/` base for missing categories or stateful framework bases.

跳到安装

仓库: maksimzayats/specx
最近来源活动: 2026年7月18日 15:18
检测到的 SKILL.md 语言: 英语
星标: 201
分支: 35

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

直接命令不会经过审查 Prompt；运行前请先检查来源。

npx skills add https://github.com/maksimzayats/specx --skill specx-foundation

命令会保持在同一行。复制前请横向滚动并检查完整内容。

想先保存到本地？可下载 SkillsMP 当前能够提供的文件。

检查来源文件

决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。

文件资源管理器

3 个文件

SKILL.md

来源说明 · 只读预览

返回搜索返回安装

specx-add-core-service

Add or refactor a specx core scope service. Use when implementing focused reusable business/application behavior under a core scope services package, extracting logic from a use case, injecting deterministic collaborators, accepting an active unit of work, choosing between Service and Capability, or keeping business decisions away from delivery and infrastructure.

2026-07-18

specx-add-core-use-case

Add or refactor a specx core scope use case. Use when implementing an externally meaningful application action under a core scope use_cases package, adding same-file command/query inputs, result DTOs, coordinating services, opening a unit-of-work transaction, or moving behavior out of delivery or infrastructure into class-based application code.

2026-07-18

specx-add-delivery-controller

Add delivery controllers for specx services, especially FastAPI HTTP routes. Use when creating top-level `delivery/` request/response schemas, one controller per scoped use-case set, route registration, FastAPI lifecycle managers, HTTP error translation, delivery-only auth/rate-limit/request services, or integration tests that exercise the delivery edge.

2026-07-18

查看这个仓库的全部 Skills

specx Foundation

Use this skill when a service class needs an explicit base, or when a new class category may need a project-local foundation base. Read references/foundation.md before editing foundation-related code.

Workflow

Prefer packaged scoped bases from specx.core.foundation, specx.delivery.foundation, and specx.infrastructure.foundation.

Do not create an empty src/<package>/foundation/ package.

Add a project-local foundation/ module only when current code needs a real project-local base category or a stateful framework base that must not be shared globally, such as a SQLAlchemy declarative base.

Keep project-local foundation limited to base definitions: marker bases, common external-base wrappers, justified ABCs, and stateful framework bases. Put stable cross-scope concrete primitives under shared/, not foundation/.

Give every project source class, including each local base, a docstring that explains what it protects and includes a concrete usage example.

Make every non-foundation project source class inherit an explicit scoped base.

Name each class with the suffix implied by its base ancestry, such as TaskDTO, TaskEntity, TaskResponseSchema, CreateTaskUseCase, or TaskTitleNormalizerService.

Use BaseLifecycle for delivery app lifespan managers such as FastAPILifecycle.

Prefer @dataclass(frozen=True, kw_only=True, slots=True) for commands, queries, DTOs, entities, and other core data classes unless the user asks for another model type.

Keep BaseCommand and BaseQuery as use-case input bases, independent from BaseDTO. Commands and queries are not result DTOs.

When an application value has a limited known set, model it with BaseStrEnum instead of plain str or Literal[...].

Keep business rules, delivery behavior, adapter code, and runtime wiring out of project-local foundation modules.

Code Style

Use blank lines as logical separators in all code. Keep related statements together, but separate independent setup, action, assertion, response, branch, and transformation groups so long blocks stay readable.

References

references/foundation.md - packaged base catalog, import paths, extension rules, and architecture guardrails.