Add a rule to a project: when an issue enters 'status', append 'template' to its description. A rule appends its checklist to an issue's description when the issue ENTERS the rule's state — from the board, the Jira API or update_issue alike. The block starts with a hidden marker line '[//]: # (pm-rule:)'; while that line is in the description, entering the state again adds nothing (the journal says 'alreadyThere'). A [~username] in the template is a mention: that person is notified when the checklist lands. A checklist that would make the description too long is not added and the journal says 'tooLong'; the move itself still happens. 'trigger' says WHEN: 'entered' (the default — the issue entered 'status'), 'versionReleased' (a version it goes out in was marked released), 'subtasksDone' (every issue under it is finished — the rule acts on the PARENT) or 'subtaskStarted' (an issue under it was taken into work — the parent again); or what the project's repository said through its webhook: 'branchCreated' (a branch naming the issue was made), 'mrOpened', 'mrMerged' or 'mrClosed' (a merge request — a pull request on GitHub — naming the issue was opened, merged, or closed without merging). An issue is named by its key in the branch, the title or the description, and only this project's issues are touched. 'branch' narrows the three merge-request events to a request going INTO that branch, e.g. 'main'. Nobody is behind a webhook, so such a rule acts as whoever last saved or switched it on, whatever its action. 'deployed' fires when a pipeline reports that the issue went out to an environment (report_deployment); 'environment' narrows it to one of the project's environments by name, e.g. 'staging'. Only 'entered' has a 'status'; pass an empty one for the others. 'fromStatus' narrows any of them to an issue coming from that state: the state it has just left for 'entered', the state it stands in for the rest. A rule with action 'move' MOVES the issue to 'moveToStatus' instead of appending anything, and has no template (pass an empty one). The move is an ordinary one — made as whoever last saved or switched on the rule, asked of the project's workflow, written to the history with the rule's name, and followed by the rules of the state it lands in. A workflow that refuses it leaves a 'moveRefused' line with the reason in the journal and nothing else; 'moved' is a move made; 'tooDeep' is a move not made because rules had already moved issues three times off one event. A rule with action 'agent' is a DUTY instead: it says which issues may be handed to an agent role (agentRole, e.g. 'product') and what the agent may do with them. Its 'template' is then the INSTRUCTION — what doing such an issue means in this project — and nothing is appended anywhere. A duty may have no state (pass an empty 'status'): then an issue is handed only by a person. agentActions is a list from: describe, subtasks, ask, wiki, report, support. agentFields names the fields it may set: priority, labels, duedate, or the project's own fields by name. doneStatus is the state it moves the issue to when done — never a finished one. capUsd raises what one task may cost, up to 5 dollars. Commenting is always allowed; finishing, deleting, reassigning and anything outside the issue never are. Saving or switching on a duty makes it yours: it runs on your behalf and access, and is switched off if you lose the project. The state and the type are NAMES of this project's own (list_project_rules lists them); an unknown one is refused with the list. Project lead or admin only.