feat: add dhtmlx-angular-gantt skill

README.md

@@ -27,18 +27,30 @@ Guides AI agents through building and integrating DHTMLX React Gantt in web appl
 - Styling, CSS variables, template-based visual customization
 - Common pitfalls and constraints
 
+### `dhtmlx-angular-gantt`
+
+Guides AI agents through building and integrating DHTMLX Angular Gantt in web applications. Covers:
+
+- Package installation (trial and commercial)
+- CSS setup and layout requirements
+- Angular integration patterns
+- Task and link state, mapping, and persistence
+- Styling, CSS variables, template-based visual customization
+- Common pitfalls and constraints
 
 ## Installation
 
 ```bash
 npx skills add DHTMLX/skills --skill dhtmlx-react-gantt
+npx skills add DHTMLX/skills --skill dhtmlx-angular-gantt
 ```
 
 Or copy manually:
 
 ```bash
 git clone https://github.com/DHTMLX/skills
 cp -r skills/dhtmlx-react-gantt ~/.claude/skills/
+cp -r skills/dhtmlx-angular-gantt ~/.claude/skills/
 ```
 
 ## Requirements

dhtmlx-angular-gantt/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: dhtmlx-angular-gantt
+description: >
+  Builds and integrates DHTMLX Angular Gantt into Angular applications. Covers setup,
+  inputs, templates, themes, data.save, data.batchSave, resources, calendars, undo/redo,
+  row reorder, sortorder, and Angular wrapper integration patterns for
+  @dhtmlx/trial-angular-gantt and @dhx/angular-gantt. Applies when working with gantt charts,
+  project timelines, task dependencies, task CRUD, resource panels, working calendars,
+  lightboxes, or weekend highlighting in Angular. Provides verified API guidance rather
+  than guessing Angular Gantt APIs.
+paths: "**/*.ts,**/*.html,**/*.css,**/*.scss,angular.json,package.json"
+allowed-tools: Read Grep
+metadata:
+  tags: dhtmlx, gantt, angular, dependencies, baselines, milestones, resources
+---
+
+## Source Of Truth
+
+Use only:
+1. The current project's files, structure, and established patterns
+2. DHTMLX MCP for Angular Gantt API details: https://docs.dhtmlx.com/mcp
+3. Official DHTMLX Angular Gantt docs as fallback: https://docs.dhtmlx.com/gantt/integrations/angular/
+
+Never invent inputs, template signatures, callback contracts, event names, or backend behavior.
+
+If any Angular Gantt API detail is unclear, resolve it through DHTMLX MCP before writing code.
+
+## Preflight
+
+Before writing code, identify:
+- **package**: `@dhtmlx/trial-angular-gantt` or `@dhx/angular-gantt` — check `package.json`, imports, lockfiles
+- **runtime**: Angular standalone components or NgModule setup
+- **ownership model**: Angular state/store as source of truth (recommended) or Gantt as source of truth (performance-focused)
+- **persistence**: local only, `data.save` (default), or `data.batchSave` (bulk sync)
+
+## Workflow
+
+1. Confirm installed Angular Gantt package and matching import path.
+2. Confirm wrapper CSS is imported and chart height chain is explicit.
+3. Decide the state ownership model before implementing features, and keep one model per page/feature area.
+4. Read only the reference file needed for the task:
+   - Angular wrapper integration/setup: [references/angular-integration.md](references/angular-integration.md)
+   - CRUD, state, and persistence: [references/data-and-crud.md](references/data-and-crud.md)
+   - Failure cases and guardrails: [references/known-failures.md](references/known-failures.md)
+   - Advanced patterns (reorder, resources, undo/redo, schema): [references/advanced-patterns.md](references/advanced-patterns.md)
+   - Styling, theming, templates, and override strategy: [references/styling-and-theming.md](references/styling-and-theming.md)
+5. Use DHTMLX MCP before relying on advanced or unfamiliar APIs.
+6. Implement with documented APIs only.
+
+## MCP Server
+
+This skill relies on DHTMLX MCP for API verification. If the `dhtmlx-mcp` tool is not available, ask the user to add it:
+
+Claude Code:
+```bash
+claude mcp add --transport http dhtmlx-mcp https://docs.dhtmlx.com/mcp
+```
+
+Codex:
+```bash
+codex mcp add dhtmlx-mcp --url https://docs.dhtmlx.com/mcp
+```
+
+If MCP is not available, use the official docs at https://docs.dhtmlx.com/gantt/integrations/angular/ as fallback.
+
+## Consult MCP First For
+
+Consult DHTMLX MCP before using or changing:
+- template callbacks you have not already verified
+- advanced inputs such as `batchSave`, `customLightbox`, `groupTasks`, `resourceFilter`, or `allowRawHTML`
+- `events` callback signatures beyond commonly used handlers
+- theme/skin names beyond known project usage
+- complex layout/resource panel definitions (`resourceGrid`, `resourceTimeline`, shared scroll)
+- workload cell template callbacks and overload logic
+
+## Hard Rules
+
+- Use wrapper path (`<dhx-gantt>`) by default for Angular tasks.
+- The Gantt container must have explicit height through the parent chain.
+- Use app theme as single source of truth; map it to Gantt theme.
+- Keep tasks/links in Angular state/store when surrounding UI depends on chart state.
+- Normalize date values before persistence.
+- Build backend payloads explicitly from normalized app task/link models.
+- If mutating through `instance`, keep Angular state synchronized immediately.
+- Do not mix wrapper-driven inputs and imperative instance mutations without intentional synchronization.
+
+## Quick Checklist
+
+- [ ] Correct package identified
+- [ ] Matching wrapper CSS import used
+- [ ] Explicit height chain provided
+- [ ] State ownership model chosen
+- [ ] Dates normalized before persistence
+- [ ] Advanced APIs verified with MCP

