Prompts

A catalogue of copy-paste prompts for an agent connected to Hilbana over MCP: start a project, plan an epic, pull from the queue, review and more.

These are the prompts we use ourselves. Copy one, fill in the blanks and paste it into an agent with the Hilbana MCP connected. Each one runs a complete workflow against your workspace: they are not toy examples.

Replace anything in square brackets before you send it. Variable data always looks the same ([project name], [stack], [goal in one sentence], [DRAPPS-N]) so you can spot it at a glance. DRAPPS-N is an issue identifier: the prefix is your team’s, the number is the issue’s.

If you use Claude Code, install the plugin first. Most of these flows ship as commands (/hilbana-plan, /hilbana-claim-next, /hilbana-review, /hilbana-crear-docs), and they also bring per-project memory and token accounting. The raw text is here for anyone on a different agent, or without the plugin.

One note on the endpoint: if you self-host, replace https://app.hilbana.com/mcp with https://<your-host>/mcp.

1. Start a project

What for: going from “I have an idea and a repo” to a project with context docs and a first batch of executable issues, without writing any of it by hand.

Tools: save_project, save_doc, save_issue, list_workflow_states.

You are going to set up a new project in Hilbana using the MCP tools. Don't ask me
anything you can work out by reading the repository.

Project: [project name]
Goal in one sentence: [goal in one sentence]
Stack: [stack]
Repository: [local path or repo URL]

Do it in this order:

1. Create the project with save_project, with a three or four line description that
   says who it's for and what problem it solves.
2. Create three documents with save_doc in that project:
   - "Vision and scope": the problem, who it serves, what's out of scope.
   - "Architecture and stack": how it's put together, where it deploys, which
     technical decisions are already made and why.
   - "Conventions": code style, branches, commits, review criteria.
   Get it from the repository (README, CLAUDE.md, config, code). If something is
   missing and matters, write it as an open question at the end of the document.
   Don't make it up.
3. Create 5 to 8 issues with save_issue for the first stretch of work. Each one with
   description, agentContext (files to touch and the context needed),
   definitionOfDone and verifyCommand. Set agentReady=true only on the ones that
   don't depend on another.
4. Give me a table of what you created: identifier, title, and whether it's agent
   ready.

What to expect: the project created with its three documents and a first batch of issues with a filled-in Definition of Ready. Review them before you let an agent pick them up: a weak definitionOfDone gets paid for later.

2. Turn an idea into an epic

With the plugin: /hilbana-plan

What for: breaking a large goal into a graph of sub-issues, with dependencies declared and the frontier queued.

Tools: save_issue (with parentId), link_issues, list_projects.

Turn this goal into an epic with sub-issues in Hilbana.

Goal: [goal in one sentence]
Project: [project name]
Constraints: [deadlines, external dependencies, what NOT to touch]

1. Create the parent issue with the goal, the scope and what's out of scope.
2. Split it into sub-issues (parentId) small enough for an agent to close in one
   sitting. Each with a verifiable definitionOfDone and a real verifyCommand: a
   command that can be run, not "check by hand".
3. Declare dependencies with link_issues (blocks / blocked_by). Don't invent
   dependencies that don't exist: whatever can run in parallel, runs in parallel.
4. Set agentReady=true ONLY on the ones that aren't blocked by anything.
5. Show me the resulting graph and tell me which ones start now.

What to expect: an epic with its children and only the first wave in the queue. The rest get queued as their blockers close.

3. Document this repo in Hilbana

With the plugin: /hilbana-crear-docs

What for: moving the context that today lives in someone’s head (or in a CLAUDE.md) into the project docs, which is what agents read when they start.

Tools: list_projects, list_docs, get_doc, save_doc.

Document this repository in its Hilbana project.

Project: [project name]

1. Read the repo: README, CLAUDE.md, config files, scripts, folder structure.
2. Check with list_docs which documents already exist. Update the stale ones instead
   of creating duplicates.
3. End up with at least: vision and scope, architecture and deployment, code
   conventions, and how it's tested and shipped.
4. Only write what you can verify in the code. Anything that's an assumption goes in
   a final "To confirm" section, kept apart from the rest.
5. When you're done, tell me what you created, what you updated and what questions
   are left.

What to expect: documents that match what’s actually in the repo, plus a short list of open questions for you. Mind the date: docs age, and a document that claims the opposite of what the code does is worse than no document.

4. What should I do today?

What for: a plan for the day taken from the real issues, not from memory.

Tools: list_issues, search_issues, list_members, list_cycles.

Build my plan for today from what I have in Hilbana.

Person: [your name or email in the workspace]
Time available: [hours]

1. Pull my open issues with their priority, due date and state.
2. Sort them by what's burning: overdue first, then due today or tomorrow, then
   priority.
3. Propose a plan that fits the time available. Say explicitly what does NOT fit and
   why.
4. Flag the ones blocked on someone else: that isn't my work, it's a reminder I have
   to send.
5. Format: a short list. No paragraphs.

What to expect: a prioritised list and, more often than not, a couple of surprises: overdue issues you thought were done, or blockers that have been sitting for days.

