菜单
Use Specx foundation bases in Python services, or add a tiny project-local `foundation/` base for missing categories or stateful framework bases.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Design or review Specx core scope boundaries in Python services. Use when deciding where code belongs across packaged scoped foundation bases, optional local foundation extensions, `core/`, capabilities, delivery, infrastructure, `shared/`, and `ioc`; when adding guardrails or splitting use cases, services, DTOs, schemas, ports, and adapters.
Wire dependency injection for a Specx Python service with `diwire`. Use when adding `ioc/container.py`, explicit dependency registrations for capabilities, repositories, gateways, UoW managers, clients, settings, or factories, `Injected[...]` constructor fields, FastAPI app factory/lifecycle composition, test overrides, or rules that keep containers out of core use cases and services.
Create or reshape a Python FastAPI service repo into the Specx clean core/delivery architecture using packaged scoped foundation bases. Use when starting an API backend, adding the first src package, or establishing `AGENTS.md`, `core/`, optional local `foundation/`, `delivery/`, infrastructure, `ioc/`, migrations, and tests.
Add strict Python project tooling for a Specx service. Use when creating or updating `pyproject.toml`, `uv` dependency groups and lock checks, Ruff formatting and linting, mypy strict mode, pytest and HTTPX2 test configuration, Makefile commands, root `AGENTS.md` command guidance, or CI-like local guardrails.
Add or refine tests for Specx Python services. Use when creating unit tests for use cases/services, integration tests for FastAPI controllers or infrastructure adapters, e2e smoke tests, architecture import guardrails, DI override tests, pytest fixtures, or coverage and boundary checks.
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.
| name | specx-foundation |
| description | Use Specx foundation bases in Python services, or add a tiny project-local `foundation/` base for missing categories or stateful framework bases. |
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.
specx.core.foundation,
specx.delivery.foundation, and specx.infrastructure.foundation.src/<package>/foundation/ package.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.shared/, not
foundation/.TaskDTO, TaskEntity, TaskResponseSchema, CreateTaskUseCase, or
TaskTitleNormalizerService.BaseLifecycle for delivery app lifespan managers such as
FastAPILifecycle.@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.BaseCommand and BaseQuery as use-case input bases, independent from
BaseDTO. Commands and queries are not result DTOs.BaseStrEnum instead of plain str or Literal[...].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/foundation.md - packaged base catalog, import paths, extension
rules, and architecture guardrails.