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 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 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 objects, ready to pass to suggestAssignments:

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.

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. 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:

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:

{ 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.

{ 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.

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:

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 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:

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 run find their way back. It binds even when the resource no longer matches. The slot is then broken.
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.
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:

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:

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, commit the proposal with apply, 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:

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:

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) 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.
To keep a person on a slot whatever the load, add the slot's assignment id to the fixed option of suggestAssignments.

Errors#

slots throws the same error classes as the other Project methods. See error types:

ProjectError with code: "no-baseline": the project is unsolved, or it has unsolved edits after apply. 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.

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:

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 throw the same classes, one catch covers a whole staffing run:

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:

project error: no-baseline

See Error handling for the error model of the whole library.