mas-skills

name	mas-skills
description	Master entrypoint for MAS engineering standards and code conventions. Use when a task needs consistent conventions across code standards, schema naming, module boundaries, function design, API contracts, or data modeling, and route the work to one or more MAS sub-skills.

MAS Skills

Objective

Provide one routing entrypoint for MAS engineering standards and keep implementation decisions consistent with current project maintainer review preferences.

Repository Authority

AUTO-MAS splits responsibilities across repositories:

1. AUTO-MAS-Project/AUTO-MAS keeps application code and a minimal AGENTS.md entrypoint.
2. AUTO-MAS-Project/AUTO-MAS-docs / https://doc.auto-mas.top/developer/ owns branch, contribution, commit, version, Issue, and PR writing rules.
3. AUTO-MAS-Project/skills owns Agent Skill behavior and engineering routing rules.

When these areas overlap, use this skill for engineering decisions and use the docs site for contribution-process decisions.

Project Rule Areas

Apply these project rules directly when they overlap with a task:

1. API work follows the schema-first route flow: define app/models/schema.py, wire the matching app/api/ module, then regenerate frontend API clients.
2. Config work follows ConfigBase and ConfigItem ownership: declare fields before super().__init__(), use validators as auto-correction behavior, and register multi-config classes in the owning collection.
3. Script adaptation must be complete across config, schema, API, task dispatch, task folder, and frontend entry points.
4. Contribution style follows Conventional Commits, Google-style backend docstrings where useful, config-item comments, and keyword arguments for booleans or multi-argument calls.

Sub-Skills

Use these skills as needed:

1. mas-code-standards: project code standards derived from representative dev commits, especially for modules mainly authored by DLmaster_361.
2. mas-schema-naming: canonical naming for shared schema semantics in future domain work.
3. mas-module-boundary: module ownership and dependency direction across backend layers.
4. mas-function-design: function-level design for responsibility, signatures, side effects, and errors.
5. mas-api-contract: endpoint contract standards for HTTP/WS request-response behavior.
6. mas-data-model: modeling standards for schema/config/task layers and compatibility evolution.
7. mas-plugin-module: plugin management/market UI, frontend page extensions, plugin declarations and instances, declarative HTTP/WS, Script Adapter host contracts, and dynamic schema forms.
8. mas-script-specialized-adapter: specialized script integration by script frontend architecture line; requires intake before implementation.
9. mas-plan-schedule: plan schedule type registration, backend/frontend plan dispatch, plan combobox consumers, and per-type table integration.

Global Constraints

Apply these constraints before selecting or combining sub-skills.

1. Make minimal necessary changes first; avoid broad refactors unless explicitly requested.
2. Align with current code style and existing project conventions in the touched module.
3. Avoid over-engineering, over-abstraction, and defensive programming that does not match existing code patterns.
4. Study similar existing implementations deeply before coding and follow established local patterns.
5. Never edit files generated by OpenAPI code generation under any circumstance. If regeneration is needed, explicitly tell the developer to run the generation process manually.
6. When local patterns and generalized guidance differ, prefer concrete maintainer review comments, especially from DLmaster361, and fold them back into the selected sub-skills.

Routing Rules

Choose sub-skills by task intent.

1. Task mentions field names, shared terms, schema key consistency: Use mas-schema-naming.
2. Task mentions project code standards, code conventions, matching representative dev commit style, or asks to follow current AUTO-MAS coding style: Use mas-code-standards.
3. Task mentions layer ownership, imports, coupling, or where code should live: Use mas-module-boundary.
4. Task mentions function splitting, signature quality, return/error behavior: Use mas-function-design.
5. Task mentions endpoint payloads, response model, error contract, websocket payloads: Use mas-api-contract.
6. Task mentions model structure, typing/defaults/constraints, migration of model fields: Use mas-data-model.
7. Task mentions plugin management/market UI, plugin page extensions, plugin declarations, plugin instances, declarative HTTP/WS, or Script Adapter platform integration: Use mas-plugin-module.
8. Task mentions adding a new external script, script-specific adaptation, or task lifecycle: Use mas-script-specialized-adapter first for architecture intake, then use mas-plugin-module for plugin-platform integration and combine mas-module-boundary, mas-data-model, mas-function-design, and mas-api-contract as needed.
9. Task mentions commit messages, docstrings, config comments, or project contribution style: Use mas-code-standards for code-style decisions; use the docs site for contribution-process wording.
10. Task mentions plan schedules, schedule types, PlanConfig, PLAN_BOOK, plan comboboxes, or adding a new plan table: Use mas-plan-schedule.

Combined Execution Order

When multiple concerns appear, apply this order:

1. mas-code-standards
2. mas-module-boundary
3. mas-data-model
4. mas-schema-naming
5. mas-function-design
6. mas-api-contract
7. mas-plugin-module when the task touches the plugin platform or its UI surfaces.
8. mas-script-specialized-adapter after architecture intake, when the task adapts an external script.
9. mas-plan-schedule

Reason: establish local conventions first, place code correctly second, stabilize model structure third, then naming, function behavior, and transport contract. Plugin-platform rules apply before implementation details; specialized adapters retain their mandatory architecture-intake step, and plan schedule rules apply when the task touches scheduler registration.

Output Requirements

When using this hub:

1. State which sub-skills are selected.
2. Explain why each selected sub-skill is needed.
3. Apply only the minimum set required by the task.
4. Keep compatibility-first decisions for legacy modules unless explicitly asked to refactor broadly.
5. In review tasks, call out where findings follow known maintainer preferences rather than only generic engineering taste.
6. For Issue/PR body writing, follow the docs site instead of inventing repository-specific text here.

Review Checklist

1. Selected sub-skills match the user request scope.
2. No layer-boundary violations are introduced.
3. Shared schema semantics remain canonical.
4. Function behavior and API contract stay consistent after changes.
5. Relevant project rules were considered for API, config, script task, and contribution-style changes.
6. Contribution-process details were not duplicated from the docs site except as links or brief reminders.