$mol Skill Workflow

1) Clarify the goal

• Ask for the exact feature, target module path, and whether Giper Baza or Tauri is involved.
• If the request is vague (“сделать что угодно”), propose 2-3 concrete options and ask to choose.

2) Pick the right reference

• Use references/MOL_QUICK_START.md for core $mol/MAM structure, view.tree syntax, components, best practices, and debugging.
• Use references/MOL_GIPER_BAZA_GUIDE.md for data modeling, auth/roles, CRUD, sync, and backend-style patterns.
• Use references/GIPER_BAZA_ADMIN_GUIDE.md for admin panels, roles, UI patterns, and admin CRUD flows.
• Use references/TAURI_SETUP.md for desktop setup, build, and CI.

3) Implement in a MAM module

• Follow the module structure and naming rules from MOL_QUICK_START.md.
• Create or update:
  • index.html in the module root
  • *.view.tree for layout
  • *.view.ts for logic (use @$mol_mem, @$mol_action)
  • *.view.css.ts for styles
  • *.meta.tree for meta config when needed
• Use view.tree bindings correctly:
  • <= for one-way, <=> for two-way
  • * for list/collection properties
  • null to remove nodes conditionally

4) Data with Giper Baza (if needed)

• Model data with class ... extends $giper_baza_entity.with({ ... }).
• Keep CRUD in @$mol_mem / @$mol_action methods.
• Use presets/roles if data must be shared across lands or users.
• Follow auth/roles guidance from the Giper Baza references.

5) Validate & debug

• Don’t run the build unless you’re asked to.
• Always check yourproject/-/web.audit.js after build; fix all warnings/errors.
• Add tests in *.test.ts when logic is non-trivial.

6) Tauri (if requested)

• Follow references/TAURI_SETUP.md for setup, dev, and build steps.
• Ensure frontendDist points to the built -/ folder.

Output expectations

• Provide minimal, runnable edits in the target module.
• If the user asks for examples, include a small view.tree + view.ts pair.
• Prefer concrete file paths and exact command lines.