specx-add-core-service

Name: specx-add-core-service
Author: maksimzayats

199stars36forks

How to install specx-add-core-service?

maksimzayats/specx/specx-add-core-service

$npx -y skills add maksimzayats/specx --skill specx-add-core-service

Installs into the current project.

Summary

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 Servic

Files · 1

View on GitHub

SKILL.md

1	# specx Add Core Service
2
3	Use this skill for reusable core behavior that is smaller than an application
4	action. Read `references/service.md` before writing the service.
5
6	## Workflow
7
8	1. Confirm this is reusable business/application behavior, not a small
9	replaceable ability. Use `BaseCapability` instead for one narrow injectable
10	thing.
11	2. Name the behavior, not a vague role, and always use the `Service` suffix:
12	`InvoicePricingService`, `AccessPolicyService`, `OrderAllocationService`,
13	`SubscriptionRenewalService`.
14	3. Put it under `core/<scope>/services/<behavior>.py`.
15	4. Choose exactly one foundation base:
16	`BasePureService`, `BaseReadService`, or `BaseEffectService`.
17	5. Do not add or use a generic `BaseService`.
18	6. Inject concrete project collaborators when there is one implementation.
19	7. Inject ports/ABCs only for external IO, framework-bound dependencies, or
20	multiple real implementations. Do not create an interface only to make a
21	concrete collaborator mockable.
22	8. Add a docstring that explains the service scope and includes a concrete
23	`Example:`.
24	9. Keep methods keyword-only after `self`.
25	10. Do not open UoW scopes in services. Use cases own transaction lifecycle and
26	pass active UoWs into read/effect services when needed.
27	11. Add flat unit tests that receive the native pytest `container` fixture,
28	register local doubles or inline mocks before resolution, and resolve the
29	service with `container.resolve(ServiceClass)`.
30
31	Operational probe services may live under `core/health` when readiness checks
32	any required external dependency or policy is reused across deliveries.
33	Keep simple process liveness in delivery. Use a pure service for reusable
34	liveness policy and a read service for readiness coordination. Readiness
35	services depend on gateway ports, not SQLAlchemy, Redis, SDKs, or delivery
36	frameworks directly. Technical readiness adapters must bound external checks
37	with short timeouts so a probe cannot hang indefinitely.
38
39	## Code Style
40
41	Use blank lines as logical separators in all code. Keep related statements
42	together, but separate independent setup, action, assertion, response, branch,
43	and transformation groups so long blocks stay readable.
44
45	## References
46
47	- `references/service.md` - class shape, dependency choices, UoW parameter
48	rules, and unit-test examples.

People who liked this also viewed

6 picks

Type

specx-add-core-service

199stars36forks

View on GitHub

How to install specx-add-core-service?

maksimzayats/specx/specx-add-core-service

$npx -y skills add maksimzayats/specx --skill specx-add-core-service

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# specx Add Core Service
2
3	Use this skill for reusable core behavior that is smaller than an application
4	action. Read `references/service.md` before writing the service.
5
6	## Workflow
7
8	1. Confirm this is reusable business/application behavior, not a small
9	replaceable ability. Use `BaseCapability` instead for one narrow injectable
10	thing.
11	2. Name the behavior, not a vague role, and always use the `Service` suffix:
12	`InvoicePricingService`, `AccessPolicyService`, `OrderAllocationService`,
13	`SubscriptionRenewalService`.
14	3. Put it under `core/<scope>/services/<behavior>.py`.
15	4. Choose exactly one foundation base:
16	`BasePureService`, `BaseReadService`, or `BaseEffectService`.
17	5. Do not add or use a generic `BaseService`.
18	6. Inject concrete project collaborators when there is one implementation.
19	7. Inject ports/ABCs only for external IO, framework-bound dependencies, or
20	multiple real implementations. Do not create an interface only to make a
21	concrete collaborator mockable.
22	8. Add a docstring that explains the service scope and includes a concrete
23	`Example:`.
24	9. Keep methods keyword-only after `self`.
25	10. Do not open UoW scopes in services. Use cases own transaction lifecycle and
26	pass active UoWs into read/effect services when needed.
27	11. Add flat unit tests that receive the native pytest `container` fixture,
28	register local doubles or inline mocks before resolution, and resolve the
29	service with `container.resolve(ServiceClass)`.
30
31	Operational probe services may live under `core/health` when readiness checks
32	any required external dependency or policy is reused across deliveries.
33	Keep simple process liveness in delivery. Use a pure service for reusable
34	liveness policy and a read service for readiness coordination. Readiness
35	services depend on gateway ports, not SQLAlchemy, Redis, SDKs, or delivery
36	frameworks directly. Technical readiness adapters must bound external checks
37	with short timeouts so a probe cannot hang indefinitely.
38
39	## Code Style
40
41	Use blank lines as logical separators in all code. Keep related statements
42	together, but separate independent setup, action, assertion, response, branch,
43	and transformation groups so long blocks stay readable.
44
45	## References
46
47	- `references/service.md` - class shape, dependency choices, UoW parameter
48	rules, and unit-test examples.

People who liked this also viewed

6 picks

Type