[Canonical page](<https://docs.dhtmlx.com/planning-engine/js/resources-and-assignment/skills-and-requirements/>)
[Full documentation index](<https://docs.dhtmlx.com/planning-engine/llms.txt>)


# Skills and Requirements

This guide shows how to staff tasks by skill. You describe who can do what, state what each task needs, and get slots that [`Project#suggestAssignments`](<https://docs.dhtmlx.com/planning-engine/js/api/project-suggest-assignments.md>) fills. It also covers how earlier assignments stay attached to their requirements from one run to the next.

## How the skill layer works

The scheduling engine doesn't know about skills. Auto-assignment works on **slots**. A slot is one place for one person on one task, with a list of resources allowed to take it. [`Project#slots`](<https://docs.dhtmlx.com/planning-engine/js/api/project-slots.md>) builds those slots from data you already have: workers and their skills.

`slots(pool, requirements)` reads the accepted state of a solved project: its scheduled leaf tasks, resources and active assignments. On top of that it takes two inputs:

- A **pool**: `{ workers }`. Each worker is a `resource` id plus a list of `skills` (`{ id, value }`). A skill `value` is `0`/`1` for yes-or-no skills, or an integer grade (1 = junior, 2 = senior, and so on). It defaults to `1`. Pool order is the tie-break preference.
- A list of **requirements**. A requirement says "task `task` needs `count` people who satisfy all of these `matches`, each booked at `units`".

`slots` returns an array of [`Slot`](<https://docs.dhtmlx.com/planning-engine/js/api/types/slot.md>) objects, ready to pass to [`suggestAssignments`](<https://docs.dhtmlx.com/planning-engine/js/api/project-suggest-assignments.md>):

- Each requirement becomes `count` slots with ids `"<requirement id>#1"`, `"#2"` and so on, in requirement order.
- `allowed` lists the pool workers that pass every match of the requirement, in pool order.
- `value` is the requirement's `units`: the rate a new assignment books.
- `assignment` names the existing assignment that already fills the slot. It's absent when the slot is empty. See [Binding existing assignments](<https://docs.dhtmlx.com/planning-engine/js/resources-and-assignment/skills-and-requirements.md#binding-existing-assignments>).

A slot's id is also the id of the assignment that fills it. After you commit a proposal, the task carries assignments named `be#1`, `be#2`, and the next `slots` call finds them by id. That's what keeps staffing stable across runs. It also means a requirement id belongs to its task. Reuse `be` on another task after a commit, and `slots` refuses it.

Skills, pools and requirements aren't stored in [`ProjectData`](<https://docs.dhtmlx.com/planning-engine/js/api/types/project-data.md>). You pass them on every call, so they can come from wherever your app keeps them. `slots` never changes the project.

## Pools and skills

Build a pool, describe what each task needs, and turn both into slots:

```js
import { Project } from "plen-js";

const project = new Project();
// Two 2-day tasks starting Monday 2026-08-10.
project.solve({
  tasks: [
    { id: "api", start_date: "2026-08-10 08:00", duration: 2 },
    { id: "ui", start_date: "2026-08-10 08:00", duration: 2 },
  ],
  resources: [{ id: "ann" }, { id: "bob" }, { id: "cat" }],
});

// The pool: who can do what. Order is the tie-break preference.
const pool = {
  workers: [
    { resource: "ann", skills: [{ id: "backend" }, { id: "frontend" }] },
    { resource: "bob", skills: [{ id: "backend" }] },
    { resource: "cat", skills: [{ id: "frontend" }] },
  ],
};
// What each task needs.
const requirements = [
  { id: "be", task: "api", matches: [{ skill: "backend" }] },
  { id: "fe", task: "ui", matches: [{ skill: "frontend" }] },
];

for (const slot of project.slots(pool, requirements)) {
  console.log(slot);
}
```

Output:

```text
{ allowed: [ 'ann', 'bob' ], id: 'be#1', task: 'api', value: 1 }
{ allowed: [ 'ann', 'cat' ], id: 'fe#1', task: 'ui', value: 1 }
```

Ann has both skills, so she's eligible for both slots. Nothing is assigned yet. `slots` only says who *may* take each place. Choosing who *does* is the job of [`suggestAssignments`](<https://docs.dhtmlx.com/planning-engine/js/api/project-suggest-assignments.md>).

`{ id: "backend" }` without a `value` means grade `1`, and `{ skill: "backend" }` means "has the skill" (`at_least` 1). A worker's `resource` must name a resource in the project, and each worker appears once. A worker can be in the pool without being eligible for anything, and a project resource can stay out of the pool. A resource outside the pool is never offered for a slot.

## Requirements and matches

A requirement with only `id`, `task` and `matches` creates one slot at full rate (`count: 1`, `units: 1`, no explicit binding). Set `count` to ask for more people, and `units` for a lower rate. A match `{ skill, op, value }` compares a worker's skill value with `value` (default `1`):

| `op` | Holds when |
|---|---|
| `"at_least"` (default) | worker value `>= value` |
| `"no_more"` | worker value `<= value` |
| `"equal"` | worker value `== value` |

All three are inclusive. A skill the worker doesn't list counts as `0`, so `{ skill: "qa", op: "no_more", value: 0 }` means "not a tester". A requirement with several matches needs all of them. A requirement with an empty `matches` array allows every worker in the pool.

```js
import { Project } from "plen-js";

const project = new Project();
project.solve({
  tasks: [{ id: "release", start_date: "2026-08-10 08:00", duration: 3 }],
  resources: [{ id: "ann" }, { id: "bob" }, { id: "cat" }, { id: "dan" }],
});

// Grades: QA level 1 = junior, 2 = senior.
const pool = {
  workers: [
    { resource: "ann", skills: [{ id: "backend" }, { id: "qa", value: 1 }] },
    { resource: "bob", skills: [{ id: "backend" }, { id: "devops" }] },
    { resource: "cat", skills: [{ id: "qa", value: 2 }] },
    { resource: "dan", skills: [{ id: "qa", value: 1 }] },
  ],
};

const requirements = [
  // Two half-time backend developers.
  { id: "be", task: "release", matches: [{ skill: "backend" }], count: 2, units: 0.5 },
  // A senior tester.
  { id: "qa", task: "release", matches: [{ skill: "qa", value: 2 }] },
  // A junior tester: exactly grade 1.
  { id: "qa-jr", task: "release", matches: [{ skill: "qa", op: "equal", value: 1 }] },
  // A backend developer who also does devops: every match must hold.
  { id: "ops", task: "release", matches: [{ skill: "backend" }, { skill: "devops" }] },
  // Anyone who is not a QA: a missing skill counts as 0.
  { id: "review", task: "release", matches: [{ skill: "qa", op: "no_more", value: 0 }] },
];

for (const slot of project.slots(pool, requirements)) {
  console.log(`${slot.id}: value ${slot.value}, allowed ${JSON.stringify(slot.allowed)}`);
}
```

Output:

```text
be#1: value 0.5, allowed ["ann","bob"]
be#2: value 0.5, allowed ["ann","bob"]
qa#1: value 1, allowed ["cat"]
qa-jr#1: value 1, allowed ["ann","dan"]
ops#1: value 1, allowed ["bob"]
review#1: value 1, allowed ["bob"]
```

`count: 2` gives two slots, `be#1` and `be#2`, each booking half-time. Grades turn "senior tester" and "junior tester" into `at_least` and `equal` matches on the same skill. `review` excludes Ann, Cat and Dan, because each of them has a QA grade above `0`.

A slot list can allow the same person on several slots of one task. [`suggestAssignments`](<https://docs.dhtmlx.com/planning-engine/js/api/project-suggest-assignments.md>) never puts one resource on a task twice, so Ann can't end up in both `be#1` and `be#2`.

## Binding existing assignments

When the task already has active assignments, `slots` attaches them to slots, so a filled place isn't offered again. Binding runs per task, over all requirements on that task, in three steps:

1. **Slot id.** An assignment whose id is one of the requirement's slot ids (`be#2`) binds to that slot. This is how assignments created by an earlier [`suggestAssignments`](<https://docs.dhtmlx.com/planning-engine/js/api/project-suggest-assignments.md>) run find their way back. It binds even when the resource no longer matches. The slot is then *broken*.
2. **Explicit list.** `assignments: [...]` on a requirement replaces automatic binding for it. Listed entries take the remaining slots in order, and leftover slots stay empty. `assignments: []` leaves every slot empty. A missing `assignments` or `null` keeps automatic binding.
3. **Matching.** The task's remaining assignments go to the empty slots of requirements without a list. An assignment can go to a slot only when its resource is in the slot's `allowed`. The engine runs a maximum bipartite matching in input order. It fills as many slots as possible instead of giving each slot the first fit.

Here Ann (backend and frontend) and Bob (backend only) already work on `api`, under ids the skill layer didn't create:

```js
import { Project } from "plen-js";

const project = new Project();
// Ann and Bob already work on `api`, under ids the skill layer didn't create.
project.solve({
  tasks: [{ id: "api", start_date: "2026-08-10 08:00", duration: 2 }],
  resources: [{ id: "ann" }, { id: "bob" }],
  assignments: [
    { id: "a1", task: "api", resource: "ann", value: 1 },
    { id: "a2", task: "api", resource: "bob", value: 1 },
  ],
});

const pool = {
  workers: [
    { resource: "ann", skills: [{ id: "backend" }, { id: "frontend" }] },
    { resource: "bob", skills: [{ id: "backend" }] },
  ],
};
const backend = { id: "be", task: "api", matches: [{ skill: "backend" }] };
const frontend = { id: "fe", task: "api", matches: [{ skill: "frontend" }] };

const show = (label, slots) =>
  console.log(
    `${label}:`,
    slots.map((s) => (s.assignment ? `${s.id} <- ${s.assignment}` : `${s.id} empty`)),
  );

// Automatic: a maximum matching, so Bob takes backend and Ann frontend.
show("matching", project.slots(pool, [backend, frontend]));

// Explicit list: `be` takes a1, whatever the matching would do.
show("explicit", project.slots(pool, [{ ...backend, count: 2, assignments: ["a1"] }, frontend]));

// Empty list: every slot of `be` starts empty.
show("empty list", project.slots(pool, [{ ...backend, assignments: [] }, frontend]));
```

Output:

```text
matching: [ 'be#1 <- a2', 'fe#1 <- a1' ]
explicit: [ 'be#1 <- a1', 'be#2 empty', 'fe#1 empty' ]
empty list: [ 'be#1 empty', 'fe#1 <- a1' ]
```

A greedy pass would give `be` to Ann, the first backend assignment, and leave `fe` empty. The matching gives backend to Bob so Ann can cover frontend. The explicit list pins `a1` to `be#1`. Bob's `a2` can't fill `fe#1`, so that slot stays empty. With an empty list, `be` starts empty and Ann's assignment goes to `fe`.

An assignment that ends up in no slot stays on the task. It still blocks its resource for the task's other slots, and `suggestAssignments` never repairs or moves it.

`slots` checks explicit lists up front:

- At most `count` entries, each an active assignment on the requirement's task, and each bound once.
- If an assignment carries one of the requirement's slot ids, the list must name it. It keeps its own slot.

## From slots to suggestions

Pass the slots straight to [`Project#suggestAssignments`](<https://docs.dhtmlx.com/planning-engine/js/api/project-suggest-assignments.md>), commit the proposal with [`apply`](<https://docs.dhtmlx.com/planning-engine/js/api/project-apply.md>), and reschedule. The next run with the same requirements binds the committed assignments by slot id, so the proposal stays stable. When a worker's skills change, the bound slot becomes broken, and the `"broken"` target repairs it:

```js
import { Project } from "plen-js";

const project = new Project();
// `api` and `ui` both run Monday-Tuesday. Bob already works on `api`.
project.solve({
  tasks: [
    { id: "api", start_date: "2026-08-10 08:00", duration: 2 },
    { id: "ui", start_date: "2026-08-10 08:00", duration: 2 },
  ],
  resources: [{ id: "ann" }, { id: "bob" }],
  assignments: [{ id: "a2", task: "api", resource: "bob", value: 1 }],
});

let pool = {
  workers: [
    { resource: "bob", skills: [{ id: "backend" }] },
    { resource: "ann", skills: [{ id: "backend" }] },
  ],
};
const requirements = [
  { id: "be-api", task: "api", matches: [{ skill: "backend" }] },
  { id: "be-ui", task: "ui", matches: [{ skill: "backend" }] },
];

// Run 1: fill the empty slot.
let proposal = project.suggestAssignments(project.slots(pool, requirements));
for (const step of proposal.steps) {
  console.log(`pass ${step.pass}: ${step.slot} -> ${step.toResource}`);
}

// Commit the proposal and reschedule.
const report = project.apply(proposal.changes);
if (report.rejected.length > 0) {
  throw new Error(`${report.rejected[0].path}: ${report.rejected[0].message}`);
}
project.solve(null);

// Run 2: the same requirements bind to what run 1 committed.
let slots = project.slots(pool, requirements);
for (const slot of slots) {
  console.log(`${slot.id} <- ${slot.assignment}`);
}
const all = { targets: ["empty", "broken", "valid"] };
proposal = project.suggestAssignments(slots, all);
console.log(`run 2: ${proposal.steps.length} steps`);

// Run 3: Ann moved to frontend, so her slot is now broken.
pool = {
  workers: [
    { resource: "bob", skills: [{ id: "backend" }] },
    { resource: "ann", skills: [{ id: "frontend" }] },
  ],
};
slots = project.slots(pool, requirements);
console.log("invalid:", project.suggestAssignments(slots, { targets: [] }).invalid);
proposal = project.suggestAssignments(slots, all);
for (const step of proposal.steps) {
  console.log(`pass ${step.pass}: ${step.slot} ${step.fromResource} -> ${step.toResource}`);
}
```

Output:

```text
pass 0: be-ui#1 -> ann
be-api#1 <- a2
be-ui#1 <- be-ui#1
run 2: 0 steps
invalid: [ 'be-ui#1' ]
pass 0: be-ui#1 ann -> bob
```

Run 1 fills `be-ui#1` with Ann. Bob comes first in the pool, but he's already busy on `api`. The committed assignment gets the slot's id. In run 2 it binds back to its slot, and with every target on there's nothing to improve. In run 3 Ann no longer has the backend skill. `targets: []` only reports the broken slot in `invalid`. The full run repairs it by moving the assignment to Bob.

Some things to keep in mind:

- `slots` needs a solved, clean project. After `apply`, call [`solve(null)`](<https://docs.dhtmlx.com/planning-engine/js/api/project-solve.md>) before you build slots again.
- `suggestAssignments` checks the slots again. Unknown tasks or resources, duplicate slot ids, and a slot id that is already an assignment on another task are errors. Slots from `slots` pass these checks, unless the project changed in between.
- Targets, `fixed` assignments, `newResourcePenalty`, leveled scoring and the step log are covered in [Suggesting assignments](<https://docs.dhtmlx.com/planning-engine/js/resources-and-assignment/suggesting-assignments.md>).
- To keep a person on a slot whatever the load, add the slot's assignment id to the `fixed` option of [`suggestAssignments`](<https://docs.dhtmlx.com/planning-engine/js/api/project-suggest-assignments.md>).

## Errors

`slots` throws the same error classes as the other `Project` methods. See [error types](<https://docs.dhtmlx.com/planning-engine/js/api/types/errors.md>):

- `ProjectError` with `code: "no-baseline"`: the project is unsolved, or it has unsolved edits after [`apply`](<https://docs.dhtmlx.com/planning-engine/js/api/project-apply.md>). `slots` takes no baseline token, so there's no `stale-baseline` case.
- `InputError` with `kind: "validation"` and a `path`: bad pool or requirement values.
- `InputError` with `kind: "parse"`: the input has the wrong shape, such as a missing `matches` or an unknown field.

```js
import { InputError, Project, ProjectError } from "plen-js";

const pool = { workers: [{ resource: "ann", skills: [{ id: "backend" }] }] };
const requirement = { id: "be", task: "api", matches: [{ skill: "backend" }] };

function trySlots(project, requirements) {
  try {
    project.slots(pool, requirements);
  } catch (error) {
    if (error instanceof ProjectError) {
      console.log(`project error: ${error.code}`);
    } else if (error instanceof InputError) {
      console.log(`${error.kind} error at ${error.path}: ${error.message}`);
    } else {
      throw error;
    }
  }
}

const project = new Project();
// Not solved yet: no accepted state to read.
trySlots(project, [requirement]);

project.solve({
  tasks: [{ id: "api", start_date: "2026-08-10 08:00", duration: 2 }],
  resources: [{ id: "ann" }],
});
// `count: 0` is invalid input with a path.
trySlots(project, [{ ...requirement, count: 0 }]);
```

Output:

```text
project error: no-baseline
validation error at requirements[0].count: must be at least 1
```

The `path` points at the offending item:

| Path | Reason |
|---|---|
| `pool.workers[i].resource` | Unknown resource, or a worker listed twice |
| `pool.workers[i].skills[j].id` | A skill listed twice for one worker |
| `requirements[i].id` | Duplicate requirement id, or one of its slot ids is an assignment on another task |
| `requirements[i].task` | Unknown or unscheduled task |
| `requirements[i].count` | `0` |
| `requirements[i].units` | `0` or less |
| `requirements[i].assignments` | More entries than `count`, or an assignment with this requirement's slot id is left out |
| `requirements[i].assignments[k]` | Unknown or inactive assignment, on another task, or bound twice (the message names the other requirement when there is one) |

`NaN` and `Infinity` in a skill `value`, a match `value` or `units` are rejected before these checks, with the message `"Numbers must be finite"`.

`slots` throws on the first problem it finds and builds nothing. It never changes the project, so you can fix the input and call again.

Because `slots` and [`suggestAssignments`](<https://docs.dhtmlx.com/planning-engine/js/api/project-suggest-assignments.md>) throw the same classes, one `catch` covers a whole staffing run:

```js
import { InputError, Project, ProjectError } from "plen-js";

// Both calls throw the same error classes, so one catch covers them.
function staff(project, pool, requirements) {
  const slots = project.slots(pool, requirements);
  return project.suggestAssignments(slots);
}

try {
  const result = staff(new Project(), { workers: [] }, []);
  console.log(`${result.steps.length} steps`);
} catch (error) {
  if (error instanceof ProjectError) {
    console.log(`project error: ${error.code}`);
  } else if (error instanceof InputError) {
    console.log(`input error at ${error.path}: ${error.message}`);
  } else {
    throw error;
  }
}
```

Output:

```text
project error: no-baseline
```

See [Error handling](<https://docs.dhtmlx.com/planning-engine/js/error-handling.md>) for the error model of the whole library.