mcub-openagent-workflow

name	MCUB-openagent-workflow
description	Route OpenAgent MCUB work across repo navigation, debugger fixes, module creation, release workflows, and skill registry management.
keywords	["openagent","skill","skills","cкилл","cкиллы","workflow","aгeнт","repo","registry"]

MCUB OpenAgent Workflow

Use this skill when the user asks OpenAgent to work in the MCUB repositories, manage MCUB skills, inspect MCUB workflows, fix debugger findings, create modules, or prepare module releases.

This is the top-level routing skill for MCUB work. It does not replace the focused MCUB skills; it decides which workflow applies and keeps OpenAgent aligned with MCUB project conventions.

Core identity and context

• MCUB is a Telegram userbot project based on Telethon/Telethon-MCUB.
• MCUB modules are not Hikka modules.
• Do not use Hikka-style assumptions, imports, module base classes, or registration patterns.
• Treat openagent_skills/<skill-name>/SKILL.md as the local OpenAgent skill source of truth.
• Treat .opencode/skills as OpenCode-only and do not use it for OpenAgent skill loading.
• Preserve unrelated working-tree changes unless the user explicitly asks to include them.

Workflow routing

Route the task before editing anything.

Module creation or module updates

Use MCUB-modules-creator when the user asks to create, edit, update, refactor, or debug an MCUB module build.

That workflow owns:

• debug module location and versioning under app-debug;
• MCUB class-style module conventions;
• command and inline form/callback guidance;
• module dependency and metadata expectations;
• MCUB debugger validation for module builds.

Module release or publishing

Use MCUB-release-modules when the user asks to release, publish, upload, ship, index, commit, or push an MCUB module to the public module repository.

That workflow owns:

• release source and destination paths;
• module repository filename conventions;
• modules.ini entry rules;
• syntax and MCUB debugger validation before release;
• release repository commits and pushes when explicitly requested by the workflow.

Debugger rule work

Use the debugger workflow when the user asks about MCUB warning IDs, false positives, rule behavior, or debugger tests.

For debugger work:

• identify the warning ID and affected module first;
• prefer targeted rule changes over broad rewrites;
• add or update focused tests for the rule behavior;
• validate the targeted debugger tests;
• when practical, run the debugger against the affected module;
• avoid changing unrelated module behavior just to silence a warning.

Skill registry management

Use the OpenAgent skill registry workflow when the user asks to list, read, import, export, or save skills.

OpenAgent supports skill operations through its existing registry behavior. Use those existing operations instead of creating a parallel registry.

The expected skill operations are:

• list available skills;
• read an existing skill;
• import markdown into the skill store;
• export a skill to markdown;
• save a skill generated by the assistant.

Repository orientation

The active debug workspace is usually:

• /home/alina/test/MCUB/MCUB-fork

The release/module repository is usually:

• /home/alina/test/MCUB/repo-MCUB-fork

Important local skill locations:

• .opencode/skills/MCUB-modules-creator/SKILL.md
• .opencode/skills/MCUB-release-modules/SKILL.md
• .opencode/skills/MCUB-openagent-workflow/SKILL.md

Important exported skill location:

• openagent_skills

MCUB-specific safety rules

• Do not hardcode secrets, tokens, API keys, session strings, phone numbers, or credentials.
• Do not publish suspicious, obfuscated, destructive, or arbitrary-execution code.
• Do not treat every Telegram interaction as Bot API work; MCUB is primarily a userbot runtime.
• Use auxiliary bot behavior only when the task explicitly requires it.
• Keep generated modules within the MCUB API boundary.
• Do not overwrite debug module history unless the user explicitly asks and the workflow allows it.
• Do not force-add ignored files.

OpenAgent skill file conventions

When creating or updating a skill:

• use .opencode/skills/<skill-name>/SKILL.md as the local source path;
• include YAML frontmatter with name and description;
• keep the description short enough to work well in skill listings;
• use clear markdown sections;
• keep workflow rules actionable and project-specific;
• avoid duplicating entire specialized skills when routing to them is enough.

Validation checklist

Before reporting completion:

• confirm the local skill file exists;
• confirm the frontmatter includes the intended name and description;
• confirm module creation routes to MCUB-modules-creator;
• confirm release work routes to MCUB-release-modules;
• confirm the text explicitly says MCUB modules are not Hikka modules;
• confirm unrelated working-tree changes were not modified.

If an exported markdown copy is created, confirm it mirrors the local skill content and explain that .opencode/skills remains the source of truth.