Working method

You can use a project tracker well or badly. This is the method we use ourselves to work with agents: every phase leaves its result inside Hilbana (docs, issues, comments), so the next phase, the next agent and the next person all start from the same place. Each phase has its prompt in the MCP and its shortcut in the Claude Code plugin.

The phases at a glance

Phase	What happens	Prompt (shortcut)	Where it lands
1. Decide	Settle the project’s decisions before writing anything	— (your own interview or meeting)	«Decisiones» doc
2. Specify	One spec per area, reviewed against the decisions	especificar (/hilbana:especificar)	«Spec · …» docs
3. Plan	From specs to issues with dependencies	/hilbana:plan	Issues linked to their spec
4. Build	Each issue, from the queue to review	claim_next, finish, review	Issues, closing comments
5. Audit	When a block closes, check it against the specs	auditar_bloque (/hilbana:auditar-bloque)	Comments and issues sent back
6. Follow	The morning report for whoever runs the project	estado_proyecto (/hilbana:estado-proyecto)	«Parte del proyecto» doc

1. Decide

Before specifying, decide the things that shape the project: what’s in and what’s out, how it behaves in the hard cases, what gets reused. Each decision is one line of the project’s «Decisiones» (Decisions) doc:

D-012 · 2026-10-13 · Ana · accepted · The catalogue reaches the website unfiltered · origin WEB-41

How you get there is up to you: an interview with an agent that keeps asking until each point is settled, a meeting, or a prior document. Hilbana doesn’t impose a technique: what matters is that they end up in the doc, because the next phases read it. If you already have your own method, put its output there. See Project decisions.

2. Specify

With the decisions made, the especificar prompt proposes the areas and writes one spec per area as a project doc (“Spec · Catalogue”, “Spec · Orders”…): goal, scope, behaviour with cases, rules, permissions and acceptance criteria you can check, each tied to the decision it comes from. A second review, by another agent if your client can launch one, checks them against the decisions and brings out gaps and contradictions. You approve them.

3. Plan

/hilbana:plan turns the specs into issues with dependencies. Each issue links its spec in the agent context, and its Definition of Done comes from that spec’s acceptance criteria, not from whatever comes to mind at the time. The ones that can start now land in the agent queue.

4. Build

Each person or agent takes work from the queue (claim_next), does it and closes it with finish: it verifies, leaves the issue in the status the workspace chose and writes a closing comment for the reviewer. If something gets decided while building that changes what was agreed, the comment ends with a «Decisiones:» section. Work goes in blocks (a parent issue or a milestone), one at a time or in parallel.

5. Audit by blocks

When a block closes, auditar_bloque checks each issue against its spec, its Definition of Done and the decisions, looks at the commit and grades the findings (blocking, major or minor). It offers to send back what doesn’t pass with an actionable comment; whoever had it assigned gets the “sent back to you” alert. An agent or a person can run it: it proposes and leaves a trail, and whoever asked decides.

6. Follow the project every morning

Whoever runs the project asks for the report with estado_proyecto: the figures from the Team tab (progress, pace, estimated end, who did what each day), what each issue left done, the period’s decisions checked against the doc (the ones that clash with something accepted are flagged) and what’s waiting for an answer. Decisions get accepted or rejected from there, and the report is saved in a doc so tomorrow’s one says what changed.

A real example

A websites project for the customers of a business software product, with two people coding and one running it:

• Decide: about two hundred decisions in the doc before the first spec, from a long interview with an agent.
• Specify: eight specs (instances, catalogue, templates, payments, orders…), each reviewed against the decisions.
• Plan: about three hundred issues in blocks per spec.
• Build: in the first week, 43 issues closed at 8.6 per working day, with the estimated end date visible from day one.
• Follow: every morning, before the meeting, whoever ran it already knew what was in review, what had gone back and which team decisions clashed with what was agreed, and settled them from the report itself.

Related: Prompts · Project team · Agents · Claude Code plugin.