\r \r

Role\r

\r This skill owns service-layer implementation and business-rule placement inside modules. It keeps controllers thin, models focused on persistence, and business logic extracted into services that can be tested and reused.\r \r

When To Use\r

\r

• Use for service classes, business-rule extraction, API service contracts, and coordination between controllers and models.\r
• Use for keywords such as service, business logic, orchestration, API layer, domain rule, and refactor controller logic.\r
• Use when a task is more about module behavior than about framework infrastructure.\r \r

Source Material\r

\r

• AI-ENTRY.md\r
• CLAUDE.md\r
• dev/ai/skills/service-development/SKILL.md\r
• dev/ai/skills/code-generation-standards/SKILL.md\r
• dev/ai/skills/module-development/SKILL.md\r \r

Responsibilities\r

\r

• Place business logic in services instead of controllers or templates.\r
• Define stable module-local service contracts and collaboration boundaries.\r
• Keep persistence concerns in models and orchestration concerns in services.\r
• Structure code to support unit testing and future reuse.\r \r

Workflow\r

\r

1. Confirm the business rule, the entry point, and the owning module.\r
2. Read the existing controller, service, and model interaction before changing structure.\r
3. Extract or implement the rule inside a service with explicit dependencies.\r
4. Keep controllers and console commands focused on input/output orchestration only.\r
5. Add unit tests around the extracted service behavior.\r
6. Validate the end-to-end feature path through its real entry point.\r
7. Report the service boundary and any new contract assumptions.\r \r

Weline Rules\r

\r

• Prefer small, isolated, testable changes.\r
• Keep module boundaries intact.\r
• Do not hardcode user-facing text.\r
• Use i18n for user-facing text.\r
• Provide unit test evidence where relevant.\r \r

Inputs Required\r

\r

• The current feature entry point and expected business outcome.\r
• The owning module and collaborating models or services.\r
• Any API or controller contracts that must remain stable.\r
• Required validation path and edge cases.\r \r

Expected Output\r

\r

• A service-layer implementation or refactor with clearer business boundaries.\r
• Unit-test or focused validation evidence for the business rule.\r
• Notes about affected controller, API, or model interactions.\r \r

Validation\r

\r

• Run targeted unit tests for extracted or changed service behavior.\r
• Run a route, command, or API check through the real entry point when relevant.\r
• Confirm controllers no longer contain unnecessary business-rule branches.\r
• Confirm models remain persistence-focused rather than becoming orchestration hubs.\r \r

Constraints\r

\r

• Do not move UI rendering logic into services.\r
• Do not bury business-critical logic inside controllers, commands, or templates.\r
• Do not introduce raw SQL or framework-invented APIs in service code.\r
• Do not change public contracts silently without documenting the impact.\r \r