5. Take the next task and do it

With the plugin: /hilbana-claim-next and /hilbana-finish

What for: the full cycle in pull mode. The tracker is the queue; the agent pulls from it.

Tools: next_ready_issue, get_issue, change_issue_state, add_comment, record_run, release_issue.

Take the next task from the Hilbana queue and see it through.

1. next_ready_issue to claim it. If it returns null, tell me and stop: don't go
   looking for work on your own.
2. Read its description, its agentContext and its definitionOfDone before touching
   code. If the Definition of Ready is incomplete or the statement is ambiguous,
   do NOT improvise: comment on the issue saying what's missing, release it and stop.
3. Move it to "In Progress" with change_issue_state and work on it.
4. Run the verifyCommand. If it fails, fix it. If you can't, comment explaining why.
5. When you're done: record_run with the result and the commit or PR, a comment
   summarising it for the reviewer, the issue to "In Review", and release_issue.

Rule you don't get to skip: do NOT close the issue as "Done". That's the reviewer's
call.

What to expect: the issue sitting in In Review, with its commit recorded and enough of a trail for someone else to judge it. The working framework explains why the worker doesn’t approve their own work.

6. Review what’s in review

With the plugin: /hilbana-review

What for: closing the loop the previous prompt opens, checking against the definitionOfDone rather than against a general impression.

Tools: list_issues, get_issue, list_comments, change_issue_state, add_comment.

Review what's in "In Review" in Hilbana.

Project: [project name]

For each issue:
1. Read its definitionOfDone and verifyCommand, and the run the worker recorded
   (commit or PR).
2. Check the work against the DoD point by point. Run the verifyCommand.
3. Decide:
   - It holds up: move it to "Done" with a short comment on what you validated.
   - It doesn't: send it back to "In Progress" with a comment saying WHAT is missing
     and HOW to check it. Not a bare "please review this".
4. If the DoD was badly written and that's why the work went sideways, say so: the
   problem is the issue, not the person who did it.

At the end, give me a summary: approved, sent back, and why.

What to expect: every issue moved with a written reason. The value is in the comments on the ones sent back: those are what prevent a second round.

7. Backlog hygiene

What for: sweeping up every few weeks. Backlogs don’t rot all at once.

Tools: list_issues, search_issues, get_issue, save_issue, link_issues, add_comment.

Run a hygiene pass over the Hilbana backlog.

Project: [project name]

Find me:
1. Duplicates or overlapping issues (compare titles AND descriptions, not just
   titles).
2. Issues with no definitionOfDone, or one that can't be verified.
3. Issues with no project, no assignee or no priority.
4. Stalled issues: no activity for [number] days.
5. Issues that no longer make sense because the product moved on.

Don't delete or close anything on your own. Give me a list by category with the
identifier, the title and what you propose for each. Where you see duplicates, tell
me which one you'd keep and why.

What to expect: a list you can decide on in ten minutes. The important rule is in the prompt: the agent proposes, you close.

8. Weekly status report

What for: telling someone who doesn’t live in the tracker what happened, without opening the tracker.

Tools: list_issues, list_cycles, list_milestones, get_issue.

Write the weekly report for this project, for people who don't use the tracker.

Project: [project name]
Period: last [number] days
Audience: [client, management, team]

Structure:
1. What shipped, one sentence each, in business language, not code.
2. What's in progress and when it's expected.
3. What's blocked, why, and who unblocks it.
4. Risks and decisions I need to make.

No issue identifiers in the body (put them in an appendix at the end), no technical
jargon and no sales adjectives. If nothing moved this week, say so.

What to expect: something you can send as is. The appendix with the identifiers is there for whoever wants to dig.

9. Bug to issue with root cause

What for: so a failure doesn’t stay at “it’s broken”. A bug issue without a reproduction is a ticket someone will have to investigate twice.

Tools: save_issue, search_issues, mem_save.

Turn this into a well-formed bug issue in Hilbana.

Project: [project name]
Symptom: [what you saw]
How to get there: [steps, if you know them]
Environment: [browser, version, environment]

1. Before creating it, use search_issues to check whether it's already reported. If
   it is, tell me and don't create another.
2. Investigate the root cause in the code. Don't stop at the symptom: tell me which
   line causes it and why it behaves that way.
3. Create the issue with save_issue: step-by-step reproduction, expected versus
   actual behaviour, root cause, the files involved in agentContext, a verifiable
   definitionOfDone and a verifyCommand (the test that fails today and has to pass
   tomorrow).
4. Save the root cause to project memory with mem_save (type: bug), so the next
   session doesn't investigate it from scratch.

What to expect: an issue someone else (or an agent) can pick up without asking you anything, plus a note in memory that outlives the session.

Adapting them to your team

None of these prompts is sacred. What’s worth keeping when you edit them:

The explicit blanks. A prompt that asks fifteen questions before starting is more tiring than filling in four brackets.
The order of the tools. Read first (get_issue, list_docs), write after. An agent that writes before reading duplicates.
The limits. “Don’t close as Done”, “don’t delete anything”, “if context is missing, stop and comment”. Those are the lines that prevent silent disasters.