Task Usage Guideline

Department

HR

Summary

How to write a task everyone can act on. A task must have an actionable title that makes “done” obvious, a dependency chain that reaches its project, and no personal data in the text. These three rules apply to every task at Kiluth, in every department. If a task you are assigned does not meet them, do not start work on it — ask for it to be fixed first.

Table of Contents

Purpose

A badly written task wastes the time of everyone downstream of it. The assignee has to ask what is wanted, the reviewer cannot tell when it is finished, and the work is invisible to anyone tracking the project. This guideline sets the standard a task must meet before it is handed to someone.

Prerequisites

Before proceeding with this document, please review the following documents:

Scope

This guideline covers:

This guideline applies to everyone at Kiluth, in every department. It does not cover how the checker is built — see Kiluth Tasks Usage.

Definitions

Rule 1: Actionable Title with a Definition of Done

A title must describe a task, not a topic. Someone reading it should know what to do and what finished looks like.

Ask yourself: could the assignee reply “okay, so what do you want me to do?” If yes, the title is a noun, not a task.

If “done” cannot fit in the title, put the Definition of Done in the description or a checklist. Either location is fine. Having it nowhere is not.

Rule 2: The Dependency Chain Reaches a Project

Client work must be traceable to the project it belongs to. From any task, keep following Blocks — “what does this task block?” — and you must eventually arrive at that project.

Example:

Develop the website → Blocks → Test the website → Blocks → Deploy the website → Blocks → [[PROJ-0015]]

If the chain stops before reaching a project, the task is not set up correctly. Order and handoffs are then invisible, and nobody can see how the work rolls up.

Why the chain, when the task already names its project

A task’s project: field says what it belongs to. The chain says what must happen before it. These are different facts and you need both. Belonging alone tells you a task is part of Bonsoir; it does not tell you the developer cannot start until the designer finishes.

The two exceptions

A task may sit without a chain to a project only in these cases:

An unchained task is not the default. If you are reaching for an exception, check first whether the task really does belong to a project.

Project nodes themselves sit at the end of the chain, so this rule does not apply to them.

Rule 3: No Personal Data in the Task

Do not type a person’s full name, personal email, phone number, or ID number into a task title, description, or comment.

A person’s name is personal data. A company’s name is not. The full rule lives in the Privacy & Data Handling Guideline.

Kiluth staff are the exception. The assignee and requester fields hold full @kiluth.com email addresses, never nicknames. That is deliberate: an email is unambiguous and survives someone changing what they are called.

Where a Task Lives

One task is one file. You do not need to know the file layout to write a good task, but it helps to know these three things.

## Chain
 
Blocks: [[PROJ-0031]]
Blocked by: [[2026-09-23T14-30-creative-bonsoir-uxui-hour-breakdown]]

The chain must be written as links in the body. The web view builds its dependency graph from links it finds in the text, so a chain recorded only in the header fields will not appear on the graph.

Reject a Task That Fails

If a task assigned to you fails any of these rules, do not start work on it. Ask for it to be fixed first.

This is an expectation, not an option. Accepting a bad task moves the cost rather than removing it: you spend time guessing, the reviewer cannot judge the result, and the same unclear task gets written again next week because nobody said anything.

Rejecting is not a complaint. Say which rule the task misses and what would fix it.

How Tasks Get Checked

Tasks are checked two ways, against the same rules.

The checker applies this guideline. It does not define it — when the convention here changes, the checker follows.

The result

The checker writes its verdict into the task’s hygiene field:

hygiene: pass means the task is written correctly. It does not mean the work is finished. Completion is moving the file to tasks/done/.

Changed from Asana. The old system put [✅] and [❌] at the front of the title, which mixed a quality check into the task’s name and made titles harder to read. The verdict is now a field instead. Do not put status markers in titles.

Checklist (Before You Assign a Task)

Related