How-to guides

Where tasks come from

A task is a unit of work — a feature, a bug, a change — that DIJJI.ai can run. Most tasks arrive from your project’s connected GitHub repository: the issue you’d write anyway is the task. (You can also create tasks from a Request, which breaks an idea into work items and saves them as tasks — this page is about the issue-sourced kind.) This page explains what makes an issue become a task, what keeps it in sync, and how to read the Tasks page.

For what tasks and runs are, see Projects, tasks, and runs.

There is no Sync button

DIJJI.ai watches your connected repository for you. When an issue qualifies, it appears on the Tasks page on its own, usually within seconds. There’s no manual sync step and no Sync button anywhere in the UI — if you’re looking for one, you’re looking for something that doesn’t exist.

Label an issue with dijji

Not every issue becomes a task. DIJJI.ai only picks up issues that carry the dijji label.

This keeps your repository’s issue tracker and your DIJJI.ai task list separate by default — bug reports, discussion threads, and planning issues stay out of DIJJI.ai unless you opt them in.

To turn an issue into a task, add the dijji label to it in GitHub. The label match is case-insensitive, so dijji, Dijji, and DIJJI all work. An issue with no dijji label is ignored, however it’s worded.

How an issue becomes a task

An issue is picked up when any of these happen in GitHub:

  • You open a new issue that already has the dijji label.
  • You add the dijji label to an issue that didn’t have it before.
  • You edit an issue that already carries the label.

In each case a task appears on the Tasks page shortly after. Adding the label to an old, long-closed issue works the same way — the label is what counts, not when the issue was filed.

Editing an issue keeps the task in sync

After a task exists, editing the source issue in GitHub updates the task. Change the issue’s title, description, or priority, and the task picks up the change — it doesn’t create a duplicate.

This works the other way too: the task is a mirror of the issue, not a copy you maintain separately. Edit the issue in GitHub; the task follows.

Closing or deleting an issue leaves the task alone

Closing the source issue in GitHub does not remove or stop its task. The same is true if you delete the issue entirely — the task stays on the Tasks page, with its run history intact, and can still be run or re-run.

Tasks and issues are linked at creation, but a task’s life isn’t tied to the issue’s state afterward. If you want to stop a task, act on the task itself — see the run controls in the run states documentation.

Find your tasks

Open your project and go to Deliver > Tasks.

Each task on the list shows:

  • Title — the issue’s title, linking through to the task’s own page.
  • Issue reference — the source issue number, for example #123, linking back to the issue in GitHub.
  • Status — where the task stands: Pending, Queued, Running, Completed, Failed, Cancelled, or Archived. A fresh task reads Pending — synced, not yet run.
  • Priority — if the issue set one: Highest, High, Medium, Low, or Lowest.
  • Run number — once the task has been run, which run is current, for example Run #2.
  • Last updated — how long ago the task changed.

You can see the list two ways using the view switcher: Board (the default) lays tasks out as a five-column flow, and List shows one status at a time. The Board groups tasks across columns at a glance; the List has filter tabs to pick a single status, a search box that matches a task’s title or issue key, and pages of 20. Your choice of view is remembered the next time you open a project’s Tasks page. See Switch task views for both views in full.

A project works on one run at a time. A task you start while the project is busy doesn’t get turned away — it waits in a queue that runs tasks one after another, shown in a Queue panel above the list. See The task queue for how it works.

If no tasks have arrived yet, the List view shows an empty state — No tasks found, with a line naming the status you’re filtered to, for example:

No tasks with status “Pending”.

If you see this, the fix is almost always the label: open an issue in your connected repository, add the dijji label, and it appears here shortly after.

If the project uses Jira

A project set up with Jira as its PM tool works the same way, with one difference: tasks come from issues in a Jira project, and only issues that carry the dijji label sync. Add the label on the Jira side and the issue appears as a task in DIJJI.ai shortly after; remove it and it stops syncing. See Connect Jira for the label convention and the connection setup.

What’s next

Once a task is on the list, the next step is to run it — see Execute a task. Run your first task walks through picking a task and starting a run, and Run states covers what a run does once it’s underway.