Backend Domain Skill Author
Turn stable product-specific behavior into a concise local skill without duplicating generic architecture rules.
Required Context
Read AGENTS.md, .codex/references/domain-skill-policy.md, relevant docs/product/ rules, docs/architecture/domain-model.md, docs/architecture/api-contract.md, and docs/architecture/backend-implementation-contract.md.
Create a domain skill only when the behavior is approved, bounded, reusable, and specific to this product. Stop if rules, ownership, permissions, sensitive data, state transitions, or failure behavior remain unresolved.
Workflow
- Name one capability with lowercase hyphen-case, preferably verb-led and under 64 characters.
- Create
.agents/skills/<capability>/SKILL.md and agents/openai.yaml.
- Put only
name and a trigger-rich description in SKILL.md frontmatter.
- Document required project context, business vocabulary,
BR-### rules, workflow, invariants, allowed dependencies, forbidden behavior, tests, and completion evidence.
- Link directly to project contracts instead of copying them into the skill.
- Keep generic Model, DTO, Repository, Service, Controller, migration, and testing rules in the existing kit skills.
- Validate the skill with the available skill validator and add it to the project skill inventory in
AGENTS.md.
Boundaries
- Do not invent or approve business behavior.
- Do not store secrets, credentials, executor configuration, temporary prompts, or run artifacts.
- Do not create README, changelog, installation, or duplicated reference files without a direct execution need.
- Do not create one skill per entity or endpoint when a cohesive bounded capability is sufficient.
Finish only when the skill has clear triggers, traceable business rules, narrow scope, valid metadata, and no duplicated generic architecture prose.
1---2name: backend-domain-skill-author3description: Create or update a project-specific backend domain skill from stable, approved product behavior. Use when a bounded capability such as order lifecycle, subscription renewal, credit approval, scheduling, or payment reconciliation has repeated business rules, vocabulary, state transitions, permissions, or failure handling that future agents must reuse. Do not use for generic Django layer guidance or unresolved product decisions.4---56# Backend Domain Skill Author78Turn stable product-specific behavior into a concise local skill without duplicating generic architecture rules.910## Required Context1112Read `AGENTS.md`, `.codex/references/domain-skill-policy.md`, relevant `docs/product/` rules, `docs/architecture/domain-model.md`, `docs/architecture/api-contract.md`, and `docs/architecture/backend-implementation-contract.md`.1314Create a domain skill only when the behavior is approved, bounded, reusable, and specific to this product. Stop if rules, ownership, permissions, sensitive data, state transitions, or failure behavior remain unresolved.1516## Workflow17181. Name one capability with lowercase hyphen-case, preferably verb-led and under 64 characters.192. Create `.agents/skills/<capability>/SKILL.md` and `agents/openai.yaml`.203. Put only `name` and a trigger-rich `description` in SKILL.md frontmatter.214. Document required project context, business vocabulary, `BR-###` rules, workflow, invariants, allowed dependencies, forbidden behavior, tests, and completion evidence.225. Link directly to project contracts instead of copying them into the skill.236. Keep generic Model, DTO, Repository, Service, Controller, migration, and testing rules in the existing kit skills.247. Validate the skill with the available skill validator and add it to the project skill inventory in `AGENTS.md`.2526## Boundaries2728- Do not invent or approve business behavior.29- Do not store secrets, credentials, executor configuration, temporary prompts, or run artifacts.30- Do not create README, changelog, installation, or duplicated reference files without a direct execution need.31- Do not create one skill per entity or endpoint when a cohesive bounded capability is sufficient.3233Finish only when the skill has clear triggers, traceable business rules, narrow scope, valid metadata, and no duplicated generic architecture prose.
viniciusjsdev