← Browse

@maksimzayats/specx-foundation

A

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

skillclaude

Install

agr install @maksimzayats/specx-foundation --target claude

Writes 1 file into .claude/skills/, pinned to git-0686fa75.

  • .claude/skills/specx-foundation/SKILL.md

Document


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.

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

  1. Prefer packaged scoped bases from specx.core.foundation, specx.delivery.foundation, and specx.infrastructure.foundation.
  2. Do not create an empty src/<package>/foundation/ package.
  3. 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.
  4. 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/.
  5. Give every project source class, including each local base, a docstring that explains what it protects and includes a concrete usage example.
  6. Make every non-foundation project source class inherit an explicit scoped base.
  7. Name each class with the suffix implied by its base ancestry, such as TaskDTO, TaskEntity, TaskResponseSchema, CreateTaskUseCase, or TaskTitleNormalizerService.
  8. Use BaseLifecycle for delivery app lifespan managers such as FastAPILifecycle.
  9. 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.
  10. Keep BaseCommand and BaseQuery as use-case input bases, independent from BaseDTO. Commands and queries are not result DTOs.
  11. When an application value has a limited known set, model it with BaseStrEnum instead of plain str or Literal[...].
  12. 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.

Trustgrade A

  • passBody integrity

    Whether the stored document is plausibly the kind of file the artifact declares, rather than something fetched by mistake.

  • passType matchnot applicable to this artifact type

    Whether the artifact is really the kind of thing its metadata claims it is.

  • passFreshness

    How long since the source repository was last pushed to.

  • passPrompt injection

    Scans the artifact's own text for instructions aimed at your agent rather than at you.

  • passLicense

    Whether the source repository declares an SPDX license permissive enough to redistribute.

How the grade is calculated

Each check contributes 0 points when it passes, 1 when it warns, and 2 when it fails. The total maps to a letter:

  • Aevery check passed
  • Bone warning
  • Ctwo warnings
  • Dprompt injection or body integrity failed, or three warnings
  • Fone of those failed, and something else is wrong

These are automated hygiene checks, not a security audit, and not a dependency or vulnerability scan. A grade of A means nothing was flagged — not that the artifact is safe.

Versions

  • git-0686fa75da702026-07-31