Генерация и доработка модулей MikoPBX. Создание новых модулей по описанию на естественном языке, добавление функциональности в существующие модули, оптимизация и унификация кода модулей. Использовать когда пользователь хочет создать новый модуль, добавить фичу в модуль, оптимизировать модуль или узнать как устроена система модулей.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Генерация и доработка модулей MikoPBX. Создание новых модулей по описанию на естественном языке, добавление функциональности в существующие модули, оптимизация и унификация кода модулей. Использовать когда пользователь хочет создать новый модуль, добавить фичу в модуль, оптимизировать модуль или узнать как устроена система модулей.
allowed-tools
Bash, Read, Write, Edit, Grep, Glob, Agent
MikoPBX Module Generator & Optimizer
Создание, доработка и оптимизация модулей для MikoPBX 2025.1.1+.
What This Skill Does
Создание новых модулей — по описанию на естественном языке генерирует полную структуру модуля с нужными интеграционными паттернами
Доработка существующих модулей — добавляет новую функциональность (REST API, workers, dialplan hooks и т.д.)
Оптимизация и унификация — находит антипаттерны и приводит код к эталонным стандартам
Консультация — отвечает на вопросы по архитектуре модулей
When to Use
"Создай модуль для ..." / "Create module for ..."
"Добавь REST API в ModuleXxx" / "Add REST API to ModuleXxx"
"Оптимизируй ModuleXxx" / "Optimize ModuleXxx"
"Как сделать ... в модуле?" / "How to ... in a module?"
Любые запросы про создание, доработку или архитектуру модулей MikoPBX
Target Platform
PHP: 8.4
min_pbx_version: 2025.1.1
Framework: Phalcon 5.9.3
NO legacy compatibility (no MikoPBXVersion.php)
Core Workflow
Mode 1: Create New Module
Phase 1 — Discovery Dialog
Parse user's natural language description and determine:
Module purpose — what problem it solves
Module name — suggest ModuleXxxYyy following MikoPBX conventions
Target location — ask user:
Extensions/ — for production modules
Extensions/EXAMPLES/{Category}/ — for example/learning modules
Required recipes — analyze description and propose:
RESTful design gate — when the rest-api recipe is selected, list business
resources before endpoints. Give each resource its own
Lib/RestAPI/{Resource}/ boundary, noun-based path, schema, lifecycle, and
permissions. Map CRUD to standard HTTP methods. Use :action only for a
domain state transition that cannot be represented as CRUD. Never collect
unrelated module operations in one controller.
Confirm plan — present proposed structure and get user approval before generating
Ask many questions! It's better to clarify intent than to guess wrong. Examples:
"Модуль будет иметь свою страницу настроек в админке?"
"Нужен ли REST API для внешних интеграций?"
"Модуль должен реагировать на события звонков?"
"Есть ли данные, которые нужно хранить в базе?"
Phase 2 — Generation
Generate files using reference templates in templates/ directory. For each recipe, create the corresponding files.
File generation order:
module.json — module metadata
README.md and README.ru.md — equivalent administrator documentation
(the pair is a production-target requirement; example modules carry at most
one readme, so do not generate both for them)
.github/workflows/build.yml — production build and publish automation
(production target only — modules under Extensions/EXAMPLES/ are built by
the shared EXAMPLES/.github/workflows/build-modules.yml and must not get
their own publish workflow)
Setup/PbxExtensionSetup.php — installer
Models/*.php — database models
Lib/{Name}Conf.php — configuration class with hooks
Lib/{Name}Main.php — business logic (if needed)
App/Controllers/ — web controllers (if ui recipe)
App/Forms/ — Phalcon forms (if ui recipe)
App/Views/ — Volt templates (if ui recipe)
App/Providers/ — optional per-module Asset/Menu provider helpers (multi-page ui modules only; single-page modules register assets in the controller)
public/assets/js/src/ — ES6+ JavaScript, one file per action (if ui recipe)
public/assets/css/ — CSS styles (if ui recipe)
Lib/RestAPI/ — REST API controllers and actions (if rest-api recipe)
Code references: When generating code, study existing EXAMPLES for patterns:
REST API v3: Extensions/EXAMPLES/REST-API/ModuleExampleRestAPIv3/
Web UI: Extensions/EXAMPLES/WebInterface/ModuleExampleForm/
AMI Workers: Extensions/EXAMPLES/AMI/ModuleExampleAmi/
REST API v1/v2: Extensions/EXAMPLES/REST-API/ModuleExampleRestAPIv{1,2}/
Read the actual source code from these examples before generating — they are the canonical reference.
Phase 3 — Post-Generation Checks
After generating all files, run:
# 1. PHP syntax check on all generated PHP files
find {module_dir} -name "*.php" -exec php -l {} \;
# 2. Babel transpilation for JS files (if ui recipe)# Use /babel-compiler skill# 3. module.json validation
php -r "json_decode(file_get_contents('{module_dir}/module.json'), true) ?: exit(1);"# 4. Standalone module translation catalogs — matched on the argument, so a# `require`/`include` inside a translated value ('Include only internal# calls') is ignored while `array_merge(include 'base.php', …)` is caught.
! grep -RE '(require|include)(_once)?[[:space:]]*\(?[[:space:]]*(__DIR__|__FILE__|\$[A-Za-z_]|['"'"'"][^'"'"'"]*\.php)|\b(array_keys|array_combine)[[:space:]]*\(' \
{module_dir}/Messages/*.php
# 5. Production repository files — production target ONLY. Several example# modules ship no ru readme (and ModuleExampleForm names it readme.ru.md),# so running this on them only produces false failures.test -f {module_dir}/README.md
test -f {module_dir}/README.ru.md
# 6. Publish workflow — production target ONLY. Example modules have no# per-module workflow, so this check must be skipped for them.test -f {module_dir}/.github/workflows/build.yml
# 7. REST/OpenAPI translations — run from the Core repository root when the# rest-api recipe is present. Checks module-owned keys and generated tag# keys in both English and Russian catalogs.
php .claude/skills/mikopbx-module/scripts/validate-rest-api-translations.php {module_dir}
Report results and suggest fixes for any issues found.
See templates/ directory for code generation templates.
Translation Integration
After generating PHP code, invoke the /translations skill to create Messages files for all 29 languages.
Workflow:
Collect all translation keys used in generated code (controllers, views, forms)
Create Russian translations first (Messages/ru.php)
Call /translations skill to translate to remaining 28 languages
For every REST API resource, also collect the complete OpenAPI contract:
tag keys generated from ApiResource::tags, for example
Module Phrase Studio - Voices → rest_tag_ModulePhraseStudioVoices;
every ApiOperation summary and description key;
every parameter description key;
every request/response schema field description key;
module-specific ApiResponse keys.
Define every collected key in both Messages/en.php and Messages/ru.php
before generation is complete. A visible raw identifier such as
rest_tasks_GetList or rest_tag_ModuleExampleTasks is a validation failure,
not an acceptable fallback. Run
scripts/validate-rest-api-translations.php through the post-generation check.
Every module catalog MUST also contain the three registration keys consumed by
MikoPBX Core, even though module-owned PHP, JavaScript, and views do not
reference them:
Breadcrumb<ModuleUniqueID> — module title and breadcrumb label
SubHeader<ModuleUniqueID> — module description
Validate these keys in all 29 locales. Missing registration keys are rendered
as raw key names in module-management pages.
Every Messages/<locale>.php file MUST directly return a standalone literal
array. Never use require, include, variables, array_keys,
array_combine, merges, or runtime catalog composition. MikoPBX loads and
processes each catalog itself.
Production Repository Contract
For production modules:
Create equivalent README.md (English default) and README.ru.md files for
administrators. Lead with purpose, installation/use, security, privacy,
troubleshooting, and support; keep contributor commands secondary.
Inspect a current maintained production module such as
ModuleZabbixAgent5 before adding automation.
Add .github/workflows/build.yml using
mikopbx/.github-workflows/.github/workflows/extension-publish.yml@master
for develop, master, and workflow_dispatch.
Add release_settings.publish_release, changelog_enabled, and
create_github_release to module.json.
Verify develop creates a prerelease and master performs production
publication before pushing either branch.
Important Directories
Production modules: /Volumes/DevDisk/Developement/mikopbx/Extensions/
Example modules: /Volumes/DevDisk/Developement/mikopbx/Extensions/EXAMPLES/
