mas-skills

name	mas-skills
description	Use when a task needs AUTO-MAS engineering conventions across frontend, UI, code style, schema naming, module boundaries, function design, API contracts, data modeling, script adapters (MAA, SRC, MaaEnd, M9A, General, ok-script family such as Okww and OkNte, multi-engine HSR), plan schedules, or game community sign-in.

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. Local .agents/skills owns the project-affiliated Agent Skill behavior and engineering routing rules for this checkout.

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. Frontend work follows the dedicated frontend skills in this directory.
5. 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-frontend-standards: Vue 3, TypeScript, Vite, Electron renderer, routing, API composables, state, styles, forms, validation, and frontend verification.
2. mas-frontend-ui: Ant Design Vue UI, desktop business layout, visual tokens, forms, tables, dialogs, feedback, drag interactions, dark mode, and UX constraints.
3. mas-code-standards: project code standards derived from representative dev commits and existing AUTO-MAS modules.
4. mas-schema-naming: canonical naming for shared schema semantics in future domain work.
5. mas-module-boundary: module ownership and dependency direction across backend layers.
6. mas-function-design: function-level design for responsibility, signatures, side effects, and errors.
7. mas-api-contract: endpoint contract standards for HTTP/WS request-response behavior.
8. mas-data-model: modeling standards for schema/config/task layers and compatibility evolution.
9. mas-script-specialized-adapter: specialized script integration by script frontend architecture line; requires intake before implementation.
10. mas-plan-schedule: plan schedule type registration, backend/frontend plan dispatch, plan combobox consumers, and per-type table integration.
11. mas-game-sign: game community sign-in providers, credential encryption and login routes, sign-in locks and trigger paths, and result/notification contracts.

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. For frontend work, load mas-frontend-standards; for UI or user-facing component behavior, also load mas-frontend-ui.
7. When local patterns and generalized guidance differ, prefer concrete maintainer review comments and fold them back into the selected sub-skills.
8. Before completing a user-visible feature or fix, update res/version.json under the next unreleased version as part of the implementation; do not merely remind the developer. Do not create a commit unless the user explicitly asks for one.

Routing Rules

Choose sub-skills by task intent.

1. Task mentions field names, shared terms, schema key consistency: Use mas-schema-naming.
2. Task touches frontend, src/views, src/components, src/composables, src/router, src/types, src/utils, Vue, TypeScript, Vite, Electron renderer, API composables, forms, validation, or frontend verification: Use mas-frontend-standards.
3. Task touches UI, layout, style, Ant Design Vue, components, forms, tables, modals, drawers, feedback, loading, empty, error states, drag interactions, dark mode, or visual polish: Use mas-frontend-ui with mas-frontend-standards.
4. Task implements, fixes, refactors, or reviews repository code: Use mas-code-standards as the baseline, then add the minimum domain-specific mas-* skills. Skip it for read-only work unless code conventions or commit wording are requested.
5. Task mentions layer ownership, imports, coupling, or where code should live: Use mas-module-boundary.
6. Task mentions function splitting, signature quality, return/error behavior: Use mas-function-design.
7. Task mentions endpoint payloads, response model, error contract, websocket payloads: Use mas-api-contract.
8. Task mentions model structure, typing/defaults/constraints, migration of model fields: Use mas-data-model.
9. Task mentions adding a new script, script-specific adaptation, task lifecycle, or a specific adapter such as MAA / SRC / MaaEnd / M9A / General / Okww / OkNte（异环）/ HSR: Use mas-script-specialized-adapter first, then combine mas-module-boundary, mas-data-model, mas-function-design, and mas-api-contract as needed.
10. 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.
11. Task mentions plan schedules, schedule types, PlanConfig, PLAN_BOOK, plan comboboxes, or adding a new plan table: Use mas-plan-schedule.
12. Task mentions game community sign-in, app/tools/game_sign*, a sign-in platform such as Skland/Miyoushe/Kuro/Taygedo, sign-in credentials or QR login, or sign-in result and notification behavior: Use .

Combined Execution Order

When multiple concerns appear, apply this order:

1. mas-frontend-standards, when the task touches frontend code or docs.
2. mas-frontend-ui, when the task touches UI or user-facing component behavior.
3. mas-code-standards
4. mas-module-boundary
5. mas-data-model
6. mas-schema-naming
7. mas-function-design
8. mas-api-contract
9. mas-script-specialized-adapter after architecture intake, when the task is a specialized adapter.
10. mas-plan-schedule
11. mas-game-sign

Reason: frontend tasks need their engineering and UI constraints loaded before implementation decisions; then establish local conventions, place code correctly, stabilize model structure, then naming, function behavior, and transport contract. Specialized adapters add a mandatory architecture-intake step, plan schedule rules apply when the task touches scheduler registration, and game sign rules apply last because they constrain credential handling and external request behavior inside an already-placed module.

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.
7. For frontend tasks, state whether mas-frontend-standards and mas-frontend-ui were selected and why.

Review Checklist

1. Selected sub-skills match the user request scope.
2. Frontend tasks loaded the correct frontend skill pair.
3. No layer-boundary violations are introduced.
4. Shared schema semantics remain canonical.
5. Function behavior and API contract stay consistent after changes.
6. Relevant project rules were considered for API, config, script task, frontend task, and contribution-style changes.
7. Contribution-process details were not duplicated from the docs site except as links or brief reminders.
8. Every user-visible feature or fix includes the matching res/version.json entry under the next unreleased version.