dhtmlx-angular-gantt/references/advanced-patterns.md

@@ -0,0 +1,119 @@
+# Advanced Patterns
+
+Use this file when implementing row reorder, resource panels, undo/redo, or designing a backend schema for Gantt data.
+
+## Contents
+- Row Reorder With Sortorder Persistence
+- Resource Panel And Workload Visualization
+- Undo/Redo With State Management
+- Backend Schema Template
+
+## Row Reorder With Sortorder Persistence
+
+- enable row ordering in Gantt config
+- treat reorder as a dedicated flow — do not route it through normal single-task update logic
+- detect reorder intent from task update payload (for example `target` when available)
+- when a row moves, rebuild the full ordered task list in memory
+- recompute `sortorder` for all affected tasks, not only the moved task
+- update state/store with the reordered list
+- persist the full reordered set — update `sortorder` for every affected row
+- if hierarchy changes during the move, persist `parent_id` alongside `sortorder`
+- normal task updates must preserve current `sortorder` unless dedicated reorder flow changes it
+- load tasks with `ORDER BY sortorder` from backend
+- keep reorder implementation targeted — do not refactor unrelated CRUD paths
+
+## Resource Panel And Workload Visualization
+
+- Gantt does not enforce one standard task field for resource binding
+- the relation is defined by `config.resource_property`, and built-in resource features watch `task[gantt.config.resource_property]`
+- for a single-resource model, choose any task field that fits the app schema, then set `config.resource_property` to match it
+- for a multi-resource model, the field named by `config.resource_property` can store either an array of resource IDs or an array of assignment objects
+- for advanced flows, resource assignments can also be loaded separately from tasks
+- build the resource list dynamically from real project data, not from a hardcoded array
+- include an explicit `Unassigned` option only when the product actually needs one
+- if using a single-resource model, resource grid display, timeline display, and lightbox editing should all read and write the same task field
+- if using multi-resource assignments, keep the UI and persistence model aligned to the same assignment structure
+- if using separate assignments, build task/resource views and save flows from the assignments dataset rather than inventing a display-only task field
+- display workload in the resource grid as formatted values such as `"8h"`, `"16h"`, `"24h"` when the product uses hours
+- wire lightbox resource selection so it maps back to the same field or assignment structure used by persistence
+- layout must include both main Gantt rows (grid + timeline) and resource panel rows (resourceGrid + resourceTimeline or resourceHistogram) with shared horizontal scrolling when the product needs a combined view
+- verify `resource_cell_value`, `resource_cell_class`, histogram templates, and resource timeline callback signatures with MCP before implementing
+
+### Supported Resource Binding Models
+
+Single-resource field on task:
+```ts
+config.resource_property = "user_id";
+// task.user_id <-> resource.id
+```
+
+Multiple resource IDs on task:
+```ts
+config.resource_property = "users";
+// task.users = [2, 3]
+```
+
+Assignment objects on task:
+```ts
+config.resource_property = "users";
+// task.users = [{ resource_id: 2, value: 8 }, { resource_id: 3, value: 4 }]
+```
+
+Separate assignments list:
+```ts
+{
+  tasks: [...],
+  links: [...],
+  resources: [...],
+  assignments: [{ id: 1, task_id: 5, resource_id: 2, value: 8 }]
+}
+```
+
+## Undo/Redo With State Management
+
+- use fresh state/store snapshots inside `data.save` callbacks — do not rely on stale captured values
+- if using RxJS store, NgRx, or another external store for Gantt history, normalize all date values before writing to the store (state must be serializable)
+- undo and redo actions must also update persistence — client-only history creates data gaps on reload
+- persist history snapshots when rehydration across sessions is required
+- save or refetch operations must not wipe the undo/redo history stack
+- keep history refs/snapshots and store state in sync after every mutation
+
+## Backend Schema Template
+
+Recommended practical schema for a writable Gantt-backed app with tasks, links, and optional resources. This is not a DHTMLX-mandated contract. Adjust the field names and tables to fit the app and backend.
+
+Tasks table:
+- `id` - UUID, primary key
+- `project_id` - strongly recommended foreign key to a `projects` table for multi-project apps
+- `text` - task name
+- `start_date` - timestamp (nullable for projects that derive dates from children)
+- `duration` - integer in the configured project duration unit (nullable, >= 0 when set)
+- `progress` - numeric, constrained between 0 and 1
+- `parent_id` - self-referencing foreign key to tasks (must not equal `id`), cascade on delete
+- `sortorder` - strongly recommended integer field for persistent row ordering
+- `type` - one of `task`, `project`, `milestone`
+- resource relation:
+  - either a task field named to match `config.resource_property`
+  - or no task field at all when the app uses separate resource assignments
+
+Duration storage guardrail:
+- treat `duration_unit` as a project-level storage decision, not just a display preference
+- choose the smallest unit the product must support at project start, because changing from `day` to `hour` or `minute` later usually requires conversion of persisted task durations
+- stored durations are integers, so `duration_unit=\"day\"` supports whole-day tasks only and cannot represent a plain 4-hour task as `duration: 4`
+- use `duration_unit=\"hour\"` when tasks like 4 hours must be stored directly, and `duration_unit=\"minute\"` when the product needs minute-level precision
+
+Links table:
+- `id` - UUID, primary key
+- `project_id` - strongly recommended foreign key to a `projects` table for multi-project apps
+- `source` - foreign key to task, cascade on delete
+- `target` - foreign key to task, cascade on delete (must not equal `source`)
+- `type` - one of `0`, `1`, `2`, `3`
+
+Recommended constraints:
+- unique constraint on `(project_id, source, target, type)` for links
+- cascade on delete for project foreign keys in both tables
+
+Recommended indexes:
+- `project_id` on both tables
+- `parent_id` on tasks
+- `source` and `target` on links