\r \r

Role\r

\r This skill builds or modifies business modules in WelineFramework. It handles module structure, controllers, menus, route-aware setup, and bounded feature work while staying within module ownership instead of changing framework internals.\r \r

When To Use\r

\r

• Use for new module work, backend pages, frontend feature modules, registration files, and bounded feature delivery.\r
• Use for keywords such as module development, controller, menu, register, setup, feature module, and backend page.\r
• Use when the task belongs to one business module rather than shared framework internals.\r \r

Source Material\r

\r

• AI-ENTRY.md\r
• CLAUDE.md\r
• dev/ai/skills/module-development/SKILL.md\r
• dev/ai/skills/weline-framework-core/SKILL.md\r
• dev/ai/skills/community-module/SKILLS-CONSOLIDATED.md\r \r

Responsibilities\r

\r

• Build module-local functionality with clean structure and ownership.\r
• Keep controller, view, menu, and setup flows aligned inside the same module boundary.\r
• Route cross-module reads through supported interfaces instead of ad hoc coupling.\r
• Keep feature changes small enough to validate directly.\r \r

Workflow\r

\r

1. Read AI-ENTRY.md, the diagrams, the owning module docs, and then the relevant skills.\r
2. Confirm the target module, area, and feature boundary.\r
3. Implement the required controller, view, menu, model, or env updates inside the owning module.\r
4. Run setup or route refresh commands only when the module change requires them.\r
5. Add unit or route-level checks appropriate to the feature.\r
6. Update the module README when the bug or feature behavior changed materially.\r
7. Return focused evidence for the changed feature path.\r \r

Weline Rules\r

\r

• Do not edit generated/ directly.\r
• Do not use routes.xml.\r
• Do not hardcode user-facing text.\r
• Use i18n for user-facing text.\r
• Keep module boundaries intact.\r
• Update module README after fixing bugs.\r \r

Inputs Required\r

\r

• Target module name and owning business context.\r
• Requested feature behavior and UI or API surface.\r
• Any affected routes, menus, models, or setup changes.\r
• Expected validation path for the module.\r \r

Expected Output\r

\r

• A module-local implementation aligned with Weline module structure.\r
• Any required setup or route refresh evidence.\r
• Updated module README when the change alters user-visible behavior or fix status.\r \r

Validation\r

\r

• Run php bin/w setup:upgrade when schema or module setup changed.\r
• Run php bin/w setup:upgrade --route when controller routing changed.\r
• Run focused HTTP or unit checks on the changed module path.\r
• Confirm user-facing text is externalized through i18n.\r \r

Constraints\r

\r

• Do not escalate a module-local task into a framework-core refactor without reason.\r
• Do not directly couple to unrelated module internals for convenience.\r
• Do not leave feature changes unverified after setup-sensitive work.\r
• Do not write detailed fix reports into the repository root.\r \r