Template issue to describe a rule

When creating a rule we need to describe precisely the details of the rule to avoid confusion during the implementation.
I suggestion we should follow this template, but feel free to suggest some idea on how to make it better

The rule **{name_of_the_rule}** is triggered by the event: **{github_event}**.
If **{condition_1}** [AND | OR] **{condition_2}** [AND | OR] ... based on the data extracted from the
[ISSUE | PR]
Then apply on the [ISSUE | PR] the following actions:
- **{action_1}**
- **{action_2}**
...

Notes:
- {name_of_the_rule} is just a string representing the rule, it can be whatever we want
- A {github_event} can be (I didn't write the events for PR but they are very similar
- issue created
- One label added to an issue
- One label removed from an issue
- user assigned to an issue
- user unassigned to an issue
- comment added to an issue
- issue closed
- Only one {github_event} can trigger a rule, ie we can't combine multiple event to trigger the rule. So we can't have for example ```issue created AND/OR label in-progress added```
- The {condition} are some properties that we check on the issue or PR. For example, we can check that the list of labesl is not empty on the issue, that there is a user assigned to an issue, that the description of the issue contain some specific keyword...
- We can combine the {conditions} with a AND or a OR operator
- The {action} are applied to the issue or PR. We need to describe them with precise details, for example:
- add a comment to the issue with the following text: "..."
- add the label "in-progress" to the issue
- add the user "..." to the issue
...

An simple but complete example:
The rule **in_progress_no_assigne** is triggered by the event: **the "in-progress" label is added to the issue"**
If **the list of assignee is empty**
Then
- add a comment to the issue with: "warning: The issue is in progress but doesn't have any assignee..."

The issue names no repository file, test, or entry point. Start by locating the project's rule-description documentation or issue template, then compare it with the proposed structure and examples. Done means the agreed template and event, condition, and action guidance are recorded in the appropriate project documentation.

Written by the indexing model from the issue text.