Issues

Issues are the unit of work. Every task, bug or improvement lives as an issue with a unique identifier, a status and an assignee, which can be a person or an agent.

What it is

An issue holds everything needed to take a piece of work from start to finish:

• Identifier like DRAPPS-123: not free text: it’s the team key (DRAPPS) plus a number that increments per team. It’s stable and lets you reference the issue from branches, PRs or comments.
• Title and description (markdown).
• Priority and estimate (story points, which feed velocity).
• Workflow status (see Workflow states).
• Assignee, creator and project (every issue lives in a project; see Projects).
• Optional cycle and milestone, for planning.
• Dates: start, target and due (deadline).

Sub-issues and relations

• Sub-issues: an issue can hang off another (parent/child) to break big work into pieces.
• Blocking relations: an issue can block or be blocked by another, so execution order is explicit.

States and flow

Status isn’t fixed text: it’s a workflow state defined per team, classified by category (backlog, in progress, done, canceled…). The app records transitions with timestamps (when it started, when it completed, when it was canceled) and uses the completion one to close metrics like velocity and cycle time (see Insights).

Agent context

What makes Hilbana’s issues different is that they’re built so an agent can pick them up and execute them without rediscovering context every time:

• Agent context (agentContext): markdown notes with the relevant files, the verify command, the definition of done and any useful pointers. Both the UI and the MCP read and write it.
• Definition of Ready (DoR): two structured, machine-verifiable fields, definition of done (acceptance criteria) and verify command (e.g. pnpm build or the tests), that let the system decide whether an issue is ready for an agent.
• Claim / release: when an agent starts working an issue, it claims it (marked as “in progress by an agent”, with who and since when). It’s a soft lock so two agents don’t collide; when done, it releases it. Not to be confused with the assignee: the claim means “I’m touching this right now”.

How to use it

1. Create the issue with a clear title and its description.
2. Fill in its Definition of Ready (definition of done + verify command) if you want an agent to be able to pick it up.
3. Assign it to a person or an agent, and place it in its project (and cycle, if any).
4. Move it through states as it progresses; the app records the transitions.

See also Workflow states, Cycles and Agents.