Hule Docs

Appearance

The Hule model ​

Hule is one tree of work: a workspace holds folders, folders hold lists, and lists hold tasks. Views, sharing, statuses, relations and automations each attach to a place in that tree, whether you work alone or run a team.

Every task lives in exactly one list, and you decide what the tree above it looks like.

Once you know where a thing attaches to the tree, you know what it affects: sharing a folder covers every list and task inside it, and changing a status template changes the statuses of every list that uses it.

One home per task keeps its status, assignee and history in one place. When you need a task in several places, a view shows it there without copying it — see Views: the same tasks, another shape.

Model map: how the parts connect ​

flowchart TB
  MEM["Member"]
  PS["Permission set"]
  SH["Share: Read or Edit"]
  WS["Workspace"]
  F["Folder"]
  V["View"]
  AU["Automation"]
  STT["Status template"]
  L["List"]
  TAG["Tag"]
  T["Task"]
  ST["Subtask"]

  WS -- "has" --> MEM
  MEM -- "holds" --> PS
  MEM -- "gets a" --> SH
  WS -- "contains" --> F
  F -- "nests" --> F
  SH -- "opens a branch from" --> F
  F -- "contains" --> L
  V -- "shows tasks from" --> L
  AU -- "acts on tasks in" --> L
  STT -- "gives statuses to" --> L
  L -- "holds" --> T
  TAG -- "labels" --> T
  T -- "relates to" --> T
  T -- "breaks into" --> ST

Read each arrow as a sentence: "a folder contains a list", "a view shows tasks from a list". The map shows each part once; the sections below say where else it attaches — a list can sit at the top of the workspace, a share can open a list or a view, and views and automations can also cover a folder or the whole workspace.

Workspace, folders, lists and tasks ​

A workspace is the top of the tree: the people you work with and everything you share with them. You can belong to several workspaces — one for yourself, one for each team — and Hule lists them one under another in the sidebar's Workspaces section.

Inside a workspace, folders hold lists and other folders, and nest as deep as you need. A list sits in a folder or directly at the top of the workspace. A task always belongs to one list, and a subtask stays in its parent's list; subtasks nest as deep as tasks need. A small team's workspace might look like this:

text
🏢 Acme                               workspace
├── 📁 Product                        folder
│   ├── 📋 Roadmap                    list
│   └── 📁 Releases                   folder in a folder
│       └── 📋 2.4                    list
│           └── ✅ Ship the editor    task
│               └── ↳ Release notes   subtask
├── 📁 Marketing                      folder
│   └── 📋 Content plan               list
└── 📋 Inbox                          list at the top

Why a free tree rather than fixed levels: you can copy the way you already organize your work instead of bending it to the tool. More in Folders inside folders.

Lists: statuses, fields and tags ​

A list decides how its tasks look. It takes its statuses from a status template, and each status sits in one of three stages — Not started, Active or Done — so Hule can tell open work from finished work in any list. A list also chooses which task fields it uses and which features are on. Tags live either in a workspace tag set, which any list can attach, or in a single list, and you add them to tasks to cut across the tree. More in Statuses and status templates.

Views: the same tasks, another shape ​

A view shows tasks without owning them. It draws them from one or more sources — lists, folders or whole workspaces — and lays them out in one of eleven view types, compared in Views compared. Changing a task in a view changes the task itself, everywhere it appears.

A view can belong to a list, to a folder or the workspace, or to you alone. Your own views, under User Views in the sidebar, can gather tasks from all your workspaces at once, and one of them can open as your home page. More in Views as lenses on tasks and Personal and work tasks in one place.

Sharing: access flows down the tree ​

You share a folder, a list or a view with workspace members, with Read or Edit access. Access flows down: share a folder and the member sees every folder, list and view inside it. To keep one branch out of that flow, turn off Inherit access on it — it becomes Private: access stops flowing into it, and only people you share it with directly, the workspace owner and members whose permission sets let them see everything can open it. Access flows down because a branch usually belongs to one team or one area of work: share it once, and everything added to it later is shared too.

What a member may do across the workspace — create lists, manage sharing, change settings — comes from the permission sets they hold; the workspace owner always has full access. More in Sharing along the hierarchy.

Relations: tasks that know about each other ​

A relation is a typed link between two tasks, such as "blocks" or "relates to"; the types come from relation templates. Mentioning a task with # in a description or a comment adds a relation for you. The Relations view draws them as a graph, so you can see how the work connects across lists and folders. More in Task relations and the relations graph.

Automations, GTD and AI on top of the tree ​

  • Automations run in the whole workspace, in one folder or in one list: when something happens to a task there, they do the next step for you. More in Automations.
  • GTD uses the same pieces: your Inbox list is an ordinary list you pick on your GTD settings page, once for each workspace you belong to. The New Task form opens on it when you start a task outside any list, or every time if New task there is set to Always. A GTD view whose source is that list runs a session that takes you through its tasks one at a time. More in GTD in Hule.
  • An AI agent connected through MCP works with the same workspaces, lists and tasks, signed in as you. More in Hule and AI.

Next steps: guides and reference ​